Re: DLL naming conventions

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

There a path trick used in system integration on *metaframe/ NT Terminal
Server* machines to keep dll hell to a minimum - I just remembered it...

adding (windows path format) .\bin;..\bin;..\..\bin; to the front if your
path allowed different applications to find different versions of dlls with
the same name, the installer just moved the customised .dll to the farthest
point in the path that did cause issues...

maybe a similar trick could help? Although it doesn't get round the
in-mmeory issue for win9x/nt 4.0 workstation & server

Rob

----- Original Message -----
From: "Bernard Dautrevaux" <Dautrevaux@microprocess.com>
To: "'Charles S. Wilson'" <cwilson@ece.gatech.edu>; "Robert Collins"
<robert.collins@itdomain.com.au>; <cygwin@sources.redhat.com>
Sent: Tuesday, September 05, 2000 2:27 AM
Subject: RE: DLL naming conventions


> > -----Original Message-----
> > From: Charles S. Wilson [mailto:cwilson@ece.gatech.edu]
> > Sent: Monday, September 04, 2000 5:09 PM
> > To: Robert Collins; cygwin@sources.redhat.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@microprocess.com
> b.dautrevaux@usa.net
> --------------------------------------------
>


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com