Robert,

Excellent fix.

Sorry to stir up such a hornet's nest.

With the new patch to apndstr, resources that I created using FB4 are now compatible with FB5 created resources. (and ResFool is happy now). Yea!

Rich


On Dec 12, 2010, at 8:49 PM, Robert Purves wrote:

> 
> Deep wrote:
> 
>> I am seeing the same problem as Rich and can reproduce the issue.
>> 
>> As far as I can tell, his demo source and the runtime are both behaving
>> correctly as expected.
>> The resulting resource file physically writes the first two bytes as "00 03"
>> on PPC, and wrongly amends to "03 00" on Intel. This is not a bug on ResFool
>> Rezilla, or other Resource readers as they all behaved the same in my tests.
>> Also used HexEdit to physically check the bytes in the resulting Resource
>> file(s).
> 
> I confirm your HexEdit results. Something is indeed wrong.
> 
> When I use Rezilla to open the Intel-created file MyTestRezFile.rsrc, it doesn't complain about the file. Moreover, it shows the number of strings as 3, although the two bytes on disk specify 768. Apparently Rezilla counts the number of strings directly and thus ignores those 2 bytes. Rezilla is therefore worse than useless as a tool for examining the STR# bug. It certainly misled me.
> 
> 
>> it almost looks like "AddResource" realises the resource is originating on an Intel Mac, is a type "STR" resource, and chooses to swap the byte order trying to be helpful?
> 
> I think you're right. AddResource() takes the two bytes to be native-endian in memory and automatically swaps on Intel when saving the resource to disk.
> 
> Equally helpfully, GetResource( _"STR#", resID ) automatically swaps on Intel when loading so that the bytes are native-endian in memory. 
> The Resource Manager knows that the two bytes form an integer value, from the resource definition of STR#:
> 
> /*---STR# • Pascal-Style String List----*/
> type 'STR#' {
>        integer = $$Countof(StringArray);
>        array StringArray {
>                pstring; /* String */
>        };
> };
> 
> 
> The bug is in the FB5 runtime function apndstr(), which byte-swaps but should not.
> The fix will be in the next release. If you want to try it in the current release, see below. 
> 
> Note that after that runtime fix, byte-swapping the count field of a STR# resource Handle will no longer be required (i.e. will give the wrong answer on Intel). 
> Any projects that (1) use apndstr and (2) swap the count field will need changing. For example, in Rick's posted demo:
> 
> //theCount = fn CFSwapInt16BigToHost( rH..0% )
> theCount = rH..0%
> 
> //count = fn CFSwapInt16BigToHost( strHndl..0% )
> count = strHndl..0%
> 
> Robert P.
> 
> 
> To make the fix in the current FB5 release, open the Headers file Subs DefUsr.incl, locate the apndstr() function, comment it out, then paste in this version:
> 
> '----------
> local fn apndstr( t$, h as Handle )
> '~'
> dim as long oldSize
> long if h
> oldSize = fn GetHandleSize( h )
> SetHandleSize( h, oldSize + t$[0] + 1 )
> long if ( fn MemError == _noErr )
> BlockMoveData( @t$, [h] + oldSize&, t$[0] + 1 )
> h..nil% += 1
> xelse
> t$ = "Failed to append "" + t$ + "" to STR# handle."
> shutdown t$
> end if
> end if
> end fn
> '----------
> 
> --
> To unsubscribe, send ANY message to: futurebasic-unsubscribe@...
>