Avoid collisions between parallel installations of Cygwin

Corinna Vinschen corinna-cygwin@cygwin.com
Thu Oct 15 10:40:00 GMT 2009

On Oct 15 02:18, Larry Hall (Cygwin Developers) wrote:
> On 10/12/2009 12:28 PM, Corinna Vinschen wrote:
>> Hi,
>> this is sort of a follow-up to a mail from Earnie:
>> http://cygwin.com/ml/cygwin-developers/2009-05/msg00042.html
> <snip>
> OK, I realize I'm chiming after allot of discussion has already taken place
> but I figure better late than never. ;-)
> <more snip>
>    However, perhaps the more interesting thing is to explore the 
> possibilities if the
>    answer is "No".  What else could we do?  Well, since this implies we'd
>    need to make 1 DLL work for everyone, we'd need to make it easier for
>    everybody to use that DLL.  This has been discussed some in the past
>    but I think the key point would be that there would need to be an easy
>    way to find and update the installed DLL.  I think if we had some kind
>    of registry (yeah, I guess we could even use the Windows one if we had
>    to ;-) ), this would solve the "where do I look" problem.  Obviously 
> there's a
>    trade-off to this as well, since the user is still limited to one DLL. 
> But it
>    would be an approach that would allow 3PPs to install in a compatible way
>    with Cygwin and vice versa.  I expect there are some other possibilities out
>    there that could serve as a solution in the "No" case too.

I think I see what you're up to.  Whether or not we're having a solution
for the shared object collision, we have always the problem of multiple
Cygwin DLLs anywhere on the same machine, give that we always have third
parties using Cygwin for their own product.

So, wouldn't it be nice if every Cygwin DLL on the system would add some
system-wide available information where it can be easily found?

Let's simply assume as you did, that the Windows registry is the right
place to do this.  Assuming further the DLL creates a 64 bit key value
(heard that before?) from its installation path which is used for the
object names.  It could now simply create a new registry entry

  type REG_STRING, content = $installation_root.

(*) depending on user rights, obviosuly.

Cygcheck could fetch this information and print it.  Even without
cygcheck it's easy to examine the registry and check if there are
multiple Cygwin DLLs installed.  All past and present installation
paths can be fetched from the registry.

>  2. Now assuming the Devil is sent home unfulfilled, ;-) I've been doing some
>    thinking about what multiple Cygwin DLLs in their own little worlds 
> mean.  Or,
>    perhaps more importantly, what kind of problems that we haven't seen before
>    because we always stopped at the "1 Cygwin DLL" door will surface now that
>    the door as well as the whole side of the building is gone. ;-)  I know 
> this is
>    an incomplete list but here's a few things I thought of:

We never really stopped at the "1 Cygwin DLL" door for a long time.
Multiple Cygwin DLLs running alongside are a fact at least since
the creation of MSYS.  Nobody has been kept back to create a similar
solution from later versions of Cygwin and I know for a fact that
this already has been done.

By creating our own, builtin solution for these scenarios we have now
more control of the solution.  There won't be a reason for anybody to
hack something up by themselves.  Well, sure, except for the reason of
adding some sort of disguise.  Still, Cygwin is OSS and the solution
is definitely not rocket-science, so you have no way to prevent that.

>    A. A user has a Cygwin installation and the "Nifty-Difty Ultimate SSH" 
> 3PP installed.
>      Surprisingly, "Nifty-Difty Ultimate SSH" hangs for some reason (it has 
> a bug - who
>      knew this could happen) and the user tries to kill it using Cygwin 
> tools.  The user
>      sends email to the list asking why he can't find and kill the 
> "Nifty-Difty Ultimate
>      SSH" process using Cygwin's 'ps' and 'kill' (not '/bin/kill -f').

Sure, this could happen.  The error message is probably
"kill: XYZ: no such process".  And `ps' reveales that ssh is not
in the process list.  `ps -W' shows that there's a ssh process
installed in "C:\Program Files\Nifty-Difty Ultimate SSH\bin\ssh.exe".

I don't quite see the problem.  Many "multiple Cygwin" problems on
the list started out with an error description which wasn't very
helpful, unless, in the second or third reply, there was the hint that
the tool was installed from the "Nifty-Difty Ultimate SSH" site.
And it was very certainly not always combined with a simple "multiple
Cygwin" error message.

>    B. A user has a Cygwin installation and a 3PP with a cool new command-line
>       tool that filters stdin.  User dumps the output of a file using 
> Cygwin's 'cat' and
>       then pipes it into the new 3PP command-line tool and gets nothing.  The
>       user contacts the list to ask why.

There are two possible outcomes.  Either the Cygwin DLLs are happy with
each other since they are running basically the same version of Cygwin.
In this case the above problem just doesn't occur since piping still
works as expected.

Or, the DLLs differ in some respect which is catched by the "multiple Cygwin" test, and you'll get the "multiple Cygwin" message.

Either way, no harm is done.  Either it works, or a problem is detected.

Just to be sure I tried this in the test environment created for our

>    C. A user has a 3PP file browser.  After subsequently installing Cygwin, 
> the
>       user sends email to the list asking why Cygwin's view of the file system
>       doesn't match that of the 3PP file browser.

Isn't that really easy to answer?  If the view of the filesystem
differs, it's very likely that the different tools are looking from
different perspectives.

>    there's a potentially more important 
> issue of how
>    are we going to be able to diagnose these issues so that we know these are
>    "you're using multiple Cygwin DLLs" issues and not some other bug in Cygwin
>    that needs addressing?  Certainly it seems to me that we need some 
> augmented
>    tools (cygcheck?) to help us understand how many different DLLs are on 
> the user's
>    system and which ones are in use at least.  Along that line of thinking, 
> it seems to
>    me that we could make use of a (the?) registry again to keep track of 
> all the
>    Cygwin DLLs installed on a system and even which ones are loaded in 
> memory.  I'm
>    thinking here of the Cygwin DLL itself managing these entries, but I 
> don't want to
>    get too bogged down in details of this one diagnostic feature when I'm 

I think your registry idea is a really good one, and it isn't even
necessarily only a good one with my patch.  An easy way to detect all
(well, most, maybe) Cygwin DLLs installed on a system would be a cool
thing, since checking $PATH is not exactly bulletproof.

> really more
>    concerned about any others that I most certainly haven't even dreamed 
> of.  Has
>    anyone started enumerating a list of "possible problems" that we may see
>    popping up on the list if we allow multiple, disjoint Cygwin 
> environments in the
>    wild?  Should we be trying to think of the potential problem areas so 
> that we
>    can assure ourselves that we have a good chance of being able to classify
>    them and offer responses and solutions (or policies) for them?

As I noted above, the potential problems aren't really new, given at
least the existence of MSYS.  MSYS exists for many years now.  Have you
searched the list for problems which have been reduced to the
co-existance of MSYS and Cygwin on the same machine?  I didn't, but then
again, I can't remember any of them.  If there are some, they are very,
very seldom for sure.

So, here's your next question:  Given that there are no or so few
problem reports which could be tracked down to a MSYS/Cygwin
co-existance problem, does that mean the potential problems are
exaggerated, or does that mean we just didn't detect the cause of the
problem?  As you can easily guess, I have no answer to this question.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list