Mail Archives: cygwin/2000/09/04/11:39:20
> -----Original Message-----
> From: Charles S. Wilson [mailto:cwilson AT ece DOT gatech DOT edu]
> Sent: Monday, September 04, 2000 5:09 PM
> To: Robert Collins; cygwin AT sources DOT redhat DOT com
> Subject: Re: DLL naming conventions
>
>
....
>
> Here's the search order for DLL's when an AppPath key is set for the
> executable in the registry:
>
> 1.The directories listed in the App Path registry key
>
> 2.The directory where the executable module for the current process is
> located.
>
> 3.The current directory.
>
> 4.The Windows system directory. The GetSystemDirectory function
> retrieves the path of this directory.
>
> 5.The Windows directory. The GetWindowsDirectory function
> retrieves the
> path of this directory.
>
> 6.The directories listed in the PATH environment variable.
>
>
> See http://codeguru.earthweb.com/dll/AppPath.shtml
>
> So, if all .exe's are installed using 'install.exe', and
> install.exe is
> made smart enough to create an AppPath key for each one -- the problem
> is solved!
>
> (sotto voce: ermmm...three minor problems:
>
> 1. The AppPath entry must be in windows-format:
> C:\cygwin\bin;C:\cygwin\usr\local\bin NOT /bin:/usr/local/bin. What
> happens when you reinstall cygwin to a different location -- say
> D:\cygwin -- and change the mount points?
>
> 2. The AppPath entry is keyed by the program name:
>
> HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\foo.exe
> default value is string = "C:\cygwin\usr\local\bin\foo.exe"
> string value named "Path" = "C:\cygwin\bin;C:\cygwin\usr\local\bin"
>
> What if you have two foo.exe's -- one cygwin, and one mingw ?
Or cygwin find/native find ? Gonna crash the find feature of Explorer?
>
> 3. It doesn't work if there is already a dll with the same
> name, loaded
> into memory (for Win95, Win98, and WinNT; the following
> analysis doesn't
> apply to Win98SE or W2K)
>
> e.g.
> c:\cygwin\usr\local\bin\app1.exe
> (app1.exe has AppPath key so that c:\cygwin\usr\bin is searched
> first)
> c:\cygwin\usr\bin\my-dll.dll
>
> c:\mingw\usr\local\bin\app2.exe
> (app2.exe has AppPath key so that c:\mingw\usr\bin is searched
> first)
> c:\mingw\usr\bin\my-dll.dll
>
> Run app1.exe -- fine, c:\cygwin\usr\bin\my-dll.dll gets loaded.
> Run app2.exe -- *will not load* c:\mingw\usr\bin\my-dll.dll
> into memory.
>
> This analysis extrapolated from description in:
> http://codeguru.earthweb.com/mfc/comments/6493.shtml
>
> Maybe the problem isn't solved by AppPath, after all.
>
This seems to say that DLLs are searched FIRST in memory, then on the disk
(at least on NT and 95/98)... That was what I seems to understand while
reading MSDN Library where they says that side-by-side libraries avoid this
preference given to already loaded libraries.
If this proves true, then the only solution would be to change the name of
the DLLs ;-(
Note that the in-memory problem is particularly important giving the fact
that a lot of windoze apps (cygwin or not) are usually long-lived especially
if they have a GUI. Thus if one starts a mingw GUI app that uses libpng.dll
(quite logical) then NO cygwin app using libpng will be able to run as it
will always try to use the mingw-libpng.dll in memory.
Does that mean that most ported unix apps were not interactive apps but
short-lived ones or that people are so sued to PCs crashing when trying to
do several things at once that they do not complain :-)
Cheers,
Bernard
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: dautrevaux AT microprocess DOT com
b DOT dautrevaux AT usa DOT net
--------------------------------------------
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -