Wine64?

[Erik de Castro Lopo]

Hi all,

I'm interested in the current state of work towards Wine64, ie
running Win64 binaries on x86_64 Linux machines.

My needs are actually really simple and hence may be a good base
functionality to work towards. I just need to run Win64 binaries
that read stdin, write stdout/stderr and do file I/O using the
standard windows CreateFile/ReadFile/WriteFile/CloseHandle/
SetFilePointer etc functions.

I have found and read this:

    http://wiki.winehq.org/Wine64

but some of that stuff seems rather out-of-date.

When I configure with --enable-win64 it configures fine but then
errors out in widl generated code because of things like this:

    #if !defined(__RPC_WIN32__)
    #error Currently only Wine and WIN32 are supported.
    #endif

So, is anybody working on Wine64 stuff? Is there a Wine64 TODO list?
Any way for me to get involved?

Cheers,
Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"If you have one apple and I have one apple, if we exchange, each will
have one apple. If you have one idea and i have one idea, if we exchange
them, each will have two ideas!" -- Attributed to George Bernard Shaw

[Maarten Lankhorst]

Hello Erik,

2008/4/21, Erik de Castro Lopo <mle+win(a)mega-nerd.com>:
> Hi all,
>
> I'm interested in the current state of work towards Wine64, ie
>  running Win64 binaries on x86_64 Linux machines.
>
> My needs are actually really simple and hence may be a good base
>  functionality to work towards. I just need to run Win64 binaries
>  that read stdin, write stdout/stderr and do file I/O using the
>  standard windows CreateFile/ReadFile/WriteFile/CloseHandle/
>  SetFilePointer etc functions.
>
> I have found and read this:
>
> http://wiki.winehq.org/Wine64
>
> but some of that stuff seems rather out-of-date.
>
> When I configure with --enable-win64 it configures fine but then
>  errors out in widl generated code because of things like this:
>
> #if !defined(__RPC_WIN32__)
>     #error Currently only Wine and WIN32 are supported.
>     #endif
>
> So, is anybody working on Wine64 stuff? Is there a Wine64 TODO list?
>  Any way for me to get involved?
> A lot of the lowest level stuff is currently missing. If you don't
> mind x64 assembly it's not impossible to do. We would need support
> from gcc for the windows calling convention, and making it possible to
> mix linux calling convention with windows calling convention. If you
> are up to it just make it ignore the error for now, even if it causes
> errors. A proof of concept "Hello, world!" would be a great
> accomplishment at this point.

Cheers,
Maarten.

[Roderick Colenbrander]

> Hello Erik,
>
> 2008/4/21, Erik de Castro Lopo <mle+win(a)mega-nerd.com>:
> > Hi all,
> >
> > I'm interested in the current state of work towards Wine64, ie
> >  running Win64 binaries on x86_64 Linux machines.
> >
> > My needs are actually really simple and hence may be a good base
> >  functionality to work towards. I just need to run Win64 binaries
> >  that read stdin, write stdout/stderr and do file I/O using the
> >  standard windows CreateFile/ReadFile/WriteFile/CloseHandle/
> >  SetFilePointer etc functions.
> >
> > I have found and read this:
> >
> > http://wiki.winehq.org/Wine64
> >
> > but some of that stuff seems rather out-of-date.
> >
> > When I configure with --enable-win64 it configures fine but then
> >  errors out in widl generated code because of things like this:
> >
> > #if !defined(__RPC_WIN32__)
> >     #error Currently only Wine and WIN32 are supported.
> >     #endif
> >
> > So, is anybody working on Wine64 stuff? Is there a Wine64 TODO list?
> >  Any way for me to get involved?
> > A lot of the lowest level stuff is currently missing. If you don't
> > mind x64 assembly it's not impossible to do. We would need support
> > from gcc for the windows calling convention, and making it possible to
> > mix linux calling convention with windows calling convention. If you
> > are up to it just make it ignore the error for now, even if it causes
> > errors. A proof of concept "Hello, world!" would be a great
> > accomplishment at this point.
>
> Cheers,
> Maarten.

These days there is a 64bit version of mingw (mingw64 or so it is called). They must have patches to add the calling convention to gcc now. I'm not sure what the status is on merging the changes back but I think nothing forbids you from building gcc from their sources. I have no idea whether having the calling convention is enough for Wine.

Roderick
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

[Anssi Hannula]

Roderick Colenbrander wrote:
> Maarten wrote:
> > A lot of the lowest level stuff is currently missing. If you don't
> > mind x64 assembly it's not impossible to do. We would need support
> > from gcc for the windows calling convention, and making it possible to
> > mix linux calling convention with windows calling convention. If you
> > are up to it just make it ignore the error for now, even if it causes
> > errors. A proof of concept "Hello, world!" would be a great
> > accomplishment at this point.
>
> These days there is a 64bit version of mingw (mingw64 or so it is called).
> They must have patches to add the calling convention to gcc now. I'm not
> sure what the status is on merging the changes back but I think nothing
> forbids you from building gcc from their sources. I have no idea whether
> having the calling convention is enough for Wine.

The changes have been applied to gcc trunk, about a year ago IIRC.

Regarding mixing conventions, I had the following discussion with the
developer who implemented the convention in gcc (I didn't pursue the
matter further, though):

Kai Tietz wrote:
> Anssi Hannula <anssi.hannula(a)gmail.com> wrote on 26.05.2007 13:03:38:
> > However, as the Wine project needs to support running win64 binaries on 
> > x86_64 Linux platforms, we need to able to specify MS ABI in 
> > per-function basis as we call linux functions as well.
> >
> > I.e. we'd need something like __attribute__(__msvccall__) to specify the 
> > functions that need to have MS ABI calling convention, even when the gcc 
> > target is not x86_64 mingw.
> >
> > Do you think this is possible and/or if it would hard to implement?
>
> This shouldn't be very hard to do. In i386.c, where the ABI specific 
> calling conventions are done, it can be introduced easily by using an 
> attribute modifier to choose between the different calling conventions 
> AFAICS.

-- 
Anssi Hannula