I generate binary text file (in Windows using Dev-C++) Is the generated binary file using BigEndian? Are there any method to generate binary file using LittleEndian? Because I want the generated binary file to be used in Palm, is it necessary to do so ? thanks!
As someone mentioned, Windows probably defaults to "Little-Endian". It's how Intel CPUs work. The Palm would probably expect "Big-Endian" as Palms used Motorola CPUs and that's how they work. You probably want to ask about this on a Palm Forum. It could be that you might be able to write a Palm Conduit to flip the data bytes around.
It's almost impossible to answer your question as-is, because there is no such thing as a "binary text file". A file can be created in binary mode, or in text mode, which affects the way line ends and potentially the EOF character are handled. A "binary text file" is a self-contradiction in that context.
Hans-Bernhard Broeker (firstname.lastname@example.org)
Even if all the snow were burnt, ashes would remain.
We do a similiar process quite often. The idea is that somewhere along the line you are going to need to swap the bytes in the data stream around.
It's arbitrary to decided if it's done on the PC side or the handheld side. Applications I'm involved with usually involve mobile communications to a desktop machine runing a server, so we've arbitrarly decided to do it on the PC side. This offloads the PDA from having to byteswap all incomming and outgoing data, however it's became more arbitrary to us because we now support various other PDA platforms with "the other endian".
Have a look at the functions ntohl(...) and ntohs(...) on the PC side.
On the Palm equivalent functions are part of NetLib and have the names NetNtoHL(...), NetNtoHS(...), NetHtoNL(...) and NetHtoNS(...).
Depending upon your Palm programming environment, your standard C library might provide wrapper functions/macros so that you can call NetNtoHL(...) via it's more traditional name ntohl(...).
The choice of where the conversion is done will also depend on the excate method you intend to use to access this file from the Palm device. For example if you are planning to place it on a memory card and use the VFS library to access it, it might pay to keep it in Little Endian if there is also the chance that the file could be used unmodified by a desktop application.
Answer to 1: It's configurable by tying up (or down) a pin.
For 2 and 3: Only an engineer who went to high school in the U.S. and forced to read Gulliver's Travels would readily identify that the Lilliputians (or was it the Brobdingans (sp?) would break their egs at the big end or little end!
IIRC, the egg endian wars were internal rebellions (the emperor declared everyone should break the big end after his son cut his finger breaking the little end, but people resented the order, especially since breaking the little end was traditional). The (neighboring?) realm of Blefescu fomented the rebellions in hopes of gaining some advantage (taking over Lilliput?).
Endianness doesnt apply to a file full of bytes. Now if its a file full of 2 byte words or 4 byte longs, it would be nice to know if they were hi byte first or lo byte first. Hi byte first is called 'network order'. Thats how stuff gets sent over networks. Thats a fairly good standard to follow.
BobGardner wrote: : Endianness doesnt apply to a file full of bytes. Now if its a file full of 2 : byte words or 4 byte longs, it would be nice to know if they were hi byte first : or lo byte first. Hi byte first is called 'network order'. Thats how stuff gets : sent over networks. Thats a fairly good standard to follow.
You all talk about endianness from a SW point of view. That is fine per se, as it is in SW that endianness mismatch will have to be fixed anyway. But it is helpful to understand what really goes on from a HW point of view. I have written up a one-page on this isse:
Look at it and tell me what you think. But the point I want to drive home is that Big and Little endian achitectures connected to the same local bus will see exactly the same data in the full natural word width on both sides. The endianness problem only arises when the datasize is smaller than the cores' natural bus width. Or data is somehow transported between them.
It is this dependancy of endianness on actual data width that makes it so hard (impossible) to design HW byte-lane switchers in eg. PCI bridges. A endianness switching scatter-gather DMA transfer breaks down once there is a _mixture_ of data widths in the data block.
(BTW, the one-sheet also mention PowerPC as Big Endian. While this is [usually] true, PPC also has reversed bit notation wich makes comparison difficult.)
Never ever underestimate the power of human stupidity.