Even though RequestBootVarRouting fixed most of OS switching issues in macOS Startup Disk preference pane due to UEFI incompatibilities, multiple issues still remain when Windows is involved. Below I list the subissues that we may want to handle.

• Windows UEFI detection does not work in macOS
• Shortened device paths are not supported by OpenCore
• Incompatible BootCamp installations are not warned in docs
• Missing CSM bit in FirmwareFeatures makes incompatible BootCamp installations unusable in macOS preference pane. Should set it in MacInfoPkg as a hack.

We may also want to potentially investigate why Boot Camp installation does not automatic disk partition and direct installation, like it does on recent Macs by creating OSXRESERVED partition, and requires USB installation. This is most likely a separate enhancement.

1. Windows UEFI detection does not work in macOS

The cause of this issue is that the normal windows disk is partitioned with 4 partitions: Windows Recovery, EFI, Reserved, Main data:

The sequence to detect Windows is done based on FirmwareFeatures UEFI support, then given ntdll presence in system32, case insensitive file system, and finally EFI partition Microsoft bootloader presence (BOOTX64.EFI and BOOTMGR.EFI).

The issue happens in /usr/libexec/diskmanagementd in macOS, which implementation
in -[DMToolBootPreference checkESPFileContentForWholeDisk:containsUEFIBootFiles:], assumes that EFI partition is the first partition on the disk, ignoring its type and layout. This seems to be an Apple bug, as UEFI 2.8 13.3.1.3 Directory Structure does not require EFI System Partition to be the first partition on the disk. I believe we should file a radar on it.

Since macOS assumes legacy Windows for UEFI Windows, which can still live with if we try. As a temporary solution we should handle it from the fixed boot entry and BootCampHD variable:

01:554 00:002 OCB: 0 -> Boot0080 = MemoryMapped(0xB,0xFFE00000,0xFFF9FFFF)/FvFile(2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7)

BootCampHD: <02010c00 d041030a 00000000 01010600 00170312 0a000200 00000000 7fff0400>

The latter provides disk drive path, which we can use to later force boot from EFI System Partition on it. Support for legacy (MBR) Windows booting does not make any sense to me, but may be contributed in theory, as regardless of the method the disk may be identified as GPT or MBR.

2. Shortened device paths are not supported by OpenCore

At least Windows Boot Camp preference pane stores UEFI Boot entries in shortened format, which looks as follows:

# macOS entry created by Boot Camp Windows pane:
# partition 2 points to APFS container partition
# UUID identifies disk itself
01:523 00:002 OCB: 0 -> Boot0080 = HD(2,GPT,C9DF436D-3F5C-4CC4-8CA0-23F5A4FA4B22,0x0,0x0)
# Windows entry created by Boot Camp Windows pane:
# partition 1 points to Windows Recovery
# UUID identifies disk itself
01:556 00:002 OCB: 0 -> Boot0080 = HD(1,GPT,8877D421-77FC-4C33-A280-6A86ED732483,0x0,0x0)

Which implies we have additional issues with short entries:

• Windows entry always points to first partition, which may not actually be EFI System partition. The radar on (1) if created should mention this.
• macOS entry always points to container, which means at most one macOS installation can be pointed within the container.

As a temporary solution we can add a hack to assume that:

• 1st partition ID, when it is not EFI System Partition, implies any EFI System Partition on the disk
• Not 1st partition ID (as it must be EFI on all Mac installations) pointing to APFS container must prefix first non-recovery boot entry.

3. We should leave a warning in the docs that installing Boot Camp with standard Windows layout,
   i.e. when EFI is not the first partition, is not a supported option regardless of the quirks we have.

Relevant logs and data: BootSwitch.7z.zip