Managing a massive Windows installation has already been likened to administering a colossal database. Today, Microsoft added new functions to its Installer for setup packages, that really does start treating Windows like one.

In the last major update to Microsoft's Windows Installer package, used by setup software to ensure proper installations, a feature was added to capture the running state of applications, suspend them, and restart them after setup. This was reportedly necessary for installing updates to Windows Vista; but outside of Vista itself, it's a feature that, frankly, hasn't seen much use -- in fact, quite a bit of software out there still seems to work fine with Installer 3.1.

That might change with the release today of Windows Installer 4.5, which in addition to hardening new features, adds some new incentives for developers to finally make the shift, including a database-like transaction processing facility that not only enables rollback in case of failure (without having to restore from backups) but also enables multiple-package installations.

Registering a process as a transaction and then committing it, like an addition to a remote database, enables that process to be rolled back and revoked, restoring the previous state. This holds the promise of making installations significantly safer.

One major bug fix which developers will appreciate has to do with prior Installers' tendency to clean up too much after themselves, often removing interim components that were necessary to later steps in the process. In a post last month to the Windows Installer team blog, one developer wrote, "When a patch added new content in the form of a new component and that patch was being uninstalled, we used to remove that content, even if that content is shared by other products. This is now fixed in Windows Installer 4.5."

But perhaps the biggest and most anticipated addition to the new version is the ability for developers to embed a custom UI in their installer packages. Custom UIs were possible in prior versions, but only in very limited scenarios, and only when a bootstrap setup executable was invoked first, that in turn invoked the process that invoked Windows Installer.

"Embedded UI...provides the package author enhanced control of the Windows Installer user interface," reads an April post to the Installer team blog, "through custom code which is bundled with the MSI file itself and without requiring complex and bug-prone workarounds to handle the various activation paths which can trigger an install. Regardless of the activation method of the installer operation, MSI will use the custom embedded UI provided within the package."

XAML, perhaps? That would have been perfect. But you can create a front end that's compiled into a DLL -- using Visual Studio 2008, of course -- and then reference that DLL using one of Installer 4.5's upgraded list of intrinsic functions.