Multiple Cygwins/ Distributing Cygwin apps

John Moore gmanenews@tinyvital.com
Mon Nov 3 02:20:00 GMT 2003


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/



More information about the Cygwin mailing list