Avoid collisions between parallel installations of Cygwin

Larry Hall (Cygwin Developers) lhall@cygwin.com
Thu Oct 15 06:18:00 GMT 2009


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?



More information about the Cygwin-developers mailing list