Mail Archives: cygwin/2000/09/01/09:58:44
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 AT rfk DOT 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 AT sourceware DOT cygnus DOT com
- Raw text -