The short version
- After power-up or reset, x86 processors begin in real-address mode. That is the 8086-style environment. Intel's manual describes real-address mode as the programming environment of the 8086 with extensions, and says the processor is placed in it following power-up or a reset.
- Firmware, not Windows, does the early heavy lifting. Firmware is code the CPU executes from its reset location, and it prepares the machine before any operating-system loader runs.
- By the time a 64-bit UEFI loader such as the Windows boot manager takes over, the firmware environment is already 64-bit. Windows doesn't relive 45 years of history on its own.
- This is a compatibility story, not a performance penalty. Modes are states of one processor, not separate chips or "generations" inside the CPU.
Stop one: 1978, real mode and the 8086
Real-address mode, or "real mode," gives you the programming environment of the Intel 8086, with a few extensions such as the ability to switch to protected or system management mode. Intel's own history of the chip says it introduced the 8086 microprocessor in 1978, and that its architecture served as the template on which future chips would be built.
The How-To Geek piece describes the original 8086 as having 16-bit registers and a 20-bit address space, good for 1MB. That matches the broader technical record: the related 8088 used in the original IBM PC had 20 address lines and could directly address 1 MiB.
The reset location is part of this legacy. On the classic 8086, the reset vector is at physical address FFFF0h, 16 bytes below 1 MB. Modern chips use a different physical address, but the principle is the same: the CPU begins fetching instructions from a fixed spot, and firmware lives there.
One nuance from a firmware-engineering paper, "Booting an Intel System Architecture": the first power-on state is actually a special subset of real mode, with the top 12 address lines held high so the processor can run code from non-volatile storage. So "starts as an 8086" is a useful shorthand, not a literal claim of identical behavior.
Stop two: 1982 and 1985, protected mode
The explainer gets the protected-mode chronology right. Protected mode debuted with the 80286 in 1982, and it was still a 16-bit design. The 80386 in 1985 brought the 32-bit x86 era and paging for virtual memory. Intel's manual describes protected mode as the native state of the processor, which is the conceptual flip side of real mode being the "compatibility" starting point.
Be careful with one common over-reading. Protected mode provides the mechanisms for memory protection and multitasking. It doesn't by itself deliver isolation. The operating system has to build and enforce it. Passing through protected mode during boot does not mean your PC enjoys process isolation at that moment.
Intel's documentation also describes the practical sequence on the software side. Software initiates the switch from real-address mode to protected mode, and if IA-32e mode is wanted, software then initiates a switch from protected mode to IA-32e mode. That is the origin of the "real, then protected, then long" narrative.
Stop three: 2003, AMD64 and long mode
The 64-bit story is where AMD takes the spotlight. AMD's 2004 annual report says it introduced Opteron in April 2003 and Athlon 64 in September 2003. AMD's filing also states that these chips were designed for both 32-bit and 64-bit processing, letting users keep 32-bit software while adopting 64-bit applications on their own schedule. The filing describes AMD64 as extending the industry-standard x86 instruction set architecture to 64-bit computing.
For Windows users, the filing contains a nice footnote. AMD said it had announced a collaboration with Microsoft in April 2002 to bring 64-bit support into Windows, with Microsoft indicating a 64-bit Windows XP release in 2004. That is the lineage behind today's 64-bit Windows 11 on x64 hardware.
Long mode (Intel calls it IA-32e) contains two flavors. It adds 64-bit general-purpose registers, extra registers and a flat 64-bit linear address space, and its compatibility submode uses the same segmentation as 32-bit protected mode so older 32-bit programs can still run. Intel followed AMD with a compatible extension, which is how we got the x86-64 chips everyone buys now.
Where UEFI fits in
UEFI is often misunderstood as "the thing that replaced real mode." It didn't. UEFI is a firmware interface specification, not a processor reset behavior. The CPU still wakes up in its architectural reset state, and firmware (including UEFI implementations) has to get it to the right environment.
The UEFI specification is explicit about the environments it expects. Boot Services define an environment where paging is not enabled for 32-bit, or where translations are enabled but virtual equals physical on x64. It also notes that an application may alter the processor execution mode, but must ensure firmware boot and runtime services run in the prescribed environment.
The handoff is also formally defined. A UEFI OS loader takes control of the system from firmware, and after it successfully calls ExitBootServices(), boot services are terminated and the loader is responsible for the continued operation of the system. That is the moment Windows' boot code truly owns the machine.
Interestingly, UEFI also documents the legacy it was meant to leave behind. Legacy option ROMs typically contain 16-bit real mode code, and real mode only lets a driver directly access the lower 1 MiB of memory. That is one reason UEFI drivers were designed differently.
The real-world footprint of real mode
A recent summary on daily.dev, which I'd treat as secondary reading rather than primary documentation, claims EDK2's UEFI reset vector still begins execution before switching to 32-bit protected mode and then 64-bit long mode, and that Linux and Windows still ship 16-bit trampoline code to start additional cores. The same piece notes Intel proposed X86S in 2023 to eliminate legacy modes including real mode. I couldn't verify those specifics against primary documentation here, so treat them as informed context, not settled fact. If you're curious, firmware developers' tooling and open-source firmware code are where you'd confirm them.
What can be said confidently: the reset behavior is a compatibility choice with deep roots. The firmware paper above puts it bluntly that the processor continues to boot in real mode today, for no particular technical requirement. That is the honest framing: not a hard physical limit, but an ecosystem inertia story.
Corrections and caveats to the popular telling
- It's x86-64, not "x84-64." The original has a typo.
- The three-stop trip isn't a guaranteed, identical sequence. Real mode is the reset state, but the amount of work in each mode varies by processor, firmware implementation and boot configuration.
- Windows doesn't make the whole journey itself. Firmware sets the stage, and the OS loader inherits a 64-bit environment on a typical 64-bit UEFI PC.
- "Stuck in the past" overstates it. Your CPU isn't running at 1978 speeds. It briefly adopts an old programming model, then moves on.
- Socket changes are a separate matter. Platform upgrades that drop motherboard compatibility sit at a different layer from instruction-set mode compatibility.
- This applies to x86 and x86-64. Other architectures, such as RISC-V, have their own reset conventions. The UEFI spec notes RISC-V's initial privilege mode at power-on reset is Machine mode.
Why Windows admins and enthusiasts should care
Knowing the boot-mode lineage helps in a few concrete ways:
- Troubleshooting firmware issues: Understanding that firmware, not the OS, initializes the CPU explains why a machine can fail before Windows ever loads, and why a BIOS/UEFI update can fix very early hangs.
- Legacy versus UEFI boot: Legacy BIOS-style boot and its option ROMs lean on real-mode code. UEFI boot with a 64-bit loader avoids much of that.
- Virtualization and low-level tooling: Hypervisors, bootloaders and kernel developers deal with these mode transitions explicitly.
- Long-term platform thinking: If vendors ever drop legacy modes, as Intel's X86S proposal suggested, it will matter most for firmware, bootloader and old-OS compatibility, not for everyday apps.
Bottom line
The viral framing is catchy, and its core is right: an x86-64 CPU starts in the 8086-era real mode, and firmware moves it through the architecture's later modes before a 64-bit UEFI loader hands off to Windows. The nuance is in what "passes through" means. It's a compatibility handshake with history, not a slow trek that every boot repeats in full. Nearly five decades of software compatibility are preserved by a very small amount of ancient startup behavior, and that is arguably one of the better trade-offs in computing history.