This is the mail archive of the 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]

Re: Multiple cygwin installs: I have to do it, but how?

Charles Wilson wrote:

> 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?

Possibly.  right now it IS possible -- but it requires knowledge on the 
part of the user who wants to do this.  The real question is: should 
cygwin easily and seamless support multiple installations on the same 

> 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.

Not entirely true.  ANY application that uses the registry at all will 
comingle settings between multiple installations, unless those settings 
are segregated by version number or something.  But even then, if you 
want two instances of the same version -- "Office 97" and "Office 97 Sm. 
bus. edition" for instance -- you get conflict.

> 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.  

Fine.  Please explain how to do this.  There are *REASONS* why the mount 
settings are stored in the registry -- not least of which is "if they 
were stored elsewhere -- in the file system -- how would you find it?" 
Bootstrapping the dll is a big problem.  The registry "solves" that 
problem.  How would you solve it?

> 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."  ;^)

Sorry, bob, but this is hysteria.

> 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 
> dictates!

Again, BS.  Even if you avoid the fancy tricks that I mentioned, you 
could still have multiple cygwin's the same way you have multiple OS's 
-- you have to reboot to change environments.  NT(1)+cygwin1, 
NT(2)+cygwinB19.  I did this for years: Win95+cygwin, WinNT+cygwin. 
They were completely separate -- but on the same machine.

> It now seems there is no quick or direct solution to my problem:  Only a
> Cygwin redesign can allow a generic solution.  

No, but a cygwin recompile will allow a generic solution.  See, cygwin 
is open source, so these companies can do this if they want to.  The 
question is: do they want (1) to set up an isolated sandbox for their 
users, (2) integrate with existing tools without having to recompile all 
the net-available apps themselves, or (3) make a mess in the playground.

Currently, they are doing (3).  But perhaps they'd be willing to do (1) 
or (2) -- if they knew of the problem.

> 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.

That's logical.  "I like cygwin so much that I use it for non-vendor 
supported tasks.  Therefore, Mr. Vendor sir, please do not use cygwin 
yourself because I like cygwin."

How about, "Mr. Vendor sir, please coordinate with the Red Hat people 
concerning how your product's installation procedure can be harmonized 
with more recent cygwin releases"

> 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.

Vendors are free to do what they want, as long as they abide by the GPL 
or purchase a proprietary license from Red Hat.  Other than that, we can 
only encourage.  But they'd listen more to their own paying customers. 
Hint hint.

> 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?

Ah, but can those linux instances run native NT programs in the parent 
NT environment (no, WINE doesn't count)?  You're comparing apples to 
oranges; we operate under different constraints.

As for "why not" -- see the bootstrapping discussion above.  If you have 
a solution, PLEASE share it.  I'm at a loss.

> 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.

I'm sure the app vendors know this.  More likely, it is *their* 
documentation for their endusers that is lacking.

> Does that just about cover the issue?

Hyperbole?  check.
Rash decisions to un-recommend cygwin? check
Wild statements without factual basis? check
Suggestions without offers of assistance? check

Yep, looks like you covered everything.


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]