From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3337 invoked by alias); 3 Nov 2003 10:30:51 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 3324 invoked from network); 3 Nov 2003 10:30:49 -0000 Received: from unknown (HELO i2kc03-ukbr.domain1.systemhost.net) (217.32.164.138) by sources.redhat.com with SMTP; 3 Nov 2003 10:30:49 -0000 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc03-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 3 Nov 2003 10:30:47 +0000 Received: from i2km38-ukdy.domain1.systemhost.net ([193.113.30.77]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 3 Nov 2003 10:30:47 +0000 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" Content-Transfer-Encoding: quoted-printable Subject: RE: Multiple Cygwins/ Distributing Cygwin apps Date: Mon, 03 Nov 2003 10:30:00 -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] X-SW-Source: 2003-11/txt/msg00081.txt.bz2 Okay, John:=20 Blindly cutting through all the 'philosophical arguments' and getting to th= e crux of the matter.=20 Yes, you CAN install several different cygwins (or anything else) onto ONE = machine. Techniques like this have always (AFAIK) been used in the mainfram= e world but, for some reason, seem to get ignored for smaller machines.=20 To be a little PC-specific:=20 Have more than one hard drive on your PC, or partition up your hard drive i= nto handy chunks. There are plenty of partitioning tools around - I prefer = PowerQuest's 'Partition Magic'.=20 Install your op system of choice into each of the hard drives or partitions= separately, hiding one partition while installing into another.=20 Unhide all partitions and use a boot manager to give you a multi-boot scena= rio - okay, I use PowerQuest's 'Boot Magic', but there's MANY other to choo= se from - even Micro$oft's ! ! !=20 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 u= se a different version of cygwin.=20 Points to note:=20 When performing any 'Micro$oft software updates' - like 'service packs' - h= ide all but the partition you are working on until after the first re-boot = past the installation. The Micro$oft installer is aggressive !=20 You'll find that you can use this technique to keep one, or more, windoze p= artitions relatively clean and uncluttered - leading to fewer problems with= windoze (like a big, messy registry).=20 You don't need to have multiple windoze licenses for this technique as ther= e 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' cop= ies.=20 Of course, this technique works for op systems other than just windoze.=20 Hope the above is of use to you and helps get around the problem.=20 Kevin.=20 =20=20=20 -----Original Message----- From: John Moore [mailto:gmanenews@tinyvital.com] Sent: 03 November 2003 01:29 To: cygwin@cygwin.com Subject: Multiple Cygwins/ Distributing Cygwin apps I have done a bunch of googling and I find this subject comes up=20 periodically. I have just spent many wasted hours because a vendor=20 shipped a tool I have to have (customer mandate), tightly integrated=20 with a cygwin that is old and has a buggy cvs. Meanwhile I am using=20 another cygwin for another customer... the latest version. For me, the inability to install two cygwins that are independent has=20 already cost me a bunch of time. When I grumbled to a friend, his answer=20 was "buy another machine for that application." This is a poor answer, but I may have to. Or I'll have to find what=20 magic has to be switched to instantiate one and hide the other...=20 something that is mentioned in some of the email I found, but no details=20 were given. Cygwin is a great tool and it has this really neat installer so I can=20 keep it up to date. But when a vendor ships a binary, that vendor must=20 ship a binary Cygwin DLL, and there is no way it is going to match my=20 latest version. This creates a problem. I have seen two basic reasons stated that more than one cygwin shouldn't=20 be supported: 1) It's not an important problem 2) Tell the vendors to always ship the latest version of cygwin,=20 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=20 to this project, but over the last 35 years I have designed a lot of=20 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=20 continues. Either large numbers of folks will be using Cygwin, or they=20 won't. Either vendors will be releasing Cygwin based products or they=20 won't. If they do, and lots of people use Cygwin, it is an important=20 problem. If it remains a problem, Cygwin usage will go down. After all,=20 if I tell my vendor that I don't want their product because it is=20 incompatible with my system, they don't care. They have lost one sale,=20 but there are plenty of folks that are without Cygwin, so this is no big=20 deal. If a vendor gets lots of complaints, he is going to go away from=20 Cygwin. I wish my current vendor had just used Windows environment...=20 then I wouldn't be facing this issue. #2 is ridiculous, pure and simple. Vendors aren't going to spend their=20 time creating and support lots of version of their software just to stay=20 in sync with Cygwin. And they are going to bundle cygwin because 99% of=20 their customers don't have it, and the vendor wants to create an easy=20 installation for this vast majority of their customers. #3 I don't believe either. I have heard the argument that a cygwin=20 program needs to know which DLL to load and which registry entries to=20 use, and that just isn't possible. But it is actually trivial. The DLL path searched starts where the=20 cygwin application starts, so that is one way to separate DLL's. A=20 single environment variable can define which registry entry to use. It=20 can also define the name of the shared memory segment. It could also=20 name the DLL, if one wanted to go that way. Hey, that's what environment=20 variables are: a way to define different environments for software. Now I'm probably missing some big technical problems, but I'm curious=20 what they are. I would like cygwin to allow multiple versions. I can tell from google=20 that others would like this too. And vendors, especially small vendors,=20 can greatly reduce their development costs if they can distribute=20 command line cygwin tools rather than developing windows kluges, which=20 is no doubt why we are starting to see this problem. I multiple simultaneously functioning installs are a problem, how about=20 adopting a project goal that supports multiple one-at-a-time versions of=20 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=20 have created and continue to work on cygwin. It is a great thing to have=20 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/