RE: Multiple Cygwins/ Distributing Cygwin apps

RE: Multiple Cygwins/ Distributing Cygwin apps

[kevin.lawton]

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@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 
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/

Re: Multiple cygwins/ Distributing cygwin apps

[Christopher Faylor]

The correct solution for dealing with multiple cygwins on your system
is to remove all of the older DLLs.

If you have a distribution which distributes cygwin and that distribution
screws up an existing cygwin installation, then complain to the people
who provided the distribution.  Their installation software is broken.

To repeat:  There is no need to keep multiple versions of the cygwin
DLL on your system.

I'm closing this thread now.

On Thu, Nov 06, 2003 at 04:51:16PM -0700, John Moore wrote:
>I now have a procedure that works on my system for allowing more than 
>one cygwin to exist on the same Windows instance at the same time (but 
>not to execute at the same time).

--
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/

Re: Multiple Cygwins/ Distributing Cygwin apps

[John Moore]

I now have a procedure that works on my system for allowing more than 
one cygwin to exist on the same Windows instance at the same time (but 
not to execute at the same time). I thank several on this list and who 
replied privately for help. For my needs, this solves the problem that 
started the thread. Perhaps it can help others.

I have put the full discussion here at 
http://www.tinyvital.com/techblog/archives/000330.html#more.

Also, part of it follows below (minus the nice HTML formatting):

--------------------------------------------------------------------------

NOTE: This will not allow both Cygwin environments to operate at the 
same time, but it will allow one to switch back and forth without 
rebooting the Windows OS. I am running this on Windows2000, but it 
should work on any modern Windows OS.

If you follow this procedure and have problems, please DO NOT BOTHER the 
Cygwin maintainers, as they will NOT answer your questions. Multiple 
Cygwins are outside of their current charter.


The approach is based on the following known or suspected cygwin 
characteristics:

...cygwin conflicts occur if cygwin discovers that there are more than 
one cygwin1.dll's on your machine

...Cygwin keeps its file system mount point information in the registry.

...It appears to discover duplicate cygwins if the "wrong" dll is in the 
Windows DLL path, if the "wrong" one is pointed to by a mount point, or 
if there is a cygwin shared memory segment (always present when a cygwin 
app is running). I am not sure this is exactly right, but it is 
consistent with my observations. In any case, the following procedure 
does work for me.

.................

First, perform the following steps [Standard warning. I am not 
responsible if this screws up your system, and if you are going to mess 
with the registry, you should know what you are doing. Read the whole 
procedure before starting.]:


...Remove the current cygwin installation if there is one (you may want 
to copy all or parts of the installation to another area).

...Make sure no keys exist in the registry named "cygwin" by deleting 
them and the appropriate parent if necessary - ("Cygnus Solutions."). It 
may not be necessary to mess with the registry, but I did. If it make 
you nervious, try without it. One alternative that may be sufficient is 
issuing the cygwin command "umount -A" - obviously before you delete 
your cygwin!

...Install cygwin in the normal fashion. In my case, against Cygwin 
recommendations, I install it in "C:/".

...Choose a directory for the switch scripts. Mine is c:/localbin - 
which is used for the rest of the example.

...Start a cygwin shell and issue the following command:"

              mount -m >c:/localbin/mount-std
         This will save the mount information from the registry into a 
script.

...Edit the script so that each mount command is an absolute windows 
style path to the mount binary for the non-standard cygwin mount.exe 
that will be installed in a later step. The absolute path is necessary 
or some mount commands will fail once the root mount path is changed. 
See the example scripts below.

...Exit ALL cygwin applications (and terminate the cygipc service or 
other daemon if they are running). This will make the shared memory 
segment go away.

...Issue the following command to hide the current cygwin installation 
from the new one to be installed:

              umount -A


...Install the new cygwin, but NOT with the same cygwin root directory 
as the "standard" one. I installed mine on H:/cygwin. This may or may 
not be an option on the distributed software.

...Start a shell from the new cygwin (to make the other script):

...mount -m >c:/localbin/mount-ven


...Edit the script so that each mount command is an absolute windows 
style path to the mount binary for the standard cygwin mount.exe.

----------------------------------------------------------------------

Now, if you are running in the non-standard cygwin environment, to 
switch to the standard environment:


...Stop all cygwin programs (including daemons) except one shell.

...In that shell, execute the mount-std script as follows (at least for 
my system):

       . c:/localbin/mount.std


...Exit from that shell

At this point you can run applications from the standard cygwn. BE 
CAREFUL not to run any applications from the other cygwin or things will 
get and stay screwed up until you end all running cygwin applications!

If you are running the the standard cygwin environment, and want to 
switch to the non-standard environment, do everything like the previous 
procedure, except invoke mount-ven. At that point, you can run anything 
from the non-standard environment ONLY (see caution above).



--------------------------------------------------------------------------------


My mount-std script:

mount -f -s -b "M:" "/mnt/cdrom"
mount -f -s -t "c:" "/cygdrive/c"
mount -f -s -t "d:" "/cygdrive/d"
mount -f -s -t "e:" "/cygdrive/e"
mount -f -s -t "f:" "/cygdrive/f"
mount -f -s -t "g:" "/cygdrive/g"
mount -f -s -t "h:" "/cygdrive/h"
mount -f -s -t "i:" "/cygdrive/i"
mount -f -s -t "u:" "/cygdrive/u"
mount -f -s -t "v:" "/cygdrive/v"
mount -f -s -t "w:" "/cygdrive/w"
h:/cygwin/bin/mount -f -s -b "C://bin" "/usr/bin"
h:/cygwin/bin/mount -f -s -b "C:/usr/X11R6/lib/X11/fonts" 
"/usr/X11R6/lib/X11/fonts"
h:/cygwin/bin/mount -f -s -b "C://lib" "/usr/lib"
h:/cygwin/bin/mount -f -s -b "C:" "/"
h:/cygwin/bin/mount -s -b --change-cygdrive-prefix "/cygdrive"



--------------------------------------------------------------------------------

My mount-ven script:

mount -f -s -b "M:" "/mnt/cdrom"
mount -f -s -t "c:" "/cygdrive/c"
mount -f -s -t "d:" "/cygdrive/d"
mount -f -s -t "e:" "/cygdrive/e"
mount -f -s -t "f:" "/cygdrive/f"
mount -f -s -t "g:" "/cygdrive/g"
mount -f -s -t "h:" "/cygdrive/h"
mount -f -s -t "i:" "/cygdrive/i"
mount -f -s -t "u:" "/cygdrive/u"
mount -f -s -t "v:" "/cygdrive/v"
mount -f -s -t "w:" "/cygdrive/w"
c:/bin/mount.exe -f -s -b "H:/cygwin/lib" "/usr/lib"
c:/bin/mount.exe -f -s -b "H:/cygwin" "/"
c:/bin/mount.exe -s -t --change-cygdrive-prefix "/cygdrive"
c:/bin/mount.exe -f -s -b "H:/cygwin/bin" "/usr/bin"




--
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/

Re: Multiple cygwins/ Distributing cygwin apps

[Igor Pechtchanski]

On Mon, 3 Nov 2003, Christopher Faylor wrote:

> On Mon, Nov 03, 2003 at 12:24:20AM -0800, Brian Dessent wrote:
> >But seriously, you have to realize that this is a volunteer affair and
> >that the people involved could care less how some 3rd party perverts the
> >software, it's not their job.
>
> Can we get a new acronym here?  3PP?  I just embarrassed myself in a meeting
> by snorting out loud at this.
>
> cgf

Done: <http://cygwin.com/acronyms/#3PP>.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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/

Re: Multiple cygwins/ Distributing cygwin apps

[Christopher Faylor]

On Mon, Nov 03, 2003 at 12:24:20AM -0800, Brian Dessent wrote:
>But seriously, you have to realize that this is a volunteer affair and
>that the people involved could care less how some 3rd party perverts the
>software, it's not their job.

Can we get a new acronym here?  3PP?  I just embarrassed myself in a meeting
by snorting out loud at this.

cgf

--
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/

RE: Multiple cygwins/ Distributing cygwin apps

[kevin.lawton]

I think there is a point here, which often applies to those of us with end user clients to support. 
It is the client's choice as to which version of any particular software they have installed, not ours to dictate. We might advise that they move to latest versions, but they might counter that with arguments such as waiting for bugs to be fixed and security / compatibility to be fully tested and proven before they migrate.  
Some of our clients might like to keep pace with the latest developments, while others might prefer to stick with the tried and tested versions as long as possible. It's their choice. If we refuse to support anything but latest versions then we just lose out on most of our work opportunities. The fact that we have to support a software installation which contains an old version of something doesn't necessarily mean that the software is currently distributed with that same old version. It means that it is currently in use with the old version, which might have been distributed and installed some time ago. 
Meanwhile, we have to support them - which often involves building a system for ourselves which mimics theirs in behaviour, and therefore in software versions too. Some can afford to go to the lengths of dedicating a machine to each build. My preference is to dedicate one hard drive or partition to each build. Anyway, the whole point is that those of us involved in third-party support often have to cope with different versions of a piece of software at the same time. There are various ways of achieving this. I just illustrated one of them. 
Kevin.   
   
-----Original Message-----
From: Christopher Faylor
[mailto:cgf-no-personal-reply-please@cygwin.com]
Sent: 03 November 2003 16:38
To: cygwin@cygwin.com
Subject: Re: Multiple cygwins/ Distributing cygwin apps
   
On Sun, Nov 02, 2003 at 06:29:17PM -0700, John Moore wrote:
>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.

- Please let us know the vendor who is releasing old versions of the
Cygwin DLL.  I want to make sure that it complies with the GPL.  If it
doesn't, our lawyers would like to talk to them.

- Newer versions of the cygwin DLL work with older applications.

- Newer versions of the cygwin DLL are better at finding other running
versions of the dll.

- Delete all but the newest version of the DLL and you are all set.

- If a vendor is releasing a product which doesn't work right because
there is a newer version of cygwin, complain to the vendor.  Their
installation is busted.
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to aaaspam@sourceware.org
and be permanently blocked from mailing lists at sources.redhat.com

--
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/

Re: Multiple cygwins/ Distributing cygwin apps

[Christopher Faylor]

On Sun, Nov 02, 2003 at 06:29:17PM -0700, John Moore wrote:
>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.

- Please let us know the vendor who is releasing old versions of the
Cygwin DLL.  I want to make sure that it complies with the GPL.  If it
doesn't, our lawyers would like to talk to them.

- Newer versions of the cygwin DLL work with older applications.

- Newer versions of the cygwin DLL are better at finding other running
versions of the dll.

- Delete all but the newest version of the DLL and you are all set.

- If a vendor is releasing a product which doesn't work right because
there is a newer version of cygwin, complain to the vendor.  Their
installation is busted.
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to aaaspam@sourceware.org
and be permanently blocked from mailing lists at sources.redhat.com

--
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/

Re: Multiple Cygwins/ Distributing Cygwin apps

[Brian Dessent]

John Moore wrote:

> I installed Cygwin #1 on C: and Cygwin #2 on H:. I'll have to try the
> mount trick as the easy way to switch them. However, I don't think it
> will work when you first install Cygwin #2, as it will detect the keys
> and complain that a Cygwin is already present!

If you unmount everything then there should be no registry keys to
detect.

> It may also be necessary to change the Windows path (again, I don't know
> if the Cygwin installer did this or the vendor did it).

'Pure' cygwin doesn't mess with your Windows path at all.  Instead,
/etc/profile prepends the Cygwin paths to your Windows path.  If both
Cygwins do it this way there should be no conflict, as this method only
sets the path for that bash session, it's not a global change.  However,
if this vendor's package adds the Cygwin paths to your Windows path then
that could be a problem, but there's nothing that says you can't just
undo that and set it in one of the bash startup files instead.

> Ran the tool manufacturer's install, telling it to put cygwin stuff on
> H. Somehow it decided that my cygwin home directory should be
> c:/documents and settings/username.

You're not tied to what the installer makes it, you know.  There are two
places where the home directory is set: in one of the startup scripts
(probably /etc/profile) where the HOME variable is set and exported, and
the appropriate field in /etc/passwd, which is only really used by a few
things.  If you change both of these you can put your home directory
whereever you please.

> Renamed the Cygwin paths in the registry to something else (put an X on
> the end).
> 
> rebooted.
> 
> Installed cygwin using the installer. It failed with a windows abort
> message about find.exe!

You probably need to unmount, not just rename the paths.  Otherwise
setup.exe will be confused.

> tried a few utilities from cygwin. Got a complaint about having 2
> cygwin1.dll's.

As always, you must ensure that there's only one cygwin1.dll in the path
at any given time, and that it's the correct one.  If you remove all
cygwin related things from the Windows path and then add the Cygwin
paths in the bash startup scripts then this should be manageable.

> Everything worked except cvs, which failed in ssh client mode (against a 
> server at the office) with a garbled message. This cvs.exe had worked 
> before. This cygwin was from a cygwin grabbed by the nifty little 
> unresizeable (grrr) utility within the last few days.

The latest setup snapshots are resizeable, BTW.

> I will check and see if the vendor included the source to the tool (I
> doubt it, btw). But good grief, I shouldn't have to recompile the damn
> thing just to use it.

> What I would love to see is a complete procedure for doing this sort
of 
> thing posted in a cygwin FAQ.

I don't think you will ever see this added to an official Cygwin FAQ
because what you're doing is unsupported as heck.  Your complaint should
be with the vendor, really.  Cygwin can hardly be responsible for a
third party making some customized environment that locks you into some
old version of the DLL.  None of the Cygwin developers are going to want
to touch this issue with a 10-foot pole.  They support the
setup.exe-blessed environment with the current packages from a
sources.redhat.com mirror... Anything else and you're either on your own
or you need to get support from the vendor.  To expect the Cygwin
developers to have any interest in debugging a 3rd party environment
over which they have no control is asking a lot -- especially since
they're such a mean bunch <g>.

But seriously, you have to realize that this is a volunteer affair and
that the people involved could care less how some 3rd party perverts the
software, it's not their job.  So, it's not surprising that there are
not instructions anywhere on how to jerryrig two Cygwins, and that doing
so is not exactly easy.  It's not meant to be.  It's not meant to be
anything, really, it's just unsupported.  Not that it's not possible,
just that it's not a configuration that the official Cygwin folks care
to deal with.

Brian

(If I've misrepresented any of the 'official' Cygwin feelings on this
matter then please correct me.)

--
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/

Re: Multiple Cygwins/ Distributing Cygwin apps

[John Moore]

Brian Dessent wrote:

> John Moore wrote:
> 
> 
>>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."
> 
> 
> I have not tried this per se, but I don't see what's stopping you from
> having as many Cygwins installed as you want.  Now, I'm not saying that
> you could USE more than one at a time, due to the fact that only a
> single Cygwin1.dll can be active at any given time -- and I wouldn't
> expect this to change before the heat death of the universe.  But the
> only thing that Cygwin touches outside of its install path is the mount
> table in the registry, and this is easily removed/replaced with mount
> and umount.
How about the Windows PATH environment variable? I think it messes with 
that (if not, then the vendor software did it).
> 
> So, if I were doing this, I would install Cygwin #1 to \cygwin, then
> "mount -m > mounts.txt ; umount -A", then install Cygwin #2 to \cygwin-b
> or whatever, and so on.  To switch between them just unmount everything
> and remount the other one.
I installed Cygwin #1 on C: and Cygwin #2 on H:. I'll have to try the 
mount trick as the easy way to switch them. However, I don't think it 
will work when you first install Cygwin #2, as it will detect the keys 
and complain that a Cygwin is already present!

It may also be necessary to change the Windows path (again, I don't know 
if the Cygwin installer did this or the vendor did it).

In my case, to get my old environment to work, I did the following:

Cleaned out ALL cygwins from registry and disk.

Rebooted Win2K.

Ran the tool manufacturer's install, telling it to put cygwin stuff on 
H. Somehow it decided that my cygwin home directory should be 
c:/documents and settings/username.

Renamed the Cygwin paths in the registry to something else (put an X on 
the end).

rebooted.

Installed cygwin using the installer. It failed with a windows abort 
message about find.exe!

tried a few utilities from cygwin. Got a complaint about having 2 
cygwin1.dll's.

Cleaned out the Windows PATH setting of those cygwin-on-H drive paths.

Rebooted.

Tried the install again. Same failure.

Copied my archived copy of my C Cygwin back to C.

Everything worked except cvs, which failed in ssh client mode (against a 
server at the office) with a garbled message. This cvs.exe had worked 
before. This cygwin was from a cygwin grabbed by the nifty little 
unresizeable (grrr) utility within the last few days.

Downloaded the latest cvs from cvshome.org and put it in /bin in place 
of the current one.

Now, finally, I have something that seems to work.

I will check and see if the vendor included the source to the tool (I 
doubt it, btw). But good grief, I shouldn't have to recompile the damn 
thing just to use it.

I haven't yet tried to reactivate the tool cygwin (cygwin #1), which 
should be interesting.

What I would love to see is a complete procedure for doing this sort of 
thing posted in a cygwin FAQ.

I could have just gone with the vendor's cygwin, but the damned thing 
was out of date, and its cvs didn't work (something odd there that would 
  involve more diagnosis than I have time for until a current crisis is 
over). Furthermore, the idea of being hostage to some random tool 
vendor's "OS" as my primary work environment is offensive to me. In this 
case, the tool is an ARM cross assembler bundled with a JTAG interface 
(software and hardware).

I love cygwin. I have used it ever since MKS Toolkit got expensive and I 
discovered this alternative. I typically run 6 MKS bash shell windows at 
once on three monitors while working. I was a pure Unix user (started 
Unix on a PC-XT!) until the early '90s when the availability of a lot of 
applications forced me to Windows. Cygwin lets me have my cake and eat 
it too... almost.
> 
> Additionally, these vendors must have shipped you source to everything
> compiled against Cygwin1.dll, or else they are in violation of the GPL. 
> So, you should be able to recompile everything against the latest DLL,
> and just use a single installation.  The exception is if they purchased
> the Cygwin buy-out license from Redhat.
> 
> Brian
> 



--
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/

Re: Multiple Cygwins/ Distributing Cygwin apps

[Brian Dessent]

John Moore wrote:

> 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."

I have not tried this per se, but I don't see what's stopping you from
having as many Cygwins installed as you want.  Now, I'm not saying that
you could USE more than one at a time, due to the fact that only a
single Cygwin1.dll can be active at any given time -- and I wouldn't
expect this to change before the heat death of the universe.  But the
only thing that Cygwin touches outside of its install path is the mount
table in the registry, and this is easily removed/replaced with mount
and umount.

So, if I were doing this, I would install Cygwin #1 to \cygwin, then
"mount -m > mounts.txt ; umount -A", then install Cygwin #2 to \cygwin-b
or whatever, and so on.  To switch between them just unmount everything
and remount the other one.

Additionally, these vendors must have shipped you source to everything
compiled against Cygwin1.dll, or else they are in violation of the GPL. 
So, you should be able to recompile everything against the latest DLL,
and just use a single installation.  The exception is if they purchased
the Cygwin buy-out license from Redhat.

Brian

--
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/

RE: Multiple Cygwins/ Distributing Cygwin apps

[Gary R. Van Sickle]

> On Sun, 2 Nov 2003, Gary R. Van Sickle wrote:
> 
> > [snip]
> > > Cygwin is a great tool and it has this really neat installer so I can
> > > keep it up to date.
> >
> > Could somebody *PLEASE* put this quote at the top of the main 
> Cygwin page?!?!?!?
> > "Really neat installer", wowzers, that's a first and a half! ;-)
> 
> Gary, this referred to the non-resizeable chooser, so will soon be
> out-of-date.  The newer snapshots, once the initial excitement wears off,
> will be branded messy and buggy and a disgrace to the project.  I'd like
> to be wrong, but...
> 	Igor

I know, that's why I want this unsolicited praise saved for posterity! ;-)

-- 
Gary R. Van Sickle


--
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/

RE: Multiple Cygwins/ Distributing Cygwin apps

[Igor Pechtchanski]

On Sun, 2 Nov 2003, Gary R. Van Sickle wrote:

> [snip]
> > Cygwin is a great tool and it has this really neat installer so I can
> > keep it up to date.
>
> Could somebody *PLEASE* put this quote at the top of the main Cygwin page?!?!?!?
> "Really neat installer", wowzers, that's a first and a half! ;-)

Gary, this referred to the non-resizeable chooser, so will soon be
out-of-date.  The newer snapshots, once the initial excitement wears off,
will be branded messy and buggy and a disgrace to the project.  I'd like
to be wrong, but...
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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/

RE: Multiple Cygwins/ Distributing Cygwin apps

[Gary R. Van Sickle]

[snip]
> Cygwin is a great tool and it has this really neat installer so I can
> keep it up to date.

Could somebody *PLEASE* put this quote at the top of the main Cygwin page?!?!?!?
"Really neat installer", wowzers, that's a first and a half! ;-)

--
Gary R. Van Sickle


--
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/

Multiple Cygwins/ Distributing Cygwin apps

[John Moore]

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/