Understanding MultiBooting
and Booting Windows from an Extended Partition

by Dan Goodell

MultiBooting Principles

Techniques for booting more than one OS generally fall into one of two broad categories: the Microsoft way and everyone else's way. (Of course! You knew Microsoft would go their own way, didn't you?) The two methods use incompatible concepts and cannot simply be substituted for each other. To understand the principle behind each method, first let's review how the normal boot process works when there is only one OS involved:

(a)    the boot process starts by executing code in the first sector of the disk--the MBR,
(b)    the MBR looks over the partition table to find the "active boot partition",
(c)    control is passed to that partition's boot record (PBR) to continue booting,
(d)    the PBR locates the system-specific boot files (such as Win98's io.sys),
(e)    which continues the process of loading and initializing the rest of the operating system.

Any hard disk can be multibooted by installing OS's in separate partitions and selectively marking in the partition table which is the "active boot" partition. Mark one partition active and it, along with its OS, will be the one that boots when the computer is turned on. Mark a different partition active and that will be the one that boots. This method is straightforward but not very convenient--it requires some way to manually edit the partition table each time you want to change which OS boots.

To make the procedure more convenient, we interrupt the above boot process somewhere with a menu from which we can choose which operating system to load. Third-party boot managers generally interrupt the process between steps (a) and (b) to allow the user to select which partition to activate. The Microsoft method interrupts the process between steps (c) and (d).

MultiBooting the Third-Party Way

Multibooting has been around forever, and is not a Microsoft invention. In fact, Microsoft did not invent their own method until the advent of Windows NT. Third-party boot managers load before the OS, so are independent of the operating system. Therefore, they work fine with DOS and all versions of Windows, whether Microsoft likes it or not. Most work in a similar way and can generally be substituted for one another, but not for the Microsoft boot manager.

Installing multiple OS's is conceptually straightforward. Install one OS, then change its partition status to "hidden", effectively setting that part of the disk aside. Then install another OS on another partition without interfering with the part set aside, just as though it's still a blank disk. When installing Windows NT, 2000, or XP, it is vital that any pre-existing OS's be hidden while NT/2000/XP is being installed to keep the installation routine from undesirably setting up a Microsoft-style multiboot.

By toggling the hidden/active status of each partition, one partition or the other can be booted while the other is hidden and dormant. Installing a boot manager makes toggling the hidden/active status easier. Installing the boot manager replaces the code of the standard MBR (the embryonic startup code in the first sector on the hard disk) to divert the boot process to the boot manager. The boot manager displays a menu, and based on the menu selection made by the user, the appropriate partition is designated "active" and the boot process continues through that partition. OS's are kept totally independent. Non-booted partitions may optionally be set "hidden" so they can't be interfered with by the booted partition.

Removing the boot manager is as simple as replacing the MBR again with a standard version.

MultiBooting the Microsoft Way

The Microsoft boot loader is a native part of the NT-family operating systems (Windows NT, 2000, and XP). No multiboot capabilities were included with earlier Windows (95, 98, or ME) or DOS versions. During installation of an NT-family OS, the file "ntldr" is copied to the root directory of the active partition and the installation routine scans the computer for another known Microsoft OS. A boot.ini file is created, which ntldr will read at each boot. If no other OS is found this boot.ini file is configured to boot straight into the new OS, but if another Microsoft OS is found boot.ini is automatically configured for multibooting. In a multiboot system, this means the previously installed OS must be visible (not hidden) and must be known to the later OS, or else the later OS can't properly configure the dualboot. Thus, Microsoft recommends always installing the "older" OS before the "newer" OS. The Microsoft way always starts booting through the same ("active") partition and then forking to either the old or new operating system, typically on different partitions with different drive letters.

To understand how the Microsoft method works, let's consider an example of installing Windows XP to a computer that already has Windows 98 installed. The computer already has an active boot partition (C:) that includes a Win98 partition boot sector and the Win98 system files. The XP-Setup routine copies the existing Win98 partition boot sector into a file, bootsect.dos, and replaces the partition boot sector with a XP version. The XP boot sector expects to find the XP startup files (ntldr, ntdetect.com and boot.ini) in the root directory of the same partition, so XP-Setup puts the startup files in C:\. Note this is the partition the Win98 system is already in, but it now has a XP boot sector and XP startup files. XP-Setup then installs the rest of the XP operating system itself to the new partition and giving it some other drive letter--let's say, D:, for example. Boot.ini will be configured with two entries, one for Win98 on C: and the other for WinXP on D:.

The C: partition will now have the Win98 startup files, the WinXP startup files, a XP boot sector, and a file (bootsect.dos) containing the old Win98 boot sector. The rest of the Win98 operating system is in a directory on the C: partition (usually C:\Windows), while the rest of the XP operating system is in D:\Windows. At boot time the MBR passes control to the partition boot sector--which, remember, is now a XP boot sector. Boot code in the XP boot sector takes control and a menu is displayed from boot.ini to choose which OS to continue booting: 98 or XP. If we choose XP, the XP boot files on C: load the XP operating system from drive D:. But if we choose 98, the XP boot files recall the 98 boot record from the saved file, step out of the way, and let the 98 boot record take over and load the 98 operating system from C:, just as though the MBR had passed control to a 98 boot sector in the first place.

Typical Boot Manager

Microsoft Boot Manager


a b c g g e f m m i

Read more about the NT boot loader in Nick Rozanski's excellent primer, or about the changes Microsoft has made with Vista in Brian Stewart's comprehensive treatise.

What's Wrong with the Microsoft Way?

Using the MS-style multiboot method presents some significant variances from the multiboot technique that is the subject of our project. Our project provides Win98 and XP each with their own boot sectors in their own partitions and the OS choice is made through the partition table instead of through a boot file in a common partition. As we can see, if we use the XP boot loader to control our multibooting we will always start booting from the same partition for both OS's but end up loading Windows from different partitions. The OS's are not completely independent from one another--they both use a common starting partition. The MBR always passes control to the same partition, and it's up to the startup files in that partition (ntldr, ntdetect.com, and boot.ini) to determine which system partition to bring up. This is not the same thing as having the MBR boot different partitions.

Because the OS's are intertwined, the Microsoft method requires that one OS installation must be present before the other is installed, and the newer OS (in this example, WinXP) must be installed after the older OS (Win98). This also explains why subsequently reinstalling Win98 will mess up the dualboot--the 98 reinstall replaces the XP boot sector again with a 98 version, but this 98 version doesn't know about boot.ini and multibooting.

Backing up partitions with imaging programs (Ghost, DriveImage, et al) can be more problematic. Since the OS's are entangled, you must backup both. The XP partition cannot stand on its own, so copying/restoring it by itself won't restore a working XP system.

Subsequent resizing of your partitions may break the dualboot. Tools like PartitionMagic can non-destructively resize partitions and adjust the PBR correspondingly, but remember, the 98 "boot sector" was captured and tucked away in the bootsect.dos file. It doesn't get fixed as its partition is resized, so when you later try to boot 98, the resurrected boot sector no longer matches the partition.

The Microsoft method can multiboot only one DOS/Win9x version with one or more NT-family OS. If you want to triple-boot XP with both Win95 and Win98, for example, you're out of luck.

The XP boot loader doesn't keep OS's hidden from each other--when you boot into XP, the 98 partition will still be visible as C: and the XP partition will be designated D: or higher.

The odd menagerie of drive letters can cause problems. Imagine the entangling if, while in XP, you install an old application that puts its program files on drive C: and registry keys into the XP registry on D:.

And try to imagine how you would eliminate the Win98 partition if you should ever decide you no longer want it on your computer. Since XP boots through the 98 partition, you can't simply delete it. The XP partition also is not assigned as drive C:, so the XP registry is filled with other drive letter references. Even if you could fix the XP boot sector and startup files, you may have problems fixing all the registry references. Internet newgroups are full of tales of frustration from people who used the Microsoft method and later decided they wanted to eliminate the older OS and revert to a single-boot system.

The method using a third-party boot manager is much cleaner, keeps OS's totally independent and truly boots separate partitions. OS's can be installed in any order--they're independent, remember? Since the OS's are independent, they can be backed up separately, and it is much easier to eliminate or upgrade either one later. You can install multiple DOS/Win9x versions if you like, and there are fewer problems if you want to subsequently resize partitions. OS's can be kept hidden from each other, so when you boot 98 it will be designated C: and the XP partition will be hidden, and when you boot XP it will be C: and the 98 partition is hidden. Hiding OS's from each other reduces the risk of one messing up the other.

What's Good About the Microsoft Way?

Installing a multiboot the Microsoft way generally requires no extra tools, provided the disk has unallocated space with which to create a new partition for the additional OS. Nearly all computers come with an OS already installed and no unallocated space, though, so this "no extra tools" advantage is rarely realized because you'll need third-party tools to non-destructively resize the existing partitions.

For uncritical users the XP boot loader may be acceptable. Consider the typical computer user: he probably bought a computer from a large manufacturer, the hard disk came partitioned with a single C: partition, he didn't bother to repartition it, and since then he has been dumping all his stuff into "My Documents" and "Favorites" on the C: drive. (He also doesn't image or backup his system partition, but that's another story.) Now he decides to repartition the disk and add Windows XP. Letting XP control the dual-boot configuration is easy and he doesn't have to understand very much technical stuff. He doesn't know (or care) why it works, he's just happy it works. In fact, he's actually happy his old drive C: doesn't get hidden because he can get at all his data files he had been saving there all these years. He doesn't care that drive letters are all mixed up--he thinks that's normal because he's been lulled into believing partitions have specific drive letters tatooed on their foreheads. For this kind of user, the overhead of learning about partitions and boot managers is probably unnecessary. But if he ever decides to get rid of his old OS . . . well, wish him luck.

"But I don't want the added complexity of third-party software!"

Alas, the protestation of an uninformed user! It is the Microsoft-style multiboot that is actually more intrusive and introduces the greater complexity.

To understand what I mean, consider the parts of a basic 98/XP dualboot system. A single-boot Win98 system includes a standard MBR and a Win98 partition. A single-boot WinXP system includes a standard MBR and a WinXP partition. If we put the pieces together in a single system, we have a standard MBR, a Win98 partition, and a WinXP partition. But the system won't dualboot this way--we have to alter something. Microsoft's answer is to alter both OS partitions, but leave a standard MBR. In contrast, the third-party answer leaves both OS partitions untouched and changes the MBR.

Which is more intrusive? Altering two huge partitions so that neither can easily be converted back to single-boot use? Or leaving both partitions untouched and altering the MBR, a mere 400-odd bytes in a single sector? Converting a third-party multiboot back to single-boot is trivial--a third-party boot manager doesn't even need to be uninstalled, just restore a standard MBR (yes, one single sector), and designate which partition is active. Don't expect to do this with the Microsoft boot manager. The third-party method interferes with the operating systems less than the Microsoft way.

author: Dan Goodell, ©2003