Re: RFC: Cygwin 64 bit?

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

On 8/6/2011 10:44 PM, JonY wrote:
> Most programs that were built under Cygwin 1.5 kind of still work when
> used under Cygwin 1.7, so no need for a separate cygwin9x. I don't see
> how that will apply to 64bit Cygwin interacting with 32bit DLLs unless
> some special loader tricks are applied.

But if I understand the first few messages in this thread, Corinna has
found a way that the 64-bit cygwin dll and the 32-bit cygwin dll can
share information.

The issue isn't "some 32bit app using 64bit dlls" or vice versa. It's
that, apparently, we CAN have a mixed system where 32bit *apps* and
64bit *apps* can interact.

For instance, a 64bit bash /may/ be able to fork/then-exec a 32bit
client application.  And receive its error code, and hook up its stdio.

This is why some folks (Yaakov excepted!) have been pushing for a new
prefix for the 64bit dlls: so that all the various dlls can live in the
same bin/ directory (*) where the exe's (whether 32 OR 64bit) live.
32bit exe's will load 32bit cygwin and 32bit dll's; 64bit exe's will
load 64bit cygwin and 64bit dll's -- but can still communicate via
cygwin(32) and cygwin(64)'s shared comm mechanism (whatever it is).  As
different *exes* are released in 64bit form, setup.exe on a 64bit system
would "upgrade" that exe to the 64bit version (and install its 64bit
prereq DLLs).  Ideally, the user upgrade experience would be seamless,
gradual, and more-or-less unnoticed.  (devs, OTOH, might have more of a
challenge).

(*) Even if we WERE to adopt a cyg64 naming scheme, we'd ALSO have to
adopt a new naming scheme for the packages which deliver those DLLs, so
that $user could install both cygz-1.dll and cyg64z-1.dll.

--
Chuck