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 Subject: Re: Multiple cygwin installs: I have to do it, but how? To: cygwin AT cygwin DOT com X-Mailer: Lotus Notes Release 5.0.1b September 30, 1999 Message-ID: From: RCUNNINGHAM AT redlake DOT com Date: Thu, 11 Oct 2001 14:01:28 -0700 X-MIMETrack: Serialize by Router on notes1/RSMASD(Release 5.0.2c |February 2, 2000) at 10/11/2001 02:00:39 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Thanks to a hefty dose of RTFM, I'm finally on the list. Thanks, Chuck, for forwarding my posts while I was in my clueless state. I've been thinking about it a bit more, and there is a better way to look at this issue: From an OO perspective. Right now, Cygwin is a singleton. We need only add an abstraction layer to allow multiple instances. First, the Cygwin registry entries must be tied to a specific Cygwin instance. Hopefully, the location of the Cygwin root directory alone should be sufficient to make the distinction. So, under the "Cygnus Solutions" key, there should be trees for each install, with the name of the head of each tree being simply the path to the root for that install. All the existing keys would then be replicated within that tree. Simple? As for cygwin1.dll, it needs to know which install launched it (or, conversely, which install it belongs to), which in turn will let it determine if a separate common memory area needs to be allocated and used. This would be independent of the DLL version, which would allow each install to be updated independently. (However, the DLL version *may* need to be saved in the Registry as well, though I'm not at all sure about that.) Would this work? Still, we may need a way to bind each application installation to a specific Cygwin instance. Again, we can add information to the Registry to handle this, though at this point it will be simpler to build a list of the binaries "belonging" to a given Cygwin installation within a file located under the root for that install (the logical place would be in /etc/setup). Heck, all we need to do is place only the root mount point in the registry, as the name of a key. Everything else can (and should?) be in files within the associated Cygwin installation, especially including all other mount points. Let's say an app is started that is not associated with any Cygwin installation. What should be done? The cygwin1.dll need only make the association by presenting the user with a list of the root points, and requesting one of them be selected. Then the app is added to that Cygwin instance, and it runs under that environment. This would even allow multiple Cygwin instances to share mount points, say for data or home directories. Also, there is no reason why a given program can't be "registered" to run with multiple Cygwin instances (to avoid redundant installs of apps that work fine under more than one installation). Someone, please tell me this is too simple to work. (Not necessarily easy to implement, but conceptually simple.) -BobC -- 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/