From: "Peter K. Stys" <[EMAIL PROTECTED]>
Date: Fri, 16 Feb 2007 10:44:21 -0500
On 1/19/07, Jonathan Johnson <[EMAIL PROTECTED]> wrote:
On Jan 19, 2007, at 7:03 AM, James Sentman wrote:
Hi Folks,
I finally upgraded my RB IDE to begin building universal versions
of things and I'm running into issues with memory blocks and endian
problems. Specifically for data that was stored in binary files
and for binary network protocols between a PPC and an Intel
Macintosh.
I can get some things to work by simply setting the littleendian
property of the memory blocks I use to build the packets to false
on the Intel build. But that doesn't seem to solve all the
problems. What other things are affected by endianness? String set
via the stringvalue command in a memory block seem to be
unaffected. Are there some things that aren't set properly by
simply setting the littleendian property to false?
Because strings are treated as binary data, REALbasic does not know
how to swap strings when assigning them to memoryblocks. If you're
using UTF-16 strings, this could be a problem because the strings
need to know what endinanness they are, and may require manual
swapping.
The items that need to be swapped are all the integer types. The
MemoryBlock will automatically swap these values for you, if you
properly set the LittleEndian flag. Any strings that need to be dealt
with are up to you to let REALbasic know what encoding they are.
HTH,
Jon
I too have run into this problem with my new UB builds (I use custom
plugins that write to memblocks complicating even further).
The obvious solution is to set m.LittleEndian = false to mimic
PPC-style endianness on all platforms. Is this the "correct" way of
dealing with endianness? Importantly, is there a performance hit when
running on Intel and having PPC-style bigendian memblocks
(byte-swapping)?
What about files (eg. memblocks dumped to a binary file) written to
disk from a PPC version of my app then read in on an Intel version?
what about a PPC version running under Rosetta on Intel?
Why the heck did Intel and Motorola/Apple/IBM not decide on the same
endianness 30 years ago for crying out loud?
This is becoming a nightmare.
Why not just process your strings as UTF-8? Reading and writing UTF-8
has no encoding problem.
You only need UTF-16 for reading and writing to files that must be
UTF-16.
For writing it's simple, you just convert to UTF-16, and it's the
correct one for your platform.
For reading, it's a bit more complex as the endian may not be the
correct one for your platform. ElfData can help you here, it will
automatically detect the correct encoding for you, assuming the first
4 characters of your text is ascii, as is the case for XML. Or if
you've written a BOM, then ElfData will detect that. ElfData will
convert for you also. Just do this:
dim e as ElfData
e = s // s is a string
e.EncodingXMLGuess // can detect your encoding if it is XML or the
first 4 characters are ASCII!!!
s = e.ConvertToUTF8
A BOM is some official Unicode "mark" to signify what encoding you
are using.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
