【发布时间】：2020-09-04 08:34:22
【问题描述】：
在编写自己的 MBR 时，我需要告诉 nasm 使用 16bit 程序集，我想知道为什么在 2020 年我们必须使用 16bit 程序集才能编写引导加载程序。
为什么我们不能使用现代 x64 程序集开发引导加载程序？
【问题讨论】：
标签： assembly x86-64 x86-16 bootloader
【发布时间】：2020-09-04 08:34:22
【问题描述】：
你可以。
如果您不想处理旧版 BIOS 16 位不便，请编写 UEFI 引导加载程序而不是旧版 MBR。 UEFI 引导加载程序是由固件在与 MBR 完全不同的环境中加载的 32 位或 x86-64 “应用程序”，来自文件系统而不是磁盘上的特定位置，这意味着嵌入少量代码（512 字节）到磁盘上的一个特殊位置。
主流 PC 使用 UEFI 启动已有十多年了；让固件将 CPU 置于实模式并设置传统 BIOS 调用处理程序是一种向后兼容功能，可保持与 MBR 启动的兼容性，因为该格式没有空间让元数据告诉系统您要在哪种模式下启动。
请注意，使 CPU 处于 64 位长模式需要启用分页，因此仅修改 MBR 引导以使 CPU 在进入 MBR 时处于 64 位模式将无法正常工作。你需要一堆新的标准化。很多实模式 BIOS API 都是过时的东西，跟不上现代 PC，比如基于 CHS 而非线性偏移的磁盘访问，对图形 + 鼠标的简单支持，以及没有文件系统访问。所以是时候进行全面改造了。更不用说勉强兼容的 BIOS 的可怕之处了，这些 BIOS 恰好与 Windows 引导加载程序一起工作，但以各种随机方式彼此不同，例如它们如何将 CS:IP 设置为相同的线性地址或其他段寄存器。
业界最终采用 EFI / UEFI 作为传统 IBM-PC BIOS 样式引导的完全替代品。 https://wiki.osdev.org/UEFI
【讨论】：
-
“没有跟上现代 PC 的步伐，例如基于 CHS 而非线性偏移的磁盘访问” - 公平地说，中断 13 小时服务的 LBA 扩展在 UEFI 之前就已经存在。
-
@ecm：公平点。但是你能指望它们在每个可以引导你的 MBR 的系统上都可用吗？如果不是，那么它仍然可能存在问题或不方便。也许更好的例子是图形+鼠标，文件系统访问（而不是原始磁盘扇区），因此您可以更新引导加载程序，而无需将其重新嵌入到实际分区之前的扇区中，也许是 USB / 可移动设备包括可移动存储。也许是光盘？尽管现在光盘的相关性较低。磁盘检测顺序也可能有问题。
-
@PeterCordes - 我有一个使用 MBR 的多引导系统 - Win XP、Win XP X64、Win 7 Pro 64 位、Win 10 Pro 64 位。 EFI/UEFI 很好，但任何当前版本的 Windows 都不需要它（也许服务器版本需要它？）。
-
@rcgldr：我当然过于简化了。大多数（全部？）现代 PC可以配置为以旧版 BIOS 模式启动。但是开箱即用，主流 PC没有这样配置，因此启动（在世界上任何一天启动的所有 PC）从硬件重置到操作系统完全运行，而不涉及 MBR 引导加载程序.除非周围的旧 PC 比我预期的要多 很多，在这种情况下，我的意思是“现代”PC，这些 PC 是在 UEFI 足够老到可以稳定并用作默认设置的年代制造的。您可以仍然从传统 MBR 引导现代操作系统这一事实与我的观点无关。
-
@PeterCordes - Win XP / Win XP X64 是否支持 EFI/UEFI 启动？多引导 Win 7 / Win 10 设置或只是 Win 7 设置怎么样？我没有不是多重引导的 Win 7 系统，所以我不知道 Win 7 是否默认为传统文本模式屏幕引导。如果我将 Win 10 设为默认启动操作系统，我只会获得 Win PE 启动。