This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]