dll version collision - my old and now broken solution

["Max Bowsher" <maxb at ukf dot net>]

[Sorry not to add to this thread sooner. Exams have been keeping me
unavoidably busy.]

AFAIK, using multiple independent Cygwin environments simultaneously is
impossible without recompiling a modified cygwin1.dll under a different
name, and then either recompiling or hex-editing every dll and exe you wish
to use in the modified environment to load the alternative dll name.

Obviously, this is a non-trivial operation (and I haven't started discussing
the modifications to the cygwin dll yet.) Anyone attempting this should be
aware that the cygwin list does not support modified versions of cygwin.

----------------------------------------------------------------------------
------------
Sidenote to Michael Hale:
Why not just compile a "last known good" list of package versions, maintain
an internal mirror, and tell your developers "use a recent version of
cygwin, fall back to the known good versions if you have problems"? That
would seem achieve most of your goals with a *lot* less pain.
----------------------------------------------------------------------------
------------

OK, so if you still think that modifying the Cygwin dll is a good idea, and
are prepared to receive limited, if any, support from this list:

*** Be warned that this info is incomplete! It used to work, some time in
the past, but when I tested it, I got a broken modified bash, that couldn't
start any subprocesses. So if you are prepared to take my work and enhance
it, please go ahead! (Naturally I'd quite like to know if any successes are
made). But do not think that the below text is a cookbook solution. ***

For the most part, the changes are a careful manually-directed search and
replace through the winsup/cygwin (and possibly winsup/utils) directories.

The remaining issue is one Igor indirectly referred to. If you run a
modified cygwin process from an unmodified one, or vice versa, you still get
version mismatches. The problem is the child_info struct, aka the
lpReserved2 data in CreateProcess. Here's a nice webpage I found:
http://www.catch22.org.uk/tuts/undoc01.asp

Extremely fortunately for our purposes, only 4 bytes of leading zeros are
required to avoid the nasty Microsoft C-runtime interactions mentioned in
that webpage, whilst Cygwin uses 16 bytes. We can therefore use the
intermediate 12 bytes to fill with our own magic number, isolating us both
from official Cygwin and from Microsoft C-runtime apps.

At least, it did, a long time ago.
Attached is my patch, updated to apply cleanly (though not to work!) with
current CVS.

Have fun!
Don't bother the list with "this is broken, help me fix it" emails.
Let me know of any progress.

Max.

Attachment: cygwin-isolation-mygwin-1510.patch
Description: Text document

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/