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:00, Ryan Johnson wrote:Actually, in retrospect, I think it would happen automatically. If I understand correctly, Windows always searches the binary's own '.' first, followed by %PATH%. That would cover loading of static libraries, dlopen, and fork. So, if the user starts an N-bit app and then forks some app having both 32- and 64-bit versions available, Windows would select the N-bit version unless the file name given forces use of the other.On 26/06/2011 8:52 PM, JonY wrote:How does that happen for per-app?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.
We'll probably have to tweak %PATH% per-app, though -- 64-bit apps would need the Cygwin64 first and Cygwin second, with that reversed for 32-bit apps.
Something like Wow64, I guess. Most winapi calls have a pretty narrow interface as far as long/LONG goes, so it shouldn't be too hairy to make the conversion. Also, for anything exotic, the target audience is Windows programmers using cygwin, and they'll be using LONG properly already.- 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.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?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |