Design mixed 32 and 64 bit systems.

Warren Young warren@etr-usa.com
Mon Dec 2 19:35:00 GMT 2013


On 11/27/2013 13:11, Buchbinder, Barry (NIH/NIAID) [E] wrote:
>
> My question is why 64 bit wasn't named cygwin2.dll?

While I agree that there is justification for that on "different ABI" 
grounds, it doesn't solve the core problem.

That being, the Cygwin DLL maintains a bunch of shared data structures 
to provide the POSIX emulation that Cygwin programs require.  Different 
DLLs mean different memory spaces, which means two *independent* sets of 
these data structures.

Consider a simple case: parent PID.  A 64-bit Cygwin program launches a 
32-bit Cygwin program.  What goes getppid(2) return in the child?

Take a second and think about it.

Got your guess?  Okay, now put the two attached C++ files into a 
directory that both Cygwins can see (/cygdrive/c for example) and build 
them.  The easiest way to do that is to say "make child32" from Cygwin 
32 and "make parent64" from Cygwin 64.

Now from Cygwin 64, run parent64.  Does the output match your guess?  I 
bet you'll find it surprising!

------- BEGIN SPOILER --------

This happens because POSIX PIDs are in a table that lives in 
cygwin1.dll's memory space, and because there are two DLLs, there are 
two different PID tables.

-------- END SPOILER ---------

You don't run into this problem on "real" 32/64-bit OSes because there 
is only one kernel, and the 32 vs 64 bit differences are abstracted away 
by the syscall layer, so that everything becomes 64-bit within kernel 
space.  There is no single central entity in Cygwin, since Cygwin runs 
entirely in user space.

Perhaps one could build a special 32-bit cygwin1.dll that worked like 
Wow64[*].  It may not be possible without kernel level support, from a 
driver at least.  On the other hand, it can't be any more tricky than 
building something like VirtualBox.  The question then is whether it's 
worth the effort.


[*] http://goo.gl/oYbLwg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: child32.cpp
Type: text/x-c++src
Size: 159 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-talk/attachments/20131202/026be9c6/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parent64.cpp
Type: text/x-c++src
Size: 460 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-talk/attachments/20131202/026be9c6/attachment-0001.bin>


More information about the Cygwin-talk mailing list