One of the reactions to my discussion of why Windows 95 setup used three operating systems (and oh there were many) was my explanation that a miniature version of Windows 3.1 was used to get MS-DOS customers upgrading to Windows 95. But why not use a miniature version of Windows 95?

A technical reason is that the miniature version of Windows 3.1 compressed to only 441,906 bytes, or just under a third of the capacity of a single floppy disk. A miniature version of Windows 95 wouldn’t fit on a single floppy, so the user would be spending a lot of time in ugly text mode doing floppy swapping. Using a miniature Windows 3.1 gets the user out of text mode quickly. And the code to deal with floppy swapping would have to be written as an MS-DOS program, which is not a lot of fun. I don’t want to be here any more than you do.¹

An engineering argument against using a miniature Windows 95 is that there was no miniature Windows 95! Windows 3.1 already had developed a miniature version, so we could use that one immediately. But developing a miniature Windows 95 would have required diverting resources from the rest of the operating system team to develop a special miniature version of Windows 95, looking for places where components could be removed and fixing the dependencies so they could tolerate running without it. For example, you probably would not include the multimedia system in the miniature Windows 95, but now you have to make sure all the rest of the system still runs okay without any multimedia support. Anybody who called a function in mmsystem.dll would have to switch from a static dependency to dynamic loading because mmsystem.dll might not exist. This is a lot of work to develop a version of Windows 95 that serves exactly one purpose: Installing Windows 95.

There’s also a marketing reason for using a miniature Windows 3.1 for MS-DOS customers: Keeping your best customers (Windows 3.1 users) happy. Having the MS-DOS upgrade path used a miniature Windows 95 but making the Windows 3.1 upgrade path use the existing Windows 3.1 would be an awkward situation to explain to our staunchest supporters, the existing Windows 3.1 users. Why are they getting a worse graphical experience than the MS-DOS holdouts? The alternative would be using a miniature Windows 95 even for Windows 3.1 customers, but see the next point.

Another reason for using a miniature Windows 3.1 is aesthetic: Windows 3.1 can be started from MS-DOS without a reboot, whereas installing a miniature Windows 95 would require rebooting into it, and then rebooting again after Windows 95 was fully installed. In this era, computer boot times were not the best,³ and there was that big ugly BEEP at the end of the power-on self-test. A single-reboot install was the desired experience. You go through a little song and dance while the setup program copies files, and at the end, your computer reboots and you are welcomed into the exciting world of Windows 95, like a butterfly emerging from a cocoon.

Bonus chatter: There’s also the rollback problem. If the user cancels Windows 95 setup, or if Windows 95 setup fails for some reason, or if the user experiences a power outage in the middle of setup, you need to leave them with a computer that can return to its original state. The least risky way of doing this is to avoid modifying an existing file on the system until the very end. If you install a miniature Windows 95, then you’ll have to modify the system boot files so it will reboot into miniature Windows 95, violating the principle of “don’t change anything until the very end.” The Windows 95 installation process does do a little bit of final preparation after the boot files are changed, but they were designed so that even if those steps failed, Windows 95 setup didn’t have to roll back; it just proceeded into Windows 95 anyway, but maybe without the user’s printers being fully migrated.

Another question is what the fate of the miniature Windows 95 is after setup is complete. One idea is that the miniature Windows 95 is discarded after the full Windows 95 is installed somewhere else. This consumes a lot of extra disk space and I/O since the files in the miniature Windows 95 have to be written twice, once for the miniature Windows 95 and again for the real one. Another option is that the miniature Windows 95 is upgraded in place to a full Windows 95. However, this means that you would have to replace the original win.com and other system files with their Windows 95 counterparts so that you can use them to boot into the miniature (soon to be full) Windows 95. This complicates rollback since the user is now in a state where an unexpected power outage will result in a system that system boots into a partially-installed Windows 95, and troubleshooting that is going to be ugly.

The miniature Windows 3.1 was small enough that the extra disk space it occupied during Windows 95 setup was not significant.

Bonus bonus chatter: What about a bootable CD? Why didn’t you use that?

This is sort of like asking why they didn’t use the Space Shuttle to rescue the Apollo 13 astronauts. The El Torito specification for bootable CDs was not published until January 1995, so the number of systems that supported it was still very small (and the numbers that supported it without bugs was even smaller).⁴ Besides, it was too late in the Windows 95 development cycle to add as a major feature like this.

It’s possible that later editions of Windows 95 did have a bootable CD, but I don’t know for sure.

¹ I wrote one of the iterations of the file copying code for Windows 95 setup, back when we thought we would have two separate setup programs, one for upgrading from MS-DOS and another for upgrading from Windows 3.1 or Windows 95.² To avoid duplication of work (both coding and debugging), the main logic of the code could be compiled either as an MS-DOS program or as a 16-bit Windows program. The I/O and memory management portions were conditional, but shared code was used to keep track of all the I/O buffers, decide when we needed to ask for a new floppy, etc. The MS-DOS version had to be aware that it might have access to as little as 512KB (or less) of conventional memory, so the file buffering has to be done through expanded memory or extended memory, depending on how the user configured their memory, and then double-buffered through conventional memory for I/O to the device. You thought far pointers were annoying? Wait’ll you deal with bank-switched memory.

² After my loan to the setup team ended, they realized that they could squeeze a miniature Windows 3.1 onto a single floppy and avoid having to write two setup programs. I think some of my original file copying code is still present in the GUI portion of Windows 95 setup, but probably not much any more.

³ One might argue that we have never left this era.

⁴ In the pre-Windows 95 era, CD-ROM drivers weren’t really standardized. Every CD-ROM drive came with its own drivers, some of which were carefully tailored to cover shoddy workmanship on the hardware side.