RFC: Compiling as 16 bit

[Morten Rønne]

This is related to the creation of the DOS test programs for which I 
have sent another mail.

But this is a more generic question relating to the fact that openwatcom 
is a 16 bit compiler while gcc (of course) is a 32 bit compiler.

Currently this have lead me to drop the inclusion of the files windef.h 
and winbase.h, because the definitions created aren't of the correct 
size (int is 16 bit, not 32 bit and so on).

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?

Best Regards
Morten Rønne

[Alexandre Julliard]

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.

[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.

I can understand that, but the problem is that in order to write proper 
test of the 16 bit environment I need to include the definitions of the 
structs that make up the 16 bit execution environment e.g. 
wine/winbase16.h and others.
That file (and probably also the others) will in turn include windef.h 
and winbase.h, which will in turn include winnt.h and so on.
Ending up in a problem due to size errors.

Or are you saying that I should change wine/winbase16.h to not include 
windef.h and winbase.h and make sure that they don't include anything 
from "windows 32" include files?
Or should I duplicate all those file for the test enviroment, so that I 
have to maintain the same structs in two different files?

Best Regards
Morten Rønne

[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

[Alexandre Julliard]

Morten Rønne  writes:
> 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).

You can't do that. You need to have appropriate 16-bit headers for the
basic Windows stuff, this should come with the compiler. For
undocumented structures and the like, you have to define them yourself.