Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <39AFB1A2.D9A5BF96@ece.gatech.edu>
Date: Fri, 01 Sep 2000 09:39:46 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bernard Dautrevaux <Dautrevaux AT microprocess DOT com>
CC: "'Egor Duda'" <deo AT logos-m DOT ru>, Chris Faylor <cygwin AT sources DOT redhat DOT com>
Subject: Re: DLL naming conventions
References: <17B78BDF120BD411B70100500422FC6309E0BC AT IIS000>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


> 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

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com