The MBR originated in the
PC XT.
IBM PC-compatible computers are
little-endian, which means the
processor stores numeric values spanning two or more bytes in memory
least significant byte first. The format of the MBR on media reflects this convention. Thus, the MBR signature will appear in a
disk editor as the sequence 55 AA. The bootstrap sequence in the BIOS will load the first valid MBR that it finds into the computer's
physical memory at
address to . The last instruction executed in the BIOS code will be a "jump" to that address in order to direct execution to the beginning of the MBR copy. The primary validation for most BIOSes is the signature at offset , although a BIOS implementer may choose to include other checks, such as verifying that the MBR contains a valid partition table without entries referring to sectors beyond the reported capacity of the disk. To the BIOS, removable (e.g. floppy) and fixed disks are essentially the same. For either, the BIOS reads the first physical sector of the media into RAM at absolute address , checks the signature in the last two bytes of the loaded sector, and then, if the correct signature is found, transfers control to the first byte of the sector with a jump (JMP) instruction. The only real distinction that the BIOS makes is that (by default, or if the boot order is not configurable) it attempts to boot from the first removable disk before trying to boot from the first fixed disk. From the perspective of the BIOS, the action of the MBR loading a volume boot record into RAM is exactly the same as the action of a floppy disk volume boot record loading the object code of an operating system loader into RAM. In either case, the program that the BIOS loaded is going about the work of chain loading an operating system. While the MBR
boot sector code expects to be loaded at physical address :, all the memory from physical address : (address : is the last one used by a Phoenix BIOS) to :, later relaxed to : (and sometimes up to :)the end of the first 640 KBis available in real modeKB minus the first 1281 bytes of memory)-->. The INT 12h
BIOS interrupt call may help in determining how much memory can be allocated safely (by default, it simply reads the base memory size in KB from
segment:offset location :, but it may be hooked by other resident pre-boot software like BIOS overlays,
RPL code or viruses to reduce the reported amount of available memory in order to keep other boot stage software like boot sectors from overwriting them). The last 66 bytes of the 512-byte MBR are reserved for the partition table and other information, so the MBR boot sector program must be small enough to fit within 446 bytes of memory or less. The MBR code examines the partition table, selects a suitable partition and loads the program that will perform the next stage of the boot process, usually by making use of INT 13h
BIOS calls. The MBR bootstrap code loads and runs (a boot loader- or operating system-dependent)
volume boot record code that is located at the beginning of the "active" partition. The volume boot record will fit within a 512-byte sector, but it is safe for the MBR code to load additional sectors to accommodate boot loaders longer than one sector, provided they do not make any assumptions on what the sector size is. In fact, at least 1 KB of RAM is available at address in every IBM XT- and AT-class machine, so a 1 KB sector could be used with no problem. Like the MBR, a volume boot record normally expects to be loaded at address :. This derives from the fact that the volume boot record design originated on unpartitioned media, where a volume boot record would be directly loaded by the BIOS boot procedure; as mentioned above, the BIOS treats MBRs and volume boot records (VBRs) exactly alike. Since this is the same location where the MBR is loaded, one of the first tasks of an MBR is to
relocate itself somewhere else in memory. The relocation address is determined by the MBR, but it is most often : (for MS-DOS/PC DOS, OS/2 and Windows MBR code) or : (most DR-DOS MBRs). (Even though both of these segmented addresses resolve to the same physical memory address in real mode, for
Apple Darwin to boot, the MBR must be relocated to : instead of :, since the code depends on the DS:SI pointer to the partition entry provided by the MBR, but it erroneously refers to it via :SI only.) It is important not to relocate to other addresses in memory because many
VBRs will assume a certain standard memory layout when loading their boot file. The
Status field in a partition table record is used to indicate an active partition. Standard-conformant MBRs will allow only one partition marked active and use this as part of a sanity-check to determine the existence of a valid partition table. They will display an error message, if more than one partition has been marked active. Some non-standard MBRs will not treat this as an error condition and just use the first marked partition in the row. Traditionally, values other than (not active) and (active) were invalid and the bootstrap program would display an error message upon encountering them. However, the
Plug and Play BIOS Specification and
BIOS Boot Specification (BBS) allowed other devices to become bootable as well since 1994. Consequently, with the introduction of MS-DOS 7.10 (Windows 95B) and higher, the MBR started to treat a set bit 7 as active flag and showed an error message for values .. only. It continued to treat the entry as physical drive unit to be used when loading the corresponding partition's VBR later on, thereby now also accepting other boot drives than as valid, however, MS-DOS did not make use of this extension by itself. Storing the actual physical drive number in the partition table does not normally cause backward compatibility problems, since the value will differ from
only on drives other than the first one (which have not been bootable before, anyway). However, even with systems enabled to boot off other drives, the extension may still not work universally, for example, after the BIOS assignment of physical drives has changed when drives are removed, added or swapped. Therefore, per the
BIOS Boot Specification (BBS), it is best practice for a modern MBR accepting bit 7 as active flag to pass on the DL value originally provided by the BIOS instead of using the entry in the partition table.
BIOS to MBR interface The MBR is loaded at memory location : and with the following
CPU registers set up when the prior bootstrap loader (normally the
IPL in the BIOS) passes execution to it by jumping to : in the CPU's
real mode. •
CS:
IP = : (fixed) : Some Compaq BIOSes erroneously use : instead. While this resolves to the same location in real mode memory, it is non-standard and should be avoided, since MBR code assuming certain register values or not written to be relocatable may not work otherwise. •
DL = boot drive unit (
fixed disks /
removable drives: = first, = second, ..., ;
floppies /
superfloppies: = first, = second, ..., ; values and are reserved for ROM / remote drives and must not be used on disk). : DL is supported by IBM BIOSes as well as most other BIOSes. The Toshiba T1000 BIOS is known not to support this properly, and some old Wyse 286 BIOSes use DL values greater or equal to 2 for fixed disks (thereby reflecting the logical drive numbers under DOS rather than the physical drive numbers of the BIOS). USB sticks configured as removable drives typically get an assignment of DL = , , etc. However, some rare BIOSes erroneously presented them under DL = , just as if they were configured as superfloppies. : A standard conformant BIOS assigns numbers greater or equal to exclusively to fixed disk / removable drives, and traditionally only values and were passed on as physical drive units during boot. By convention, only fixed disks / removable drives are partitioned, therefore, the only DL value a MBR could see traditionally was . Many MBRs were written to ignore the DL value and work with a hard-wired value (normally ), anyway. : The
Plug and Play BIOS Specification and
BIOS Boot Specification (BBS) allow other devices to become bootable as well since 1994. The later recommends that MBR and VBR code should use DL rather than internally hardwired defaults. This will also ensure compatibility with various non-standard assignments (see examples above), as far as the MBR code is concerned. : Bootable CD-ROMs following the
El Torito specification may contain disk images mounted by the BIOS to occur as floppy or superfloppies on this interface. DL values of and may also be used by
Protected Area Run Time Interface Extension Services (PARTIES) and
Trusted Computing Group (TCG) BIOS extensions in Trusted mode to access otherwise invisible PARTIES partitions, disk image files located via the
Boot Engineering Extension Record (BEER) in the last physical sector of a hard disk's
Host Protected Area (HPA). While designed to emulate floppies or superfloppies, MBR code accepting these non-standard DL values allows to use images of partitioned media at least in the boot stage of operating systems. •
DH bit 5 = 0: device supported through
INT 13h; else: don't care (should be zero). DH is supported by some IBM BIOSes. • Some of the other registers may typically also hold certain register values (DS, ES, SS = ; SP = ) with original IBM ROM BIOSes, but this is nothing to rely on, as other BIOSes may use other values. For this reason, MBR code by IBM, Microsoft, Digital Research, etc. never did take any advantage of it. Relying on these register values in boot sectors may also cause problems in chain-boot scenarios. Systems with
Plug-and-Play BIOS or BBS support will provide a pointer to PnP data in addition to DL: • DL = boot drive unit (see above) •
ES:
DI = points to "$PnP" installation check structure : This information allows the boot loader in the MBR (or VBR, if passed on) to actively interact with the BIOS or a resident PnP / BBS BIOS overlay in memory in order to configure the boot order, etc., however, this information is ignored by most standard MBRs and VBRs. Ideally, ES:DI is passed on to the VBR for later use by the loaded operating system, but PnP-enabled operating systems typically also have fallback methods to retrieve the PnP BIOS entry point later on so that most operating systems do not rely on this.
MBR to VBR interface By convention, a standard conformant MBR passes execution to a successfully loaded VBR, loaded at memory location :, by jumping to : in the CPU's real mode with the following registers maintained or specifically set up: • CS:IP = : (constant) • DL = boot drive unit (see above) : MS-DOS 2.0–7.0 / PC DOS 2.0–6.3 MBRs do not pass on the DL value received on entry, but they rather use the boot status entry in the partition table entry of the selected primary partition as physical boot drive unit. Since this is, by convention, in most MBR partition tables, it won't change things unless the BIOS attempted to boot off a physical device other than the first fixed disk / removable drive in the row. This is also the reason why these operating systems cannot boot off a second hard disk, etc. Some FDISK tools allow to mark partitions on secondary disks as "active" as well. In this situation, knowing that these operating systems cannot boot off other drives anyway, some of them continue to use the traditionally fixed value of as active marker, whereas others use values corresponding with the currently assigned physical drive unit (, ), thereby allowing booting from other drives, at least in theory. In fact, this will work with many MBR codes, which take a set bit 7 of the boot status entry as active flag rather than insisting on , however, MS-DOS/PC DOS MBRs are hard-wired to accept the fixed value of only. Storing the actual physical drive number in the partition table will also cause problems, when the BIOS assignment of physical drives changes, for example when drives are removed, added or swapped. Therefore, for a normal MBR accepting bit 7 as active flag and otherwise just using and passing on to the VBR the DL value originally provided by the BIOS allows for maximum flexibility. MS-DOS 7.1–8.0 MBRs have changed to treat bit 7 as active flag and any values .. as invalid, but they still take the physical drive unit from the partition table rather than using the DL value provided by the BIOS. DR-DOS 7.07 extended MBRs treat bit 7 as active flag and use and pass on the BIOS DL value by default (including non-standard values .. used by some BIOSes also for partitioned media), but they also provide a special
NEWLDR configuration block in order to support alternative boot methods in conjunction with LOADER and REAL/32 as well as to change the detail behaviour of the MBR, so that it can also work with drive values retrieved from the partition table (important in conjunction with LOADER and AAPs, see NEWLDR offset
0x000C), translate Wyse non-standard drive units .. to .., and optionally fix up the drive value (stored at offset
0x019 in the
Extended BIOS Parameter Block (EBPB) or at sector offset
0x01FD) in loaded VBRs before passing execution to them (see NEWLDR offset
0x0014)—this also allows other boot loaders to use NEWLDR as a chain-loader, configure its in-memory image on the fly and "tunnel" the loading of VBRs, EBRs, or AAPs through NEWLDR. • The contents of DH and ES:DI should be preserved by the MBR for full Plug-and-Play support (see above), however, many MBRs, including those of MS-DOS 2.0–8.0 / PC DOS 2.0–6.3 and Windows NT/2000/XP, do not. (This is unsurprising, since those versions of DOS predate the Plug-and-Play BIOS standard, and previous standards and conventions indicated no requirements to preserve any register other than DL.) Some MBRs set DH to 0. The MBR code passes additional information to the VBR in many implementations: • DS:SI = points to the 16-byte
MBR partition table entry (in the relocated MBR) corresponding with the activated VBR.
PC-MOS 5.1 depends on this to boot if no partition in the partition table is flagged as bootable. In conjunction with LOADER,
Multiuser DOS and
REAL/32 boot sectors use this to locate the boot sector of the active partition (or another bootstrap loader like IBMBIO.LDR at a fixed position on disk) if the boot file (LOADER.SYS) could not be found.
PTS-DOS 6.6 and
S/DOS 1.0 use this in conjunction with their
Advanced Active Partition (AAP) feature. In addition to support for LOADER and AAPs, DR-DOS 7.07 can use this to determine the necessary INT 13h access method when using its dual CHS/LBA VBR code and it will update the boot drive / status flag field in the partition entry according to the effectively used DL value.
Darwin bootloaders (Apple's boot1h, boot1u, and David Elliott's boot1fat32) depend on this pointer as well, but additionally they don't use DS, but assume it to be set to instead. This will cause problems if this assumption is incorrect. The MBR code of OS/2, MS-DOS 2.0 to 8.0, PC DOS 2.0 to 7.10 and Windows NT/2000/XP provides this same interface as well, although these systems do not use it. The Windows Vista/7 MBRs no longer provide this DS:SI pointer. While some extensions only depend on the 16-byte partition table entry itself, other extensions may require the whole 4 (or 5 entry) partition table to be present as well. • DS:
BP = optionally points to the 16-byte
MBR partition table entry (in the relocated MBR) corresponding with the activated VBR. This is identical to the pointer provided by DS:SI (see above) and is provided by MS-DOS 2.0–8.0, PC DOS 2.0–7.10, Windows NT/2000/XP/Vista/7 MBRs. It is, however, not supported by most third-party MBRs. Under DR-DOS 7.07 an extended interface may be optionally provided by the extended MBR and in conjunction with LOADER: •
AX = magic signature indicating the presence of this NEWLDR extension () • DL = boot drive unit (see above) • DS:SI = points to the 16-byte
MBR partition table entry used (see above) • ES:
BX = start of boot sector or NEWLDR sector image (typically ) •
CX = reserved In conjunction with GPT, an
Enhanced Disk Drive Specification (EDD) 4
Hybrid MBR proposal recommends another extension to the interface: •
EAX = ("!GPT") • DL = boot drive unit (see above) • DS:SI = points to a Hybrid MBR handover structure, consisting of a 16-byte dummy
MBR partition table entry (with all bits set except for the boot flag at offset and the
partition type at offset ) followed by additional data. This is partially compatible with the older DS:SI extension discussed above, if only the 16-byte partition entry, not the whole partition table is required by these older extensions. : Since older operating systems (including their VBRs) do not support this extension nor are they able to address sectors beyond the 2 TiB barrier, a GPT-enabled hybrid boot loader should still emulate the 16-byte dummy MBR partition table entry if the boot partition is located within the first 2 TiB. • ES:DI = points to "$PnP" installation check structure (see above) == Editing and replacing contents ==