Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Multiple Cygwins/ Distributing Cygwin apps Date: Mon, 3 Nov 2003 10:30:43 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: To: , X-OriginalArrivalTime: 03 Nov 2003 10:30:47.0460 (UTC) FILETIME=[8B6AD640:01C3A1F5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id hA3AVEaN020529 Okay, John: Blindly cutting through all the 'philosophical arguments' and getting to the crux of the matter. Yes, you CAN install several different cygwins (or anything else) onto ONE machine. Techniques like this have always (AFAIK) been used in the mainframe world but, for some reason, seem to get ignored for smaller machines. To be a little PC-specific: Have more than one hard drive on your PC, or partition up your hard drive into handy chunks. There are plenty of partitioning tools around - I prefer PowerQuest's 'Partition Magic'. Install your op system of choice into each of the hard drives or partitions separately, hiding one partition while installing into another. Unhide all partitions and use a boot manager to give you a multi-boot scenario - okay, I use PowerQuest's 'Boot Magic', but there's MANY other to choose from - even Micro$oft's ! ! ! Now boot into one copy of your op system to install and use one version of cygwin, then re-boot into the other copy of your op system to install and use a different version of cygwin. Points to note: When performing any 'Micro$oft software updates' - like 'service packs' - hide all but the partition you are working on until after the first re-boot past the installation. The Micro$oft installer is aggressive ! You'll find that you can use this technique to keep one, or more, windoze partitions relatively clean and uncluttered - leading to fewer problems with windoze (like a big, messy registry). You don't need to have multiple windoze licenses for this technique as there is just ONE user (you), ONE machine (yours) and you can only boot and run ONE copy of windoze at a time - the other(s) being legitimate 'backup' copies. Of course, this technique works for op systems other than just windoze. Hope the above is of use to you and helps get around the problem. Kevin. -----Original Message----- From: John Moore [mailto:gmanenews AT tinyvital DOT com] Sent: 03 November 2003 01:29 To: cygwin AT cygwin DOT com Subject: Multiple Cygwins/ Distributing Cygwin apps I have done a bunch of googling and I find this subject comes up periodically. I have just spent many wasted hours because a vendor shipped a tool I have to have (customer mandate), tightly integrated with a cygwin that is old and has a buggy cvs. Meanwhile I am using another cygwin for another customer... the latest version. For me, the inability to install two cygwins that are independent has already cost me a bunch of time. When I grumbled to a friend, his answer was "buy another machine for that application." This is a poor answer, but I may have to. Or I'll have to find what magic has to be switched to instantiate one and hide the other... something that is mentioned in some of the email I found, but no details were given. Cygwin is a great tool and it has this really neat installer so I can keep it up to date. But when a vendor ships a binary, that vendor must ship a binary Cygwin DLL, and there is no way it is going to match my latest version. This creates a problem. I have seen two basic reasons stated that more than one cygwin shouldn't be supported: 1) It's not an important problem 2) Tell the vendors to always ship the latest version of cygwin, with the implied therat of losing market share. 3) It's too hard or impossible to run two cygwins. Personally, I don't buy any of these. Of course, I haven't contributed to this project, but over the last 35 years I have designed a lot of systems in a lot of OS's (or designed the OS's). As to #1, that will become a self supporting prophecy if this situation continues. Either large numbers of folks will be using Cygwin, or they won't. Either vendors will be releasing Cygwin based products or they won't. If they do, and lots of people use Cygwin, it is an important problem. If it remains a problem, Cygwin usage will go down. After all, if I tell my vendor that I don't want their product because it is incompatible with my system, they don't care. They have lost one sale, but there are plenty of folks that are without Cygwin, so this is no big deal. If a vendor gets lots of complaints, he is going to go away from Cygwin. I wish my current vendor had just used Windows environment... then I wouldn't be facing this issue. #2 is ridiculous, pure and simple. Vendors aren't going to spend their time creating and support lots of version of their software just to stay in sync with Cygwin. And they are going to bundle cygwin because 99% of their customers don't have it, and the vendor wants to create an easy installation for this vast majority of their customers. #3 I don't believe either. I have heard the argument that a cygwin program needs to know which DLL to load and which registry entries to use, and that just isn't possible. But it is actually trivial. The DLL path searched starts where the cygwin application starts, so that is one way to separate DLL's. A single environment variable can define which registry entry to use. It can also define the name of the shared memory segment. It could also name the DLL, if one wanted to go that way. Hey, that's what environment variables are: a way to define different environments for software. Now I'm probably missing some big technical problems, but I'm curious what they are. I would like cygwin to allow multiple versions. I can tell from google that others would like this too. And vendors, especially small vendors, can greatly reduce their development costs if they can distribute command line cygwin tools rather than developing windows kluges, which is no doubt why we are starting to see this problem. I multiple simultaneously functioning installs are a problem, how about adopting a project goal that supports multiple one-at-a-time versions of cygwin, and put the details in a faq or a shipped script? Finally, regardless of how all this comes out, I want to thank those who have created and continue to work on cygwin. It is a great thing to have and I use for all of my work. Thanks John Moore -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/