Before I say anything on this topic I should point out that Shotter_Nail made a website detailing a bunch of methods, with and without boot managers, to boot early versions of Windows.
I initially didn't even want to make this page, because I had zero knowledge on this topic, and I didn't have real hardware to test on. Shotter_Nail's website seemed detailed enough to cover everything.
However, later I was bored, and decided to test on VMs, because I wanted to understand how these boot managers work, and how the booted OSes behave, regarding partition visibility and drive letters. Then I discovered that, to my surprise, none of the boot managers I tested (XOSL, OSL2000, BootItNG) worked on VMWare, and Win9x can't be installed on VirtualBox at all, with or without patcher9x. Then I came up with a new method that Shotter_Nail didn't cover: using GRUB4DOS to boot from floppy images. This means I have new knowledge to offer, so I made this page.
Later I also found other websites about multibooting:
Broadly speaking, unlike NT, Win9x is not multiboot-aware. The boot sector loads IO.SYS from the active partition, and each version of Win9x can only be loaded by the DOS version that it's designed for. MSDOS.SYS specifies the drive letter and path of the WINDOWS folder, which would have to be changed for a different version of Win9x to be loaded.
To make Win95/98 boot into its own DOS 7.x without going into Windows, just setting BootGUI=0 in MSDOS.SYS is not enough. You also have to have a CONFIG.SYS with a SHELL= line.
If before installing Win95/98 there is an existing DOS installation (with existing CONFIG.SYS etc), they will be kept for the most part and adapted as needed by Windows Setup.
DOS 7.0 doesn't support "INT 13h extensions", which means it couldn't see partitions that fully or partially reside outside of the CHS barrier, which is about 8GB. (source) Partition managers would set the partition type ID for such partitions to 0x0E instead of the usual 0x06 for FAT16. So if a data-sharing partition is to be made, it should be within the CHS barrier. The GUI of Win95 RTM and OSR1 does support LBA though and can access such partitions.
KB51978 from Microsoft details how drive letters are assigned in DOS. drvexch and dlmanip can (supposedly) switch drive letter assignments.
Windows Setup checks the existence of win.com in the Windows installation folder (windir), regardless of what it's called, at least when windir is only one level deep, like D:\Windows (I don't plan on testing a deeper windir, as that would be unusual and unnecessary), and if win.com exists, Windows Setup would either "upgrade" the existing version rendering it unbootable, or in case of OEM versions, straight up block you from installing. So, you have to make Windows Setup believe that there is no existing version of Win9x.
To do that, after each version of Windows 9x is installed, do the following:
debug DOS command, as described heredd Linux command: dd if=/dev/sdXY of=bootsect.dos bs=512 count=1 (replace X and Y with your actual device name)The sections below start with the approaches that I abandoned, either because I couldn't get them to work, or because I don't like how they turned out. Skip to the last section, the NTLDR method, to see the solution I like the best.
(Skip to the next section if you just want to know what works)
Ideally I want the same setup as my NT multibooting setup: one shared boot partition, and then one partition for each OS, with the same drive letter assignments on every OS. This rules out the partition-hiding method.
I first tried editing files as Shotter_Nail suggested. After realizing that I couldn't go beyond the barrier of different DOS versions, I tested boot managers.
XOSL, OSL2000, BootItNG, and PLOP were often mentioned on forums such as VOGONS. Of these 4, only PLOP was rated rated "poor" by Shotter_Nail, and the other 3 were rated "EX" or "very good". I decided to try all 4, but nothing else, as 50 is too many.
XOSL and OSL2000 offer DOS installers, so I figured I should use them, as DOS installers can be started from a DOS boot floppy, when the hard disk is still empty. Unfortunately, neither DOS installer worked. OSL2000's froze immediately at the first step ("creating edisks", IIRC) when I chose "Install", and XOSL's reported an error (forgot what it was).
Later in another attempt, I used the Windows installer of OSL2000 under Windows Me, and that worked.
BootIt offers a boot floppy so I used that. It has a Win9x-style GUI, and feels like a "mini-OS", with many settings about boot entries, and a partition manager. Installing it to hard disk was successful, but using the "Multi-OS" feature (a toggle in partition properties), a BSOD happens while installing Windows 98 as the second OS. The "EMBR" feature allows "fully standalone" (in Shotter_Nail's words) installations in each partition, with boot files (IO.SYS, MSDOS.SYS, CONFIG.SYS, AUTOEXEC.BAT) and Windows files (WINDOWS, Program Files, and My Documents folders) in the same partition. The downside is that, as BootIt presents in a "virtual MBR" up to 4 primary/extended partitions of your choice per hard disk, some partitions would not be visible from the booted OS.
The "multi-OS" feature in BootIt seems to "capture" bootloader files by "hooking" file operations. Captured files can be assigned to different "groups", and each boot menu entry can choose a group to use. This might be worth having for convenience, but at its core it seems to be no different than the more manual approaches such as editing/swapping the file yourself. (Especially when it triggers a BSoD under VMWare.)
Newly inserted floppies after you have already booted into BootIt aren't recognized. This means for bootitbm to recognize your floppy and boot into it, you have to have it inserted before booting, and as a consequence you'd have to set hard disk to have a higher priority than floppy in the BIOS setup.
PLOP seems to only use partition-hiding, as I can't find references to any unusual trickery done in the boot process, unlike OSL2000 (which claims to be able to boot from logical partitions) and BootItNG (which claims to be able to boot multiple Win9x versions from the same primary partition, as well as to have more than 4 primary partitions with EMBR). So I didn't bother testing it.
xfdisk (extended fdisk) is a partition manager that comes with a boot manager. I tested it because it was also mentioned on forums. But I don't know how it is "extended". It still can only create four primary partitions at most. (Though I haven't tested if it can boot from logical partitions.) It doesn't help that, despite the program itself being available in English, the detailed manual is only available in German, while only a simple readme is available in English.
I believe these errors are the result of bugs or incompatibilities of hypervisors and/or new CPUs, not issues in the boot managers; unfortunately that still means I wouldn't be able to test them, unless I use other emulation/virtualization solutions like QEMU and 86box, which are hard to use. For now I'll only be testing using VMWare.
I'm still not sure about this one. "Normally" it shouldn't be possible. But you can still do it thanks to third-party boot managers. XOSL, OSL2000, and BootIt all claim to be able to do it. The XOSL FAQ said you just need to execute the SYS command on the logical partition to make it bootable, but another guide says you also have to edit the partition boot record of the logical partitions to make it work.
Either way, there are other problems with this. The SYS command on DOS 8.0 (WinMe) only lets you do it to the C: drive, so you'd have to use DOS 7.1 or older for that. And it appears that the rule of "the partition that DOS/Win9x is booting from is always C:" still applies even when booting from a logical partition. This doesn't work:
sys D:First of all I tried to have an installation where I could just edit files or swap files around to boot another version of Win9x. Because the underlying DOS version is the same between Win95 OSR2.x, Win98FE, and Win98SE (these three use 7.1, while Win95 RTM and OSR1 use 7.0 and WinMe uses 8.0), if your multiboot configuration only consist of these 3 versions, you only need to edit MSDOS.SYS and change the drive letter and path to the Windows directory (= use the same DOS kernel i.e. IO.SYS to load all three versions), which could be automated in a bat file after boot, or even an autoexec.bat + config.sys boot menu (I haven't tested that though). You also need to pay attention to the %PATH% variable to prevent Win9x from trying to load binaries from another installation of Windows. I simply removed all Windows paths and only kept paths containing DOS commands for use in pure DOS only. Win9x doesn't seem to have a problem with that, and would correctly load its own binaries and boot.
Shotter_Nail used this method in Dual Boot - Windows 95+98 and Quad Boot - Windows 98 x 4 Themed Installs, but as these versions only use DOS 7.1 (Win95C aka OSR2.5 is used), you only need to modify MSDOS.SYS, and this method can't be used if you want to cross DOS version boundaries.
To cross DOS version boundaries, for example to dualboot Win95 RTM and OSR2, you would have to swap other files as well, at least IO.SYS. I just swap the entire contents of the C drive (while %windir% is in another partition) to be safe.
I'm inspired by some bootable CDs I use, that contain a [BOOT] directory with a "Boot-1.44M.img" file inside when viewed with 7-Zip, but not with other more "normal" viewers. I searched a bit and found that it's probably the El Torito standard, which is only usable in optical media. While some bootable CDs come with an IMG file normally viewable in the filesystem, I can't figure out how that is used (it's probably not El Torito).
Searching for methods of booting from a virtual floppy, I found that GRUB4DOS can do it easily. However, it's accomplished by hooking BIOS stuff, and therefore only works within DOS / real mode, and doesn't (fully) work in protected mode (source). If I map the image as (fd0), the drive virtualized from the floppy image is the only floppy drive accessible, both in DOS and in Win98. If I map (fd0) as (fd1) and then map the image as (fd0), which should leave the real floppy drive accessible as (fd1), the real floppy drive would be accessible as B: in the DOS prompt inside Win98, but not the GUI. So this basically disables the real floppy drive under Win98. I decided that this shortcoming is acceptable for me, as I don't expect to be using real floppy drives at all. However this might not be acceptable for some people.
Another problem is that the virtual floppies created are basically "live floppies". Any changes made will be discarded on reboot instead of being written back to the image file. You have to actually change the image file for changes to persist, which can be tedious.
There are other "virtual floppy" solutions under DOS, such as fakedisk. However I expect them to also be unavailable in protected mode (untested).
To make boot floppy images for use with this method, make a normal boot floppy first, and then copy all files in C:\ (without the "WINDOWS", "Program Files", and "My Documents" folders if Windows is installed into the active partition) to the floppy. The files can then be removed from the C drive in preparation for the next OS install.
Of course, you can also prepare floppies from a "real" floppy drive ("real" as far as the computer can tell, which means you can use a hardware floppy drive emulator like Gotek) and boot from there, but it's more tedious than simply pressing keys on a keyboard to navigate a boot menu, and Win9x becomes noticably slower when doing many things (even opening the start menu), even inside VMWare, which is probably caused by slow floppy drive access speeds, so I don't recommend that.
Here's a menu.lst entry:
title Windows ME map --mem (hd0,0)/wme.img (fd0) map --hook chainloader (fd0)+1 rootnoverify (fd0) boot
Same as above, except the image is mapped as a hard disk.
Testing configuration: Win95 OSR1 on E: (second logical partition), Win95 OSR2.5 on F: (third logical partition)
Mapping as 0xFF would have no effect; the computer would end up booting from the real hard disk normally.
Mapping as hd1 would cause an error message saying that "You started your computer with a version of DOS incompatible with this version of Windows."
Mapping as hd0 causes all drive letters to be shifted one place (the img file is now drive C), and Windows can't boot due to the mismatch between DOS and Windows. Considering that you can't change the drive letter where %windir% is, you would probably have to move files around for this to work. So I moved OSR1 to the first logical partition, and OSR2.5 to the second logical partition, so that they would be E: and F: after being shifted. Now OSR1 boots as expected, but for some reason there's one more drive letter at the end, after the last logical partition, with contents equal to the primary partition of the real hard disk, which is assigned D:. OSR2.5 boots as well and doesn't have this additional drive letter. This probably means that OSR1 accesses disks using DOS, while OSR2.5 doesn't.
Here's a menu.lst entry:
title Windows 95 OSR1 map (hd0) (hd1) map --mem (hd0,4)/w95osr1.img (hd0) map --hook chainloader (hd0)+1 rootnoverify (hd0) boot
Shotter_Nail used this method in Quad Boot - Win 3.1, 95, 98, ME - No Boot Manager. While Shotter_Nail said "partition 1", even with the weird expression of "what the Windows installers define as partition 1 on the disk" "can be induced to vary", the truth is that Win9x simply uses the active partition, regardless of its order and location. You would need to use a partition manager or boot manager to change the active partition. Unlike what many people (including even the GRUB documentation) said, you don't need to hide other primary partitions, at least for Win9x.
One shortcoming is that this changes the drive letter assignment. This goes against my requirement of having the same drive letter assignments across all multibooted Windows installations.
Although, if you're fine with different drive letter assignments, this could be the best arrangement without a boot manager. You could have four standalone installs each occupying a primary partition like the VM that Shotter_Nail created, or you could have three primary partitions, with DOS 7.0, 7.1 and 8.0 on each of them respectively, and boot dozens of versions of Win9x, each installed on a logical partition. You can even use the China DOS Union version of DOS 7.1, which has patches for running Windows 3.1. (Or you can patch DOS 7.1 and Windows 3.1 yourself as described in this VOGONS thread)
Win9x has a "boot menu" that let you boot the "previous version of DOS", and NTLDR (from NT 3.5 and later) supports "/WIN95" and "/WIN95DOS" switches in boot.ini to support booting into both Win9x and DOS straight from NTLDR. However, because Win9x still has DOS underneath, both can be "abused" to load another copy of Win9x instead of DOS < 7. I chose this method because I want to have NT installed anyway, so this saved me from having to use a third-party boot manager.
As mentioned in file editing, the corresponding DOS version of each Win9x version is as follows:
Because NTLDR can only boot two versions of DOS, at least without further hackery, you would have to give up one of the three groups. I don't think anyone would give up DOS 7.1, in which case the question becomes: which to give up, 7.0 or 8.0? Personally I chose 7.0, as with DOS 7.1 you can still use Win95 OSR2.x which still looks and feels like Win95 RTM/OSR1.
Start by installing your Win9x OSes of choice, making sure to backup the boot sector of them along with the boot files. After all of them are installed, install NT. (I used 4.0 since that's what I intended to make coexist with Win9x; I might try 3.5 and 3.51 later.) You don't need to backup or delete boot files and the boot sector for the last 9x OS you install, as NT Setup would generate a bootsect.dos and do the necessary renaming for the version of 9x that is present just before setup started. So when installation is complete you should already have a set of files for NTLDR to boot DOS/9x (BOOTSECT.DOS, IO.SYS, MSDOS.SYS), and boot.ini should already have an entry that reads: C:\ = "Microsoft Windows"
Remove that entry and create two similar entries instead. In my case, I used the .W40 set for DOS 7.1, and the .DOS set for DOS 8.0, so I wrote:
c:\bootsect.w40 = "DOS 7.1" /win95 c:\bootsect.dos = "DOS 8.0" /win95dos
Now copy the files from the backup to the active partition, and rename them accordingly:
| Original | .W40 set | .DOS set |
|---|---|---|
| IO.SYS | WINBOOT.SYS | IO.DOS |
| MSDOS.SYS | MSDOS.W40 | MSDOS.DOS |
| COMMAND.COM | COMMAND.W40 | COMMAND.DOS |
| AUTOEXEC.BAT | AUTOEXEC.W40 | AUTOEXEC.DOS |
| CONFIG.SYS | CONFIG.W40 | CONFIG.DOS |
Only IO.SYS and MSDOS.SYS are required.
Note that only one of the .W40 and .DOS sets should be present. If, like me, you let NT Setup generate a BOOTSECT.DOS for you, then you should copy the files for the other DOS version you chose (DOS 7.1 in my case) as the .W40 set, and copy the boot sector image file for DOS 7.1 as BOOTSECT.W40.
Now, a multiboot of NT and two versions of DOS is set up, and each path could potentially include many different versions of Windows. Additionally you can use file editing (swapping) to decide which installation of Win9x to use for a particular version of DOS.