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: <01e001c152ac$3e9d8e10$0200a8c0@lifelesswks> From: "Robert Collins" To: , References: Subject: Re: Multiple cygwin installs: I have to do it, but how? Date: Fri, 12 Oct 2001 09:27:07 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 11 Oct 2001 23:33:00.0040 (UTC) FILETIME=[105C7880:01C152AD] ----- Original Message ----- From: To: Sent: Friday, October 12, 2001 7:01 AM Subject: Re: Multiple cygwin installs: I have to do it, but how? > 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. Uh, to draw an analogy, what you are saying is that the Linux kernel is a singleton, and with the correct abstraction layer multiple kernels can coexist at once. Well, actually they cannot - witness user mode linux - AFAIK the user mode linux is not able to be booted from as the base kernel, it can only be booted into within Linux. > 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 Chuck has pointed out, you are not allowing for a bootstrap - how does each 'instance' identify itself? If your answer is a compile time switch to cygwin1.dll, well then this ALREADY EXISTS. See the mailing list and you can build your own cygwin2.dll that uses a different registry key. See that was easy. > 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? I suggest you actually grab the cygwin source and read for a little. The common memory area is *not optional* and *is always used*. Having different names for that is not *supported* but can be done by those-who-are-willing-to-support-themselves. > 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). This is so far off-base I can't believe it. Cygwin1.dll is automatically loaded by the OS. If you want a binary to use a different cygwin1.dll, you have only two choices: 1) Use the path luke. 2) Use a different .dll name. > 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 logic is false. a) Cygwin1.dll is what you want to associate with given .exe's. b) cygwin1.dll is autoloaded. c) HOW CAN IT REPLACE ITSELF TRANSPARENTLY? > 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). Actually there is a very very very good reason. The windows linker does not support asking the user which .dll to load with. > Someone, please tell me this is too simple to work. (Not necessarily easy > to implement, but conceptually simple.) Conceptually you have missed the ballgame. Let me point out a few things: 1) Cygwin1.dll takes the place of libc in a linux environment. 2) AFAIK you cannot have two copies of a single libc with the same major version on a single machine. 3) You can have two copies if the major version is different. 4) With cygwin you can have two copies if the major version is different. Thus cygwinb19.dll(??) and cygwin1.dll co-exist. 5) Cygwin is not an "environment". Cygwin is a .dll, pure and simple. It's got no *portable* means to tell a new process what copy of cygwin1.dll to load, so 80% of your idea won't work. 6) The other 20% IS ALREADY IN PLACE. AND YOU"VE BEEN GIVEN A POINTER. There is no reason for vendors that distribute copies of cygwin1.dll - the net release with source - to spend man-weeks fiddling around to make everything separate. All they need to do is ship the cygwin1.dll with the cygwin setup program and a local cache dir already created. Then for their specific apps - say gcc + scripts - all they have to do is integrate them the *same way* they would on a unix system. No problem, no fuss. If they choose not to, that is their problem, and they will lose customers. As a part time hacker on cygwin, I've spent far to many hours trying to tweak performance up to consider adding the sort of overhead you are proposing simply to allow *software vendors* to get away with sloppy product integration. And finally, as for the idea of "want two cygwin's get two PC's".... AHAHHAAHAHAHAHAHAHHHAHAHAHHAHAHAHAHAHAHA Rob -- 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/