November 12th, 2024

Why did Windows 95 setup use three operating systems?

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?

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.

Topics
History

Author

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.

4 comments

  • Jake Thompson

    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?

  • Start Is Back 4 days ago

    It was surely possible to fit MinWin95 in 1-2 floppies, path not taken.

  • Jose Antonio Jamilena Daza 1 week ago

    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.

  • Andreas Rejbrand

    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.