Special Topics

Managing MSVC8 Assemblies
Known Windows Issues

In this section we have special topics that provide extra detail about new or changed features affecting your installation of Firebird on Windows.

Managing MSVC8 Assemblies

V. Khorsun

Applies from V.2.1.2 Onward

Firebird 2.1 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.

Installing Runtimes as a Shared Assembly

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.

Installing Runtimes as a Private 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.

Notes

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

Known Windows Issues

Over the years, various Windows issues that affect Firebird have been noted. They are listed here as being of possible interest when things seem to go not so well.

Winsock2

Firebird requires WinSock2. All Win32 platforms should have this, except for Win95. A test for the Winsock2 library is made during install. If it is not found the install will fail. To find out how to go about upgrading, visit this link.

System Restore Utility (XP, Server 2003 and ME)

Windows XP (Home and Professional editions), Server 2003 and ME have a feature called System Restore, that causes auto-updating (backup caching?) of all files on the system having a ".gdb" suffix. The effect is to slow down access to Firebird databases having that suffix to a virtual standstill as the files are backed up every time an I/O operation occurs. (On XP and Server 2003 .NET Servers, there is no System Restore).

A file in the Windows directory of ME, c:\windows\system\filelist.xml, contains "protected file types". ".gdb" is named there. Charlie Caro, an InterBase developer, originally recommended deleting the GDB extension from the "includes" section of this file. However, it was later demonstrated that WinME rebuilds this list. In XP, it is not possible to edit filelist.xml at all.

On ME, the permanent workarounds suggested are one of:

use FDB (Firebird DB) as the extension for your primary database files--RECOMMENDED
move databases to C:\My Documents, which is ignored by System Restore
switch off System Restore entirely (consult Windows doc for instructions).

On Windows XP and Server 2003 you can move your databases to a separate partition and set System Restore to exclude that volume.

Windows XP uses smart copy, so the overhead seen in Windows ME may be less of an issue on XP, for smaller files at least. For larger files (e.g. Firebird database files, natch!) there doesn't seem to be a better answer as long as you have ".gdb" files located in the general filesystem.