This is the mail archive of the
mailing list for the Cygwin project.
Re: Avoid collisions between parallel installations of Cygwin
On 10/15/2009 06:40 AM, Corinna Vinschen wrote:
On Oct 15 02:18, Larry Hall (Cygwin Developers) wrote:
On 10/12/2009 12:28 PM, Corinna Vinschen wrote:
this is sort of a follow-up to a mail from Earnie:
OK, I realize I'm chiming after allot of discussion has already taken place
but I figure better late than never. ;-)
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
trade-off to this as well, since the user is still limited to one DLL.
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.
True enough. There would be some benefit to this even with the status quo.
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
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
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.
I completely agree that it's better for us to provide a solution and present it
for use than have multiple external sources take their own shots at it. And, of
course, you're right that we can't stop anyone from doing whatever they want,
no matter what we do. We've seen that already, as you've pointed out. But
I think there are 2 points here that are worth reiterating:
1. Without some provided solution/policy, people are inclined to provide
own. Or, perhaps more realistically, if we provide something to address a
need here, folks will more likely "buy" than "build", since that's
"build" now because they don't see a "buy" option.
2. While it's true this door has been opened by some in the past (MSYS is
obvious example), I still believe this isn't a commonly exercised mode of
operation for most Cygwin users. The 3PP I've seen simply deliver
(unfortunately) and I expect most would switch away from this if they were
given another option. So I expect that whatever solution we come up
with will increase the number of possible cases for multiple Cygwin's
Side-by-side 1.5/1.7 installations are one area of this too, though I
that's going to be our typical problem vector on this list because I
the number of side-by-side installations will diminish over time after
released, those who have it typically "get" the idea of separate
and it's not that unnatural to view the two installations as separate,
since we've been talking about it this way for a long time, even
for this was added.
A. A user has a Cygwin installation and the "Nifty-Difty Ultimate SSH"
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
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.
True but it was obvious to ask for a 'cygcheck' and to tell the poster to
look for multiple DLLs. And the message was there for the user to indicate
the problem and a possible solution. Of course, the scenario above wouldn't
happen currently. The multiple DLLs complaint would either show up when
trying to run or the 3PP would "just work". So I see this as one of multiple
potential new vectors that we will start seeing. Will this occur more than the
current situation? Probably not (otherwise, why bother! ;-) ) But my point is
that if we're going down the road of supporting multiple DLLs in their own
environments, there isn't anything right now that I know of that helps the user
understand what's wrong (not even a cryptic error message ;-) ) if something
goes wrong and we're going to need to develop more diagnostics and/or
to help resolve these. This could still be an overall win, if the number of
on the list is reduced and the aggregate time spent on them is less (over
the long term). I'm guessing that's what you expect.
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.
Yep. Thanks for pointing this out. It is an important point that I glossed
Of course, if this is one of those times when the 3PP needs it's DLL or Cygwin's
'cat' uses something new in Cygwin's DLL, this could still be a problem. And
although we run that same risk now if the 3PP delivers their own DLL, if we
change the policy to allow multiple, coexisting DLLs, there may be a perception
that we should allow this as well. So we'll have to be prepared for that.
besides the possible perception change, this doesn't seem like a new issue
Or, the DLLs differ in some respect which is catched by the "multiple
Cygwin" test, and you'll get the "multiple Cygwin" message.
Ah, that's good.
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
OK, so this one doesn't seem like it's much of an issue, which is good. :-)
Thanks for checking this out.
C. A user has a 3PP file browser. After subsequently installing Cygwin,
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
Certainly. The point is that it is another vector for complaints, however
number may be, all stemming from the change to allow multiple DLLs. This is a
change from the current behavior where the DLL is either just shared and see the
same thing or the DLLs collide and a message is issued. Obviously, we can
this question and provide the user with options but there's not much there
the user understand why this is the case, why it doesn't "just work" or
when it used to (of there was a 1.5-based version let's say).
This isn't an unsolvable problem and I'm not suggesting that any of these
others that I haven't mentioned are. I just want to point out that there
may be a bevy
of end-user issues that flow from this change, even while it addresses an
and real issue.
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
tools (cygcheck?) to help us understand how many different DLLs are on
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
Cygwin DLLs installed on a system and even which ones are loaded in
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.
Yeah, I was thinking the same thing. So doing something along this line
makes good sense, no matter what we end up doing about multiple Cygwin DLLs.
concerned about any others that I most certainly haven't even dreamed
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
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.
Yeah, I don't recall allot of complaints reported to the Cygwin list and it
like Earnie isn't aware of anything on the MSYS side. I think that does
some support for the idea that this kind of change isn't going to make large
waves in the user community. Of course, no guarantees. ;-) And we also have
to consider the differences in the size and clientÃle in these two communities.
I'd wager that the typical MSYS user is not a newbie trying to learn about Linux
or someone that just wants to check out a cool new packaged app. I'm betting
we will see more users of this ilk on the Cygwin side and that group is the
that's more likely to be bitten by any issues that pop up and end up on the
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.
It's a reasonable question and there's no way to really answer it beforehand.
I'm not really suggesting that we should try to qualify the potential problems
either. My concern is that we make an attempt to quantify them as part of
this discussion. I see this as an exercise that does 2 things:
1. Make sure we haven't overlooked something really important.
2. Make sure we have what we need to diagnose these issues.
Yeah, this doesn't sound very easy or like allot of fun. :-( It just
me that if we're going to make a big change in policy, it makes sense to
understand the new problems that can arise. This is something that you may
have done allot of already, Corinna, since it quite possibly was part of
had to do to test what you have. I don't know. But I think there is some value
in anticipating the user issues here and see if we're ready for them. I suppose
this could end up being gratuitous exercise as well, if the end result doesn't
unearth any major (or "showstopper") issues or a huge amount of minor ones,
since we'd likely come to the same conclusion over time after fielding (or
not ;-) )
problems on the list. However, I thought that this was worth bring up while we
were talking about this change.
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?