Installing Firebird with your application

under Windows

About this talk

I'm Paul Reeves and I work for IBPhoenix. I've been maintaining the Windows installation kits
since more or less the beginning of the Firebird project.

I'm going to explain today how the installation kits are built and how it responds to the needs of
both Firebird and the requirements of the different Windows operating systems that Firebird
runs on.

I'm also going to look at the internals of the Firebird install script and explain how it can be
deployed from your own installer.

Hopefully this will give you enough info to help explore the way Firebird is packaged and use
some of those insights to either repackage Firebird itself, or help with the packaging of your own
software.
 Good Practice
Do No Harm

• Don't screw up the users system

• Make it as easy as possible (click through install).
• Don't make guesses - if in doubt leave it to user to decide.

Leave Quietly and Without a Trace

• Make it as easy as possible to uninstall

• Don't screw up the users system
• Don't leave a mess lying around.
• You'll be the one to appreciate a clean uninstall more than anyone.
 File copying is not the same as installation
File copying really does not work as an installation method unless the application is single user
and does not require deployment of runtime libraries. Even then it is probably not safe. Modern
Microsoft operating systems work on the assumption that they are multi-user and more than one
user may be logged in at a time. And the rules for installing into the system directory have
changed considerably. Because of this, installation methods have been forced to grow up.

Remember – File copying is not an installation method.

Windows installation woes - a brief history

• In the beginning it was just a matter of decompressing some files and copying them
around.

• This started to get complicated when developers needed to deploy MS runtime libraries.
Users soon found their <sys> directory was screwed up. The term DLL hell was invented.

• MS tried to tighten up the rules with Windows 2000

• MS then completely changed the rules with the release of Win XP and Windows 2003

• The new rules required using their installer.

• During the lifetime of WinXP / W2K3 they changed the required installer version from v2
to v3

• None of this mattered to Firebird until we added support for 64-bit binaries

• Only Vista and later ship the required MSVC8 runtimes.

• All new windows operating systems are now (nominally at least) multi-user.

• Users no longer have full administration rights by default.

The different requirements of each windows
o/s

Win9* and Win Me

• No services
• File copy works fine

NT4
• File copy into <sys> works fine .
• New versions of Firebird use some api calls that are unavailable on NT4

Windows 2000
• File copy into <sys> will work if the file is not in the protected list.
• Ships with Windows Installer 2.0
• Doesn't know about assemblies.

Windows XP and Windows 2003

• Use assemblies
• Early releases don't have Windows Installer 3.0

Vista
• Already ships with MSVCRT8 assembly.

Windows 2008
• No specific problems known
 The different requirements of each version
of Firebird.
Firebird 1.0

• Minimal requirements (probably just works)

• Installer is unmaintained
• Doesn't know about any O/S after W2K

Firebird 1.5

• Built with MSVC6

• Installer built with Inno Setup 4.2.7 (Vista support poor)
• Install Kits deploy CPP run-time
• Control Panel applet doesn't work with Vista

Firebird 2.0

• Built with MSVC7 ( aka VS2003) (No service pack)

• MS runtimes were/are stable

Firebird 2.1

• Built with MSVC8 ( aka VS2005)

• Installer created with Inno Setup 5.2.3
• No known Vista deployment issues
 A word about the x64 architecture

• Easy for users to switch.

• Easy for application developers.

• Not so easy for installation script builders.

• It is more fun when you need to detect 32 bit and 64 bit installs.

At first glance the MS O/S implementation of x64 is not intuitive. 64-bit binaries are in Windows\
System32 and the 32-bit libraries are in Windows\Syswow64. This is the opposite to the way
they approached the move from 16-bit to 32-bit.

The logic underlying this is simple – users should not have to do anything to switch to 64-bit. It
should all 'just work'. An existing 32-bit installer will install without any internal changes. The O/
S will handle everything. Files destined for “Program Files” will be sent to “Program Files (x86)”.
The O/S will detect any attempt to deploy a 32-bit binary into System32 and automatically place
it in Syswow64. It will behave similarly with any changes made to the registry.

This is great until you start creating 32-bit and 64-bit kits. Then the fun starts. If a 32-bit installer
does a registry lookup it will only see the 32-bit registry. Ditto for a 64-bit installer. However,
software like Firebird needs to check for 32-bit and 64-bit installs. And the installer needs
common code for both targets. If the host is a 64-bit O/S the pre-installation checks for Firebird
2.1 are twice as complicated as in previous versions.
 Firebird Installer - the main components
The requirements to package Firebird are fairly straight forward.

• Inno Setup

• WiX

• sed

• The output from a Firebird build

• The relevant MS runtime libraries

• The relevant documentation

The Firebird binary packages are built from BuildExecutableInstall.bat. The batch file is fairly
comprehensive. It will throw an error if the build environment is incomplete. If all the required
components are available it will launch the InnoSetup compiler and output the binary installer.
Note that the target platform is dependent upon the console environment. On 32-bit systems
this will always be 32-bit. On 64-bit systems this will default to 64-bit, unless the 32-bit cmd.exe
is run.
 About Innosetup
InnoSetup is open source and code is available via CVS. InnoSetup itself is compiled from
Delphi 2 and the pascal scripting component is compiled with Delphi 3.
It has been maintained and developed continually since at least 2000.

InnoSetup consists of three major components:

● The original inno setup script

This is laid out like an ini file, with sections and instructions within each section. Inno
Setup compiles the script into the installable executable.

● A pre-processor

This works very much like a standard c/c++ preprocessor.

As its name suggests it is useful for preparing the script for compiler. It enables us to
make the script as dynamic as possible

● A scripting language based on Object Pascal

The object pascal scripting environment brings with it many familiar Delphi classes, as
well as the expected core Pascal routines. There are hooks into InnoSetup so that it
knows when and where to call the Pascal Script functions and methods.

This combination of script environments makes Inno Setup extremely powerful. The downside is
that it is difficult to maintain and debug a large installation script.

Over the years the Firebird installer has become a useful repository of InnoSetup tips and tricks.
You can always download the Firebird InnoSetup script from these locations:

http://firebird.cvs.sourceforge.net/viewvc/firebird/firebird2/builds/install/arch-specific/win32/
(For the latest script - untagged for official release, therefore not fully tested.)

http://firebird.cvs.sourceforge.net/viewvc/firebird/firebird2/builds/install/arch-specific/win32/?
pathrev=B2_1_Release
(For the scripts used by Firebird 2.1)

http://firebird.cvs.sourceforge.net/viewvc/firebird/firebird2/builds/install/arch-specific/win32/?
pathrev=B2_0_Release
(For Firebird 2.0)

http://firebird.cvs.sourceforge.net/viewvc/firebird/firebird2/src/install/arch-specific/win32/?
pathrev=B1_5_Release
(For Firebird 1.5)
 What's in the InnoSetup script?

There are quite a few tricks in the InnoSetup scripts. The script itself is broken up into three
files. The main script contains the compilation instructions and the control code. There are two
supplementary files with some use Pascal Script code available too. Here are some examples
of useful tricks in the script.

1. Using the pre-processor to dynamically set the version number and use it through the
script.

This works in combination with BuildExecutableInstall.bat. The batch file sets the
environment and the preprocessor picks it up.

2. Removing hard coded strings with the preprocessor.

Again the preprocessor works with the environment set by BuildExecutableInstall.bat to
ensure that the InnoSetup script has very few hard coded strings.

3. Generating a custom form and display it.

The include file 'FirebirdInstallSupportFunctions.inc' demonstrates how to create a form
in code and display it. See the code for the CreateHelpDlg procedure.

4. Changing the InnoSetup GUI defaults.

It is possible to change the setup form. The UI is accessible in a similar manner to a
Delphi form. Some simple examples of changing it can be seen in the CurPageChanged
procedure.

5. O/S detection.
Some useful functions that simplify runtime o/s detection are in
'FirebirdInstallSupportFunctions.inc'

6. Decoding Binary version numbers.

Again, 'FirebirdInstallSupportFunctions.inc' has some useful functions to decode a binary
version number. This is useful checking which version of a file is installed.
 About WiX
• Open source

• hosted on Sourceforge

• run by guys from MS

• Builds MSI files (more or less) painlessly

• Uses a few simple xml files to describe the build. (These files are hidden in the win32
build dir.)

WiX became necessary when implemented support for 64-bit binaries on Windows. To do this
we needed to switched to the Microsoft Visual Studio 2005 compiler. Unfortunately, this entailed
deploying MSVCRT8 runtime libraries. In most cases these libraries can only deployed as
assemblies. WiX allows us to create our own assemblies, rather than shipping the entire MSVC
redistributable package.
Some problems with Firebird Installation
checks

• Installer will not run if it detects any version of Firebird or InterBase running.
This is a nuisance if, for example, the running server is not using the default port.

• The attempts to test if Firebird is running are not 100% reliable. The 'detection' signature
changes from version to version and the installer hasn't always kept up.

A particular problem is an attempt to install an older version when a newer version is

running.

• It makes a much better attempt to detect an existing install.

Most usage scenarios are covered, but it is still not 100% reliable.

• Older versions cannot reliably detect newer versions.

This is the main area where problems may arise.

• No guarantees vis-a-vis Firebird <> InterBase.

This is the second most important area where installation problems may arise.
 Scripted Installation

Just type HELP :-)

For example, at a command prompt, if you type something like:

c:\> Firebird-2.1.1.17910_4_Win32.exe HELP

a window will appear with the full documentation set for doing a scripted installation.

This document is also available in the \doc directory after a full install of Firebird.