RE: winnt32.exe on AMD64
From: "Nadgir, Ananth P" <ananth.p.nadgir(a)intel.com>
Does Wine now support executing x64 bit PE executable like winnt32.exe under amd64 directory?
No, the biggest problem is that the 64-bit calling conventions are different between PE executables and Linux executables. Some more info on the Wine64 wiki page http://wiki.winehq.org/Wine64 Ge van Geldorp.
On Tuesday 18 July 2006 03:16, Ge van Geldorp wrote:
the biggest problem is that the 64-bit calling conventions are different between PE executables and Linux executables. Some more info on the Wine64 wiki page http://wiki.winehq.org/Wine64
This isn't necessarily a huge problem - even if GCC can't support it, there's no reason we could not generate assembly language thunks for each entry point - the information required to do this is already in the spec files. The different size of "long" is not a big issue since all of the entry points and structure members should be declared using Win32/64 typedefs anyway. Even if GCC is modified to support the Win64 calling convention, it's not going to be available universally for some time so we'd probably have to generate thunks to support systems where the Win64 capable version is not available (plus I think Alexandre still wants compiler-neutrality as far as is possible). -- Troy Rollo - wine(a)troy.rollo.name
Troy Rollo wrote:
On Tuesday 18 July 2006 03:16, Ge van Geldorp wrote:
the biggest problem is that the 64-bit calling conventions are different between PE executables and Linux executables. Some more info on the Wine64 wiki page http://wiki.winehq.org/Wine64
This isn't necessarily a huge problem - even if GCC can't support it, there's no reason we could not generate assembly language thunks for each entry point - the information required to do this is already in the spec files.
It's not enough. We have to be able to call these functions from the Wine code, call callbacks, COM interfaces etc... Jacek
On Tuesday 18 July 2006 09:53, Jacek Caban wrote:
It's not enough. We have to be able to call these functions from the Wine code, call callbacks, COM interfaces etc...
These are complications rather than impenetrable barriers. Wine->Wine (and Winelib App->Wine) calls would not need to go through the thunks. Many of the issues involved have already been dealt with for 16<->32 thunking and cross-process COM calls. It's not ideal, but it should be possible. -- Troy Rollo - wine(a)troy.rollo.name
From: Troy Rollo [mailto:wine(a)troy.rollo.name]
These are complications rather than impenetrable barriers. Wine->Wine (and Winelib App->Wine) calls would not need to go through the thunks. Many of the issues involved have already been dealt with for 16<->32 thunking and cross-process COM calls.
It's not ideal, but it should be possible.
It's an intriguing idea, but I can't see how it could work for even slightly complex cases. Take the COM calls. When the COM object is constructed, you have absolutely no idea whether its methods are going to be called from a Wine or from a PE environment. The difference with thunking and cross-process COM calls is that in those cases the caller knows he's doing something special. Not so for in-proc COM calls, it's just a function call. Gé van Geldorp.
On Tuesday 18 July 2006 16:28, Ge van Geldorp wrote:
It's an intriguing idea, but I can't see how it could work for even slightly complex cases. Take the COM calls. When the COM object is constructed, you have absolutely no idea whether its methods are going to be called from a Wine or from a PE environment.
No, but if an interface pointer to it is being made known to another part of the system then this will be done through some API call that will have to be (made) aware of which calling convention has been used to provide the pointer (or which is a more complex thunk). Internally if it came from a PE context, it would need to create a new pointer that would be to an object created based on the IDL for the interface, the new pointer being something using the host calling convention that passes all calls on to the original interface (essentially, more thunks). It might be useful for the newly created object to have a WINE-specific interface available for querying whether it is a thunk and identifying the original pointer so that when passing the pointer back to a PE context we can just pass the original pointer (rather than creating a new Win64 calling convention object that directs back to the host calling convention object which in turn directs back to another Win64 calling convention object). The complexity of this is such that most of it would have to be done by writing code generators rather than by writing the code directly, however the languages that would be inputs to the code generators are largely already defined (IDL and Wine's spec files). No doubt it would be easier to wait for gcc to support the Win64 calling convention, but that is not the only option. -- Troy Rollo - wine(a)troy.rollo.name
Ge van Geldorp wrote:
From: "Nadgir, Ananth P" <ananth.p.nadgir(a)intel.com>
Does Wine now support executing x64 bit PE executable like winnt32.exe under amd64 directory?
No, the biggest problem is that the 64-bit calling conventions are different between PE executables and Linux executables. Some more info on the Wine64 wiki page http://wiki.winehq.org/Wine64
Ge van Geldorp.
Which brings me to an Idea I had a long time ago. Why not compile the all of Wine as PE with a GCC cross-compiler (MinGW), But for the 3 low level DLL's. In effect a ReactOS system and Makefiles (On a Linux kernel). Sure we will maybe want an alternate system for Builtin/Native, maybe different system folders for builtin dlls and executables vs. native. This will surely solve the Above problem. It will also make a clear cut of what are Wine DLLS that are the same for Wine/ReactOS and what are System dlls that are System/Kernel dependent. It will avoid the problems with export functions and so on ... Has any one (ReactOS?) tried such a system on Linux? What is the minimum dll set that must be compiled ELF? Does MinGW (gcc for PE) has support for Win64? (And a philosophical Question: The "Sameness" of 32 bit calling convention (and virtual tables) between PE and lets call it GCC, was that a freak of nature? or is it just that Unix people got there first this time and MS people must be cocky? Or was it the Unix People who got cocky this time? ;-) Free Life Boaz
Ge van Geldorp wrote:
From: "Nadgir, Ananth P" <ananth.p.nadgir(a)intel.com>
Does Wine now support executing x64 bit PE executable like winnt32.exe under amd64 directory?
No, the biggest problem is that the 64-bit calling conventions are different between PE executables and Linux executables. Some more info on the Wine64 wiki page http://wiki.winehq.org/Wine64
Ge van Geldorp.
Which brings me to an Idea I had a long time ago. Why not compile the all of Wine as PE with a GCC cross-compiler (MinGW), But for the 3 low level DLL's. In effect a ReactOS system and Makefiles (On a Linux kernel). Sure we will maybe want an alternate system for Builtin/Native, maybe different system folders for builtin dlls and executables vs. native. This will surely solve the Above problem. It will also make a clear cut of what are Wine DLLS that are the same for Wine/ReactOS and what are System dlls that are System/Kernel dependent. It will avoid the problems with export functions and so on ... Has any one (ReactOS?) tried such a system on Linux? What is the minimum dll set that must be compiled ELF? Does MinGW (gcc for PE) has support for Win64? (And a philosophical Question: The "Sameness" of 32 bit calling convention (and virtual tables) between PE and lets call it GCC, was that a freak of nature? or is it just that Unix people got there first this time and MS people must be cocky? Or was it the Unix People who got cocky this time? ;-) Free Life Boaz
From: Boaz Harrosh
Why not compile the all of Wine as PE with a GCC cross-compiler (MinGW), But for the 3 low level DLL's. In effect a ReactOS system and Makefiles (On a Linux kernel). Sure we will maybe want an alternate system for Builtin/Native, maybe different system folders for builtin dlls and executables vs. native. This will surely solve the Above problem.
I hate to be so negative but at the moment this will not work. The reason is simple, there's no 64-bit MinGW (yet?).
Has any one (ReactOS?) tried such a system on Linux?
ReactOS could be cross-compiled, using MinGW, on Linux a few months ago. I assume that's still possible.
(And a philosophical Question: The "Sameness" of 32 bit calling convention (and virtual tables) between PE and lets call it GCC, was that a freak of nature? or is it just that Unix people got there first this time and MS people must be cocky? Or was it the Unix People who got cocky this time? ;-)
I was wondering about that too. I have no idea about the timeline, who was first. It's conceivable that both parties worked on it at around the same time. G? van Geldorp.
On Tue, 18 Jul 2006, Boaz Harrosh wrote: [...]
Why not compile the all of Wine as PE with a GCC cross-compiler (MinGW), But for the 3 low level DLL's.
It's more than just 3 low level dlls. It's also all the Wine dlls that use native libraries like opengl, cups, sane, lcms, and of course, Alsa, OSS, NAS, aRts, etc. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't.
Hi, On 7/19/06, Francois Gouget <fgouget(a)free.fr> wrote:
It's more than just 3 low level dlls. It's also all the Wine dlls that use native libraries like opengl, cups, sane, lcms, and of course, Alsa, OSS, NAS, aRts, etc.
Hmm the ones I can name off the top of my head that dlsym a native *nix lib I think are capi32, gdi32, user32, winex11.drv, winmm, all the gl/directx stuff, wldap32, winspool and winmm I guess that also means you would need two copies of libwine.dll one that was PE and one that was ELF. If someone REALLY needs a PE build of Wine dlls for a app (I know there are some stupid ones that really check) then we need to fix the documentation. There is no easy way to do it as your talking about multiple configs. It would require adding a rule to the build system to allow them to give the path to mingw, support another config.h for that target, maintain the list of exceptions that don't build and or have it do a "make -k" after its installed the normal Wine ELF files and copy whatever built rather than having to maintain a huge list of exceptions in the build system. The current system of keeping two trees just works better the only difference is all of those steps are manually now. Perhaps we could add a script to wine/tools or something to make it less trouble if someone needs to build a set of PE dlls for a stupid app.... -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
participants (7)
-
Boaz Harrosh -
Boaz Harrosh -
Francois Gouget -
Ge van Geldorp -
Jacek Caban -
Steven Edwards -
Troy Rollo