15 replies to this topic

[PAUL1966]

Hi!

Here is a question i started to think about when i recently started my latest project. I have not got any answer to my question yet,
so i hope that someone here might help me.

Declarations such as WORD, DWORD, UINT and LONG are as far as i know platform dependant. That is, the number of memory bytes they allocate can differ from computer to computer platform.

Now, according to the specification of a bitmap file the BITMAPFILEHEADER consist of :
UINT bfTYPE;
DWORD bfSize
and some other variables.

As the bitmap file consist of variables that are platform dependant this should then mean that the size of the bitmap file can vary between different platforms.

But as far as i know bitmap files are platform independant!!!

How is this?

//Paul

[v0id]

Datatypes does not depend on the platform/operating system, but on the architecture of the processor. The names for the datatypes you see in the BITMAPFILEHEADER is just some names Windows have given them. Actually "UINT" is the same as "unsigned int," and "DWORD" is the same as "signed int," or just "int."

[PAUL1966]

Hi!

As you say, "UINT" is the same as "unsigned int" and according to the C standard a "int" or "unsigned int" is defined as "at least 16 bits". This means that an int can actually be more than 16 bits on some architectures.

So if you have two computers with different architecture (one that defines a UINT as 16 bits, and the other that defines a UINT as 32 bits) and creates a bitmap file on one computer. Then it will be corrupt if you try to read it on the other computer, would it not?

[v0id]

PAUL1966 said:

This means that an int can actually be more than 16 bits on some architectures.

On modern computers it almost always is. On 32-bit processors the size is 32-bit, and on 64-bit processors the size is 64-bit. It's possible to use real mode on most processors though, so you make the size go 16-bit instead.

About your next question; I'm not sure. I would (after I thought about it) say it would be corrupted, but I can't say for sure, I've never tried to open a 32-bit bitmap file on a 16-bit processor. There's probably some other people around here who can help you further, with a more detailed explanation.

[Lop]

What type of specifications are you looking at that lists the header with those terms? I'd have to believe it is a Windows specification list?

[v0id]

I think he has used a specification page like those you can find on MSDN, such as this one.

[Lop]

Ahh, makes sense then. I did a quick google search and found several but all used Windows terms.

[PAUL1966]

Yes, the info is taken from a Microsoft Windows spec of Bitmap file format. But is is also the only spec i found when googlling on bitmap.

The question is the same between 32- and 64-bit computers
as between 16- and 32-bit machines.

Does anyone know?

[WingedPanther]

Another question: would the endian-ness of the OS affect reading the file?

[Lop]

I've never heard that term before.

[v0id]

Endianness is about how the data is stored in the memory. When you're talking about endianness, you're usually talking about big endian, little endian, and some times mixed endian. There's much more information on Wikipedia.

[dargueta]

UPDATE: FREAD AND FWRITE DO NOT COMPENSATE FOR BIG/LITTLE ENDIAN MODE.

And yes, it would affect the data. 0xABCD is not the same as 0xDCBA. I think (but I'm not sure) that fread() and fwrite() take care of that. If you need to use specific data sizes that are cross-platform, instead of using BYTE,WORD,DWORD, and QWORD, use __int8, __int16, __int32, and __int64 (use unsigned prefix if necessary). These are guaranteed to be the same size on any system, indicated by the number after int which is the number of bits.