RFC: Cygwin 64 bit?

Andy Koppe andy.koppe@gmail.com
Sun Jun 26 20:15:00 GMT 2011

On 26 June 2011 12:45, Corinna Vinschen wrote:
> I'm not sure if you agree, but as far as I can see, 32 bit systems are
> more and more reduced to a niche market, namely Netbooks and other very
> small systems.  On the Desktop, 32 bit is declining fast, in the server
> segment it's practically dead.
> Given this, I'm wondering how much future Cygwin has if we stick to
> 32 bit.  I think it will be pretty limited.  In fact, we're probably
> rather late in the game.

I agree. Even though the advantages for programs that don't have much
use for 64-bit integers or pointers are modest, the '*32' in Task
Manager will increasingly be interpreted as 'legacy'.

> Lately I read a bit more about how 32 and 64 bit processes can interact
> with each other on Windows, and it seems we could come up with a 64 bit
> DLL which shares all important information with its 32 bit counterpart,
> so that we could run 64 and 32 bit processes in parallel on a 64 bit
> system acting as a single system.  This would be especially important,
> given the fact that 64 bit Cygwin applications will be pretty rare in
> the beginning.

That would be brilliant, because getting 64-bit versions of all the
packages looks like the biggest challenge to me. Something like the
1.5/1.7 unionfs might be helpful here.

> As far as I can see what we have to do in about this order is
> - Discuss certain basics.  This is probably the most crucial step.
>  For instance:
>  - What name should the 64 bit DLL have?

That question applies not just to the Cygwin DLL but also to every
other library.

>  - Where should 64 bit binaries and libs go?

What does Linux do?

(Also, do libraries still need to go into the same directory as executables?)

>  - Do we define "long" as 32 bit or 64 bit type?

Oooh, that's a difficult one. (For anyone who doesn't know: It's 64
bits on Linux, but 32 bits on Windows, including MinGW-64.)

I suspect 64 bits would be possible, but painful, due to LONG != long.
I guess it depends on how many programs use 'long' where they should
be using 'int64_t' or 'intptr_t'. Are there other 64-bit Unixes where
long == 32 bits?

>  - What defines should a 64 bit Cygwin compiler define?

Again, what does Linux do? (Avoiding additional Cygwin-specific
defines would be nice.)

>  - What Windows headers and link libs do we use?

Meaning: can we use MinGW-64's, or do we need to create our own fork
of MinGW's 32-bit ones?

> - Decide how we can integrate 64 bit stuff into the distro.  Will we have
>  a 32 bit and a distinct 64 bit distro?

I'd say yes, but wind down development of the 32-bit one as the 64-bit
one becomes stable enough, similarly to what happened with 1.5.

Packaging resources are thinly spread as it is, so maintaining two
distros in parallel might not work out well long term.

> - Change setup to allow installation of 64 bit stuff on 64 bit systems.

It would be good if setup didn't need any substantial changes (or a
64-bit version) for this.

> This is a big project which can only work if we have help and support
> from the community.  Before we can even contemplate to start discussing,
> I would like to learn:
> - How much interest do you have in a 64 bit Cygwin?
> - How much interest do you have to help to make 64 bit Cygwin real?
> - What part of the project would most interest you to help?  Coding
>  Cygwin?  Documentation?  Setup?  Toolchain?  You name it.

I'd try to port mintty as soon as practical, and I can chip in with
newlib as well. Unfortunately I can't promise an awful lot of time

(I see there's a libc/machine/x86_64 directory in newlib. Has this
x86_64 support been used in anger?)


More information about the Cygwin-developers mailing list