Commentary: Windows Vista Gets Harder To Multiboot

In Visual Tour: Windows Vista Begins To Get Real, I took a close look at the December CTP (Community Technology Preview) beta (Build 5270) of Windows Vista. However, one of the many small things about Windows Vista that wasn't covered in that review — and hasn't been covered much by reviewers — is the change in the way the new OS handles boot instructions.

Under Windows XP and 2000, Windows looks for a simple text file, called boot.ini, that controls boot options, displaying them for your selection in character mode during system boot. If you have more than one version of Windows installed on a computer, Windows consults the boot.ini file (located in the root directory) for this information at boot time. Boot.ini controls basic defaults, such as which installed OS will load automatically if you don't intercede on the multiboot screen, the wordings that describe your options there, and how long the multiboot screen will display at boot time before executing its defaults.

A simple tool for editing boot.ini to control default boot behavior is available in the Advanced > Startup and Recovery area of the Control Panel. The boot.ini file is protected by read-only attribution, but that doesn't make it secure. If someone hacked your network or a Trojan wanted to execute a script to edit this file, that wouldn't challenge it much. In fact, the vulnerability could cause major headaches, especially for inexperienced users.

Presumably, this is the reason Microsoft opted to do away with the boot.ini text file in Windows Vista. I'm OK with that. My problem is with the alternative it has instituted instead.

Introducing Bcdedit
The only way to make changes to the multiboot configuration now is with a complex command-line utility called bcdedit (bcdedit.exe). Admittedly, there isn't much documentation for this utility yet. There is extensive help information built into the tool, although it's poorly written and figuring out the syntax requires guesswork. I found the tool incredibly difficult to use, and I had trouble making it do what I needed it to do.

For example, the act of switching the default OS from Windows Vista to Windows XP took me several trial-and-error attempts, and even then it didn't work properly. I'm sure I'll finish climbing the learning curve, but why the heck would Microsoft do this? Why not just encrypt the file and make it accessible only to users with Admin privileges who know the Administrator password? Why make the tool for editing the file as arcane as DOS or Linux?

When installing new versions of Windows Vista, I usually run Windows XP in drive C:, create a new partition, and then install the latest Vista beta in the new partition. Windows Vista, like Windows XP and Windows 2000 before it, automatically sets up the multiboot configuration during installation so that both operating systems are accessible. When I'm ready to install the next beta, I simply boot to Windows XP and change the multiboot configuration to default to XP. I use a utility to delete the Vista partition, recreate it, and reformat it as an NTFS drive. Then I install the new version.

Boot.ini Loses Control
With Vista's new way of managing the multiboot script — which has been in place since the October CTP — Windows XP's boot.ini file can't control Vista at all. The Vista way of doing this trumps the XP way of doing it. Even if you entirely delete the Vista volume, as I described in the previous paragraph, you'll still see the Vista version of the multiboot screen when you boot your machine, and your Windows XP boot.ini file goes totally ignored.

How is that possible? Simple. Microsoft has placed a new "boot" folder on your root drive. The bcdedit utility stores data in this folder. As of the December CTP, in order to solve the problem of uninstalling a Vista build and returning to the Windows XP default boot configuration, I added a simple step. I started by editing the Windows XP boot.ini file, making XP the default entry (and deleting the Vista entry). Then I simply deleted the c:\boot directory added by Vista, and followed the steps above, deleting, recreating, and reformatting the Vista partition.

Overall, the new way of managing boot script data seems overly complex and not particularly secure. Hey, utility programmers! I see an opportunity for a GUI program that makes the Vista boot data as easy to edit as it was under previous versions of Windows. (Perhaps you could add some encryption too?)