MBR and GPT are two different partitioning methods. APM is a third. MBR pre-dates GPT. The UEFI spec defines the GPT, and suggests that LBA 0 (the first sector of a drive) contain a protective MBR, which is an MBR with a single partition entry, type 0xEE, covering all sectors from LBA 1 (the start of the GPT) to the (second to) last LBA. The UEFI spec also distinguishes between such a protective MBR and a legacy MBR which is one that doesn't contain an 0xEE entry.
The GPT of such a disk contains three entries: EFI, Mac OS, Recovery HD. Before Bootcamp, the MBR contains one 0xEE entry for the whole disk. After Bootcamp, the MBR contains entries in all four locations: an adjusted 0xEE for blocks that contain the primary GPT itself, and EFI partition; an entry 0xAF for Mac OS, an entry 0xAB for Recovery HD, and entry 0x07 for Windows.
It's much easier to visualize this if you use GPT fdisk, from Source Forge, also knowns as gdisk to view the actual GPT entries. And the included fdisk from Apple to view the MBR.
The original reference is misleading in that you don't really have two independent partition tables, by default. You have just one, GPT. Which comes with a recommended protective MBR, which is an MBR that has a single protective entry, type code 0xEE, spanning the whole disk. This is just to protect the primary GPT and the contents of the disk from legacy OS's and apps that don't know what GPT is. That's it. It's not an independent partition table.
Disk Utility doesn't have a way for you to add any partitions to a disk, you have to re-partition from scratch. When you do this, that disk gets a whole new GPT with however many partitions you define (plus a hidden EFI System partition), and a protective MBR with a *SINGLE* 0xEE entry.
In the case of Boot Camp, first it resizes an existing JHFS+/X volume, adjust the entry in the GPT, creates a new GPT entry for the freed up space (for Windows), formats it FAT32, and then creates a hybrid MBR which contains a resized 0xEE entry for just the blocks containing the primary GPT and EFI System partitions. And separate entries for Mac OS, Recovery HD, and Windows.
If you were to use command line tools to resize that JHFS+ partition yet again, you'd have one messed up disk because it will not update the hybrid MBR. Just the GPT.
Here is a good time to point out that hybrid MBRs are flakey, dangerous, non-standard, and depart from the UEFI spec considerably. They even depart from Apple's own technote on this, yet they use them. I'm not a fan, but this is consequence of not having UEFI 2.x firmware on Apple hardware, which is the minimum required for a Windows 7 x86_64 UEFI installation, instead of a BIOS based installation. Windows BIOS installs only use MBR for boot disks. And Windows UEFI installs only use GPT for boot disks. Since we don't have UEFI 2.x firmware, but Apple and Intel did include a CSM-BIOS with most Apple hardware - we're in this hybrid MBR business.
Not really. That protective MBR is just a place holder to protect the data on the disk from legacy MBR only tools and operating systems that do not understand GPT.
It's confusing, I admit it. A protective MBR as defined in the UEFI spec is an MBR that contains a single protective 0xEE partition entry. That's it.
A hybrid MBR is not defined anywhere. It is an MBR that contains one protective 0xEE entry: it is protecting the blocks for the primary GPT and the EFI System partition; and it contains one or more additional entries.
Further, there is NO requirement that the MBR entries at all match up with GPT entries. In order for me to triple boot Apple hardware, I generate my own hybrid MBR using gdisk. I have a GPT with 8 entries, depending on which OS's are installed and how they're configured. I will generally make Windows the very last GPT entry. The MBR 1st partition is defined for the blocks making up *all* of the GPT first 7 partitions, with type code 0xEE, and the MBR 2nd partition defines the blocks identical to the GPT's 8th partition entry for Windows. So in the MBR, I'm only exposing the Windows blocks. I mark that bootable, because that's what Apple's EFI implementation needs to activate the CSM-BIOS to find and run the bootloader code in the first 440 bytes of the MBR.
It all gets VERY confusing because different hardware treats hybrid (non-standard!) MBRs differently.
Umm, definitely not. As soon as the 0xEE entry is missing from an MBR, it is no longer a protective or hybrid MBR. It is a valid legacy MBR and the UEFI spec language fully supports treating such a disk entirely an only as an MBR disk, and the GPT is to be ignored.
And think of the reason why. When you use a legacy tool for partitioning a disk, like fdisk, that has no idea what a GPT is, what's it going to modify? Only LBA 0. It will only alter the MBR. It has no way of blanking out the primary or backup GPT, which means they will be left intact.
The only way to resolve this ambiguity fairly is to treat a disk that has a valid legacy MBR (no 0xEE entry) as strictly MBR.
Remember, the 0xEE entry starts at LBA 1. LBA 1 is the primary GPT header, and subsequent sectors contain the GPT entries themselves. If they are not protected by an MBR partition entry of 0xEE, then those sectors are NOT allocated as far as MBR aware applications/systems are and are fair game for being overwritten.