RFC: Cygwin 64 bit?

Ryan Johnson ryan.johnson@cs.utoronto.ca
Mon Jun 27 12:53:00 GMT 2011


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



More information about the Cygwin-developers mailing list