Windows 95 Fast Restart Explained: Shift Restart and the Win9x Boot Stack

Microsoft veteran Raymond Chen has pulled back the curtain on a decades‑old Windows 95 trick: hold the Shift key while choosing Restart and the system would, in many cases, come back to life far faster than a full cold reboot — and the reason lies in the way the Win9x boot stack handed control between 16‑bit DOS-era components and the 32‑bit protected‑mode kernel.

Background​

Early consumer Windows — the Windows 9x family — was a hybrid creature: part MS‑DOS legacy, part 16‑bit kernel, and part nascent 32‑bit protected‑mode operating system. That hybrid architecture made clever engineering possible, but also introduced fragile dependencies between components. The trick Raymond Chen described depends on that layered boot model and on a loader called win.com that sat at the boundary between real mode and protected mode.

• Real mode: the CPU’s legacy startup mode with direct hardware access and a 1MB addressable range.
• Protected mode: the operating mode modern OS kernels use to enforce memory separation and multitasking.
• win.com: the DOS‑era COM loader that started protected‑mode Windows when booting via MS‑DOS.

Understanding the trick requires a short tour through how Windows 95 shut down and restarted under the hood.

---

How the “fast restart” sequence worked​

At its core the Shift + Restart shortcut didn’t do anything magical; it simply asked Windows to take a soft restart path instead of forcing the machine through a full cold reset. The mechanism used an older shutdown API path — essentially the 16‑bit ExitWindows behavior with a restart flag — and relied on win.com to relaunch the protected‑mode OS without power‑cycling the machine. Raymond Chen explains the sequence crisply: the 16‑bit kernel exits, the 32‑bit virtual memory manager tears down, the CPU drops to real mode, and control returns to win.com with an instruction to start protected‑mode Windows again. Put into sequential steps, the attempted fast restart looked like this:

1. Windows calls the legacy ExitWindows path with the restart flag (historically a 16‑bit flavor such as EW_RESTARTWINDOWS).
2. The 16‑bit kernel shuts down cleanly.
3. The 32‑bit virtual memory manager (VMM) and associated protected‑mode subsystems exit.
4. The CPU is set to real mode and control transfers back to win.com.
5. win.com re‑initializes the environment and attempts to switch the CPU back into protected mode and relaunch Windows.
6. If all memory and prerequisites look right, the GUI reappears rapidly without powering off the machine; otherwise win.com falls back to a full cold reboot.

This was visually fast because the hardware never had to go through the full power cycle — the BIOS and device initialization that accompany a cold boot were frequently avoided.

---

The memory layout constraint: why it usually failed​

The reason many attempts at this fast restart fell over is simple: contiguous conventional memory. In the MS‑DOS + Windows 9x world, .com programs (including win.com) were implicitly assigned whatever conventional memory (the first 640 KB) remained, and programs could subsequently release that memory back to the system. win.com deliberately released the memory beyond its own code image to create a single large contiguous block suitable for allocating the protected‑mode structures required by Windows. If that block wasn’t available — because some TSR, driver, or other component had allocated chunks in the expected region — the memory layout became fragmented and win.com could not re‑establish the exact layout it assumed. When that happened, win.com refused the fast‑restart path and triggered a normal reboot. The fragility came from two practical realities:

• In the 1990s, many real‑mode drivers and resident utilities (TSRs) grabbed conventional or upper memory and did not always release it cleanly.
• Some code purposely reused dead code bytes or other low‑level tricks to squeeze memory — a common assembly optimization of the era that left little margin for assumptions about contiguous free space. Chen even notes an assembly trick where entry‑point bytes were re‑used as storage after the code path was no longer needed; that trick could be benign in normal runs but made memory layouts brittle for a restart path that relied on an exact initial state.

Microsoft’s own technical guidance for Windows 95 and MS‑DOS memory management confirms the importance of upper memory blocks, HIMEM/EMM settings, and careful configuration to preserve conventional memory for DOS programs and compatibility scenarios. If those pieces weren’t carefully controlled, the “one giant contiguous block” expectation simply didn’t hold.

---

Raymond Chen’s take — clarity from the source​

Raymond Chen’s explanation is authoritative because he worked on these systems and has a long history of documenting Windows internals. He makes three key points that resolve the long‑running mystery:

• The behavior is driven by an older restart flag passed through the legacy ExitWindows code path (EW_RESTARTWINDOWS in 16‑bit terms).
• The restart is attempted by returning to win.com in real mode and asking it to re‑start protected‑mode Windows.
• win.com must find the same memory layout it had when it was first launched (notably, a large contiguous conventional memory block) to make the jump back into protected mode; otherwise it falls back to a full reboot.

Chen also provides a vivid anecdote about the fragility of repeated fast restarts: trying the fast‑restart twice in a row could crash the machine — a practical demonstration of just how brittle the assumptions were. That single observation encapsulates both the elegance and the risk of the mechanism.

---

Why modern Windows avoids this shortcut​

Modern Windows (NT‑family: Windows 2000, XP, 7, 10, 11, etc. is architected very differently. The kernel is not a fragile, multi‑mode stack riding on top of MS‑DOS; instead, the OS owns the boot path and provides robust, documented shutdown and restart APIs (ExitWindowsEx and friends) that operate in a uniform protected‑mode environment. Those APIs are explicit about shutdown flags, privileges, and restart semantics — and they are designed to avoid brittle reliance on external DOS loaders, fragmentable conventional memory, or code reuse hacks. The modern model favors correctness and data integrity over squeezing milliseconds from reboot time. Two additional practical reasons modern Windows avoids the Win9x-style trick:

• Device drivers and kernel components today expect a clear, well‑documented shutdown sequence and often commit state during shutdown; bypassing those semantics increases the risk of data loss or corruption.
• Modern boot configurations, firmware interactions (UEFI), secure boot, and device initialization paths have increased the number of things that must be initialized in a cold boot, making a half‑step restart either impossible or unsafe without elaborate bookkeeping.

Where modern Windows does pursue “faster” startup paths, it does so in safer, more controlled ways — for example, hybrid shutdown / fast startup behavior that hibernates kernel session state (Windows 8+ Fast Startup), or by providing recovery‑targeted flows (Shift + Restart now intentionally routes to Advanced Startup / WinRE rather than attempting any fragile soft reboot trick).

---

The engineering trade‑offs: speed vs safety​

The Windows 95 fast‑restart trick is an excellent case study in engineering trade‑offs.

• Strengths and ingenuity:
  • It was a clever reuse of an existing boot loader to save the time spent on hardware reinitialization.
  • When the memory conditions were right, it produced a noticeably faster user experience — a real win for usability on slow 1990s hardware.
  • The approach is emblematic of resource‑constrained engineering: short code, clever memory reuse, and maximal reuse of existing components delivered functionionality that otherwise would have demanded far more code.
• Fragility and risks:
  • The mechanism presumes a near‑perfect world where device drivers and TSRs do not interfere with the memory region win.com expects. In practice, many third‑party drivers didn’t play nicely, creating intermittent failures.
  • A failed memory layout check results in a full reboot, and repeated fast restarts could crash the machine — a showstopper for reliability.
  • There’s an operational risk to the user: because the process skips some of the normal reinitialization choreography, device state or pending writes might be left in an inconsistent state in edge cases.

Those trade‑offs explain why modern OS design moved away from brittle optimizations toward predictable, auditable shutdown and restart flows.

---

Practical lessons for IT teams and hobbyists​

For anyone maintaining vintage hardware, retrocomputing enthusiasts, or sysadmins supporting legacy fleets, Chen’s write‑up has concrete, actionable lessons:

• If you want fast soft restarts on Windows 9x-era machines, keep conventional memory as clean and contiguous as possible: avoid unnecessary TSRs, and prefer protected‑mode drivers where supported. Microsoft guidance from the era shows specific CONFIG.SYS and AUTOEXEC.BAT practices to preserve conventional memory for DOS‑mode programs.
• Be cautious with repeated forced restarts or tricks that bypass normal shutdown logic. They may expose latent driver bugs that only surface during teardown‑and‑restart sequences.
• Treat such tricks as convenience hacks rather than supported recovery mechanisms. For modern troubleshooting, use documented recovery paths (Advanced Startup, WinRE, or Emergency Restart behind the Secure Attention Sequence) rather than legacy shortcuts. Community write‑ups and practical guides document these modern recovery flows and their risks in detail.

---

Where history meets modern practice: Shift + Restart vs Emergency Restart​

The 1990s Shift + Restart fast‑reboot is not the same as the Shift + Restart behavior in modern Windows, nor is it the same as the “Emergency Restart” hidden in the Secure Attention Sequence (Ctrl+Alt+Del + hold Ctrl + click Power). Contemporary Windows uses Shift + Restart to enter Advanced Startup (WinRE) — a documented, safe path to recovery tools — and keeps emergency forced reboots behind a privileged SAS gate for last‑resort scenarios. Community and documentation resources make the distinctions clear: the old trick was a fragile performance shortcut tied to win.com and conventional memory; modern mechanisms prioritize integrity and diagnosis.

---

Cross‑checks and verification​

This article’s technical claims rest on multiple independent sources:

• The detailed mechanics of the win.com return and memory layout requirement come from Raymond Chen’s direct explanation and veteran‑level commentary.
• The formal shutdown and restart API behavior and modern replacement semantics (ExitWindowsEx and related flags) are documented in Microsoft’s API references.
• Historical memory management practices for Windows 95 and MS‑DOS mode — including the importance of HIMEM.SYS, EMM386, and upper memory blocks — are confirmed in contemporary Microsoft guidance and KB archives.
• Community and re‑reporting of the fast‑restart phenomenon, its intermittent reliability, and operational warnings appear across technical reporting and user forums, which corroborate the anecdotal parts of the story and highlight the uncertainty around exact vintages of certain behaviors.

Where claims are based on internal behavior not exhaustively documented in public Microsoft developer docs (for example, the exact internal checks win.com performed in assembly), the strongest primary source is Chen’s firsthand account. Those statements are credible but should be treated as expert recollection of product internals rather than a line‑by‑line authoritative API spec; readers who need to reproduce behavior on real hardware should test in a controlled environment.

---

Why this history still matters​

The Windows 95 fast‑restart anecdote is more than nostalgia. It’s a concise lesson in systems engineering:

• Resource constraints drive creative solutions, but those solutions can become brittle when assumptions are violated.
• Backward compatibility designs (mixing real mode and protected mode) introduce subtle coupling between components that can hinder recovery and evolution.
• Modern OS design has learned to favour predictable correctness over fragile micro‑optimizations, especially when user data integrity is at stake.

For practitioners, Chen’s explanation is a reminder to document assumptions, avoid hidden state dependencies, and prefer restart/recovery flows that are auditable and robust — design choices that shape operating systems to this day.

---

Conclusion​

The Shift + Restart trick from the Windows 95 era was a neat piece of engineering theater: a fast, assembly‑tight path that called on win.com to relaunch protected‑mode Windows without cycling power. Its success depended on fragile memory layout assumptions and DOS‑era memory semantics that modern OS design intentionally avoids. Raymond Chen’s explanation peels back the fog on how and why the technique worked — and why, ultimately, the Windows platform moved on to safer, more predictable restart and recovery models. For retrocomputing enthusiasts it’s a fascinating footnote; for system designers it’s a compact cautionary tale about the trade‑offs between cleverness and reliability.

---

---

Source: theregister.com Microsoft veteran explains Shift restart Windows 95 trick

 

[ChatGPT]

Few software tricks feel as much like a secret handshake as the old Windows 95 “hold Shift while you restart” shortcut — and the explanation, laid out by Microsoft veteran Raymond Chen, is a compaccesst lesson in how clever engineering once traded fragility for speed. c

Background​

Windows 95 lived in a transitional era: CPUs, firmware, and user expectations were moving rapidly from the old MS‑DOS world toward the protected, multitasking kernels we use today. That hybrid architecture — a 16‑bit DOS/Win16 layer grafted to a nascent 32‑bit protected‑mode kernel and virtual memory manager — left engineers room to build small, pragmatic shortcuts. One of those shortcuts let Windows avoid a full hardware cold boot and instead *restart then returning control to the DOS loader, win.com. Modern readers should note two important context points up front:
historical: it applied to the DOS‑based Win9x family (Windows 95/98/ME), not the NT lineage (Windows NT/2000/XP/10/11).

• Today’s Shift+Restart does something entirely different: it’s the supported path into the Windows Recovery Environment (WinRE) / Advanced Startup on Windows 8, 10 and 11. This is a documented, safe entry to recovery tools, not a fast‑reboot trick.

---

The mechanics: what actually happened when you held Shift and clicked Restart​

The key actors: win.com, real mode and protected mode​

At boot time, DOS‑based Windows used a small DOS program named win.com to bootstrap the rest of the OS. In Win9x, win.com sat between the legacy real‑mode environment (the CPU’s startup mode) and the protected‑mode kernel the GUI depended on. That boundary is central to the trick: rather than cycling the power and reinitializing hardware, Windows could tear down its protected‑mode components, drop the CPU back into real mode, and then ask win.com to relaunch the protected‑mode image — if the memory and environment looked the same as when Windows first started.

The sequence, step by step​

Raymond Chen describes the flow succinctly: the system called the legacy ExitWindows path with a restart flag, the 16‑bit kernel shut down, the 32‑bit virtual memory manager (VMM) and related subsystems exited, the CPU reverted to real mode, and control returned to win.com with a signal: “start protected‑mode Windows again.” win.com displayed “Please wait while Windows restarts…” and attempted to re‑enter protected mode and recreate the running system. If the memory layout and prerequisites matched expectations, Windows came back without a full cold reboot; otherwise win.com fell back to a normal reboot.

• ExitWindows with EW_RESTARTWINDOWS was invoked.
• The Win16 kernel shut down.
• The VMM and 32‑bit subsystems tore down.
• CPU switched to real mode; control transferred to win.com.
• win.com attempted to relaunch protected‑mode Windows (rebuilding VMM and GUI).
• Success → soft restart; failure → full cold reboot.

Why it looked fast​

The visible speed came because the motherboard, BIOS/POST and many device initializations were not redone. Those hardware steps often dominated boot time on 1990s PCs: avoiding them saved seconds or even tens of seconds on sluggish machines. The OS-level re‑startup simply re‑created the kernel and GUI using the existing hardware state. That user‑visible speed is what made the trick feel like magic to people who’d waited for slow mechanical disks and early PCI enumerations.

---

The fragile secret: why it often failed​

Contiguous conventional memory was the fragile linchpin​

The trick relied on one very brittle assumption: that the conventional memory (the first 640 KB used in DOS-era setups) would look the same to win.com when it regained control. By design, .com programs like win.com were given whatever conventional memory remained; win.com released extra memory to create a single large contiguous block it expected to reuse when jumping back into protected mode. If any TSR, real‑mode driver, or piece of code had stolen or fragmented that conventional memory space in the interim, win.com’s reinitialization would fail and the system would fall back to a full reboot.

Typical breakage vectors​

• Legacy device drivers and resident utilities (TSRs) grabbed slices of conventional or upper memory and did not release them predictably.
• Aggressive memory‑squeezing assembly tricks reused code bytes as storage — valid optimizations in their day but fatal to an algorithm that needed a pristine memory layout.
• Repeated fast‑restart attempts could destabilize the environment; Chen himself recounts that trying the trick twice in a row could crash the machine — an anecdote that underscores how close to the metal the method was. Treat those anecdotes as first‑hand testimony from one of the engineers who worked the stack, but also as practical, empirical rather than exhaustively formalized evidence.

Practical limits on reliability​

In the home‑PC era, users installed many driver packages, sound card TSRs, anti‑virus resident helpers, and toolbar‑style utilities that were not written with this restart path in mind. Those add‑ons introduced unpredictable memory fragmentation and side effects, making the fast restart an occasional hit rather than a dependable feature. This is why many veteran users remember the trick as “it worked sometimes,” rather than as a guaranteed technique.

---

Cross‑checks and validation​

Multiple independent write‑ups and primary accounts line up on the core technical claims:

• The primary, authoritative explanation comes from Raymond Chen’s Old New Thing entry, which explicitly describes the EW_RESTARTWINDOWS flag, the 16‑bit/32‑bit teardown, the CPU’s switch back to real mode, and handoff to win.com.
• PC Gamer and The Register reproduced Chen’s explanation and added practical perspective about user experience and driver fragility; these outlets corroborate Chen’s description and place it in a user‑facing narrative.
• Contemporary technical writeups of the DOS‑based Windows boot process and win.com’s role confirm that win.com bootstrapped the protected‑mode kernel and that COM/.COM program memory semantics meant large contiguous regions were assumed by some early Windows subsystems. These technical overviews match the claims Chen makes about why win.com required a contiguous block to relaunch Windows.

Where claims depend on internal implementation details not fully documented in public MSDN archives (for example, the exact set of memory checks win.com performed in assembly), Chen’s account is the best primary source available — he’s an engineer with direct experience. Those specific low‑level behaviors are therefore authoritative but deserve a cautious label: they are engineer testimony about implementation, which is the strongest available evidence for historical internals even if the original assembly is not widely published.

---

Why modern Windows doesn’t (and can’t) replicate this trick​

Different architecture: NT kernel vs DOS legacy​

Modern Windows (the NT family: Windows 2000 onward) is not a Win9x hybrid that sits on top of DOS. It uses a unified, protected‑mode kernel from the moment the OS runs, with explicit shutdown and restart APIs designed for safety and consistency. That design both removes the opportunity for a win.com‑style handoff and makes the kind of fragile, memory‑layout‑dependent restart fundamentally incompatible.

Device drivers, firmware, and security make single‑step restarts unsafe​

• Today’s drivers and kernel components often commit state during shutdown (for example, journaling, encrypted volumes, firmware updates). A soft trick that skips a full hardware reinitialization risks inconsistent device state or data loss.
• UEFI, Secure Boot and modern firmware interactions add complexity to the boot and initialization process; devices may require specific enumerations and reinitializations that a Win9x trick would skip.
• The security model puts recovery and emergency actions behind well‑defined surfaces (WinRE, Secure Attention Sequence) and away from brittle hacks.

Safer modern alternatives for faster recovery​

Microsoft and the ecosystem chose safer paths to accelerate restarts:

• Fast Startup (Windows 8+): hybrid hibernation that preserves kernel session state across shutdown/power‑on cycles (not used for Restart), which reduces boot time in a supported and tested way.
• Shift+Restart → Advanced Startup (WinRE): a documented, graceful way into recovery tools and Safe Mode for troubleshooting. This is how modern Shift+Restart is used and documented in user guides.
• Emergency Restart behind Ctrl+Alt+Del (SAS): a gated, last‑resort forced reboot option intended for when the shell is completely unresponsive; this is deliberately obscure and warns users about data loss. It is not a safe substitute for graceful shutdowns.

---

Strengths and engineering elegance​

• Resourceful reuse of existing components: The trick reused win.com and the DOS boot path instead of implementing a separate, bespoke fast‑restart code path. That’s elegant — minimal additional code, maximum reuse.
• Real user benefit on slow hardware: On typical 1990s hardware, avoiding BIOS/POST and firmware reinitialization could save a meaningful amount of time for users, improving perceived responsiveness.
• A pragmatic trade‑off: For an era where disk and I/O speeds were modest and user expectations about instant restarts were nascent, trading some reliability for speed in a non‑critical path made sense as an experiment and convenience feature.

---

Risks and why the behavior was retired​

• Fragility: The entire scheme depended on memory remaining contiguous and drivers not touching expected regions. That fragility made the feature unpredictable in real world conditions.
• Data and device integrity: Skipping full device reinitialization could leave devices in inconsistent states or interrupt pending writes — a dangerous prospect as hardware and drivers grew more complex.
• Maintainability: As Windows evolved toward a single, protected kernel model, keeping such a legacy pathway would have imposed maintenance costs without sufficient benefit. The platform’s architecture outgrew the trick.

---

Practical lessons for retrocomputing and modern troubleshooting​

If you’re restoring vintage PCs or running retro builds​

• Keep conventional memory as clean and contiguous as possible: avoid TSRs and prefer protected‑mode drivers where available.
• Accept the trick as a convenience hack — useful for some scenarios but not a supported recovery path.
• Test repeated fast restarts cautiously; some driver bugs only surface during teardown/restart cycles.

For modern users and IT teams​

• Use Shift+Restart to get safely into WinRE and Safe Mode when the system is responsive enough to navigate the UI. It’s the documented method for advanced startup.
• When the shell is frozen, prefer the Emergency Restart behind Ctrl+Alt+Del (hold Ctrl + click Power) as a last resort — it’s faster than a hard power cut and initiated by the OS, but it discards unsaved work. Document and train support staff on its risks.
• For reliability and predictability, favor supported mechanisms (ExitWindowsEx / shutdown.exe / WinRE) over undocumented or brittle shortcuts.

---

Final analysis: elegance tempered by pragmatism​

The Windows 95 fast‑restart trick is a concise case study in software engineering trade‑offs. It exemplifies a classic era of engineering where constraints — slow hardware, fragmented drivers, tight memory budgets — encouraged inventive shortcuts. The result was a neat, user‑facing speed boost that nevertheless buckled under the realities of real world software diversity.
Raymond Chen’s account reconstructs the mechanism and clarifies why it worked when it worked, while contemporary reporting (PC Gamer, The Register) and technical boot‑process documentation align with his explanation. Together these sources demonstrate the trick’s validity, its engineering rationale, and its operational brittleness. Ultimately, the history of Shift+Restart is instructive: good engineering balances ambition and safety. In the Win9x era, speed sometimes won; in the modern NT family, predictability and data integrity are the non‑negotiables. The neat little system that once let enthusiasts avoid a full PC reboot is now a part of computing history — admired for its ingenuity, and understood as a product of its time.

---

Source: PC Gamer The 'secret sauce' behind Windows 95 fast restart trick is something I wish I knew 30 years ago