At 09:03 AM 1/19/2007, you wrote:
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?
I appreciate any wisdom you have to offer ;)
Personally, I advise you to do all this yourself and don't rely on
the .LittleEndian parameter. Not that it's buggy, or inefficient, but
you lose control because you are letting something else handle this
for you. It also makes your code less readable.
Take for example you are reading an AIFF file. That's Motorola by
definition. If you are reading your code, you see that you are
reading .Short() and .Long(), but how sure are you that the
.LittleEndian property was set correctly, where it was set, and if it
was set right per platform?
AIFF's are ALWAYS Motorola, that's constant. So you need to read them
in a constant way, like a explicit function that reads BigEndian data.
So, when it comes to binary data, I treat EVERYTHING as raw bytes, as
it should. Binary data should as a strict rule declare what endian it
is, if it's using any datatype larger then 1 byte.
So, 1) find out what endian the binary data is, then 2) use your own
functions to read the data. I use the following self-written functions:
GetFourIntel(memoryblock, location)
GetFourMotorola(memoryblock, location)
GetFourAny(memoryblock, location, byteorder) // which routes to the
above two functions
GetTwoIntel(memoryblock, location)
GetTwoMotorola(memoryblock, location)
GetTwoAny(memoryblock, location, byteorder) // which routes to the
above two functions
... etc. etc. for Float and Double and 24-bit numbers, etc.
These function effectively wrap the #if TargetX86 conditional
declares necessary to read things properly regardless of platform.
Your code shouldn't be littered with #ifdefs, which is what happens
if you choose the .LittleEndian() method approach on a "case-by-case" basis.
I like this approach because my code becomes self-documenting.
* * * * * * * * * * * * * * * * * * * * * * * * * * *
| Garth Hjelte |
| Customer Service Representative, President |
| Chicken Systems, Inc, Rubber Chicken Software Co. |
| 714 5th Street SE |
| Willmar, MN 56201 USA |
| |
| 800-8-PRO-EPS Toll Free Order Line (US Only) |
| 320-235-9798 Tech Support, Sampler Questions |
| International Line |
| 360-838-7689 Fax |
| Product Sales: [EMAIL PROTECTED] |
| Product Support: [EMAIL PROTECTED] |
| Sampler Q+A: [EMAIL PROTECTED] |
| Web Page: www.chickensys.com |
* * * * * * * * * * * * * * * * * * * * * * * * * * *
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
