RE: [RFC] Wine headers
> On December 1, 2002 12:35 pm, Patrik Stridvall wrote:
> > That solves the libc problem however compiling with -flong-int also
> > means that it will be impossible to call other libraries, which
> > means that it will be a little hard to use Unix specific library
> > to have extra functionallity under Unix.
>
> But those apps will be aware of the issue, and can use explicit types,
> just like we're going to do in Wine. Sure, they will not be able to
> use the header files directly (actually, they might by having some
> compat files that are not compiled with said flag on), but I don't
> think it's a big deal anyway. It's workable,
A better solution would be to port the source code to the LP64 model.
It is entirely possible for to support all of LP32 (Win32 and "Unix32"),
LLP64 (Win64) and LP64 ("Unix64") in a sane way.
I don't think it is worth the effort to support LLP64 beyond having
a "-flong-int" flag to get a working version to show as a prototype
that porting is indeed possible.
> and Win64 will not
> bother us for some time...
True. Microsoft doesn't seems that eager pushing Win64 either...
Re: [RFC] Wine headers
On December 1, 2002 12:35 pm, Patrik Stridvall wrote: > That solves the libc problem however compiling with -flong-int also > means that it will be impossible to call other libraries, which > means that it will be a little hard to use Unix specific library > to have extra functionallity under Unix. But those apps will be aware of the issue, and can use explicit types, just like we're going to do in Wine. Sure, they will not be able to use the header files directly (actually, they might by having some compat files that are not compiled with said flag on), but I don't think it's a big deal anyway. It's workable, and Win64 will not bother us for some time... -- Dimi.
RE: [RFC] Wine headers
> 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). That solves the libc problem however compiling with -flong-int also means that it will be impossible to call other libraries, which means that it will be a little hard to use Unix specific library to have extra functionallity under Unix. But sure having a -flong-int flags is nice but it doesn't solve all problems. Perhaps would be good to push for its addition even now, it might take a few years before standard GNU C installation supports it.
Re: [RFC] Wine headers
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). -- Dimi.
RE: [RFC] Wine headers
> 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.
Re: [RFC] Wine headers
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? -- Dimi.
Re: [RFC] Wine headers
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Here is my proposal:
> ${prefix}/include/win32 -- standard Win32 headers
> ${prefix}/include/msvcrt -- MS Visual C Runtime library
> ${prefix}/include/wine -- Wine specific headers
I think everything should be under wine/ otherwise we risk conflicts
with other packages. So I'd suggest something like this:
${prefix}/include/wine/windows -- standard Windows headers
${prefix}/include/wine/msvcrt -- MS Visual C Runtime library
${prefix}/include/wine -- Wine specific headers
It means the Windows headers are a bit buried instead of being
directly under wine/, but it's not too bad. As long as you don't
change anything in the source tree I could be convinced to go along
with that...
--
Alexandre Julliard
[EMAIL PROTECTED]
RE: [RFC] Wine headers
> The only thing I don't like in my proposal is the win32 name, namely > the 32. I guess Win64 will go in the same namespace, as well as win16. > This is confusing. What about winxx or even better winapi? Windows uses the same header files for both Win32 and Win64. It is Win32 if _WIN32 is defined and Win64 if _WIN64 is defined. 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. So we probably should have the same include directory for Win32 and Win64. As for the name well I think I like "windows" best. > > > plus a bunch of other things (like making it easy to use other > > > headers for the Win32 API, etc). And best of all, it seems to > > > be easily implementable, no? > > > > "mv" is your friend however the CVS versioning doesn't like > it though... > > We don't have to move anything in the tree, just modify where > we install > stuff. Of course, this means that you will not be able to use > your tree > include files in all cases, but I think it's good as a start. Perhaps.
Re: [RFC] Wine headers
On November 29, 2002 01:03 pm, Patrik Stridvall wrote: > With your suggestion above we can, so I like it. :-) Yay!!! I guess the problem is that we the current setup we can not include wine specific headers without having *our* win32 headers in the include path. Bad. Cool thing (me thinks) about my proposal is that it doesn't complicate Winelib use at all. Right now apps need to have a -I$(prefix)/include/wine now that will change to -I$(prefix)/include/win32 The only thing I don't like in my proposal is the win32 name, namely the 32. I guess Win64 will go in the same namespace, as well as win16. This is confusing. What about winxx or even better winapi? > > plus a bunch of other things (like making it easy to use other > > headers for the Win32 API, etc). And best of all, it seems to > > be easily implementable, no? > > "mv" is your friend however the CVS versioning doesn't like it though... We don't have to move anything in the tree, just modify where we install stuff. Of course, this means that you will not be able to use your tree include files in all cases, but I think it's good as a start. -- Dimi.
RE: [RFC] Wine headers
> Alexandre,
>
> Patrik brought up the header location sometime ago, in this thread:
> http://www.winehq.com/hypermail/wine-devel/2002/10/index.html#540
>
> At the time, I thought it is a bit premature, that we have other
> things to do. Now I realize that this is one of those highly visible
> external things, that would be a _lot_ better to fix before people
> start using Winelib. Otherwise will piss people off when we change,
> or we will not change because people are already using the headers.
True.
> Both versions are not good, and I think we can fix them now without
> too much pain.
>
> Here is my proposal:
> ${prefix}/include/win32 -- standard Win32 headers
> ${prefix}/include/msvcrt -- MS Visual C Runtime library
> ${prefix}/include/wine -- Wine specific headers
>
> It is simple (to understand & implement), clean, and pretty.
> And I think it solved Patrik's problem (even if I can't quite
> understand what the problem is from the first message :)),
It not easy to mix different flavours of the Win32 headers
because of include problems.
The problem is that is you have since we include wine specific files like:
#include "wine/debug.h"
we need to have a include path like
-I${prefix}/include
However now since the Wine version of the standard Win32 header are in
${prefix}/include
we get them included as well if we do
-I${prefix}/include
So if we do for example
-I/opt/microsoft/windows/include
we get header include collisions.
Sure with GNU C on Linux (and presumably) on Windows we can fix that
by specifing a correct include order. However with Microsoft C++
we can't do it in a portable way.
With your suggestion above we can, so I like it. :-)
> plus a bunch of other things (like making it easy to use other
> headers for the Win32 API, etc). And best of all, it seems to
> be easily implementable, no?
"mv" is your friend however the CVS versioning doesn't like it though...
