Why did Windows 95 setup use three operating systems?

Original Article ↗ Hacker News Discussion ↗

Windows 3.1, DOS, and Windows 95 Architecture

  • Debate over whether Windows 3.1 was “just a shell” on DOS:
    • One view: primarily a GUI shell with DOS handling drivers, disk I/O, and config (config.sys, autoexec.bat).
    • Counterview: functionally “95% of an OS,” managing memory, processes, input, graphics, and many drivers while DOS mainly provided filesystem and legacy app support.
  • Discussion of 386 protected mode, v86 mode, and virtualized DOS/BIOS:
    • Windows for Workgroups 3.11 and Windows 95 use DOS as a bootloader, then switch to protected mode and run DOS in a VM, trapping BIOS and some I/O.
    • Over time, more drivers moved from DOS/BIOS into 32‑bit VxDs, culminating in 9x being able to run without leaving protected mode for most operations.

Runtime Windows and Why Setup Used Windows 3.x

  • Historical “runtime” Windows shipped with apps like Excel, PageMaker, Word, and some scanners:
    • Stripped‑down Windows 1.x/2.x/3.x with no general shell, intended to run a single app (or a very small set).
    • Still required DOS; early Windows used DOS for all file access.
  • Windows 95 setup reused the same idea: a minimal Windows 3.x environment to host a 16‑bit installer, rather than inventing a tiny “Windows 95” just for setup.
    • Suggestion to have a “bare 95” that the installer could reboot into is dismissed as extra complexity and disk space for only cosmetic gains.

Modern Windows Setup (WinPE and Relatives)

  • Current installers boot into Windows PE, a stripped‑down NT environment used for installation and recovery.
    • It uses the same kernel generation as the target OS, though the UI assets largely date back to Vista.
    • WinPE is distinct from Windows CE and from embedded NT variants used in ATMs/signage.
    • Installing and injecting drivers into WinPE is described as quirky and more limited than full Windows.

Backward Compatibility and DOS/NT

  • NT 3.51’s stricter DOS compatibility prompted user backlash; 16‑bit apps and DOS behavior lingered far longer than designers expected.
  • Comparisons with Unix/Linux and Solaris:
    • Some Unix systems (e.g., Solaris) are praised for strong binary compatibility.
    • Linux compatibility depends heavily on userland libraries; containers are seen as a modern workaround.
  • Windows’ long‑term ability to run decades‑old software is cited as a key reason for its desktop dominance, though it adds complexity.

Upgrade Chains and Multiboot Experiments

  • Discussion of whether an install can be upgraded from very old versions (DOS/Win95) all the way to modern Windows without reformatting.
    • Some describe elaborate multiboot setups: DOS and Win9x on FAT32, then XP on FAT32, then NT‑based systems (7, 10, possibly 11) on additional NTFS partitions, all chained via boot loaders.
    • YouTube experiments are referenced showing very long upgrade chains.

UI/UX, Stability, and Performance Opinions

  • Mixed views on Windows 95:
    • Some recall it as unstable and crash‑prone compared to today; others remember it as usable and revolutionary for its time.
    • Windows ME is generally regarded as worse.
  • Comparisons with classic Mac OS:
    • Mac is praised for always‑graphical, polished boot and install flows, and simple system installation (copying a System Folder).
    • PCs’ text‑mode BIOS and flickering mode switches are attributed to heterogeneous hardware and legacy constraints.
  • Modern Windows UI:
    • Some praise current Windows 10/11 UI as solid and continually tweaked.
    • Others see regression: removal of features (e.g., vertical taskbar), ads in the Start menu, right‑click changes, animation slowdowns, and reliance on continuous, incremental changes.
    • Running old XP in a VM feels snappier to some, highlighting perceived bloat and overhead (registry chatter, UI animations, security/ACL checks, and poor small‑file performance vs Linux).

Market Inertia and Lost Diversity

  • Nostalgia for the 80s–90s era of many competing platforms (Commodore, Atari, Acorn, etc.).
  • Microsoft’s OEM contracts, strong backward compatibility, and the IBM PC standard are cited as locking in the platform and making new mainstream OS+hardware entrants rare.

Reflections on Chen’s Material

  • The broader blog (beyond the linked post) is valued for:
    • Explaining internal design trade‑offs (e.g., “what if two programs tried this?” as a mental model for rejecting certain APIs).
    • Illuminating how Windows balanced compatibility, UX, and architecture through the DOS–9x–NT transition.