If we only use creator ID and type as UInt32, it should be portable. Some
people get use to the the way like 'myCR' because it is easy to use and it
happen to look like a string ordered in the same way as big endian order on
m68k.
My hope is PalmOS may include a smaller macro in the SDK and encourage people
to use it. It is nothing fancy, just like the one defined below, so people can
avoid converting ascii to hex and using "0x6d794352". "CREATOR('m', 'y', 'C',
'R')" seems much easier!
The compatbility only breaks when people want to display the creator or type,
which most joe users will never need to do.
Max
--- Keith Rollin <[EMAIL PROTECTED]> wrote:
> I think I see what you're saying. Correct me if I'm wrong, but
> you're saying that since the value of multi-character literals is
> implementation defined, that 'myCR' should evaluate to 0x6d794352
> when using a Big Endian compiler, but 0x5243796d when using a Little
> Endian compiler?
>
> An intriguing notion, but I'm not sure it will solve all problems and
> not cause others. For instance, the OS is pretty much going to be
> working with native endianness. That means that if you call
> DmCreateDatabase, the OS will create the database with the given
> creator and type values, and will not swap them to Big Endian format.
> Similarly with resource types.
>
> Also, consider developers who take a different approach in trying to
> remain portable. For instance, some developers may hardcode their
> creator type with something like:
>
> #define kMyCreator 0x6d794352 // 'myCR'
>
> Others may use a macro to help:
>
> #define FOUR_CHAR_CODE(a, b, c, d) \
> (((unsigned long) ((unsigned char) (a))) << 24) \
> | (((unsigned long) ((unsigned char) (b))) << 16) \
> | (((unsigned long) ((unsigned char) (c))) << 8) \
> | (((unsigned long) ((unsigned char) (d))) << 0)
>
> #define kMyCreator FOUR_CHAR_CODE('m', 'y', 'C', 'R')
>
> In either of these cases, *they* would break.
>
> I think it all comes down to what the actual definition of what a
> creator ID, database type, or resource type is. If it's a
> non-terminated 4-character string, then your WinDrawChars example
> should continue to work. If it's a 32-bit scalar, then your example
> should break. And I think the OS generally considers it to be the
> latter (since it's defined as a UInt32 and not a char[4]). In either
> case, using multi-character literals is compiler implementation
> defined and not portable. But you can probably expect it to be
> defined to be something that causes the lest amount of havoc.
>
> -- Keith
>
>
> At 2:38 PM +1100 1/7/02, Michael Glickman wrote:
> >Sorry, Keith, but is the first (and hopefully the last) time I have to
> >disagree with you.
> >
__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
