DLL naming conventions
Larry Hall (RFK Partners, Inc)
lhall@rfk.com
Fri Sep 1 06:58:00 GMT 2000
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
More information about the Cygwin
mailing list