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
|
|
|
|
|
|
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.