我读过很多关于在 Mac 电脑上安装和启动 Windows 的帖子。许多程序使用 rEFInd 来启动 Windows 的 BIOS 安装。这些程序似乎没有表明 MBR 中安装了任何代码。因此，要么假设 MBR 中已经有来自先前安装的代码，要么 rEFInd 不需要这样的代码来启动 Windows。有人知道答案吗？
答案1
如果 MBR 尚未启动，并且分区中存在适当的启动代码，则 rEFIt 和 rEFInd 都会将 SYSLINUX MBR 启动代码的副本放入 MBR 中。也就是说，启动代码应该存在于 MBR 中，但它可能会被分区工具破坏，因为分区工具认为 GPT 磁盘上的 MBR 的前 440 个字节应该被清零，就像 EFI 可引导的 GPT 磁盘通常的情况一样。
不过，这又引出了另一点：Windows 8（可能还有 Windows 10）在许多 Mac 上以 EFI 模式安装效果很好。以这种方式安装时，不需要 BIOS 模式启动代码，无论是在 MBR 中还是在 Windows 分区中。EFI 模式安装可能更安全，因为不需要 Mac 用于双启动 OS X 和早期版本的 Windows 的危险混合 MBR。这种安装类型的陷阱是，如果您尝试为 Windows 准备磁盘（例如，通过设置 FAT 分区），磁盘实用程序和其他一些 OS X 工具将创建混合 MBR。当以 EFI 模式启动的 Windows 安装程序看到混合 MBR 时，它会抱怨它无法安装到 MBR 磁盘。您可以使用任意数量的工具（例如gdisk：输入x，然后n，然后w），但如果您不了解问题的本质或如何修复它，这可能会令人沮丧和困惑。
答案2
当使用 CSM 时，一种选择是像 BIOS 一样加载 MBR 引导代码。
逻辑：为了兼容，CSM 必须完全像 BIOS 一样运行。操作系统会将其所需的启动代码放入 MBR和分区引导扇区。
但这是针对基于 CSM 的启动而言的。请记住，rEFInd 本身是一个 EFI 启动选项。因此，rEFInd 将由 (U)EFI 作为标准二进制 EFI 可执行文件（PE 32 位或 64 位，取决于 EFI）加载，就像任何 EFI 操作系统的加载程序一样。当显示 rEFInd 菜单时，尚未加载任何 CSM。由于 rEFInd 是作为 EFI 可执行文件启动的，因此不需要 CSM。
以 EFI 启动的 rEFInd 为起点，rEFInd 本身将继续寻找可启动选项，即分区、其他 EFI 加载程序或内核。对于基于 BIOS 的操作系统，rEFInd 将通过检查 MBR（混合）分区是否具有来自基于 BIOS 的操作系统的启动代码来确定选项是否完全可启动，就像 CSM 一样。如果该分区丢失或损坏，操作系统将无法启动。（原因可能是将操作系统安装到 MBR 分区时出现问题。）
所以最简洁的答案是不。仅在启动时磁盘（不是分区！）从 CSM 开始，MBR 引导代码将被加载。作为 EFI 引导加载程序启动的 rEFInd 不需要甚至无法启动 MBR。
假设 rEFInd 会启动 MBR（为此我们假设它也可以让 UEFI 加载 CSM）：如果启动代码和/或分区存在缺陷（例如没有设置分区为积极的）或者如果选定的启动选项（通过 rEFInd）不是在 MBR 分区表中标记为活动分区的选项，则 MBR 启动代码将不会加载选定的分区，从而导致 rEFInd 启动选择菜单的整个目的无效。
从rEFInd 启动管理器：使用 EFI 驱动程序， 部分选择 EFI 驱动程序：
NTFS — Samuel Liao 贡献了此驱动程序，它使用 rEFIt/rEFInd 驱动程序框架。请注意，此驱动程序不是使用 rEFInd 启动 Windows 所必需的，因为 Windows 将其 EFI 引导加载程序存储在 (FAT) ESP 上，BIOS 启动过程（通常在 Mac 上双启动时使用）仅依赖于分区的引导扇区，无需借助该驱动程序即可读取。
这清楚地意味着 rEFInd 将仅加载相应 MBR 分区（但必须是混合分区）的引导扇区，从而故意跳过 MBR。
此外，UEFI（Mac 上的 EFI 1.x）提供了“传统启动”选定分区的方法，当选择/指示这样做时，会自动加载 CSM。并非所有 UEFI 机器都具有此功能。如果缺少此功能，rEFInd 无法从 MBR 分区启动基于 BIOS 的操作系统。
来自OSDev 维基， 部分UEFI 0-3 类和 CSM：
PC 分为 UEFI 0、1、2 或 3 类。0 类机器是具有旧式 BIOS 的旧式系统；即根本不是 UEFI 系统。
1 类机器是专门在兼容性支持模块 (CSM) 模式下运行的 UEFI 系统。CSM 是 UEFI 固件如何模拟旧版 BIOS 的规范。CSM 模式下的 UEFI 固件会加载旧版引导加载程序。1 类 UEFI 系统可能根本不会宣传 UEFI 支持，因为它不会暴露给引导加载程序。它只是 BIOS“内部”的 UEFI。
2 类机器是可以启动 UEFI 应用程序的 UEFI 系统，但也包括在 CSM 模式下运行的选项。大多数现代 PC 都是 UEFI 2 类机器。有时，选择运行 UEFI 应用程序还是 CSM 是 BIOS 配置中的一项设置，有时 BIOS 会在选择启动设备并检查它是否具有旧式引导加载程序或 UEFI 应用程序后决定使用哪一个。
3 类机器是不支持 CSM 的 UEFI 系统。UEFI 3 类机器仅运行 UEFI 应用程序，并且不实现 CSM 以实现与旧式引导加载程序的向后兼容性。
从rEFInd 启动管理器：使用 rEFInd部分启动旧版操作系统：
为了在您需要以 BIOS 模式启动时提供帮助，rEFInd 支持启动旧版操作系统；但是，Mac 和 UEFI PC 之间的细节有所不同。另外，请注意，一些 UEFI PC 缺少此功能所需的兼容性支持模块 (CSM)。即使是一些可以本地启动基于 BIOS 的操作系统的计算机也是如此。之所以会发生这种情况，是因为固件基本上是一个 BIOS，并在其上附加了 UEFI 实现；此类系统依靠本机 BIOS 进行启动，并且可能无法为 EFI 应用程序提供通过 CSM 机制访问 BIOS 功能的方法。如果您有这样的计算机，并且在配置文件中启用了传统的启动选项，rEFInd 会在启动时通知您它无法显示传统的启动选项。
如果您对 EFI 启动菜单中是否确实有一些 CSM 条目感兴趣（不是 rEFInd，而是真正的 (U)EFI 启动选择），您可以efibootmgr -v在 Linux 上尝试。这仅在 Linux 本身作为 (U)EFI 操作系统启动时才有效。当 Linux 作为 CSM 启动选择启动时，它将无法访问底层 EFI 实现。只是，在 Linux 上，分区方面没有太大区别，因为 Linux 不像 Windows 那样挑剔，并且可以在 BIOS 模式下愉快地使用 GPT 分区。
# efibootmgr -v
Timeout: 2 seconds
BootOrder: 0000,0004,0005
Boot0000* Windows Boot Manager HD(2,GPT,1bf25484-f461-4892-a640-a24136b1d45f,0xe1800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...e................
Boot0004* Hard Drive BBS(HD,,0x0)P0: INTEL SSDSC2CT060A3 .
Boot0005* UEFI: SanDisk Extreme 0001 PciRoot(0x0)/Pci(0x1d,0x0)/USB(1,0)/USB(4,0)/HD(1,MBR,0x97,0xb4,0x298c)/File(\EFI\BOOT\BOOTX64.EFI)
在此示例中，只有 UEFI 条目。
# efibootmgr -v
BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0003,0002,0000,0004
Boot0000* CD/DVD Drive BIOS(3,0,00)
Boot0001* Hard Drive HD(2,0,00)
Boot0002* Fedora HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\fedora\grubx64.efi)
Boot0003* opensuse HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\opensuse\grubx64.efi)
Boot0004* Hard Drive BIOS(2,0,00)P0: ST1500DM003-9YN16G
在此示例中，Boot0000和Boot0004是 CSM 选择（注意路径BIOS），UEFI 将在加载 CSM 的情况下启动这些条目。但请注意，调用所选条目的启动的仍然是 UEFI！
当 rEFInd 应该使用 CSM 机制从 MBR（混合）分区启动旧版操作系统时，我只能假设这与永久 UEFI 启动项非常相似。rEFInd 可能使用一次性启动项（如BootNext）来完成此任务...