This is the mail archive of the cygwin-developers 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]

Re: Avoid collisions between parallel installations of Cygwin


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. ;-)

First, I think it's great to open up a discussion about possible solutions to
the whole multiple cygwin1.dll situation. This is certainly one of those issues
that's reoccurring and it would be *so* nice if there was a way to retire it for
good. :-) Since I've had the advantage of reading through all the discussion so far
(and finding the answers to some of my questions in the process), I'd like to touch
on two areas that haven't been discussed (much?) yet in this thread.


1. I don't want to imply that Corinna hasn't done allot of good work with this patch
(which she certainly has!) but I also want to look at this from the perspective of
"Devil's Advocate". So, most succinctly, one question that pops to mind is "Is this
the best way to address this issue?" Certainly one could characterize this problem
of multiple Cygwin DLLs as our own strain of "DLL Hell" and in this respect,
supporting multiple DLLs fits with the common solution to the generic issue.
However, we do have an issue which is definitely not so common, the shared
memory. So this got me to wondering "Is the common solution to 'DLL Hell' the
right one for Cygwin?" I know, now everybody is waiting for me to answer that
question. ;-) I'm not going to. I wouldn't be a proper "Devil's Advocate" if I did.
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.


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:


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').


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.


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.


So where we had one issue before, all classified under 1 big category of "1
Cygwin DLL" which was pretty easy to diagnose and had a very direct answer,
I'm wondering how many new offshoots of this we're "trading up" to, if we
allow multiple DLLs to coexist out there in user land. But even putting aside the
possible multiplication of issues, 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 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?


OK, I think I've said enough for now. If it's worth delving into the details of any of
these areas, I'm happy to discuss them further. But I think it's best I don't get too
tedious (if that's even possible! ;-) ) with my first reply at least.


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?


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