Mail Archives: cygwin/2000/09/01/09:41:03
> 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
- Raw text -