X-Spam-Check-By:	sourceware.org
Message-ID:	<43E2B779.4371E33B@dessent.net>
Date:	Thu, 02 Feb 2006 17:52:57 -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>
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

Bob Rossi wrote:

> Here's another question I have (sorry). Why wouldn't it be acceptable to
> have to (different version) cygwin1.dll's running on a single system?
> That is, 2 completely different Cygwin environments? So, all programs
> that link against the same cygwin1.dll are in one Cygwin environment. If
> there is another version of the cygwin1.dll, and programs link against
> it, they would be in another Cygwin environment, completely independent.

It *is* possible to create two Cygwin DLLs that can co-exist.  But to do
so requires much more than just naming them differently.  The source
code must be modified to use a different filename/identifier for the
shared memory region, as well as different registry keys for the mount
table.  The Cygwin testsuite does a limited version of this to allow
running the just-built Cygwin DLL for the purposes of executing the
tests, from within the developer's existing Cygwin environment.

So yes, it can be done.  But it is a very bad idea to do so.  If you
made two DLLs that were isolated in this way they would be truly
isolated -- you could not send signals from one to the other, they would
not see each others processes in their PID tables, and so on.  It would
be the absolute worst way to have two sets of software interact.

This is ESPECIALLY true when the code goes to great lengths to be
backward compatible.  The idea is that you can ALWAYS replace an
existing cygwin1.dll with a newer one, without recompiling the old apps
that were linked against the old version of the DLL.  You of course
can't go in the other direction (using an older DLL with newer .exes)
but this backwards compatibility is in theory good all the way back to
version 1.0.0 from circa 1998-ish.  So there is no reason why you should
ever need two Cygwin DLLs in the first place, because you can always
replace an older one with a newer one.

If you are writing an installer of a third party application the basic
logic should thus be:

Is a cygwin1.dll already on the system somewhere?
  Yes:
     Is it newer than mine?
        Yes: Install my .exe, but do not install my cygwin1.dll,
             use the existing one.
        No:  Prompt user of the situation, and either bail or 
             overwrite older DLL with newer DLL.
  No:
     Install my DLL.

Essentially, you must ensure that if a Cygwin DLL already exists you
either use it as-is or replace it with a newer one.  Never install a
second copy, and never overwrite a newer one with an older verison.

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/

- Raw text -