Burn is the name of the new WiX chainer. (Burn is brought to you by the letter B, which stands for bootstrapper.) Though we’re working to ship WiX v3 without Burn, work on Burn continues — it turns out that several members of the WiX virtual team need a chainer for their day jobs. As I’m one of them, I thought I’d blog about the work I’m doing. To start that, this post covers the layers in Burn and how they fit together:
- Core: The Burn core is where the actual chaining and installation code lives. This is, not surprisingly, the biggest chunk of code in Burn, with several thousand lines of code. The core supports installing .msi and .exe packages, with .msp patch package support planned. The core is a static library.
- UX: UX, which stands for User eXperience, handles user interface. Burn includes StdUx, which provides a basic UI. StdUx can be replaced by any DLL that adheres to the Burn UX interface.
- Stub: The Burn stub is an .exe that handles standard command-line processing and startup. It loads the manifest, UX DLL, and packages — any of which might be embedded in the .exe — and lets the UX take over.
- BurnExe: BurnExe is the manifest compiler and bundle builder. The package manifest is an XML file that specifies the list of packages to be installed; BurnExe resolves references to packages and extracts metadata like the product code and product version. BurnExe also optionally builds a bundle — a copy of a stub with embedded data. For example, right now, BurnExe supports embedding the resolved manifest so setup.exe can be signed to help ensure the manifest hasn’t been tampered with. The plan is to also support embedding the UX DLL and packages to provide a single setup.exe download.
Any layer of Burn can be replaced. For example, I expect someone on my team to create a custom UX for Train Simulator 2. The Burn design focuses customizability in the UX so the other layers can be used as-is.
There’s plenty more work to do, so that’s it for today. More to come as more of Burn matures!