Well, an hour looking around on MSDN didn't help alot, as I didn't find anything at all on how MSVC++ (6.) stores classes/structs to file, however, after messing around myself, I found something out;
something that is very odd and mystifying.
sizeof(unsigned short) on my computer (using either djgpp or MSVC++ 6) is 2.
However, when I save the following struct to file:
Code:
struct TMP {
long l;
unsigned short s;
int i;
} tmp;
ofstream o;
o.open("dump.txt", ios::out | ios::binary);
o.write((char*)&tmp, sizeof(tmp))
(of course I snipped a bit..)
it seems that it is padding the value of the short with two extra bytes.
I tried filling a Bitmap header struct with values that a normal one would contain, and saving it to a file as well;
It padded the first short in the struct (which is supposed to contain (dec)19778 (hex)4d42 (char)MB which will be swapped to make (char)BM once it hits the text file) with another two bytes.
In a normal bitmap file (created with any of the three programs I used, at least..) the short is *not* padded with the extra two bytes, so I have absolutely no idea why it would be padding mine, however if it also attempts to pad the short when it is loading, and doesn't find it padded in a normal bitmap file, then it's no wonder it's messing everything up.. but why??
The worst part is, there are two other unsigned short values in the bitmap header, and it doesn't pad either of those !!
I am really getting confused, and a couple hours of messing with hex editor and searching through MSDN hasn't helped.
It seems, though, that a program compiled either in djgpp or in MSVC, and using struct or class, and using fstream or the fopen() functions, still thinks that the third and fourth bytes in the bitmap file belong to the first unsigned short in the struct/class, which they don't. (they belong to the second member variable in the class, which is a long.)
Does anyone have any idea what I'm doing wrong?!?!
p.s. about the fact that the MS Paint bitmap I created was loading differently than the other two, I doscovered that the MS Paint one was a 24bit bitmap, so that's why it was different. However, regardless of whether the bitmap is 24 or 8 bit the header still remains the same.
p.p.s don't you think we should make it so the graphic smileys don't appear inside [code] brackets?
--edit--
p.p.p.s it also seems that VC++ at least, stores the short values with a pad after them even in memory - *if* the next value in the class/struct is a 4-byte value; i.e. two shorts beside each other are not padded, while one short with a long after it is, and so is a short if it is the last member variable in the struct. somehow all of this seems needlessly complicated to me?!? how in the world do paint, and photoshop, and paint shop pro, and windows for that matter, still load bitmaps?