[futurebasic] Re: [FB] Another string resource problem

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : May 2009 : Group Archive : Group : All Groups

From: Brian Stevens <bstevens33@...>
Date: Tue, 26 May 2009 11:15:12 -0700
On May 26, 2009, at 2:55 AM, Joe Lertola wrote:

> Thanks for your comments and thanks for the back channel screen  
> shot. It does not tell me much though.
The only point was to highlight the extra file size. Other methods for  
saving strings ( CFIndex ) do not have this overhead.


> I hesitate to suggest this but could this be a bug in FB or FBtoC?
What bug?

> The code is not working for me because I can no longer count on  
> getting the correct number of strings saved in a string resource.
I thought it worked with the swaps? Please describe or show the code  
that fails.


>
>
> -Joe
>
> On May 25, 2009, at 7:52 PM, Brian Stevens wrote:
>
>> Joe,
>>
>> I ran your code to create the resource file with the same results.  
>> Yes, big endian puts the most significant ( i.e. the byte with the  
>> higher bit values such as 32,768, 16,384, 8192, 4096 etc. ) byte  
>> ( only in multi-byte vars of course ) first. Since the "03" is in  
>> the least significant byte ( coded in the 2 and 1 bits ), it would  
>> be stored last on big-endian. The Apple Resource Manager is smart  
>> and handles endian issues for standard resources, so it looks like  
>> the 2 byte count var in your 'tempList' resource is stored as  
>> little endian on disk.
>> In any event, the code is working. Be careful using FB resource  
>> calls. Some such as DEF APNDSTR have been tweaked to do byte  
>> swapping but others may not. BTW: I'm sending a screen  
>> print( backchannel ) showing the resource file in HexEdit so you  
>> can see what else is in this file. There is ( presumably ) overhead  
>> in the first hex 103 bytes of this file. Your string data starts at  
>> hex offset 103. These don't show up in Rezilla because it  
>> "understands" resources.
>>
>> On May 25, 2009, at 2:46 PM, Joe Lertola wrote:
>>
>>> OK, I just looked it says: "Standard system-defined resource types  
>>> (e.g. STR#, moov, MENU) are big-endian on disk."
>>>
>>> However when I run my demo the string resource looks like it is  
>>> being save in little_endian format, not big_endian. Look at this  
>>> Rezilla screen shot:
>>>
>>> http://www.joelertola.com/temp/res_prob.jpg
>>>
>>> There is a 3 in the first byte and a zero in the second byte.  
>>> Big_endian should be the opposite I think.
>>>
>>> -Joe
>>>
>>>
>>> On May 25, 2009, at 5:13 PM, Brian Stevens wrote:
>>>
>>>>
>>>> On May 25, 2009, at 10:14 AM, Joe Lertola wrote:
>>>>
>>>>> Yes, I see that fixes it in this case. But doesn't it seem like  
>>>>> there is a problem in the string resource if the byte order has  
>>>>> to be swithched to big enden when running on an intel chip?
>>>>
>>>> Joe - look at "byte order on disk: resources" in the FBtoC Help  
>>>> in the section on Byte Order.
>>>>
>>>> Brian S
>>>>
>>>> --
>>>> To unsubscribe, send ANY message to: futurebasic-unsubscribe@...
>>>>
>>>
>>>
>>> =
>>> --
>>> To unsubscribe, send ANY message to: futurebasic- 
>>> unsubscribe@associate=
>>> .com
>>>
>>> =
>>
>> --
>> To unsubscribe, send ANY message to: futurebasic-unsubscribe@...
>>
>
> --
> To unsubscribe, send ANY message to: futurebasic-unsubscribe@...
>