[RFC] Wine headers

[Patrik Stridvall]

> On November 29, 2002 01:43 pm, Patrik Stridvall wrote:
> > On 64 bit platforms we can never get 100% Win32 source compabillity
> > because of compiler problems. If fact we can't get 100% 
> Win64 support
> > either for the same reasons so I guess Wine on 64-bit platforms will
> > be some kind of pseudo mode.
> 
> Why are you saying that? What about the current difference between the
> sizeof(wchar_t), it wasn't such a big deal. Can't we have other flags
> in the great tradition of -fwchar-short?

It is a little worse that that. 

The C programming langauge doesn't really specify the sizes of the
various integer types. It it up to the ABI.

In Win32 the only really problematic difference I the one you meantion
above ie the size(wchar_t) problem. It can be "solved" as specified
above with -fwchar-short. The price is that you can't call the
C library "wchar" functions or for that matter any library
functions that depend of wchar. Not that big deal though.

In the Win64 ABI Microsoft in it infinity "wisdom" has choosen
the type long to be 32 bit instead of 64 bit like in most (all?)
Unix API on 64 bit platforms. 

The Microsoft Win64 choice is called LLP64. 
That is long long and pointers are 64 bit.

The Unix64 choice is called LP64.
That is long and pointers are 64 bits.

So this means that if we add an option similar to -fwchar-short,
say -flong-int or -flong-32bit or whatever we can call we can't
call the any library on the platform since it would could ABI problems. :-)

So that is why we "never" will support 100% Win64 source compatibillity
on 64bit platforms. We can (and presumably) will support a LP64 variant
of Win64 but it won't be 100% source compatible.