VGUI Structure Packing Alignment
I tested the VGUI packing alignment under Win32.
I used Watcom Version 11 on WinNT 4 with Service Pack 4, with different
packing alignment parameters of /zp2, /zp4, or /zp8 separately for the
VGUI library and the TestApp application under the V\Test directory.
I compiled the VGUI library with different alignments, then compiled the
TestApp application separately with its own (possibly) different
alignments, and then linked and tested the application.
In summary, I could distinguish NO difference in behavior on the TestApp
application, including all of the dialogs. I tried all combinations of
compiling the VGUI library with 2/4/8 alignment, combined with
independent compilations of the TestApp code using 2/4/8 alignment.
I did not try single byte alignment with /zp1, Dr. Wampler has already
reported problems with this.
Although I tried such things as compiling VGUI library with /zp4 and
TestApp with /zp2, I do NOT recommend it. Each header file should be
compiled with consistent alignment. An application should NOT compile a
given header file, such as vcolor.h, with alignment different from its
compilation in the library.
In reviewing the V header files, it appears that most of the class
elements consist of functions, pointers, long's, and int's, which are
all 4 bytes in a 32-bit environment. Since combinations of these are
always an even 4 and 8 bytes, the different alignment parameters should
have no effect except for padding at the end of a class. For example,
compiling a structure with two long integers (an even 8 bytes) should be
the same under 2 or 4 or 8 alignment. Compiling a structure with three
long integers should yield a memory size of 12 bytes under 2 or 4 byte
alignment, and 16 bytes (with 4 bytes padding at the end) for 8 byte
alignment. (At least, that's my understanding...)
It is true that there are a few character declarations in VGUI, but they
do not seem to have alignment issues. Such declarations include an
array in vboxlblc.h that is a multiple of 8, some pointers to char or
byte, a structure dChar used with pointers for the screen, some ChrAttr
constants, etc.
I did notice one header file that might be an issue, however, namely
vcolor.h. Class vColor has 4 protected char elements, including a 1 byte
padding by Dr. Wampler to force an even 4 bytes. The 4 bytes are
followed by a private function declaration. Although the compiler can
rearrange the order of elements in memory, it is likely that the
compiler may add an additional padding of 4 bytes after the char
elements, in the case of 8 byte alignment but not 2 or 4 alignment.
This is an example where it is important that the VGUI Libary and the
application use the same alignment when compiling vcolor.h. Still, I
did not notice any problem in my tests even when I compiled
inconsistently -- perhaps Watcom 11 happened to arrange the structure in
memory so the padding was placed at the end with no side effects.
In summary, in a 32-bit environment, the VGUI seems to support 2, 4, or
8 byte alignment as long as everything is compiled consistently.
- Steve
-----Original Message-----
From: Bruce Wampler [mailto:bruce@objectcentral.com]
Sent: Monday, November 30, 1998 7:36 PM
To: Dr. Stephen K. Young
Subject: Re: VGUI Structure Packing Alignment
I never really understood why 4 and 8 would not work. Perhaps they
really do. I know 1 doesn't! Do you have any dialogs in the apps.
The problem is in the structure used to build dialogs, and it seemed,
at least with some compilers, to require word alignment, and not
even 4 or 8. It may be that only the library needs 2, and the app
can work with 4 or 8. I last used Watcom 10.5, so it might be something
new in 11.
If you have the time, could you try to build the V library with
2,4, and 8, and see if corresponding apps work? I would guess
that a 4 byte aligned library would NOT work with a 2 byte
aligned app, but that a 4 or 8 app might work with a 2 lib.
Bruce E. Wampler, Ph.D.
Author of the V C++ GUI Framework
e-mail: mailto:bruce@objectcentral.com
web: http://www.objectcentral.com
Reply to: