Twitter users @tthirtle asked why Windows 95 setup goes through three operating systems: MS-DOS, Windows 3.1, and then Windows 95. Why not go from MS-DOS straight to Windows 95?
Here’s another good question. Why does Windows 95 setup use 3 different UI’s. DOS,Win3.x,and Win9x?
— Thomas (@tthirtle) July 7, 2024
Windows 95 setup could upgrade from three starting points: MS-DOS, Windows 3.1, or Windows 95. (Yes, you could upgrade Windows 95 to Windows 95. You might do this to repair a corrupted system while preserving data.)
One option is to write three versions of Windows 95 setup: One for setting up from MS-DOS, another for setting up from Windows 3.1, and a third for setting up from Windows 95.
This was not a pleasant option because you basically did the same work three times, but implemented separately, so you have to do three times the coding.
A better option is to just write one version of Windows 95 setup and use it for all three starting points. So now you get to choose the platform on which to base your code.
From | App type | ||
---|---|---|---|
MS-DOS | 16-bit GUI | 32-bit GUI | |
MS-DOS | • | ||
Windows 3.1 | • | • | |
Windows 95 | • | • | • |
If you write Windows 95 setup as an MS-DOS app, then it runs on all three platforms. That’s great! You need to write only one setup program. The downside is that it’s going to be a text-mode setup program, which looks ugly and gives a poor initial impression of what is supposed to be a brand new GUI world.
At the other extreme, you can write Windows 95 setup as a 32-bit GUI program, but that means that if the user is starting from MS-DOS or Windows 3.1, you have to install Windows 95 before you can run Windows 95 setup, which is a bit of a catch-22.
In the middle is the happy medium: You can have the MS-DOS setup program install a minimal version of Windows 3.1, just barely enough to support what the 16-bit GUI setup program needs.¹ This tiny version is small enough to be copied and installed off a small number of floppy disks. Once that’s done, boot into the tiny version of Windows 3.1 and run the 16-bit GUI setup program.
Okay, so now we have three setup programs. The first one is used if you’re installing from MS-DOS: It installs the tiny version of Windows 3.1, and then boots into Windows 3.1 to continue to the next step.
The second setup program runs as a 16-bit Windows app, either in the miniature copy of Windows 3.1 (if the user is upgrading from MS-DOS), the real copy of Windows 3.1 (if the user is upgrading from Windows 3.1), or the real copy of Windows 95 (if the user is upgrading from Windows 95). This second setup program is the one that does almost all of the real work: It does the initial interaction with the user to gather information about how to install Windows 95, like asking which optional components to include, and does hardware detection to decide which drivers to install.² And then it copies the drivers and Windows 95 files onto the system, migrates your old settings to the new operating system, and boots into Windows 95.
The third setup program runs as a 32-bit Windows app. It is running in the real Windows 95 system and does some final steps that require operation a live running system, like installing printers.
Starting from MS-DOS → | Install mini Windows 3.1 |  |  | MS-DOS app |
↓ | ||||
Boot into mini-Windows 3.1 | ||||
↓ | ||||
Starting from Windows 3.1 → | Gather information |  |  | 16-bit Windows app |
or Windows 95 | ↓ | |||
Detect hardware | ||||
↓ | ||||
Copy drivers and Windows 95 files |
||||
↓ | ||||
Migrate settings and configure drivers | ||||
↓ | ||||
Boot into Windows 95 | ||||
↓ | ||||
Final setup | Â | Â | Windows 95 app |
So that’s why Windows 95 setup is really three setup programs chained together. It allows a single copy of the code to be used for all three of the installation scenarios. Each program takes you one step closer to the goal. And everything got implemented only once.
¹ There was existing precedent for a tiny version of Windows that is barely enough to run a single program. The original Windows version of Microsoft Excel came with a runtime version of Windows 2.1, so that customers who didn’t have Windows could still use Excel.
² This hardware detection code that Setup uses is the same code that runs when you do hardware detection from within Windows 95 itself, so even that code needed to be written only once. It did have some runtime checks to change behavior slightly depending on whether it’s running in Windows 3.1 or Windows 95, but the vast majority of the code is identical.
I wonder how much extra work it took to make the hardware-detection code compatible with Windows-3.1/16-bit mode and whether it was also running as 16-bit Code in Windows-95.
Anyway, the design of Windows-95 really fascinates me: it is incredible how the existing design of enhanced mode Windows was extended into what I wouldn't call an elegant design, yet it more or less worked surpisingly well especially considering the low hardware requirements. It also reminds me how...
Would there have been any consideration of Win32s+real 3.1 or Win32s+mini 3.1 so that the GUI installer could be a 32-bit application? Or would that do nothing but bloat the install disk count?
It was surely possible to fit MinWin95 in 1-2 floppies, path not taken.
It’s fascinating. I thought MiniWin from the installer was Windows 95 with the Shell modified in system.ini/win.ini (I don’t remember the file).
I used to take out MiniWin and use it for standalone applications that took up 2 or 3 megabytes, for example games. It was very fast and efficient. The games were probably on Win16.
Microsoft, forgive me, it wasn’t piracy, it was a teenager learning.
I loved the article.
I grew up with Windows 3.1 and Windows 9x, and I remember being hugely fascinated by the Windows 95 installer and the fact that you actually were running Windows 3.1 for a while. I’m not sure exactly why, but to me this was so cool and awesome.