Mastering Multibooting Madness

GUIDELINES FOR CONFIGURING AND MANAGING A MULTI-OS ENVIRONMENT

I often dream of a future Windows NT. An NT that has evolved into the über-OS: An NT on which I can run not only essential business and productivity applications but also run multimedia applications, develop applications, and operate my favorite aerial combat simulator. Although this dream is growing closer to reality, NT doesn't provide this functionality yet. Several applications don't run under NT 4.0, and NT 4.0 lacks support for popular hardware technologies such as Universal Serial Bus (USB) and APIs that Microsoft included in Win9x (e.g., DirectX 5.0 and 6.0). These shortcomings make NT users feel left behind, and although Windows 2000 (Win2K) promises to cure most of NT's ills, this promise doesn't help current NT users.

You're lucky if NT 4.0 supports all your applications, but you might still need to install and run more than one OS (e.g., if you're a developer or network administrator who needs to run applications under multiple versions of Windows for compatibility testing). Whatever your reason for running multiple OSs, getting them to run happily on the same PC can be challenging. Read on for tips, tricks, and tools that you can employ to help manage a multi-OS environment.

NTLDR: NT Boot Central
When you install NT, the OS sets up an NT-specific Master Boot Record (MBR) on your first hard disk's primary partition. When you first start up a PC, NT Setup automatically loads the MBR, then passes control to NTLDR. NTLDR parses the boot.ini file from the root of the NT system partition and uses boot.ini to generate a list of OS boot selections. (For more information about NT's boot process, see Mark Russinovich, "Inside the Boot Process, Part 1," November 1998.) Boot.ini contains the OS boot options that NT is aware of, which usually include NT-related entries but can also include entries that point to other OSs. The boot.ini file's [Operating Systems] section lists each NT-related entry and uses an Advanced RISC Computing (ARC)-style path to describe the relative disk location of each entry. On a system running only NT, the [Operating Systems] section lists at least two entries: one for a normal NT boot and one for a VGA-mode startup configuration, which boots NT using a plain-vanilla VGA video driver. Your boot.ini file's [Operating Systems] section might look like

[Operating Systems]multi(0)disk(0)rdisk(0)partition  (1)winnt="Windows NT  Workstation 4.0"multi(0)disk(0)rdisk(0)partition  (1)winnt="Windows NT   Workstation 4.0 [VGA mode]"  /basevideo /sos

If you want to install additional OSs on your PC and you want to use NT's boot loader to access them, the following factors affect how you'll proceed:

These factors are important because every OS has a set of supported file systems and quirks and variations in the disk partition configurations and OS locations it supports. For example, you can install NT on a primary or extended partition (i.e., a logical drive within an extended partition), but you can install DOS and Win9x only on a primary partition. In addition, NT can handle drives that contain multiple primary partitions, but these configurations cause problems for DOS and Win9x. Table 1 shows the file systems and accessibility types that common OSs support.

To determine which file system to use on a partition, you must consider which OSs will require access to the data you store on that partition. If you store important Microsoft Word and Excel documents on an NTFS-formatted drive, you can't access those files when you're booted under Win98. In addition, from an NT installation, you can't see data you store on a FAT32 volume under Win95 OEM Service Release (OSR) 2.x or Win98. (You can use add-ons from Systems Internals to read and write to FAT32 volumes from NT installations. For a list of related products, see "Multibooting Resources.") So, why don't you use FAT16 on all partitions in a multiboot system? The answer is that by doing so, you sacrifice disk space and performance because FAT16 uses larger cluster sizes and less efficient data-retrieval techniques. However, FAT16 might be your only option.

FAT16: Your Friendly Common Denominator
As Table 1 shows, FAT16 is a common denominator in several OSs. Thus, this file system is usually your only choice for a primary system partition (e.g., the C drive). If you use an NTFS-formatted C drive in a multiboot system, you will experience problems because Win9x must reside on the primary partition of the first drive and Win9x can't reside on an NTFS-formatted volume. If you use a FAT32-formatted C drive in a multiboot system, NT's boot loader can't run from a FAT32 volume, so the system will simply boot to Win9x.

Thus, you need to format the primary partition of your first hard disk as a FAT16 volume. If you use Win9x's Fdisk utility to create this partition, reply "No" when the system asks if you wish to enable large disk support, as Screen 1 shows. Replying "Yes" to this question creates a FAT32 partition, which prevents you from using normal methods to install NT's boot loader on the system, because NT doesn't support FAT32-formatted disk volumes.

Although the FAT16 primary partition requirement is frustrating, this partition must hold only the files the OSs require to boot the system. For example, the required boot files for NT include NTLDR, boot.ini, and the ntdetect.com boot manager (i.e., the NT system partition). The primary system partition must be large enough to contain the required boot files for each OS that will reside on that partition. Some third-party boot managers let you create a small primary partition that has enough space for only the boot manager's required files. You can even find third-party boot managers, such as PowerQuest's BootMagic, that eliminate the need for a FAT16 primary partition.

The maximum partition size of FAT16 volumes is 2GB because DOS and Win9x FAT16 volumes use a maximum cluster size of 32KB. Third-party disk-partitioning programs and NT's Disk Administrator utility and Format command allow a FAT16 maximum partition size of 4GB by using a 64KB cluster size. However, resist the temptation to use these tools, because you're almost guaranteed major problems: Critical disk utilities (e.g., Scandisk) can't handle the larger cluster size, and many Win9x applications report that no free space is available on the volume although gigabytes of space remain. As a result, using Disk Administrator or third-party disk-partitioning tools can result in data corruption or loss.

Dual-Booting NT and Win95
When you create a dual-booting NT and Win95 system, the process is much simpler if you install Win95 first. NT detects Win95's presence and automatically creates an option for it in NT's boot loader menu. In this scenario, NT encapsulates the existing DOS 7.0 or Win95 boot sector into a special file called bootsect.dos. NT uses this file as a custom boot sector, which it loads when you select the newly created Microsoft Windows option from the boot loader menu. A similar process takes place when you install NT over an MS-DOS 6.22 installation, except that the MS-DOS 6.22 and Win95 boot sectors differ slightly. (For information about multibooting NT, Win95, and DOS, see the sidebar "Triple-Booting and Direct-Booting NT, Win95, and DOS," page 66.)

The installation process is simple if you install NT after Win95, but it's a little more complex if you install NT first. In this situation, you need to boot to a DOS or Win95 boot disk to launch Win95 setup. If you use the original version of Win95 or earlier versions of Win95 OSR2, be prepared for the Win95 setup process to hose your NT boot loader. These Win95 versions don't recognize NT's boot sector and boot loader, and overwrite the NT boot sector with their own boot information. If you experience this problem, follow the instructions in the sidebar "Repairing a Blown-Out NT Boot Sector." Later versions of Win95, such as OSR2.5, don't usually exhibit this boot sector-breaking behavior.

In addition, some Win95 OSR2 versions cause the system to hang during successive boots when you select the Boot Previous Operating System option during Win95 startup (e.g., by pressing F4). This is a known bug that you can remedy by booting a Win95 Emergency Repair Disk (ERD) and using the Sys C: command. If your system is also running NT, this solution will cause Win95 to overwrite the NT boot sector and prevent the boot loader from appearing. Finally, if you're running the original version of Win95 and you can't boot to MS-DOS, try adding

"BootMulti=1"

to the [Options] section of your Win95 msdos.sys file. Be sure you are booted under Win95 when you edit this file to ensure that you're editing the correct file.

Dual-Booting NT and Win98
I'm happy to report that Win98 gracefully multiboots with NT. Although you must still use FAT16 on the primary partition of the first hard disk, Win98 was far more intelligent than Win95 when I installed Win98 in an existing NT environment. In fact, Win98 was better at integrating the two OSs than NT was. Regardless of which OS I installed first, the operation resulted in a functional installation of both OSs. However, when I installed Win98 over NT, Win98 displayed an accurately labeled Microsoft Windows 98 option in boot.ini, whereas when I installed NT over Win98, NT created an ambiguous Microsoft Windows entry.

Although the Win98 and NT multiboot configuration process is straightforward, a potential gotcha exists when you install NT Workstation over a Win98 installation that you upgraded from Win95. If you uninstall Win98, the uninstall might delete your boot.ini file, which will prevent NT's boot loader from functioning properly. You need to use an ERD or a similar method, such as manually recreating the file, to restore the deleted boot.ini file. Also, when you uninstall Win98, the uninstall deletes the Win98 bootsect.dos file.

In addition to an NT ERD and boot disk, if you're running Win98 in a dual-boot configuration, I recommend that you use the Add/Remove Programs applet in Control Panel to create a Win98 startup disk during or after setup. This disk is an invaluable troubleshooting and recovery tool for Win98 installations. Also, unlike Win95 startup disks, Win98 startup disks contain a cool universal CD-ROM driver that works with most CD-ROM drives on the market—no more creating custom disks with support for your SCSI or IDE CD-ROM drives.

Dual-Booting NT and Linux
The growing popularity of Linux has created a new generation of users who want to run their favorite Linux distribution side by side with NT. LILO, the Linux Loader, handles Linux's boot management. Although you can use tricks to make LILO boot to NT's boot loader, most Linux users who implement Linux and NT multiboot systems use a third-party management utility or a LILO option in NT's boot loader.

To implement a Linux and NT multiboot configuration, install Linux on the partition of your choice and install LILO in the first sector of the Linux partition (i.e., the superblock) rather than in the MBR. If you load LILO into the MBR, you'll overwrite the NT boot sector and disable the boot loader. After you install LILO, you need to tie it to NT's boot loader menu by creating a Linux boot sector file (many users prefer to call this file bootsect.lnx, but NT and Linux don't require that name) and adding a reference to this file in the boot.ini file. A dual-boot NT and Linux system's boot.ini [Operating Systems] section might look like

[Operating Systems]multi(0)disk(0)rdisk(0)partition  (1)winnt="Windows NTWorkstation 4.0"multi(0)disk(0)rdisk(0)partition  (1)winnt="Windows NT   Workstation 4.0 [VGA mode]"  /basevideo /sosC:bootsect.lnx="Linux"

You can use Linux's dd utility or a similar utility to create a Linux boot sector file, then manually add the boot sector file to boot.ini. However, a simpler method is to use Gilles Vollant Software's BootPart 2.20, a utility that creates the boot sector file and automatically adds the entry to boot.ini. For more information about the BootPart utility, see the sidebar "BootPart Enhances NT's Boot Loader" and "Multibooting Resources."

You must create a new copy of bootsect.lnx every time you modify the boot sector of your Linux partition (e.g., when you install a new kernel with LILO). If you're implementing a multiboot NT and Linux system, I recommend that you read the Linux-related articles listed in "Multibooting Resources."

Third-Party Boot Managers to the Rescue
Although you can use NT's boot loader to create multiboot scenarios that involve several OSs and partitions, the boot loader isn't the most capable tool for managing multiboot environments. For maximum flexibility when you install and manage multiple OSs, consider using a third-party boot-management utility. These utilities not only allow for greater flexibility, but most of them also provide some or all of the following additional capabilities (for a list of third-party utilities, see "Multibooting Resources"):

The ability to hide selected partitions lets you conceal primary partitions that inhabit the same drive as a primary partition that contains the OS you're booting. The presence of multiple primary partitions on one drive is especially problematic for MS-DOS and Win9x and can result in data loss and a failure to boot. In addition, hiding partitions lets you control how the system assigns drive letters and lets you maintain consistent drive-letter assignments in different OSs.

NT and Win9x Resource Sharing
You can set up an NT and Win9x multiboot configuration to share certain resources, such as application installation directories and files. The two OSs can't share the Registry entries an application creates within NT and Win9x because each OS has a private Registry that is inaccessible to the other OS. However, the OSs can share the directory in which the application resides. To ensure that an application creates the proper Registry entries and local support files for each OS, install the application twice—once under each OS. The benefit of a shared directory is that you have only one instance of the application, so you conserve the disk space that an application installed in separate folders or partitions wastes.

To share a partition, the partition must be FAT16-formatted, because FAT16 is the only file system that NT and Win9x support for writing. Although this scenario usually works fine, a particular application might react negatively to such an installation, which can result in a nonoperative installation or a loss of application data. Thus, always back up an application and the OS partition, including the Registry, before you attempt this procedure. Also, Registry-based user options that you change under one OS won't be reflected in the other OS, so you need to manually synchronize changes under each OS.

Uninstalling applications creates a potential downside to this practice. You can uninstall an application and its Registry entries only once, so one OS will be confused because the application is no longer available. This inability to delete an application's Registry entries can result in a clogged Registry, ghosted Add/Remove Program entries, and functionality problems in the dual-booting OS. Although sharing application-installation folders seems to improve disk efficiency, you should maintain a separate installation of an application for each OS. The easiest way to keep your application installations separate is to devote Program Files on two drives—one for each OS. Although this practice uses more disk space, it creates a clean and stable system configuration.

A less-obvious resource that NT and Win9x can share is the paging file. You might know that NT and Win9x use a paging or swap file as virtual memory; however, you might not be aware that you can configure Win9x to use NT's paging file. This procedure requires that the paging file be on a FAT16 volume that is accessible to both OSs. The following steps walk you through how to configure NT and Win9x to share a paging file:

If you change the size of a shared paging file under NT, you should immediately re-edit Win9x's system.ini file and make the appropriate adjustments.

Mastering Multibooting Madness
In this article, I discussed the major challenges you face when configuring NT systems to accommodate multiple OSs. I geared this article toward x86-based systems because they load their bootstrap code directly from the hard disk, so they are the only systems capable of running both NT and DOS, Windows 3.x, or Win9x. These guidelines don't apply to RISC-based NT systems (e.g., systems that use Alpha processors) because they use ARC or RISC firmware to specify OS boot options, rather than the boot.ini file that x86-based systems use. Configuring a multibooting system is a risky operation, so always back up your entire system before you install an additional OS or employ a disk-partitioning or boot-management utility.

Corrections to this Article: