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] |
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? > > 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? Like the other post mentioned one solution might be sizeof(LONG) != sizeof(long).
Attachment:
0xED74C077.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |