Related Topics: Virtualization Magazine

Virtualization: Article

An Approach to a Multi-Boot Windows Solution

When virtualization just isn't an option

I've been a big fan of boot loaders for the past decade; whether its lilo or grub or BootMagic, the ability to have multiple bootable copies of Windows has always been a necessity to anyone who works with beta software. The great thing is that with Windows XP Professional and Windows 2003, the NTLDR has finally come of age and can hold its own against the Linux boot loaders.

Why bother though? With virtualization software such as VMWare and Microsoft Virtual Server, you can just create a virtual machine to isolate different copies of Windows. While this is true, virtualization comes at a cost: you can't use your processor(s)'s full potential, and you can't use all of your system's available RAM. By definition, you are sharing the system's resources with the host operating system, which also will impact performance. In some cases, you may not be able to use your video or sound card's full potential either. When these limitations are not an option, you may find setting up your workstation with multiple bootable partitions is a better alternative.

It's a given nowadays that beta software runs slower than the release version. This is often due to the overhead of debug code and additional logging. In some cases, beta software is more timing sensitive too. You don't dare run beta software side by side with your bread-and-butter development environment. At times though, running it in a virtual machine makes it run far too slowly or not at all. I have seen some beta software that slows down so much when run on a virtual machine that it appeared to be hung. This common scenario for beta software would be a good candidate for a multi-boot configuration.

Another scenario that doesn't fit perfectly into the virtualization world is performance testing and analysis, or benchmarking. Here also, since the virtualized guest must share resources with the host, it's difficult, if not impossible, to determine what bottlenecks really exist in your code. Again, being able to boot into a custom configured Windows environment specifically set up for performance testing would be a more powerful solution than resorting to virtualization.

So why don't more people use multi-boot configurations? Quite simply, because it's much less convenient than just creating a new virtual machine. One way to set up a multi-boot configuration is to use a separate physical drive for each instance. Another option would be to split a single drive into multiple partitions, with an instance of Windows on each partition. Either way, it's something that requires forethought and planning before you set up your workstation.

Most seasoned IT professionals, however, will tell you that setting up multiple instances of Windows can be fraught with problems. It's not that the process is difficult: the Windows installer is perfectly happy with configuring multiple instances of Windows on the same workstation. The problem is that when the installation of Windows is done, the drive letters of each instance of Windows (other than the one on the first partition of the first drive) is something other than drive C. So while they will boot and run fine, many programs will not install properly, or will cross-corrupt other installations of Windows. This is because they make the assumption that drive C is the drive with the \Windows and \Program Files directories.

The funny thing is that since the release of Windows NT, all of these drive letter problems were supposed to be fixed. The operating system no longer sits on top of DOS, so the whole idea of a drive letter is nothing but a mutually agreed upon figment of the operating system's imagination.

Therefore, to whet your appetite for what follows, let me say outright that you can have AS MANY DIFFERENT WINDOWS INSTANCES on a single workstation as you have space and patience to create, and all of them boot as drive C. That's right... all of you naysayers who say you're limited to four per drive, and that you can't change the drive letters of the system, get a load of the power of NTLDR and Windows XP and 2003.

Final disclaimer: the following process is not for the squeamish. I take no responsibility if you wipe out critical data.

This process has been tested with Windows XP professional 32bit and Windows 2003 32bit. If you want to try this process with other operating systems, you are on your own. I can tell you that I have tried this with Windows 2000, and while it does work, you will need to have the latest service packs to handle drives > 137GB, and you will not be able to have an infinite number of operating systems in your boot.ini [see this link].)

To pull off this feat you will need:

So, on to the fun:
  1. Start with a blank hard drive - not the one on which you have all of your critical programs and data! If you don't have a hard drive to spare, or you're not willing to back up everything important to you and start over, you won't want to do this process!
  2. Think about how many separate instances of Windows you want and list them on a piece of paper. For me, I just made a quick list of which applications I needed to keep separate:
    (a) Visual Studio 2005 for normal day-to-day development
    (b) BizTalk 2004 for normal day-to-day development (this uses the older Visual Studio 2003)
    (c) BizTalk 2006 (it's a beta, so I don't put it anywhere near the things I use daily)
    (d) Windows Workflow Foundation Beta
    (e) Windows Communication Foundation Beta
    (f) Windows Presentation Foundation Beta

  3. Then think about if you want a "data" drive... just for data, not for an OS or programs. I knew I wanted a drive set aside just for writing Ghost images to.

    So total up the number of drives you want, and come up with the amount of disk space you want to allocate to each. For me, I wanted 30GB for each of the six instances of Windows, and whatever space was left over on my 250GB drive would be for the data partition.

  4. Each drive will be a partition, but remember, there really is a limit of four primary partitions on a drive. What we want to do is have one primary partition, and one extended partition that contains several logical partitions. So my primary partition would be for running Visual Studio 2005. The rest of my instances of Windows, and my data drive, would all be logical partitions (see figure 1).
  5. Create your first partition on your drive. If you like to do this with a third-party partitioning tool, that's up to you, but make sure that you only create one primary partition that is just big enough for your first Windows Installation. Or, when you install Windows onto a hard drive with no partitions, let it do the work by only specifying a partition size big enough for your first instance of Windows.
  6. Install Windows XP or 2003 on the primary partition. Load all of your network drivers, sound, video, etc., service packs, and patches. Go ahead and install any other tools that you want on all of the partitions anyway. (For me, I waited to install Microsoft Office, since I needed different versions of it on different partitions, and BizTalk is woefully picky about the order in which things are installed). If you are going the Windows 2003 route but want it to have the look and feel of XP, you may also want to apply some of the suggestions found here:
  7. Start the Windows Disk Management GUI in the Computer Management MMC snap-in. This can be done by selecting the Administrative Tools menu, then select Computer Management, and finally select Disk Management from the tree view. From here you should create an extended partition that consumes the remainder of your available drive space.
  8. Still using the Windows Disk Management GUI, create and format a logical partition inside the extended partition for each remaining drive that you decided you needed in steps 2 and 3.

    Figure 2 shows what my drive looked like with one primary partition (dark blue) and the six logical partitions (light blue) inside the extended partition (green).

  9. Copy your primary partition to each of the logical partitions. I highly recommend Ghost ( ghost10/index.html) for making the copies. Not only can it copy from partition to partition, but also it's just as easy to back up the partition to CD-R. I recommend making a real Ghost backup so that you can restore it to any of the partitions when you want to start it fresh (I do this a lot when I get new beta bits for an app... it's quicker and cleaner than uninstalling because the uninstallers for beta applications usually aren't good at completely removing the application).
  10. Boot your primary partition. You may want to change its wallpaper to make it easier to identify.
  11. Edit your C:\Boot.Ini. You may need to unhide it in order to edit it. You'll need one operating system entry for each instance of Windows you wanted. The first logical partition in the extended partition will be partition #2 and they go up from there. If you have SCSI drives, your boot.ini will look different from the one below, but you'll get the idea of what we're doing.

    See the link for a review of the different ways partitions are numbered between logical and primary partitions.

    Listing 1 shows my original boot.ini (watch for word-wrap!), and Listing 2 shows my revised version.

    OK, so you're thinking: What's the big deal? I've done this type of partitioning and editing of the boot.ini before... and I ended up with drive-letter problems just as you described at the top of the article. Like some sort of drive-letter scurvy, if I attempt to boot from partitions 2-n, those Windows instances will have the wrong drive letters for the System Volume. What's worse is that no fiddling with drive letter assignments in the Disk Management GUI will correct the problem.

    Here is the secret fix. On a completely unrelated knowledge-base article, Microsoft explains how Windows maps drive letters to each partition, and how to change them, even when the Disk Management GUI won't let you (see;en-us;223188).

  12. For each instance of Windows running from the logical partitions, we need to swap the system volume and the bootvolume. Here's how (repeat these steps for all instances of Windows on a logical partition):
    (a) Boot to the logical partition in SAFE mode by pressing F8 when the workstation starts and then selecting SAFE mode. Then select the logical partition from the boot menu.
    (b) Run cmd.exe from the run box. Make a note of the drive letter of the prompt, then type SET and press ENTER. Make note of the SystemDrive. This should be the same as the drive letter of the prompt. This is your SystemVolume. For the purpose of example let's say this is drive H.

    Listing 3 shows an example of my environment variables after booting from one of my logical partitions. Notice that the HOMEDRIVE is H, even though the ProgramFiles drive is C. It's completely confused.
    (c) Run RegEdit and go down to HKLM\System/Mounted-Devices. This is the mapping table that Windows uses for assigning drive letters to partitions (see Figure 3).
    (d) Rename the \DosDevices\C: key to something else, like \DosDevices\Cx: This is the BootVolume. It's the primary partition (your first partition) and actually is the partition from which NTLDR booted. The problem is, once NTLDR jumps to the partition that you select from the boot menu, you really want the assignment of drive C to follow the partition you selected.
    (e) Find the entry corresponding to the drive letter from step (b) (the SystemVolume) and make a note of it (you'll use it in step (f)). Rename the key so that the name of the key is \DosDevices C: For example, if your System-Volume is H according to step (b), then rename the \ DosDevices\H: key to \ DosDevices\C: (Now the partition you selected from the boot menu will get the drive C assignment).
    (f) Now we need to fix up the botching of the original C drive. Rename the BootVolume key from step (d) to the name you make a note of in step (e) of your SystemVolume. Therefore if your system drive is H, you would rename \DosDevices\Cx: to \DosDevices\H.
    (g) Close RegEdit
    (h) Reboot and select the same partition. Once it boots, run cmd.exe from the run box. Type SET and press ENTER. The SystemDrive should now be C. Listing 4 shows the same partition after making the registry changes and rebooting. Now both my HOMEDRIVE and Program-Files point to Drive C.
    (i) Repeat all steps for the remaining partitions

  13. Install all of the apps you want on each partition. You may want to change the wallpaper on each to make them easy to identify.
Thus with some forethought and planning you can configure your workstation with multiple bootable partitions, and have an alternative to using virtualization.


Note: The legality of this solution may depend on your licensing arrangements. This document in no way endorses breaching your license contract and is intended only for development, primarily within the realms of an MSDN subscription or a VLE copy of Windows XP or Windows 2003. Your mileage may vary.

More Stories By Pat Piccolo

Pat Piccolo is a consultant with Magenic Technologies. He has over 20 years of experience in the software industry. Pat lives in Atlanta, GA with his wife and daughter.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.