Bootloader 真的位于扇区 0 吗？

Question

仔细观察我开始编写的个人引导加载程序，我有一个问题。当我执行以下步骤时会出现此情况：

1. 我创建了 bootloader.asm 并制作了 bin：

nasm -f bin bootloader.asm -o bootloader.bin

2. 将生成的 bin 放在零填充文件的开头（扇区 0）（大小 1.44 MB，标准软盘容量）：

dd if=/dev/zero of=bootloader.img bs=1024 count=1440
dd if=bootloader.bin of=bootloader.img seek=0 count=1 conv=notrunc

3. 在 El Torito 扩展中使用给定目录创建了 iso 映像：

genisoimage -quiet -V 'hashidaOS.iso' -input-charset iso8859-1 -o hashidaOS.iso -b bootloader.img -hide bootloader.img iso/

在这一切之后，一切都在虚拟机中运行，但是当我尝试读取 .iso 以了解有关 El Torito 的更多信息时，我意识到 .iso 的扇区 0（512 字节）全都是 0！那么，如果虚拟机的“虚拟 BIOS”尝试仅从扇区 0 获取引导加载程序，这怎么可能呢？

要阅读我使用的.iso：

hexdump -C hashidaOS.iso

和

dd if=HashidaOS.iso bs=512 count=1 | xxd

两者都给了我0号区中填充的零的残酷真相。

基于这一切（抱歉，如果我写了这么多，这是我关于堆栈溢出的第一个问题），你们能回答一些问题吗？ 他们在这里：

• 如果存储是可引导的，引导加载程序真的一直在物理扇区0吗？
• 如果我的引导加载程序不在 .iso 的扇区 0 中，Oracle VM 如何获取它？
• 用于加载引导加载程序的 INT 19h 是否也被 Oracle VM 用作真正的 BIOS？如果是这样，它是否也会加载存储的扇区 0？
• 扇区 0 丢失的代码可能与 ISO El Torito 规范有关？

如果有任何帮助，我将非常感激，抱歉，如果有任何英语错误，我快要睡不着了，完成这个问题

Answer 1

对于可启动 CD-ROM，有一个“启动目录”，它就像不同启动加载程序的列表。计算机的固件会搜索此列表以查找有意义的内容。例如，如果计算机是“80x86 BIOS”，它将搜索用于“80x86 BIOS”的启动目录条目，如果计算机是“80x86 UEFI”，它将搜索用于“80x86 UEFI”的条目”，如果计算机是 PowerPC 或 SPARC 或其他任何计算机，则固件将为这些计算机搜索合适的引导加载程序。这样，您就可以拥有一张支持并适用于许多不同计算机的 CD（可能是操作系统安装程序），并为每种类型的计算机提供不同/合适的引导加载程序。

启动目录项还说明了启动目录项的实际可启动数据在 CD 上的位置。数据永远不会位于“CD 的扇区 0”；所有与 CD-ROM 相关的规范都将第一个扇区（我认为是前 16 个扇区）指定为“全零”，因为 CD 的扇区以螺旋方式写入，并且 CD 读取器将从最外层的随机位置开始螺旋的一部分，不能保证它是任何特定扇区，并且 CD 驱动器从随机起点“向后查找”到第一个扇区的能力很差。换句话说;硬件被设计为在媒体开始时有一个空白且可忽略的“导入”，以解决技术问题（在螺旋开始时从随机扇区开始并向前扫描/搜索要容易得多）。

对于“80x86 BIOS”，启动目录项实际上有 3 种可能：模拟软盘、模拟硬盘和不模拟任何东西。前 2 个选项适用于在 CD-ROM 存在之前编写的传统引导加载程序，在这些情况下，引导目录条目指向磁盘映像，并且从模拟磁盘引导遵循模拟设备的旧规则。

换句话说，对于“软盘模拟”，引导加载程序将位于假/模拟软盘的第一个假/模拟扇区中，并且实际上可以位于真实 CD 上的几乎任何位置，但不应该位于光盘的第一个扇区中。光盘。

我可能还应该提到，在旧的 CHS 方案（用于真实和模拟软盘）中，第一个扇区传统上是“扇区 1”（“扇区 0”不存在）。当引导加载程序尝试加载某些内容以从软盘引导时，您需要记住这一点。