I noted some time ago that Windows 95 Setup was actually three programs running under three different operating systems. The first part was an MS-DOS program, which was used if you installed Windows 95 from MS-DOS. It installed a miniature version of Windows 3.1 and then used it for the next part. The second part was a 16-bit Windows program, which was the starting point if you installed Windows 95 from Windows 3.1 or Windows 95. This second part did most of the work. The third part was a 32-bit Windows program, which ran inside the inewly-installed Windows 95 to carry out some final steps that must be done inside the installed operating system.

Some people wondered if the MS-DOS and Windows 3.1 versions could install a miniature Windows 95 rather than a miniature Windows 3.1. That would allow the bulk of the work to be done in a fully 32-bit operating system and take advantage of new Windows 95 features.

I guess you could do that, but there are problems with that design, both from an engineering and a user experience standpoint.

From the engineering side, it would mean having to develop a miniature version of Windows 95 in the first place. Using the miniature Windows 3.1 didn’t incur any extra engineering cost because there was already a fully-debugged miniature Windows 3.1 that could be pulled off the shelf and pressed into service. The Windows 95 project was notoriously behind schedule, and adding a “Develop a variant of Windows 95 for the sole purpose of running Setup” would be a large work item that would instantly get pushback. “Can you find a quicker and less expensive way of doing this?” Especially since Windows 95 itself was still under development, so you would be chasing a moving target. Everybody working on a new feature would have to remember, “Oh wait, but what if we’re running in miniature mode?”

Even if you decide that creating a miniature version of Windows 95 is feasible within the desired timeframe, there is the user experience issue: That miniature version of Windows 95 is probably not going to fit on a single floppy disk. It appears that somebody managed to strip it down to around 7.5 MB, with a remark that 5 MB “might” be possible.

Now, the MINI.CAB that comes on the Windows 95 Setup Disk 1 is 441,905 bytes in size, and it expands out to 815,307 bytes, a compressed size of 54.2%. Let’s be nice and call it 50%.

This means that a miniature install of Windows 95 might fit into 2.5 MB, which is two floppies. That’s not so bad.

So now we have this:

MS-DOS userWindows 3.x user↓↓MS-DOS file copyWindows 3.x file copy↘↙Reboot↓Main setup← Windows 95 user↓Reboot↓Final setup

One catch is that we have to write two versions of the code that copies the miniature Windows 95 to the system, depending on the starting point. That is a little bit of code duplication, and it’s a little more complex than the file copying code that Windows 95 actually uses for copying the miniature Windows 3.1 since there is a floppy swap involved.

Another catch is the need for a reboot into the miniature Windows 95, since the Windows 95 file system takes over operations from the MS-DOS file system that booted the system. In order to do that, they need to agree on the internal MS-DOS data structures the track the open files, and the MS-DOS side needs to provide the necessary hooks for the Windows 95 virtual machine manager to take over from it.

After the main setup is done, we do another reboot, this time into the real copy of Windows 95 (not the temporary one), and let the final setup delete the temporary copy and finish setting up the real copy.

Now, this design does impair the user experience.

The preferred workflow would be to get the user quickly to the point where they are answering questions about how they want Windows to be installed, and then go off and do the work and then finish in Windows 95 with a single reboot.

With this alternate design, the MS-DOS and Windows 3.x cases now do a lot more work before the user can start answering questions. This is frustrating because it means that the user can’t just start Setup, answer some questions, and then walk away and get some coffee. They have to babysit the Setup past the initial file copy (that includes a floppy swap) and sit through a reboot, wait for BIOS to POST, then wait for the miniature Windows 95 to boot itself up and get to the point where it can ask questions.

Furthermore, we now have two reboots, which breaks the “only one reboot” principle.

The staged version where the MS-DOS Setup program quickly installs and runs a miniature version of Windows 3.1 lets us get the user into the “asking questions” stage faster, and it also avoids the double-reboot.

¹ Another suggestion I saw was to install Windows 3.1 with Win32s so that the main setup program could be written as a 32-bit program. Unfortunately, there are a few problems with this proposal. One is that Win32s itself requires a reboot after installing, so you haven’t solved the double-reboot problem. Also, Win32s is itself 2 MB in size, so that adds to the amount of stuff the user has to wait for before they can start answering questions. And this extra 2 MB is used only by Setup; it isn’t going to be reused by the real Windows 95, so this adds to the number of floppies that need to be used.

Furthermore, Win32s requires Enhanced Mode Windows 3.1, so the miniature Windows 3.1 isn’t good enough, since that is just Standard Mode Windows. You now need to include a miniature Enhanced Mode Windows 3.1, but nobody has made one of those yet. The ready-made miniature Windows 3.1 is Standard Mode, not Enhanced Mode. And the Enhanced Mode Windows 3.1 will probably be a few more megabytes, adding to the amount of “dead weight” on the Windows 95 installation floppies.

The post Why didn’t Windows 95 setup install a miniature Windows 95 so that it could be written as a 32-bit program? appeared first on The Old New Thing.

From The Old New Thing via this RSS feed