Dear Users,
How do I account for endian-ness while reading a Binary File generated from Solaris 5.8 (Sparc) on a Windows XP (x86) system. I just know that its a Binary File. I have no knowledge about the native datatype of the Binary File.

IF the file came from tape or other media created on a Solaris machine, then it is big endian.

If you (s)ftp'ed the file to Windows then you can read it on Windows. Windows is little endian and so is the file.

Otherwise you will have to convert the file, search the forums for 'change endianness of file'

Hi,
Thanks for the reply.
This file comes in an encapsulated form from some other Unix machine over the network and then the Target OS i.e. Solaris 5.8 reads and extracts the relevant part from the encapsulation as a Binary and writes & saves in a file on the Hard Disk. This saved file is the input binary file for me which I took in a USB or through FTP.

So, how do I interpret the endian-ness here ?

A file endianness as not that much to do with OS endianness. That's the file format that matters so if you have no idea about it, why bother ?
Windows on x86 can certainly create big endian files if the binary format mandates it just like Solaris on SPARC will create binary files with little endian data inside. Any combination of big and little endian can be found in the binary files, just like binary files flowing the internet can be little, big or a mixture of these indianness.

Ok. I agree.
But, the problem is the Unix C Code which parses this Binary File is not working on the WIN32 platform although it is compiling successfully on VS-2005. It starts parsing from the file's base address and tries to read data at particular Hardcoded Offsets from the base & these memory locations return garbage value on Windows. Hence, the question of endian-ness arose.

Any thoughts on this behavior ?

Not only the data would be garbage but also the offset if not hardcoded.

You didn't tell you had the parser source code. In that case, you need to modify that code for it to be able to correctly parse the data. You can use the htonl family of macros on the x86 machine to convert from network (big endian) to host (little endian) order.

I used a HEX Editor and converted the binary file to BIG-endian format. And, then I ran the same parser code. It still returns garbage

So, keeping the original Binary File intact, while reading, how do I judge the native datatype for byte swapping order - because these n/w apis suggest something like this -

ntohs() - “network to host short”
Converts the unsigned short integer netshort from network byte order to host byte order.
ntohl() - “network to host long”
Converts the unsigned integer netlong from network byte order to host byte order.