I also recommend the Starman for good documentation over the decades. Basically you're supposed to know BIOS/MBR booting quite well in order to make the best p

I also recommend the Starman for good documentation over the decades. Basically you're supposed to know BIOS/MBR booting quite well in order to make the best progress on UEFI/GPT. Originally upon powerup the BIOS would run from ROM and then boot control to a program known as the Master Boot Record which would reside on the first 440 bytes of sector 0 of the HDD. The partition table took up the final bytes of sector 0. The MBR checked which of the 4 possible primary partitions was flagged as active, and then booted control to the Volume Boot Record (Boot Sector) residing at the first sector of that particular partition which would then (usually, but specifically according to BOOT.INI on Windows [BCD today] or GRUB configs for Linux) load the OS contained within that partition. Usually by reading files from the filesystem beyond that point, but capable of being chained directly to other executable sectors. Starman can be a very good resource on underlying structures: https://thestarman.pcministry.com/asm/mbr/ https://thestarman.pcministry.com/asm/mbr/ He's got lots more pages like this, and references too. Now, straight to modern UEFI: The MBR code itself is best not there on sector 0, just an imitation partition table in the final few bytes still exists which is considered "protective" and keeps BIOS PC's from recognizing the HDD since they can not handle partitions layed out by the GPT regime. Sector 1 designates GPT drive parameters, and sector 2 begins the defining data for each partition, which by default extends to sector 33 so you have room to define many more than 4 partitions, and any of them can be booted to from a single EFI folder on a hidden ESP partition, depending mainly on the config files in the EFI folder. There are backups of these defining sectors (not the EFI folder itself) in the final area of the HDD. In the ESP partition which is often expected by MB UEFI to carry a specific ESP GUID (but often works just fine after changing to a "regular" GUID so you can unhide it for maintenance), the UEFI expects to find it formatted as FAT32, and there behold a recognizable EFI/BOOT folder containing the elusive BOOTX64.EFI file. That's the only thing normally found in the EFI/BOOT folder except for systems having bootability by the rare remaining 32-bit UEFI firmwares, then you might see BOOTIA32.EFI. Lots of times it will do just fine having an EFI folder on an NTFS partition too. UEFI 64-bit firmware just runs whatever file is currently named BOOTX64.EFI in the BOOT folder. Or falls back to secondary alternatives if not present. When you install an OS like Windows it adds an EFI/MICROSOFT folder, but each time you add a different version of Windows to a different partition, you do not add additional Microsoft folders to EFI, instead you add additional boot entries to the default boot menu already present in the Microsoft BCD file there. The OS installation procedure overwrites the existing BOOTX64.EFI file with one directing the boot process to continue from the Microsoft folder after that point, according to the NT6 boot menu you have in place at the time. Installing Linux creates an EFI/ubuntu folder for example, containing most necessary GRUB elements, while overwriting BOOTX64.EFI to direct the boot process to the ubuntu folder and use the GRUB bootmenu accessible from there. Each distinct distro will add its own folder like EFI/debian/, EFI/fedora, with the most recently added claiming the most coveted BOOTX64.EFI prize. Ideally, you install all the Windows versions you want into their designated NTFS volumes, which naturally builds up your NT6 bootmenu as you go. You will best do some BCDEDITing as you go just to keep the Descriptions in the bootmenu straight as to which entry goes to which Windows version on which partition. Ideally again, your final Linux install will be a distro that automatically detects all other Linux installations residing on their EXT-formatted partitions, while also correctly detecting & adding a bootentry for Windows, so GRUB can take you to your already-established NT6 bootmenu when you want. In the EFI/Microsoft folder you will find an os-specific file in EFI/Microsoft/BOOT named BOOTMGFW.EFI. Not to be confused with the basic EFI/BOOT/BOOTX64.EFI. These are EFI executables, either one will boot the PC from UEFI directly if you drop down to the UEFI Shell preboot using your MainBoard tools. Navigate to fsx:EFI/Microsoft/BOOT and run bootmgfw.efi to boot Windows (even without an EFI/BOOT folder present), or navigate to the main EFI/BOOT folder and run the latest BOOTX64.EFI that your final OS install has overwritten for you accordingly. Where "fsx:" is the filesystem which contains the EFI folder as detected by the UEFI firmware, often fs0. You can even find grubx64.efi files for Linux. Not only OS installs, but things like GRUB updates and BCDBOOT commands can overwrite BOOTX64.EFI. Finally, once different OS's are properly installed in a traditional self-contained way on each of their own partitions, you should be able to craft any number of alternative EFI folders or contents such that any or all of the OS choices are presented to you on a bootmenu upon powerup, booting to your established choice of default (or fallback) in case of unattended powerup. GRUB can still boot Windows but Windows NT6 bootloader can no longer boot Linux when using GPT. But you can even still make a boot floppy you can use to load OS's present on the HDD without having any boot files on the HDD at all. UEFI can also sometimes do well when it finds a good recognizable EFI folder on an MBR-layout HDD.