This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
[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/
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |