X-Spam-Check-By: sourceware.org
Message-ID: <43E2C112.CFE77C07@dessent.net>
Date: Thu, 02 Feb 2006 18:33:54 -0800
From: Brian Dessent <brian AT dessent DOT net>
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: mismatched dll
References: <020220062158 DOT 387 DOT 43E28079000ACE870000018322007507440A050E040D0C079D0A AT comcast DOT net> <20060203013712 DOT GC17485 AT brasko DOT net> <43E2B779 DOT 4371E33B AT dessent DOT net> <276FEDDB-C5A7-4B38-A82D-025CC97D674E AT rehley DOT net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Peter Rehley wrote:

> Can we get this added to the faq?  It sounds like there are several
> companies out there that install the cygwin1.dll without caring that
> it can cause problems.  This would at least provide some information
> for those that read the faq.

I think regardless of what the FAQ says there will still be 3PPs that
don't follow its advice, and instead supply their own cygwin1.dll
regardless of the state of the machine.

From the perspective of the software vendor that is selling a product
(or otherwise has some vested interest in having their software work)
there are a few problems with the procedure in my last post.

For example, suppose that the user installs Cygwin and then later
installs CygwinBasedCommercialProduct (CBCP from here on.)  The CBCP
installer plays nice, notices that the user has Cygwin installed with
the most recent DLL, so it does not install its own copy.  Everyone is
happy.  But then say six months later the under removes Cygwin, unaware
the CBCP was relying on its DLL, and now CBCP fails to start or fails in
other strange ways.  From the standpoint of the user, he doesn't really
care what the underlying reason is, his CBCP now doesn't work and it's
obviously a CBCP bug.  You can repeat this scenario in several
permutations, say for example if there are two CBCPs installed on the
system, and one is using the DLL provided by the other. 
Upgrade/downgrade/remove one and the other breaks.

There's also the scary notion of an installer potentially messing with
files from a software package it does not "own."  In order for the "one
Cygwin DLL" plan to work in the face of 3PPs and CBCPs you have to be
prepared to accept that at some point you might have to delete or
overwrite the .dll shipped with the product, if it's older than what is
current or what you are shipping.  Here again your options are to either
play nice, and try to inform/educate the user that you're about to go
messing with some other software's files, potentially something
completely unrelated to yours, all because their DLL is too old but it
was there first.  Or you can just trudge ahead and be a quinessential
3PP and have no regard for what might have been installed already -- of
course you also don't have to shoulder the burden of possibly FUBARing
some existing software because you messed with its DLL.

And then on top of all this there is the "stability" argument, where you
have 3PPs that (for better or worse) only care about trying to support
their CBCP with a certain known version of the cygwin DLL.  If you have
other cygwin.dll-consumers on your system and try to "do the right
thing" by keeping the sole copy as the latest version, you risk losing
support from the stubborn 3PP that will not budge on the fact that
you're doing something they don't want to have any part of.

So, I guess all I'm saying is it's a complicated issue and there is no
100% foolproof way to go if you want to be a provider of Cygwin-based
software that is meant to interact with other Cygwin-based software --
other than perhaps introducing your software as an official package, or
telling users to install Cygwin from the cygwin.com mirrors first and
then integrating with that.  But for some vendors that is too many steps
and not "turnkey" enough.

I think at the end of the day, user education as to the nature of the
problem is really what is required.

Brian

--
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/