[Firebird-devel] fbclient.dll - why not statically link it to its compiler support libraries ?

[Olivier M. <om...@ti...>]

Dear all,

Here is an (edited for length) post from the support list.

 >>We developed an application using Delphi 7 with Firebird Embed dll
 >>(RC7).
 >>We renamed the fbembed.dll to gds32.dll.
 >>We place this dll in the application folder during installation.
 >>Some users have reported the following error when opening the
 >>application in Windows 98:
 >>"Exception EIBClientError in module xxxx.exe at yyyy.
 >>Interbase library gds32.dll not found in the path. Please install
 >>InterBase to use this functionality."
 >>In other versions of Windows it runs ok.
 >>Does anybody have a clue?

 > Hi, we already found the cause of the error.
 > The file msvcp60.dll is missing in the system32 folder of the Windows
 > installation.
 > All we had to do was to ship this dll in our installation program.
 > Thank you.

This is far from being the first time that users have issues with 
fbclient.dll (or gds32.dll or fbembed.dll) because they don't have an 
up-to-date msvcrt.dll or are missing msvcp60.dll.

Since FB 1.5 RC8, some command-line utilities meant to be used during 
install time like instreg/instsvc/instclient were re-linked statically 
to suppress dependency to msvcrt/msvc60p.dll.

I seem to remember of past discussions and objections about statically 
linking the engine (fbserver.exe) - udf dlls related.

But why couldn't we statically link fbclient.dll at the very least ? 
Wouldn't it make it simpler for users ? I remember people saying they 
expected to be able to take fbclient.dll, drop it in their directory or 
the Windows System directory, nothing more, and then having it fly. With 
dependency to the dll version of the compiler libraries, the job is a 
bit more complex.

What am I missing about fbclient.dll that would forbid us to statically 
link it ?

Going a step further (the engine), couldn't we reconsider the UDF 
interfaces so that we are not forced to link to mscvrt.dll ?

Those static links will increase (by a small amount) the size of our 
executables. We're speaking some KB or tens of KB here, as we depend so 
*few* on C library and the goal is to not depend at all on C++ standard 
library soon.

Not intending to patch anything soon, just calling for discussion.

-- 
Best Regards,
Olivier Mascia