Subject | Re: [firebird-support] FB1.5 Win32 Installer - Possible Error |
---|---|
Author | Paul Reeves |
Post date | 2003-11-19T08:42:34Z |
On Wednesday 19 November 2003 00:23, ericthorniley wrote:
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'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.
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.
You also wrote (about the use of myapp.exe.local files) :
entries for each server (or client) installed. If we know we want to test a
1.6 server then we load the library from the path specified for the 1.6
install. The default instance is for agnostic applications that really
don't care or just don't know. But where possible Firebird compliant
applications should look to load the correct library.
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.
Paul
--
Paul Reeves
http://www.ibphoenix.com
Supporting users of Firebird and InterBase
> My reading of the MS documentation suggests there is an error inActually, I believe you may be right. On re-reading the microsoft
> the new scripts. (Of course I may be wrong.)
>
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'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.
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.
You also wrote (about the use of myapp.exe.local files) :
> Without them, I can see an issue when doing an upgrade. If we have aActually, this isn't (or shouldn't) be true. The registry will contain
> 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.
entries for each server (or client) installed. If we know we want to test a
1.6 server then we load the library from the path specified for the 1.6
install. The default instance is for agnostic applications that really
don't care or just don't know. But where possible Firebird compliant
applications should look to load the correct library.
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.
Paul
--
Paul Reeves
http://www.ibphoenix.com
Supporting users of Firebird and InterBase