Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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
Importance: Normal
Sensitivity: 
Subject: Re: Concurrent versions of cygwin1.dll on one system
To: cygwin AT cygwin DOT com
Message-ID: <OFF491C054.CC98ACD9-ONC1256BF1.00405309-C1256BF1.0040E04A@sto.se.ibm.com>
From: "Franz Wolfhagen" <FRANZW AT dk DOT ibm DOT com>
Date: Tue, 9 Jul 2002 13:35:39 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g69Ba2h09270


Be aware that there is commercial software that uses the cygwin1.dll.

One example is Tivoli Framework from IBM (which I happens to work with
proffesionally...).

To ensure that a dll is not interfering with other versions of the same dll
you must ensure that it is located in a directory that by default is NOT
included in the windows path. You should aælso familiarize yourself with
terms of dll search sequence and private dlls. This will help you
understand how to avoid conflicts of this kind.

Another (and much worse) example of a dll conflict is the infamous
MSVCRT40.Dll conflict that I belive any NT 4.0 system maintainer knows -
this problem shows exactly what problems may arise when people advice (or
just puts it) to move a dll into the %system% directory....

Med venlig hilsen / Regards
Franz Wolfhagen


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/