I know that this is the correct structer for the bitmap header, but...

struct BITMAPFILEHEADER
{
    WORD    bfType; 
    DWORD   bfSize; 
    WORD    bfReserved1; 
    WORD    bfReserved2; 
    DWORD   bfOffBits; 
};
 

...makes use of WORD and DWORD. I don''t want to use these. What are the equivalents to WORD and DWORD in thers of int, long, short, char, unsigned, signed, and so on. Thanks

Hi,

WORD: unsigned short
DWORD: unsigned long

Aldenar

The below struct properly loads the header:

struct BITMAPFILEHEADER{    WORD    bfType;     DWORD   bfSize;     WORD    bfReserved1;     WORD    bfReserved2;     DWORD   bfOffBits; }; 

The below definition of the struct does not:

struct BITMAPFILEHEADER{    unsigned short	bfType;     unsigned long	bfSize;     unsigned short  bfReserved1;     unsigned short  bfReserved2;     unsigned long   bfOffBits; }; 

Why?

I don''t really know.. I tried a sizeof and both returned 16

You could try to give the struct a new name because BITMAPFILEHEADER was already defined when I included windows.h (VC++6)

Aldenar

just think of it as the asm dword...double word, two words, right? and one words is 2 bytes or 16 bits. so that makes a dword 32 bits. and no dwords are not 16 bit ints.

You may try with this code, it changes the data alignment for the structure, giving it a size of 14 bytes (as the one defined in wingdi.h) instead of 16..
Assuming that you use Visual C++ 6 (don't know for other versions)

#include (pshpack2.h)
struct BITMAPFILEHEADER
{
unsigned short bfType;
unsigned long bfSize;
unsigned short bfReserved1;
unsigned short bfReserved2;
unsigned long bfOffBits;
};
#include (poppack.h)

Edited by - Aldenar on 1/19/00 3:45:06 PM

A WORD is two BYTES or 16 bits.
A DWORD is four bytes or 32 bits.

Even though DWORD generally equates to an unsigned int on a 32 bit system there''s no official C specification that says how long a int, float, short, long, or double has to be. That is platform dependant. An int, short and long could all be the same on a given platform.

This isn''t that big of a deal for a compiled program (assuming you don''t assume too much when you cast) since it will compile for that system.

It can be a big deal for file formats though. Obvious example is that bitmaps would work with the old Windows 3.11 and NT even though 3.11 was a sixteen bit system. I believe on that WPARAM and LPARAM were actually different lengths.

And with sixty-four bit Windows systems around the corners, expect the size of different units to change again. Intel''s 64 bit chip can''t even run in a thirty-two bit mode.

So, anyway, the moral of the story is to use WORD and DWORD if windows does and get used to it.

I do use windows (actually that all I use and that is the problem). I''m trying to teach someone C++ and I''m starting them off with console mode programs. I didn''t want to intoduce the windows stuff until a little father down the road.

What about the int8, int16 and int32? these should be direct conversions to BYTE, WORD and DWORD, and more "readable" as to the kind of data they represent. i don''t know if they are supported by the compiler you''re using, though, don''t remember about them in the C/C++ specs.

>What about the int8, int16 and int32? these should be >direct conversions to BYTE, WORD and DWORD
Point to note though. BYTE, WORD and DWORD are unsigned, while *__int8*, *__int16* and *__int32* are signed.
Besides, they are microsoft specific and might lead to unportable codes