This is the mail archive of the
mailing list for the Cygwin project.
Re: Multiple cygwin installs: I have to do it, but how?
- To: Peter Buckley <peter dot buckley at cportcorp dot com>
- Subject: Re: Multiple cygwin installs: I have to do it, but how?
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- Date: Thu, 11 Oct 2001 16:05:03 -0400
- CC: cygwin at cygwin dot com
- References: <3BC5B226.email@example.com> <3BC5C7B1.BF4ABFB7@cportcorp.com>
forwarded to the list on behalf of Bob Cunningham. disclaimer: the
following represents Bob's views and not my own.
Thanks Peter. I'm monitoring the list from the Web always up-to-date
archives at: http://sources.redhat.com/ml/cygwin/2001-10/
Let's forget new-vs-old issues for now: There's still the generic
question: **Should** multiple Cygwin installs be supported/allowed? In
*any* way, shape or form?
Remember, multiple instances are possible for the majority of
applications under any/all operation systems: Simply install additional
copies in separate directories. We all do this all the time.
This doesn't work for Cygwin for at least two reasons (and probably
several more, as yet unidentified):
1. The cygwin DLL uses a shared/common memory area.
2. Mount points are kept in the Registry.
I'd like to see both of the above made optional in Cygwin, or
(preferably) eliminated completely. Otherwise, Cygwin will be used by
PC and Windows vendors to make you buy more PCs and more Windows
licenses: "Need an additional Cygwin environment? Get another PC." ;^)
In essence, the above design/implementation decisions serve to "lock"
Cygwin to a single instance on a single system. Period. On my systems,
not even Operating Systems have that right! (I use Win4Lin whenever I
can, and Cygwin when I can't.) I suppose I *could* use VmWare to
configure multiple NT environments, just so each could have its own
Cygwin environment. Silly, I know, but that's what Cygwin presently
It now seems there is no quick or direct solution to my problem: Only a
Cygwin redesign can allow a generic solution. The alternative (getting
vendors to all act the same) will be like herding cats, and I suspect
the results will be just as useful. For this reason, I'm going to
recommend to all such vendors that they avoid using Cygwin (or start
shipping VmWare or a PC with their Cygwin-based products). After all,
ANY non-Cygwin CLI tool implementation will still be useful within my
personal Cygwin environment. Only a "Cygwin native" port of such tools
screws things up.
So, it seems the Cygwin developer community has a decision to make. I
see three distinct paths:
1. Tell vendors NOT to distribute Cygwin with their products.
Furthermore, any products that are Cygwin dependent should follow a
stringent set of functional and packaging guidelines. Such guidelines
would certainly need some sort of verification/validation mechanism.
2. Eliminate any and all restrictions that make Cygwin unable to coexist
with multiple instances of itself. Heck, there's even a full user-mode
port of the Linux kernel that can run multiple instances of itself under
Linux. Why not Cygwin under NT?
3. The status quo: "Each Cywgin environment needs its own OS instance."
At the very least, vendors considering Cygwin should know this
limitations exists, and what its significant negative impact is for
users of their tools who are already Cygwin users.
Does that just about cover the issue?
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html