Hi, i'd like to know if anyone knows the current status of wine's support fro win64. I've tried to build a git checkout with --enable-win64 configure switch. It has taken some tinkering to make it build, but after that i'm not able to run anything and ti seems that wineboot cannot start. Any suggestion?
Alessandro Pignotti
This summer Maarten Lankhorst did some basic work on win64 support but for the rest no work has been done it for a long time. I'm not sure what Maarten exactly did but but there is a lot of work to be done before it will run even a basic app.
Roderick
Hi, i'd like to know if anyone knows the current status of wine's support fro win64. I've tried to build a git checkout with --enable-win64 configure switch. It has taken some tinkering to make it build, but after that i'm not able to run anything and ti seems that wineboot cannot start. Any suggestion?
Alessandro Pignotti
Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 Encrypted mails are welcome
This summer Maarten Lankhorst did some basic work on win64 support but for the rest no work has been done it for a long time. I'm not sure what Maarten exactly did but but there is a lot of work to be done before it will run even a basic app.
I think we still have the problem that gcc doesn't support the calling convention Win64 uses, so we can't compile a Wine that is compatible with Win64 apps.
That may be fixed in gcc already though. I haven't checked since some time.
On Tue, Nov 4, 2008 at 8:36 AM, Stefan Dösinger stefan@codeweavers.com wrote:
I think we still have the problem that gcc doesn't support the calling convention Win64 uses, so we can't compile a Wine that is compatible with Win64 apps.
That may be fixed in gcc already though. I haven't checked since some time.
I am not sure if this is merged in stock gcc but there is a mingw64 we have been using for ReactOS and it is able to build valid binaries.
On Tue, Nov 04, 2008 at 02:36:02PM +0100, Stefan Dösinger wrote:
This summer Maarten Lankhorst did some basic work on win64 support but for the rest no work has been done it for a long time. I'm not sure what Maarten exactly did but but there is a lot of work to be done before it will run even a basic app.
I think we still have the problem that gcc doesn't support the calling convention Win64 uses, so we can't compile a Wine that is compatible with Win64 apps.
That may be fixed in gcc already though. I haven't checked since some time.
This will be in gcc 4.4.
From my LinuxTag trip report this year:
- Kai Tietz of mingw64 told me that they have a GCC patch ready for gcc 4.4 which will support the Win64 calling convention attribute just like __attribute__(stdcall).
Was committed to GCC TRUNK: http://gcc.gnu.org/viewcvs?view=rev&sortby=date&revision=136311 __attribute__(ms_abi)
If we have more GCC requirements for Win64, he is willing to help.
In general he would like to have Wine as a testbed for mingw64 development (and we could use it as testbed the other way round).
This was committed to GCC TRUNK (what will be 4.4) on 2008-07-06.
Ciao, Marcus
On Tue, 4 Nov 2008, Stefan Dösinger wrote: [...]
I think we still have the problem that gcc doesn't support the calling convention Win64 uses, so we can't compile a Wine that is compatible with Win64 apps.
In the meantime we can work on the long vs. LONG issue: * there are a number of places where the Windows SDK uses 'long'. But on Win64 'long' is 32bit, while every other 64bit platform treats it as 64bit. * in Wine's headers and in the code there are plenty of places where we use long where we really want a 32bit integer for 64bit.
The fix for all these is to replace 'long' with 'LONG' which Wine keeps 32bit just like Windows (though I wonder if we should not use something lile 'wine_long' instead).
This is not awfully complex stuff but there's a ton of it. So we might as well start now so that we're ready when the time comes.
2008/11/4 Francois Gouget fgouget@free.fr:
On Tue, 4 Nov 2008, Stefan Dösinger wrote: [...]
I think we still have the problem that gcc doesn't support the calling convention Win64 uses, so we can't compile a Wine that is compatible with Win64 apps.
In the meantime we can work on the long vs. LONG issue:
- there are a number of places where the Windows SDK uses 'long'. But
on Win64 'long' is 32bit, while every other 64bit platform treats it as 64bit.
- in Wine's headers and in the code there are plenty of places where we
use long where we really want a 32bit integer for 64bit.
The fix for all these is to replace 'long' with 'LONG' which Wine keeps 32bit just like Windows (though I wonder if we should not use something lile 'wine_long' instead).
This is not awfully complex stuff but there's a ton of it. So we might as well start now so that we're ready when the time comes.
Don't forget that you should use the *_PTR types for data that can hold pointers (LONG_PTR, DWORD_PTR and the like).
- Reece
Francois Gouget wrote:
On Tue, 4 Nov 2008, Stefan Dösinger wrote: [...]
I think we still have the problem that gcc doesn't support the calling convention Win64 uses, so we can't compile a Wine that is compatible with Win64 apps.
In the meantime we can work on the long vs. LONG issue:
- there are a number of places where the Windows SDK uses 'long'. But
on Win64 'long' is 32bit, while every other 64bit platform treats it as 64bit.
- in Wine's headers and in the code there are plenty of places where we
use long where we really want a 32bit integer for 64bit.
The fix for all these is to replace 'long' with 'LONG' which Wine keeps 32bit just like Windows (though I wonder if we should not use something lile 'wine_long' instead).
What would 'wine_long' gain us? LONG is already ugly enough.
bye michael
On Tue, 4 Nov 2008, Michael Stefaniuc wrote: [...]
The fix for all these is to replace 'long' with 'LONG' which Wine keeps 32bit just like Windows (though I wonder if we should not use something lile 'wine_long' instead).
What would 'wine_long' gain us? LONG is already ugly enough.
The Windows SDK did not standardize on either long or LONG, instead they use a mixture (well, mostly LONG with some longs here and there). I don't know what their intention is with that, if they have one, it just bothers me to lose that information in the Wine headers. Just in case a few years down the road they decide that long extends to 128bits in Win128 but LONG does not. I don't want to have to convert back all our LONG-that-should-be-longs to something else again.
It may be a bit paranoid, and maybe it's not worth it (though I don't think it costs us much). In any case, whatever Alexandre decides I'll follow.
Francois Gouget fgouget@free.fr writes:
It may be a bit paranoid, and maybe it's not worth it (though I don't think it costs us much). In any case, whatever Alexandre decides I'll follow.
I don't think it's worth it. There's no real logic to how the various types are used in the API anyway.
-
Alessandro -
Alexandre Julliard -
Francois Gouget -
Marcus Meissner -
Michael Stefaniuc -
Reece Dunn -
Roderick Colenbrander -
Stefan Dösinger -
Steven Edwards