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.
On December 1, 2002 11:36 am, Patrik Stridvall wrote:
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.
I don't think it's nearly as bad as you make it. In the Wine sources, we'll just use explicit types that don't depend of compiler switches, while Winelib apps will just use the -flong-int flag, and get what they expect. Of course, they'll have to use our msvcrt lib instead of the native libc, but that's largely true today anyway (for different reasons).