On Setup Bootstrap Loaders
Almost two years ago, I wrote about how to create multi-language MSI packages. Although using transforms to internationalize an MSI package is a viable solution, one drawback of this approach is that it may require a bootstrap loader.
While it is easy to say that a bootstrap loader is required and many high-profile setups do indeed use bootstrap loaders, bootstrap loaders do have their issues. They not only add complexity to the setup package, there actually are several reasons why a bootstrap loader-free setup may be preferrable.
Bootstrap loaders
The idea of a bootstrap loader is to have an EXE file that does some prerequisite work and then launches the actual installer, which is usually implemented as an MSI package. While the MSI package may be a separate file, a download-friendly setup usually requires the bootstrap loader to embed the MSI package inside the EXE file and extract it when started.
While the average end user probably will not care much whether he double-clicks on an .exe or an .msi file, a standalone MSI-package is a better Windows citizen for at least the following two reasons:
Active Directory has native support for deploying MSI packages. It is, of course, possible to deploy EXE-based setups through AD, but these tend to require more work or more elaborate software solutions like SMS.
msiexec supports a plethora of switches that allow customizing and automating setups. These switches usually cannot be used when a bootstrap loader is present. To be equally admin-friendly, a bootstrap loader should therefore support appropriate command line switches for things like performing quiet installations, pre-selecting features, and suppressing reboots. Needless to say, impementing these features increases complexity and implementation effort.
That said, there are good reasons to avoid using a bootstrap loader. If, for example, all the bootstrap loader has to do is determine the user’s locale to choose an appropriate MSI transform, it may well be worth considering whether it is easier to just offer 5 language-specific MSI packages for download. And in case of CD-ROM based distribution, a simple HTML Application (HTA) could serve as a bootstrap loader-surrogate.
Still, there are situations when a a true boostrap loader is required. A classic example for this is MDAC: With Windows XP, MDAC has become part of Windows, but if you still support older Windows releases, you do not have much choice but to redistribute MDAC. In all those years, however, Microsoft has not managed to provide a proper merge module for MDAC. There were several half-hearted attempts both by Microsoft and others to wrap MDAC by a MSM, and in fact, I tested at least five of them, but not a single one was robust enough to be useable in practice. Given this situation, the only sane choice was (and still is) to put the duty of installing MDAC on the bootstrap loader.
Another common reason for using bootstrap loaders used to be that the machine might not have the correct Windows Installer version installed – but unless you are crazy enough to require Windows Installer 4.0, this should not be of much concern today.
Creating a bootstrap loader
Notwithstanding these pros and cons, the question remains how to create a bootstrap loader. Several of the commercial setup authoring tools have built-in support for that and their use might be the most straighforward approach. However, after having had a horrid experience with Wise for Windows Installer, I have not used any of these Windows Installer-based authoring tools and therefore cannot say much about them.
With the upcoming 3.0 release, WiX also includes a tool for creating bootstrap loaders – although it does not quite seem ready for prime time yet.
Creating a custom bootstrap loader from scratch is certainly the most flexible approach and doing so should not actually be too hard. However, implementing a full fledged bootstrap loader is likely to require more effort than most teams are willing to put into a setup.
There is, however, another approach that may seem somewhat unorthodox at first but has served me well for a past project: Using one of the script-based setup solutions to roll your own bootstrap loader. The idea of tools such as Wise Installation System (which, btw., has absolutely nothing to do with Wise for Windows Installer_) is that the entire setup is authored as a script. Now, contrary to the original intent of these authoring tools, you can leave all the wizards and UIs aside, start off with an empty script and leverage the rather powerful building blocks and constructs these scripting languages tend to offer to create a highly customized (UI-less) bootstrap loader. Taking WIS as an example, extracting an embedded file is a matter of one line of code. Similarly, invoking GetLocaleInfo to query the system’s locale is a snap. And for even more powerful bootstrap loaders, it is possible to extract a helper DLL and call its routines from within Wise Script.
As I said, this approach has served me well for a particular project that required a pretty complex bootstrap loader. And while I cannot recommend this approach unconditionally (especially because of the quirkiness of WIS and the fact that WIS is actually an obsolete technology), it is an approach that, when a bootstrap loader is absolutely necessary, may be worth considering.