BJ> what are you using in your code for dealing with

 BJ> (a) big vs little endian for data that needs to be 
 BJ> stored or transfered
 BJ> that currently is being done in a binary format, and

 BJ> (b) packing of data structures for binary reading / writing in a
 BJ> portable way?

 WM> The key is defining everything in terms of arrays of 
 WM> unsigned chars. Mostly
 WM> that means that a "long" becomes an array of four 
 WM> chars, a "short" an array
 WM> of two. This wasn't my idea, BTW -- credit goes to George Hatchew, who
 WM> included this scheme for the benefit of big-endian systems in later
 WM> revisions of bluewave.h (included in the MultiMail source or the Blue Wave
 WM> specs, if you want to see it). 
 ...

Thanks for the response.  Yes, that is one way to handle it.

I'll need to give it some more thought.    I've had some variations on the
theme that I want to consider before implementing changes.  Because the Max
/ Squish code comes from a DOS / OS/2 / Win32 side of things, the default
will end up little endian on the Maximus code....  I've been leaning
towards making the conversion in the routine that reads (or writes) the
data....  Since I expect to only run into two's complement machines now,
integer data can easily be handled as you suggest, maybe even with a union
on the structures.....  Basically, I want to leave in backward
compatibility along with conversion options for going forward...  I don't
think there is any floating point data in the binary structures, but we'll
need to check as we go through things.

[Yes, I have progammed on a one's compliment machine.  The old CDC 6000
series / Cyber 70 & 170 series machines were one's compliment
arithmatic...  Are current Cray machines two's complement machines?]

Again, thanks for the response.  Things like this I don't like to rush off
and code without thinking through options.

I'll  post some ideas later, when I have the time.

Take care.....

Bob Jones, 1:343/41


--- Maximus/UNIX 3.03b