This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Cygwin 64 bit?


On Jun 27 22:56, JonY wrote:
> On 6/27/2011 20:59, Corinna Vinschen wrote:
> >>> I suspect we'll come out ahead in the end by following Linux and doing
> >>> the translator -- the number of native windows apps compiled with
> >>> cygwin-gcc (and which can't use mingw-gcc) seems a rather small fraction
> >>> of the total, and posix apps could become a royal pain to compile on
> >>> cygwin if sizeof(long) != sizeof(void*).
> >>>
> >>>
> >>
> >> So, some sort of thunk server/client thing in between the Cygwin DLL and
> >> system DLL?

Why should that be necessary?  This sounds a bit like a misconception.
In the 32 bit version we're just calling Win32 and native NT functions.
And we'll do the same in the 64 bit version, just that it calls the same
functions in the 64 bit Windows DLLs.  I don't see where thunking or a
client/server model comes into play here.

The only important thing to keep in mind when hacking code is that
certain assumptions are dangerously wrong now.  DWORD, ULONG, LONG are
no longer the same size as long and unsigned long.  HANDLE is now a 64
bit type, but only the lower 32 bit are used to allow duplicating
handles between 32 and 64 bit processes.

And note to myself:  Using %p to print the NT status in debug output
is wrong now.  Replace with 0x%08x.

> > What is that good for?  Cygwin apps are POSIX apps, Cygwin DLLs are
> > POSIX libs.  They only interact with the Cygwin DLL.  If they also
> > use Win32 API, they are on their own and they better use Win32 types
> > like DWORD, etc.  I don't see any need to make this even a bit more
> > complicated than necessary.  Apart from that, the only non-POSIX
> > DLL is the Cygwin DLL itself.  If it doesn't interact cleanly with
> > the Win32 API it goes boom and we fix.
> >
> 
> Yeah, I meant the Cygwin DLL itself, how does it communicate/thunk the
> ABI difference when talking with win32/win64 API?

If the cygwin compiler uses the same ABI as Windows, which would make
sense, there won't be a API difference.  The fact that long is != LONG
is not important for the ABI.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]