There is nothing really strange about that, C (and C++ I guess) pads all its structs so all elements are "naturally aligned" (to an adr that is a multiple of their size), and aligns the entire struct to the size of the largest element, in your case 4B due to the DWORD/int. The reason is the compiler can then emit code that manipulates 4B quantities without worrying about alignment and/or achieving highest performance. (Some processors do not know how to load a DWORD from an unaligned adr, others do but take more time to do it). The net result is: 1) if your struct's size is not a multiple of 4 but contains elements sized 4B, the struct will act as if its size is a multiple of 4B (even when sizeof shows otherwise). 2) if the elements in your struct are not "naturally aligned", the struct will be padded with extra bytes to achieve the natural alignment (=each element gets aligned according to its size). So struct { byte a; // offset 0 short b; // 1 ? not naturally aligned byte c; // 3 ? OK byte d; // 4 ? OK long e; // 5 ? not naturally aligned } gets compiled as if it were: struct { byte a; // offset 0 byte bDummy; short b; // offset 2 byte c; // offset 4 byte d; // offset 5 byte eDummy1; byte eDummy2; long e; // offset 8 } The function you used was an old one, relying on a stride of 6B, so something special needed to be done. In C (and C++ I guess) there are compiler switches and/or pragmas to disable the alignment/padding. In C# your splitting the 4B into two 2B elements is probably the best way to get what you needed. :)
Luc Pattyn
