--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> At 11:23 PM 18/11/2003 +0000, you wrote:
> >My reading of the MS documentation suggests there is an error in
> >the new scripts. (Of course I may be wrong.)
> >
> >To ensure that the installed dlls are used rather than ones found
> >from the system directory, there are some zero length ".local"
> >files, one for each dll.
> >
> >I think they should be tied to the exe files not the dlls. For
> >instance I think there should be a fbserver.exe.local file.
>
> Why? fbserver.exe is not a Windows system file.
>
>
> >Source information is here:
> >
> >http://msdn.microsoft.com/library/en-
> >us/dllproc/base/dynamic_link_library_redirection.asp
>
> For a complete re-read, here's the text. There is *one* example

of an exe

> file being redirected to use a local file called editor.exe,

rather than

> the text editor in the system directory. The rest is about DLLs.
>
> Furthermore, LoadLibrary calls don't apply to exe files.
>
> IOW, the kit-builders' interpretation is spot-on.
>
> ============================================
> Dynamic-Link Library Redirection
> Problems can occur when an application loads a version of a DLL

other than

> the one with which it shipped. Starting with Windows 2000, you

can ensure

> that your application uses the correct version of a DLL by

creating a

> redirection file. The contents of a redirection file are ignored,

but its

> presence forces all DLLs in the application's directory to be

loaded from

> that directory.
>
>
> The redirection file must be named as follows: appname.local.
>
> For example, if the application's name is editor.exe, the

redirection file

> is named editor.exe.local. You must install editor.exe.local in

the same

> directory that contains editor.exe. You must also install the DLLs

in the

> same directory.
>
> The LoadLibrary and LoadLibraryEx functions change their search

sequence if

> a redirection file is present. If a path is specified and there is

a

> redirection file for the application, these functions search for

the DLL in

> the application's directory. If the DLL exists in the

application's

> directory, these functions ignore the specified path and load the

DLL from

> the application's directory. If the module is not in the

application's

> directory, these functions load the DLL from the specified

directory.

>
> For example, an application c:\myapp\myapp.exe calls LoadLibrary

using the

> following path:
>
> c:\program files\common files\system\mydll.dll
> If c:\myapp\myapp.exe.local and c:\myapp\mydll.dll exist,

LoadLibrary will

> load c:\myapp\mydll.dll. Otherwise, LoadLibrary will load
> c:\program files\common files\system\mydll.dll.
>
> Note It is good practice to install your application's DLLs in

the same

> directory that contains the application, even if you are not using
> redirection. It ensures that installing your application will not

overwrite

> other copies of the DLL and cause other applications to fail. In

addition,

> other applications will not overwrite your copy of the DLL and

cause your

> application to fail.
>
> ============================================
> heLen

Thanks for thinking about this Helen.

The plan as implemented seemed very logical to me as well, but I did
not think it agrred with what MS were saying.

The only way to be sure it was to try it. I think I am right this
time!

I have now managed to create the situation where the files have an
effect, and it is only when you make one with the executables name
in it that anything seems to change. It is explained on the MS site,
but it took me a few attempts to work out what was meant. It has
nothing whatsoever to do with the complex details of the registry
entry "SafeDllSearchMode". That sent me off in a few wrong
directions. It is all to do with specifying dll paths from withing
the executable - which is just what we are doing with the new
registry settings.

My test involves (of course) some different versions of gds32 and
fbclient - at least the differences are not obscure.

I have both FB1.0.3 and FB1.5RC7 running, with 1.5 on a different
port. So if I connect using the new gds32 or fbclient I always
connect to the 1.5 server. If I use the 1.0.3 gds32, I can only
connect to the FB1.0 server because that dll cannot use the non-
standard port. (The same reliable effect is seen with local
connections because the IPC names are different.)

I have a test client app that uses the new FB registry settings to
find the correct location of fbclient.dll, and loads it without
using gds32 at all.

I placed a copy of the FB1.0.3 gds32.dll, renamed as fbclient.dll,
in my app's directory. It had no effect because my app read the
registry as it is supposed to, and loaded the real fbclient. Now I
tried adding a zero length fbclient.local file to my app's
directory - it had no effect. (fbclient.dll.local was the same).
Then I renamed the .local file to MSysTest.exe.local to match my
app - and despite passing a full path to LoadLibrary, it loaded the
local FB1.0.3 dll and connected to the FB1.0 server.

So it really is the way that MS say, not the way you would expect.
The file has to have the executable name in its name, not the dll
name.

The question then is why would the files be of use? We only need
files when an application sets a full path to a dll and we need to
override that selection.

Without them, I can see an issue when doing an upgrade. If we have a
1.5 server running and want to test a 1.6 server, we would have a
default instance setting that returned the 1.5 fbclient dll. If the
1.6 utilities used that to find their fbclient, we would be using a
1.5 client for our 1.6 tests. The presence of files in the local bin
directory would mean we would be guaranteed to use a consistent set
of code.

I'm now pretty sure we need .local files - but only because we have
a new system that sends full path information, and we may wish to
override it.

Regards

Eric