I know with older machines like 286s, the first 512 bytes loaded from the first sector of the boot drive to 0000:7C00 in memory were run in 16-bit real mode, but what about modern 64-bit architectures?

Edit: I guess this is a wrong question upon thinking about it. The writer of the boot loader is the decider of which mode assembly instructions to use, right? The hardware just does what it's told. Then my question should be, what mode do major OS boot loaders like Windows 7, Mac OS X (the latest) and GRUB on 64-bit machines use?


All current x86-compatible computers (this includes x64 architecture too, both from Intel and AMD, but not Itanium) execute boot sector code in x86 real mode, exactly like the original IBM PC did 20+ years ago. It is not kernel mode, it's the original segmented mode without memory protection, multitasking, or code privilege levels.

If you can get hold of a floppy drive, put MS-DOS (or FreeDOS) on it, and stuck into today's computer, it will start booting.

It is boot code's task to switch into protected mode, set up memory protection etc. So your guess is partially right. The boot loader starts execution as x86 real mode and switches into protected mode, loads and starts actually executing OS Kernel in "kernel" (ring 0) mode.

For more information, you can visit Wikipedia article on Windows NT startup process, which has quite a few details on this subject.

  • haimg, thanks for that link and clarification. @Deshe, sorry to take away best answer.
    – mring
    Oct 10 '11 at 17:11
  • Now's the time to edit this, otherwise you disagree with your own answer :-)
    – Daniel Beck
    Oct 10 '11 at 17:14

what about modern 64-bit architectures?

That depends from the firmware that is on the modern 64-bit machine with the modern 64-bit architecture. haimg's answer would have been the case some five to six years ago for the x86 world, but is out of date for the x86 world today.

Old PC/AT firmwares

Some of those modern 64-bit machines have old PC/AT style firmwares. As noted in other answers, they load and run the bootstrap program from sector #0 of a disc in pretty much the same way as the PC/AT did. This is the old PC/AT bootstrap process.

New EFI firmwares

Other modern 64-bit machines have new EFI firmwares. These don't load a bootstrap program from sector #0 of a disc at all. They bootstrap by the EFI Boot Manager loading and running an EFI boot loader application. Such programs are run in protected mode. This is the EFI bootstrap process.

EFI firmwares in general switch to protected mode within a few instructions of exiting processor reset. Switching to protected mode is done early on in the so-called "SEC Phase" of EFI firmware initialization. Technically, 32-bit and greater x86 processors don't even start in real mode proper, but in what is colloquially known as unreal mode. (The initial segment descriptor for the CS register does not describe the conventional real mode mapping and is what makes this "unreal".)

As such, it could be said that those EFI systems never enter real mode proper at all, when bootstrapping natively to an EFI bootloader (i.e. when they don't employ a compatibility support module), since they switch from unreal mode directly to protected mode and stay in protected mode from then on.

  • The link to the bootstrap process appears to be broken/dead. I cannot find a replacement.
    – slm
    Aug 17 '18 at 13:07
  • This yours? - jdebp.eu/FGA/pcat-boot-process.html
    – slm
    Aug 17 '18 at 13:08
  • 1
    And now I know your name looking at the URLs 8-). Not trying to spy couldn't help notice.
    – slm
    Aug 17 '18 at 13:09
  • I think you moved things from ntlworld, is that correct?
    – slm
    Aug 17 '18 at 13:12
  • Possible replacement URL for 1st - jdebp.eu/FGA/pcat-boot-process.html. My god ppl copy/paste your A'er all over. Even this wikipedia has this A'er quoted - en.wikipedia.org/wiki/Talk%3AReal_mode.
    – slm
    Aug 17 '18 at 13:15

As far as I know, the boot code always runs in Kernel mode.

For one, it's impossible for anything to decide what mode to use as it's ran from the boot sector, simply because it's the first instructions to be executed by the firmware. There is no way for the code to set what instructions are available to it before it starts running. Thus, by design, the assembly set available for the code on the boot sector is predetermined by the architecture.

Had any underprivileged mode were to be chosen for that, it would have been impossible to ever use instructions from higher privileged modes, which pretty much forces the fact that the boot code runs with the most privileged mode available.


Intel manual Volume 3 System Programming Guide 325384-053US January 2015:


The processor is placed in real-address mode following power-up or a reset.

Just for the kicks, a nice diagram from the manual:

enter image description here

GRUB starts multiboot OSes in protected mode. Multiboot specification 0.6.96 Machine state:

'CR0' Bit 0 (PE) must be set.

Not sure about GRUB and x86_64.

  • GRUB starts Multiboot specification compliant OSs in protected mode. That includes the *BSDs, but as far as I know, Linux does not follow this specification and does its own thing. When booting a Multiboot specification compliant OS, GRUB configuration uses the multiboot keyword; for Linux, there are dedicated linux, linux16 and, in UEFI versions of GRUB, linuxefi keywords, telling GRUB to use a Linux-specific boot protocol.
    – telcoM
    Dec 16 '18 at 11:36
  • @telcoM fair enough Dec 16 '18 at 11:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.