BootIt Bare Metal for testing semi-embedded systems

I use the term "semi-embedded system" to refer to a PC loaded with hardware, such as data acquisition A/D devices, motion controllers, digital I/O lines, etc. When I create installers for semi-embedded software I write, I like to make them as turnkey as possible. That means ensuring, through testing, that the installs work on fresh (and other not-so-fresh, but controlled and known) copies of Windows. BootIt Bare Metal (BIBM) by Terabyte Unlimited is indispensable for testing installs that include device drivers and other software that are not so easily uninstalled (sometimes from including very specialized software as sub-installs, which often do not come with clean uninstallers).

BIBM is a multi-booter like Grub and the built-in Windows boot menu, but so much more. It's also a partition editor like PartitionMagic or GParted, and a backup facility like Ghost. Below is a screenshot of my boot menu.

As you can see, the three operating systems I can boot from are: Windows 7 main, Ubuntu, and Windows 7 test. Below is a list of the partitions I've configured with BIBM.

But wait, how can there be so many partitions? Aren't you limited to just four? BIBM supports its own type of extended partitions (information about which are stored in that special BootIt EMBRM partition) and swaps them in and out of the regular max-four-partition MBR on the fly. That not only allows being able to multi-boot a large number of different operating systems (e.g. XP, W7, W8, Ubuntu 12, Ubuntu 13, etc.), it also enables the testing of installs. As you can see from the list of partitions, I keep clean copies of Windows 7 at the end of the hard drive -- specifically, one that is just a super-fresh install from the DVD, and the other that has Windows Updates run on it.

To test an install, I just copy and paste one of those saved partitions to the remaining blank area of the hard drive (denoted by BIBM with the line of hyphens "---"). I can do this iteratively to develop and debug an install that includes driver installs as sub-installs, without fear that I get "only one shot" to test it on fresh computer.

Even if an install doesn't involve drivers, this technique is useful from a licensing perspective. Windows 7 requires separate licenses for virtual machines, because Microsoft explicitly considers virtual machines to be separate machines. But I have not found where Microsoft forbids making backup copies on extra hard-drive partitions on a single machine. I am not a lawyer, so do not consider this to be legal advice that it is permissible to do so with a single license. But for VMs it is well-known you must have separate licenses.

Windows 8 and UEFI

Sadly, this technique is threatened with the advent of UEFI SecureBoot and Windows 8. BIBM still works, but the BIOS and OS must support a "legacy mode". It is reasonable to expect that "legacy mode" will become more rare in the future. TeraByte Unlimited is silent about whether it will support or bypass UEFI in the future.

Tips on installing Linux under BIBM

Installing Linux under BIBM requires a specific set of steps. The most important thing to remember is to install Grub onto the Linux partition (e.g. dev/sda2) rather than the MBR (e.g. dev/sda).

Additionally, the automatic install of Grub can sometimes fail. In that case, it is necessary to follow Terabyte Unlimited's instructions on manually installing Grub. If that doesn't work, it may be necessary to live-boot with the help of a Linux DVD into the Linux installation on your hard drive, and then reinstall the grub reinstaller:

sudo apt-get install --reinstall grub-pc

Installing 64-bit drivers from 32-bit installer

If you are using a 32-bit Windows installer, it is not straightforward to have it install a 64-bit driver. There are at least two reasons why you might be in this situation:

1. Your installer software is not the latest (or maybe doesn't even have a 64-bit version yet) ... or ...
2. Most of your components are 32-bit with just one or two that you want to differentiate 32 vs 64 bit.

The problem arises because shelling out to msiexec.exe from a 32-bit installer (and in the case of InstallShield, whether that be from InstallScript or as a Custom Action), the 32-bit C:\Windows\SysWOW64\msiexec.exe gets executed instead of the 64-bit C:\Windows\System32\msiexec.exe.

The basic answer comes from technet and the VB.Net code below is adapted from that with a slight improvement. By compiling the VB.Net code into an executable and shelling to that as an intermediary, the 32-bit world can be escaped from. The slight improvement to the code below is it preserves quotes around quoted arguments such as pathnames with spaces.

Module Module1
    Sub Main()
    Dim arrArgs As Array
    Dim Args As String = ""
    Dim intCount As Integer = 0

    arrArgs = System.Environment.GetCommandLineArgs()
    For Each Arg In arrArgs
        If intCount <> 0 Then
            If Arg.IndexOf(" ") > -1 Then
                Args = Args & " """ & Arg & """"
            Else
                Args = Args & " " & Arg
            End If
        End If
        intCount = intCount + 1
    Next
    Shell("cmd.exe /C" & Args, AppWinStyle.NormalFocus, True)
    End Sub
End Module

Then the InstallScript to invoke it is below.  It detects whether the OS is 64-bit, and if so installs the 64-bit drivers via the VB.Net code above (which is compiled to an executable cmd64.exe); otherwise, it installs the 32-bit drivers.

if ( REMOVEALLMODE=0 ) then
    if (Is(FILE_EXISTS, WINSYSDIR^"CsSsm.dll") = FALSE) then
        if (SYSINFO.bIsWow64) then
            svProgramCmd64 = TARGETDIR^"GaGe64\\cmd64.exe";
            svCmd64MsiExecPath = WINSYSDIR64^"msiexec.exe";
            LongPathToQuote(svCmd64MsiExecPath,TRUE);
            svCmd64MsiPath = TARGETDIR^"GaGe64\\CompuScope.msi";
            LongPathToQuote(svCmd64MsiPath,TRUE);
            svCmd64Param = svCmd64MsiExecPath + " /i " +
                           svCmd64MsiPath + " /passive /norestart";
            LaunchAppAndWait(svProgramCmd64,svCmd64Param,WAIT);
        else
            svProgramMsiExec = WINSYSDIR^"msiexec.exe";
            svGaGe32MsiPath = TARGETDIR^"GaGe32\\CompuScope.msi";
            LongPathToQuote(svGaGe32MsiPath,TRUE);
            svGaGe32Param = "/i " + svGaGe32MsiPath +
                            " /passive /norestart";
            LaunchAppAndWait(svProgramMsiExec,svGaGe32Param,WAIT);
        endif;
    endif;
endif;
The code above is for installing drivers for a GaGe CompuScope analog-to-digital converter board.  I am a user of GaGe boards, not an employee or representative of GaGe.

ProgramData virtualization

It's not enough to move data stores from Program Files to ProgramData when upgrading applications from XP to Vista/W7. It's also necessary to, in the application installation, set the permissions on those files to read/write for the group "Users". Otherwise, Vista/W7 will silently virtualize those files into shadow copies to the Users folder on a per-user basis.

PostgreSQL silent installation

I'm bundling PostgreSQL as part of a desktop application installation, only to find out what was the recommended silent installation procedure under PostgreSQL 8.3 -- using the MSI file -- has been removed from PostgreSQL 8.4. Evidently, you're supposed to use command line utilities to effect silent installation now -- and it's not entirely documented. After some trial and error, I determined that the following sequence will silently install PostgreSQL 8.4:

1. mkdir C:\Program Files\PostgreSQL\8.4
2. net user postgres password /ADD
3. initdb --username=postgres C:\MyDB
4. pg_ctl register -D C:\MyDB
5. net start PostgreSQL
6. psql -U postgres -f MyDDL.sql

Disabling XP's check for signed drivers

It is possible to disable XP's check for signed drivers with the code
at http://openvpn.net/archive/openvpn-users/2004-11/msg00341.html

Of course, it's also possible to disable it manually via Start->Control Panel->System->Hardware->Driver Signing. But the C code from the link above allows an installer to disable it automatically. For the vertical application I maintain, I bundle every possible A/D board driver into an all-in-one InstallShield installation, and I have to use a variety of tricks to make them all install silently. This is the latest such trick.

Manifest Hell

Visual Studio 2005 SP1 has different CRT (C Run-time) and MFC libraries than non-SP1 Visual Studio 2005 does (also known as VS2005 RTM, or release to manufacturing). This can wreak havoc in light of XP's strong support for (and enforcement of) SxS (side-by-side) DLLs, which allows different applications to use different versions of the same DLL. Or, in the more complex case I encountered, a single application may end up needing to dynamically link to both the RTM version of MFC and the SP1 version of MFC.

I ran into this while trying to use some ActiveX controls out of National Instruments' Measurement Studio. Measurement Studio needed the RTM version of MFC, but my Visual Studio 2005 SP1 would only create applications with the SP1 version of MFC. And they conflicted, generating "activation context" errors.

To handle SxS, Visual Studio 2005 introduced the concept of manifest files, which specify precisely which version(s) of which DLL(s) are required. There is even a mechanism to automatically promote to using later versions of required DLLs. No matter the combination, I couldn't get my MFC application to work with Measurement Studio, because I of course did not have the source code to Measurement Studio to recompile it against the SP1 version of MFC. As one blog author put it, in the course of trying to solve DLL Hell (for the user), Microsoft ended up creating Manifest Hell (for the developer).

So my solution was to use ATL instead, and let Measurement Studio use the RTM version of MFC.

Don't delete components from an MSI

In an MSI, don't ever delete a component unless you plan to make it a"major upgrade" (change of both product and package GUIDs) rather thanjust a "minor upgrade" (same product GUID, different package GUID). If you try, msiexec will fail with "another version of this product is already installed". It was particularly frustrating for me because I use InstallShield to build an MSI wrapped inside InstallScript, and InstallShield was silently suppressing the error and just notinstalling anything.

To achieve the same effect as deleting the component, I just deleted all the files within that component instead, and that worked fine.