Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
From: "Jonadab the Unsightly One" <jonadab AT bright DOT net>
Organization: There is no organisation.
To: cygwin AT cygwin DOT com
Date: Tue, 17 Jul 2001 22:42:18 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: CYGWIN1.DLL
Reply-to: jonadab AT bright DOT net
Message-ID: <3B54BF4A.18486.12FAC4B@localhost>
In-reply-to: <20010717162414.A11147@redhat.com>


# On Tue, Jul 17, 2001 at 01:12:48PM -0700, Joshua Franklin wrote:
# >Just an idea, you might just recompile the DLL with a
# >different registry entry and file name. That's the
# >only compatibility problem with having two, no?
# 
# No.

And this is a general principle (for DLLs) that transcends 
Cygwin entirely:  it is never a good idea to have two 
versions of the same DLL in any shared location on the 
same computer.  

If each application's installation routine puts its 
DLLs in the same user-specified directory where the
rest of the application's files (notably the EXEs)
are stored, and if the application deliberately 
loads them only from there, and if registry entries 
are version-specific, then a carefully-designed 
application can get away with having two versions 
installed on the same PC, as long as they aren't 
run at the same time.  Otherwise, just having two 
versions installed is a bad idea.  *Running* two 
versions of the same DLL at the same time is 
*definitely* asking for trouble.  This includes 
Microsoft DLLs such as VBRUN and MSVCRT and so on,
even if the version number is different.  (Well,
definitely if only the minor version number is
different; I'm not stone cold certain whether a
change in the major version number resolves the
problem, but I doubt it.  I think for the problem
to truly be resolved the two versions would have
to not provide any of the same functions, but
now I'm getting into technical details beyond
what I really know.)

Basically, Microsoft's implementation of dynamic
libraries is inherently broken, and there's really
nothing Cygwin (or anyone else) can do about that.
(Microsoft's DLLs may not be the only broken 
implentation of the dynamic linking concept, but 
that's either here nor there.)

RAM prices being what they are, static linking
is arguably The Only Good Way to compile anything
you want to distribute for use on Microsoft 
platforms.  However, the purpose of Cygwin is
to run Unixy stuff on Windows; producing 
software for general distribution is, AFAIK,
a non-goal for the project.  Not that I am 
intimately acquainted with the project's goals,
but that's the sense I got from the claims made
(and not made) on the website.  This is unlike
DJGPP, which definitely bills itself as a 
development environment for general use.  Of
course, there's no particular reason you can't
use Cygwin to do something that wasn't its
stated goal, but there's even less warrantee
of fitness for purpose than the "we intend
it but promise nothing" that you get if you 
use it for the intended goal.


-- 
Your font seems to be:    proportional     fixed
                                             ^
                                             |

(Fontmeter only accurate for about 90% of fonts.)

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