Re: RFC: Compiling as 16 bit

[Morten Rønne]

On 02-09-2010 21:21, Alexandre Julliard wrote:
> Morten Rønne  writes:
> > I am looking for a way to change windef.h so that it will create the
> > correct base types for both 16 and 32 bit compile.
> >
> > Openwatcom defines the symbol __I86__ while compiling for 16 bit, is
> > it acceptable that I use that to create 16 bit types?
> > It seems that _MSC_VER will change a few cases of int to long, but far
> > from enough.
> > Is _MSC_VER intended to be a 16 bit compile flag?
> > Or should I use something else more wine like (e.g. __WINE_16BIT_COMPILE).
> >
> > Also compiling 16 bit give some errors in other include files (after I
> > have defined proper sizes for the 16 bit compile)
> > ../../../include/winnt.h(3529): Error! E1040: Field width too large
> > #ifdef BITFIELDS_BIGENDIAN
> >              unsigned NameIsString:1;
> >              unsigned NameOffset:31;
> > #else
> >              unsigned NameOffset:31;
> >              unsigned NameIsString:1;
> > #endif
> > As it can be seen the include file uses unsigned directly and not a
> > type like DWORD or ULONG that would be a "safe" 32 bit.
> > Would it be acceptable to change this and others to a "proper" type
> > which I know to be size safe?
>
> I don't think it makes sense to invest time into developing a 16-bit
> Winelib environment, and we certainly don't want to add 16-bit crap in
> the standard Win32 headers. These things should be part of the 16-bit
> compiler environment.

Dear Alexandre

After having thought about this again I think you might have 
misunderstood what I am trying to do.
I do not want to compile any part of wine as 16 bit (except the DOS 16 
bit tests that I am planing to write).

To make sure that I use the same definitions I would of course prefer to 
use the existing wine include files without having to duplicate every 
include file that contains something that relates to the 16 bit 
execution in wine.

For example: I would like to test the DOS Program Segment Prefix (aka 
Program Description Block in windows).

That struct is already defined in wine/winbase16.h as PDB16.

So I would like to do this in my test program:
   #include <wine/winbase16.h>
   PDB16 *psp;

In a perfect world this would be enough to have full access to the PDB16 
struct in the test program.
But alas, the world is not perfect (yet).

Since openwatcom uses 16 bit ints the size of DWORD becomes 2 bytes and 
not 4 bytes as it does with 32 bit ints.
Which of course will make the struct wrong in the test program.

So I would like to add a few lines to windef.h to handle this:
   #ifdef __I86__
   typedef unsigned int    WORD,       *PWORD,    *LPWORD;
   typedef long int        INT,        *PINT,     *LPINT;
   typedef unsigned long   UINT,       *PUINT;
   typedef float           FLOAT,      *PFLOAT;
   typedef long                                   *LPLONG;
   typedef unsigned long   DWORD,      *PDWORD,   *LPDWORD;
   #else
   /* Current 32 bit defines for the same types */
   #endif

This only leaves the problem that LONG and a few other bits and pieces 
are defined elsewhere not using a definition from windef.h.

I think that the price of 9 lines of definitions are fine, if that means 
that every include file can be reused in both 16 and 32 bit test and not 
having to be duplicated (with all the errors that can cause).
If I put some very careful thinking into it I can probably combine it 
with the current _MSC_VER definitions and boil it down to fewer lines.

Again there is no change to anything in the current compile of wine.
This will only affect the 16 bit compile of test programs with 
openwatcom and just mean that the 16 bit test can include existing 
include files without problems.

In the hope that you will consider this again.

Best Regards
Morten Rønne