Subject | Re: [firebird-support] GBAK - fbClient not found? |
---|---|
Author | Paul Reeves |
Post date | 2004-07-13T11:22:14Z |
Ivan Prenosil wrote:
(Well, horror might not be quite the right word.) Here is an extract from
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/
html/secure06122003.asp
dealing with security changes implemented in Win2K3
---- snip -------
DLL Search Order Has Changed
No longer is the current directory searched first when loading DLLs! This
change was also made in Windows XP SP1. The default behavior now is to
look in all the system locations first, then the current directory, and
finally any user-defined paths. This will have an impact on your code if
you install a DLL in the application's directory because Windows Server
2003 no longer loads the 'local' DLL if a DLL of the same name is in the
system directory. A common example is if an application won't run with a
specific version of a DLL, an older version is installed that does work
in the application directory. This scenario will fail in Windows Server
2003.
----- snip ------
I don't (yet) know what to make of this. I cam across it while trying to
work out if we can do better when it comes to installing msvcp60.dll, but
that is another story.
Paul
--
Paul Reeves
http://www.ibphoenix.com
Supporting users of Firebird and InterBase
>>Firebird 1.5 GBAK expects to find fbclient.dll in the \bin directoryActually, this is no longer true, as I have just discovered to my horror.
>>beneath the firebird_1_5 root.
>
>
> In other words, GBAK calls fbclient.dll using "load-time dynamic
> linking",
> i.e. fbclient is located using usual schema in these places
> 1. The directory that contains the module for the current process.
> 2. The current directory.
> 3. The Windows system directory.
> 4. The Windows directory.
> 5. The directories listed in the PATH environment variable.
>
>
(Well, horror might not be quite the right word.) Here is an extract from
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/
html/secure06122003.asp
dealing with security changes implemented in Win2K3
---- snip -------
DLL Search Order Has Changed
No longer is the current directory searched first when loading DLLs! This
change was also made in Windows XP SP1. The default behavior now is to
look in all the system locations first, then the current directory, and
finally any user-defined paths. This will have an impact on your code if
you install a DLL in the application's directory because Windows Server
2003 no longer loads the 'local' DLL if a DLL of the same name is in the
system directory. A common example is if an application won't run with a
specific version of a DLL, an older version is installed that does work
in the application directory. This scenario will fail in Windows Server
2003.
----- snip ------
I don't (yet) know what to make of this. I cam across it while trying to
work out if we can do better when it comes to installing msvcp60.dll, but
that is another story.
Paul
--
Paul Reeves
http://www.ibphoenix.com
Supporting users of Firebird and InterBase