Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sources.redhat.com
Message-Id: <4.3.1.2.20000901095214.01ef2d38@pop.ma.ultranet.com>
Date: Fri, 01 Sep 2000 09:54:24 -0400
To: Chris Faylor <cygwin@sources.redhat.com>
From: "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com>
Subject: Re: DLL naming conventions
In-Reply-To: <39AFB1A2.D9A5BF96@ece.gatech.edu>
References: <17B78BDF120BD411B70100500422FC6309E0BC@IIS000>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:39 AM 9/1/2000, Charles S. Wilson wrote:

> > Note that there *is* a solution on Windows98 and Windows2000 (at least
> > reading Microsoft prose in MSDN Library) named "side-by-side DLLs"; however
> > this does *not* work on NT nor on 95 :-(
> > 
> > The idea is either by special arrangment when building the application (not
> > very practlical when porting) or by creating a file named "myapp.exe.local"
> > in the same directory than "myapp.exe", Windows will link the DLLs it found
> > in the same directory as "myapp.exe" BEFORE looking elsewhere, and even
> > before looking if it already has a copy of this DLL in memory.
>
>Actually, on all windows platforms the search order for dll's is loaded
>by the dynamic linker (windows loader, whatever)
>   1) the directory in which the executable resides
>   2) the current directory
>   3) Windows 95/98: The Windows system directory.
>      Windows NT/2K: The 32-bit Windows system directory. 
>   4) Windows NT/2K: The 16-bit Windows system directory.
>   5) The Windows directory.
>   6) The directories that are listed in the PATH environment variable.
>
>However, it is possible to do the exquivalent of a
>dlopen("c:\absolute\path\to\my.dll") (*).  In that case, you have a
>hardcoded path to a specific dll, and reqardless of whether my.dll is in
>the executable's directory, you'll still load
>c:\absolute\path\to\my.dll.
>
>(*) I forgot what the windows equivalent function of dlopen() is; I'll
>keep using the name dlopen(), but I mean the
>windows-equivalent-funtion-for-dlopen().
>
>The .local hack in Win2K is there for this explicit dlopen case, not the
>typical dynamic linker case -- because merely placing the dll's into the
>executable directory will force the dynamic linker to use those dll's
>rather than dll's in some other location.  When you have
>myapp.exe.local, W2K will OVERRIDE the absolute path in the dlopen()
>statement, and search the application's local directory first.
>
>--Chuck


Right, so in other words, Microsoft's solution to this problem is to push
back towards static libraries.  Back the pendulum swings...


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com