Dear,

On Wed, 19 Nov 2003 09:42:34 +0100,
Paul Reeves wrote :

> On Wednesday 19 November 2003 00:23, ericthorniley wrote:
> > My reading of the MS documentation suggests there is an error in
> > the new scripts. (Of course I may be wrong.)
>
> Actually, I believe you may be right. On re-reading the microsoft
> documentation it does indeed look as if we should be supplying files named
> fbguard.exe.local and fbserver.exe.local (and .local for all the .exes.)
>
> I also suspect that none this actually matters.

I think so, re-reading those docs again.

> I've tried using the current system (libname.local for each library
> that is local) and fbguard.exe.local and fbserver.exe.local. Both
> yield the same results. fbclient.dll and msvcp60.dll are loaded
> from the local images and msvcrt.dll is loaded from <sys> dir. So,
> as far as the server is concerned, we looks like we don't need to
> bother.

It would only have an effect if one of our server binaries were
loading some DLL using specific paths (like LoadLibrary("path/some.dll")
and we wanted to kill that path so that the executable runs as if
LoadLibrary("some.dll") had been coded. But we don't have such cases.
So these .local files would have no effect, present or absent.

> Of course, from Firebird's perspective the issue isn't about loading the
> correct fbclient, it is about loading the correct microsoft libraries. In
> the old days before MS tried to solve dll hell installers would try to
> write MS system libraries into <sys> dir. This doesn't work any more, so we
> are now installing them locally and the point of .local is to get the
> system to load the local system library. It ain't doing it.
>
> As it happens, I noticed this discrepancy between the loaded libraries
> yesterday, while researching another subject. I'm really not sure what to
> do about this.

Just copying the system libraries in the same directory as our
executables will do the trick of loading these local copies - most of
the times. I suspect Windows 95 might not do it (got to re-read some
more doc).

> ...
> But this does throw up another question - perhaps a client application that
> really cares about the firebird client library used should be installing
> the library in the same directory as the application and creating a
> myapp.exe.local file.
>
> I think this topic needs a little more investigation.

An old application, which doesn't care about which client library is
loaded and so does not lookup the FB 1.5 registry key to find the path
from where to load it, but would like to use a local version of
fbclient.dll could indeed pack the dll in the same directory as the
application. Assuming that this application just
LoadLibrary("fbclient.dll") or is statically bound to it, the system
should find the local fbclient.dll.

Not sure again that the .local files would change anything in there,
except if the application had a hardcoded dll path (like LoadLibrary
("path\fbclient.dll")).

To synthesize, here is an extract from the MS SDK :

| When no path is specified, the function searches for loaded modules
| whose base name matches the base name of the module to be loaded. If
| the name matches, the load succeeds. Otherwise, the function searches
| for the file in the following sequence:
|
| - The directory from which the application loaded.
| - The current directory.
| - The system directory. Use the GetSystemDirectory function to get the
| path of this directory.
| - The 16-bit system directory. There is no function that obtains the
| path of this directory, but it is searched.
| Windows Me/98/95: This directory does not exist.
| - The Windows directory. Use the GetWindowsDirectory function to get
| the path of this directory.
| - The directories that are listed in the PATH environment variable.

There is a slight difference with Windows XP, where the step 2/
(current directory - not to be confused with app directory) is
searched AFTER system directory and before path. But this does not
impact what we are discussing.

In all cases, a search for a DLL (when no specific path is used to try
to load it) will always succeed from the same directory where the
hosting module (the application executable) is loaded from, if found
there.

So just packaging system dlls in the same dir as our server
executables will make these executable use those local copies of the
dlls.

Same holds true for an application shipping a fbclient.dll in the same
directory as the application exe file : the local fbclient.dll will
get used.

This comment in the same SDK page says it all :

| The first directory searched is the one directory containing the
| image file used to create the calling process (for more information,
| see the CreateProcess function). Doing this allows private dynamic-link
| library (DLL) files associated with a process to be found without
| adding the process's installed directory to the PATH environment
| variable.

--
Best Regards,
Olivier Mascia
http://www.ibpp.org