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 01:59, Corinna Vinschen wrote: > > Right, but that wasn't what I meant. Sorry for being unclear. I was > talking about the name of the Cygwin DLL. For instance, if we decide > that it must reside in the /bin directory, it must have a different name > than the 32 bit dll, for instance, cygwin64-1.dll. If we decide that > all 64 bit applications and DLLs reside in a parallel directory, it > could have the same name, for instance, /bin64/cygwin1.dll. > > But let's not go into too much detail yet. > I was thinking that we have them totally separated, so we don't need to deal with DLL name clashes. Eg C:\Cygwin for 32bit and C:\Cygwin64 for 64bit. No need to invent bin32 or bin64. >>> - Create a x86_64-pc-cygwin cross toolchain. >> >> Yeah, I suppose newlib has to be ported first. > > Right, I forgot about that one. But newlib works rather well for many > systems, so that shouldn't be much of a problem. > There's that hairy LP64 vs LLP64 issue, personally, I'd prefer the LLP64 route since Cygwin is a translation layer and will need to communicate with Windows at the backend, but I suspect many more will want the LP64 route for Posix software compatibility. I suppose there could be a minimalist Cygwin fork of the win32api to make it LP64 compatible. Maybe a thunk/translator layer will be easier. > > That sounds kind of funny, given that you're the mingw64 maintainer :) > Anyway, the Win32 API and the native NT API are already in use just > fine. It's the porting from 32 to 64 bit which is the problem. The > calls will only marginally change, if at all. > > There's also the fact that there isn't only core Cygwin to work on. > Newlib, for instance. Or any of the stuff I mentioned above. There's > a lot to do, I fear :} > > Well, I do work with win32 API from time to time, but I'm unfamiliar with the using anything more complicated, eg NTDLL and its native API friends. I can try checking what works or what doesn't for 64bit newlib, I hope syscall emulation is just copy and pasting.
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] |