On Windows, the installer executable has some special requirements.
It needs to be built with additional things that UNIX executables do not require.
A manifest file. This is an XML file that provides metadata about the executable:
privilege required, does it need admin? (we use this to demand admin privs for the installer)
version info (optional)
compatibility info (what Windows versions is the executable supposed to work with — optional but see )
A resources file. This is a special source file that gets compiled and embedded into the executable. Our contains:
definitions for gui elements (icon, progress bar, dialogs)
version information (can be viewed by examining file properties in Explorer
Windows executables express their version in terms of a series of four 16-bit integers. I propose to map our BK versioning onto that scheme in the following ways:
bk-6.0.3 -> 6, 0, 3, 0 bk-6.0.2c -> 6, 0, 2, 3 ('c' - ('a' - 1)) bk-6.0 -> 6, 0, 0, 0 bk-6.0.0-pre1 -> 6, 0, 0, 421 (simple csum of '-pre1')
20140513123448 -> 2014, 05, 13, 1234 (drop the seconds)
To support this mapping, I’ve added src/utils/rcversion.l and added the necessary make(1) magic.
Code Signing the Installer Executable
We have purchased a code signing certificate from Comodo. The certificate lives in src/win32/bitmover-cert.p12 and the actual signing logic is encoded in src/util/Makefile.
Without a signed installer binary then at install time, when Windows displays the privilege elevation dialog, it shows "Unknown publisher".
 If your manifest does not explicitly declare compat with Windows 8.1 then the GetVersionEx() call will lie and report Windows 8 even on an 8.1 machine. Of course, it cannot be that easy. I have hacked a manifest file that makes a bk.exe that reports 8.1 correctly but as soon as that binary is moved it stops working.