| Firebird Documentation Index → Firebird 2.5 Release Notes → Installation Notes → Windows |
|
|
|
Tracker entry: CORE-1814
In this release it is possible to be a little more flexible about the location of your embedded application components than previously. Changes made here addressed a handful of interrelated issues that had been problemmatical for application developers, viz.
An external function library that depended on another DLL, such as ib_util.dll or the client code in fbembed.dll or some totally external library, could not be just placed in the ..\UDF folder beneath the emulated Firebird root (<root>) because the depended-on files should not be in that location. It was necessary to be somewhat creative with the %PATH% variable.
The previous rules for determining the emulated <root> required fbembed.dll (renamed or not) to be in the same folder as the application code. One effect of that was to make it necessary either to keep separate copies of fbembed.dll for each application that needed to use it, or to place all of the client executables in one location.
Determination of the <root> for the embedded v.2.5 engine has been changed so that it no longer has to be the application's path. It is by the location of fbembed.dll, wherever it might be located. This means that, with the v.2.5 engine, you can set up a standard, self-contained structure for the emulated Firebird <root> that is available to any of your embedded applications, to third-party UDF libraries and to local copies of the command-line tools, once they have loaded fbembed.dll.
If you separate the emulated Firebird tree from your application[s], be sure to set the RootDirectory parameter in the structure's firebird.conf file to point to the absolute path location that is its <root>.
The new rules do not break your existing embedded structures. You can still structure your embedded applications just as you did previously. The difference now is that it is not a requirement any more to deploy your executable with its own dedicated copy of an emulated Firebird <root> structure.
Tracker entry: CORE-2243
Because the changes took effect from V.2.1.2, this discussion also appears as a special topic in the V.2 Installation and Migration document.
Firebird 2.5 is built by the Microsoft MSVC8 compiler in Visual Studio 2005. Because all the Firebird binaries are built to use dynamic linking, they all require run-time libraries.
To avoid the dll-hell issue Microsoft introduced new rules for the distribution of components
that may be shared by multiple applications. From Windows XP forward, shared libraries—such
as the Visual C++ and Visual C runtimes msvcp80.dll,
msvcr80.dll and mscvcm80.dll—must be distributed as
shared or as private assemblies.
The Microsoft MSI Installer installs shared assemblies into the common special
folder SxS for use by multiple applications.
Private assemblies are distributed with applications and should be put into the
application folder. Use of the \system32 folder for assemblies is
now prohibited on the XP, Server2003 and Vista platform families.
To install the runtimes as a shared assembly, the deployment system must have MSI 3.0 installed and the user must have administrative privileges. Often, this is not possible with an application being deployed with Firebird Embedded: it must be installed ready-to-run. In that case, do not plan to install the runtimes as a shared assembly.
To install the MSVC8 run-time libraries as a private assembly its contents—the
three DLLs mentioned above and the assembly's manifest file, Microsoft
VC80.CRT.manifest—must be put into every folder where a dependent binary
(.exe or .dll) resides, because of built-in checks for the folders that are the expected
location of the runtimes that are equivalent to the compile-time libraries that were used.
A typical installation of Firebird Embedded would thus require three complete copies of the MSVC8 run-time assembly: one in the application folder and one each into the \intl and \udf folders. To avoid the issue of bloating the installation, some changes were done for V.2.1.2 in the way some of the Firebird binaries are built. (See also Tracker entry CORE-2243).
These are the changes that enable Firebird Embedded to work even if the application structure does not incorporate the MSVC8 runtime assembly:
The libraries ib_util.dll, fbudf.dll, ib_udf.dll, fbintl.dll are built without any embedded manifest. The effect is to avoid having the loader search for a MSVC8 assembly in the same folder as corresponding DLL. For this to work, the host process must have already loaded the MSVC8 run-time via manifest before any attempt is made to load these secondary DLL's.
fbembed.dll now has code to create and activate the activation context from its own manifest before loading any secondary DLL that might be required.
It is highly recommended to use the Microsoft redistribution package to install the
MSVC8 run-time! The executable installer vcredist_x86.exe
or vcredist_x64.exe (as appropriate to your kit selection) should
be present in the zip kits for the full installation and the Embedded version. If not,
it can be downloaded from the Microsoft download site.
Third party UDFs must satisfy one of the following requirements if a MSVC8 run-time assembly is installed as private assembly. When compiling the UDF library, the MSVC8 runtime EITHER:
is NOT used
is used but the build is done without the embedded manifest
is used and the build is done with the embedded manifest—the default option in the MSVC IDE. In this case the MSVC8 assembly must be in the same folder as the UDF library
|
| Firebird Documentation Index → Firebird 2.5 Release Notes → Installation Notes → Windows |