Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <3BC5FF34.9030300@ece.gatech.edu> Date: Thu, 11 Oct 2001 16:21:08 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Multiple cygwin installs: I have to do it, but how? References: <3BC5B226 DOT 104 AT ece DOT gatech DOT edu> <3BC5C7B1 DOT BF4ABFB7 AT cportcorp DOT com> <3BC5FB6F DOT 7040408 AT ece DOT gatech DOT edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 system. > 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. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/