By "multi-booting", I mean choosing from a range of Operating Systems (OSs) at boot time, without having to insert boot disks. The best way to get a grip on this is to be very clear on the different layers at which choices can be made, i.e...
Think of each layer as a box, within which all the deeper-nested layers bounce around. You should also be clear about partitions, volumes and drives, and be aware of how different OSs can or cannot co-exist on the same PC.
When planning all this, you'd want to:
Hardware and CMOS / BIOS layers
DOS-era PCs were hard-coded to boot the A: diskette first, then the first visible hard drive. Modern PCs let you choose between a number of alternate boot devices in BIOS/CMOS setup, as well as the order these are searched.
Once BIOS settles on a boot device, it looks to see if that device starts with a boot sector that terminates with the hex values 55 AA (I'm not sure what the boot validity criteria for optical disks may be). If the device isn't considered bootable, the next device is checked as per BIOS/CMOS boot order.
It is tempting to work at this level to select between different OSs installed on different physical hard drives, by:
But there can be problems with this, when the OSs don't see the system devices and device order the same way these are set in BIOS/CMOS setup. For example, Plug and Play may detect devices left connected but undefined in BIOS/CMOS, and BIOS/CMOS settings to boot IDE 1 before IDE 0 may or may not mean that IDE 1 is enumerated by the OS before IDE 0. Different OSs may see things differently, and assign drive letters to detected hard drive volumes in a different order.
Let's just say I'd recommend thorough testing if you use this level of selection, before spending any time setting up the software installation. Consider also the consequences should non-standard settings be lost (if CMOS settings were to re-default) or how a non-HD boot might see things differently.
Finally, remember that a modern PC that is switched off is still applying power to internal devices - so unplug from the mains if removing or adding hard drives, else you could cause hardware damage. The Serial-ATA standard may support hot-swapping of hard drives, but this requires use of the new Serial-ATA power connectors rather than the old legacy ones. Never use both on the same Serial-ATA drive!
System layer (within boot device)
If the boot device is a physical hard drive, the boot code is expected to look up an embedded Partition Table of 4 possible partitions to see which is marked active, and then pass control to the first sector in that partition.
That's how the standard Master Boot Record (MBR) works, and as this exists at the system rather than Operating System (OS) level, it's not supposed to be deviated from this behavior by any OS.
But because OSs assume this code to be standard, they may replace it with the standard code. This would break deviations from the standard MBR code and partition table structure, such as the following:
If you need non-standard code here (e.g. a DDO to override an old BIOS's disk services that can't cope with "large" hard drives, or a boot manager that lives in the MBR) then you need a way to restore this should anything corrupt the MBR or overwrite it with the standard MBR code.
Also, remember that other boot devices (CDR, diskettes, USB flash drives, other physical hard drives) won't process this "special" code unless the same logic is integrated into the boot-up code of these devices.
OSs and partitions
Classically, each installed OS would require a partition of its own, and you'd choose which to boot by setting that OS's partition as "active". Most OSs will have tools to set a partition as active, and may allow the process to be automated so that clicking an icon can effect the change.
Or you can install a boot manager utility, either within the MBR, as an extra partition, or within the partition of one of the OSs. This may pop up as a boot time menu, from which an OS can be selected.
Each partition entry in the Partition Table has a "type" byte that describes what OS the partition is for. In this way, an OS can recognize its own partitions and access them, while ignoring incompatible partitions from other OSs. This is crucial; an OS writing to a partition it doesn't understand could trash that partition's OS and data!
If you want multiple installations of the same or similar OS on the same system, then problems may arise when each sees the contents of the other (e.g. System Restore). To avoid this, you can set the type byte of the inactive partitions to some arbitrary value the OS doesn't understand, thus "hiding" those partitions. Boot managers such as Boot-It NG usually offer to do this automatically; all you have to do is set which partitions to hide or leave visible.
Breaking the 4 partition limit
The standard MBR is hardcoded to support only 4 partitions, which may be intolerably restrictive if you need (say) two alternate Linux partitions, an NT partition, a Windows 9x partition, and an extended partition containing data logical volumes to be shared between these. There are two ways around this:
The first is nice, because you avoid the risks associated with non-standard MBR code. But not all OSs can boot from the same partition even if the bulk of these are on a different logical volumes within the same extended partition.
OS boot layer, part 1 (within partition)
When control passes into the partition marked active, the OS begins. The first sector(s) of the partition is the Partition Boot Record (PBR), and the code within this will typically begin to understand the OS's file system, and will find and enter the OS's first code file on that system. For DOS and Windows 9x, that file is IO.SYS; for NT (including Win2000 and XP0, that file is NTLDR.
An IO.SYS doesn't know about NT, but an NTLDR may know about a DOS or Win9x that is installed to boot from the same partition. In fact, NTLDR includes a generic method of booting alternate PBR code images, and thus can boot Recovery Console, DOS or Win9x instead of NT if the user so chooses.
What NTLDR does is look for a Boot.ini file, and process it. If this defines multiple OSs, it generally displays a menu from which one can be chosen; if no choice is made within a timeout period, the default OS is booted. Two types of syntax are used to define bootable OSs:
The first is used to locate and boot NT installations, while the second is used to locate and boot MS-DOS or Windows 9x (BOOTSECT.DOS) or Recovery Console (BOOTSECT.DAT). In the latter case, the code within the image file is executed as if it had been in effect within the PBR, but it is not written to the PBR at any stage.
Caveat: Unlike most .ini files, the interpretation of Boot.ini doesn't ignore lines starting with s semicolon as "comments"!
OS boot layer, part 2 (within OS boot)
Now the OS has really started to boot, but there are still further chances to select different OSs or boot configurations of the same OS. Both NTLDR and (from MS-DOS 6 onwards) IO.SYS can offer further boot menus in response to pressing the F8 key, unless settings force this menu to be shown or bypassed.
IO.SYS potentially offers two consecutive boot menus. The first is found in Win9x only, and is a hard-coded internal menu as modified by settings in Winboot.ini, or if (as is typically the case) no Winboot.ini exists, in MSDOS.SYS - if certain conditions are met, these choices may include the option to boot an older version of MS-DOS. The second may be defined as a [Menu] section within Config.sys
NTLDR has a similar hard-coded F8 menu, which is tailored by settings within Boot.ini
With the exception of the "Previous version of MS-DOS" facility that IO.SYS may offer, none of these options explicitly support booting an alternate OS version or installation. However, they can be used to modify Windows boot mode (e.g. Safe Mode, Command Prompt Only etc.) and in the case of Win95/98, can boot that OSs DOS mode instead of Windows.
OS emulation (within OS runtime)
Windows will usually run programs written for recent prior versions of the OS, but the older the OS version, the more likely compatibility settings will be required or the program won't run at all. This is the usual reason to run multiple Microsoft OSs on the same system.
For old OS that were written for much slower computers, a different strategy suggests itself; the modern OS can emulate the older one, effectively running the older OS as a program under the new one. This can potentially provide more accurate timings as expected by the old OS, and can also be used to run software that was written for completely different hardware (e.g. games written for 1980s home computers or coin-op game machines). In addition, software development environments allow programs to be written for non-PC hardware devices within the systems OS.
All of the above have been around for a while, but Microsoft have recently released a "virtual OS host" product that can run other versions of Windows under emulation within XP.
(C) Chris Quirke, all rights reserved - April 2004
Back to index