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 27/06/2011 8:11 AM, JonY wrote:
On 6/27/2011 20:00, Ryan Johnson wrote:
On 26/06/2011 8:52 PM, JonY wrote:
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.
How does that happen for per-app?
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.

Given that, the earlier suggestion to put 64-bit binaries first in the path probably makes the most sense.


- 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?
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.

If LONG != long, we'll also have to worry about the inevitable posix app defining conflicting typedefs, but hopefully that wouldn't import the windows headers.

Ryan


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