%E2%80%9D%E4%B8%80%E8%B5%B7%E5%B7%A5%E4%BD%9C%EF%BC%8C%E5%8D%B4%E4%B8%8D%E8%83%BD%E4%B8%8E%E2%80%9C%E5%88%86%E5%8C%BA%20(2)%E2%80%9D%E4%B8%80%E8%B5%B7%E5%B7%A5%E4%BD%9C%EF%BC%9F.png)
我有一个 MBR 驱动器，在分区 2 上安装了 Windows XP，它使用指定的 boot.ini 条目进行引导patition(2)。分区表最初如下所示：
1. Windows recovery partition
2. Windows XP
3. Linux
4. Linux
然后我删除分区＃1并将其替换为扩展分区，从而得到以下表格：
1. Extended partition
2. Windows XP
3. Linux
4. Linux
现在 Windows XP 无法启动，提示缺少hal.dll。 boot.ini 中的分区号没有改变，MBR 分区表中的分区号也没有改变。然而，当我将 boot.ini 中的 Windows XP 启动项从 更改partition(2)为partition(1)Windows XP 时，它再次启动，没有任何问题。我想要知道确切的原因。
我正在阅读https://neosmart.net/wiki/rebuilding-boot-ini-file/其中有关于 boot.ini 分区编号的内容：
分区 (y)：驱动器 rdisk(x) 上的分区编号。分区 (y) 从 1 开始计数，因此第一个分区是分区 (1)，第二个是分区 (2)，依此类推。分区 (y) 首先计算主分区，然后计算逻辑分区。但是，扩展分区（逻辑分区的“容器”）本身不计算在内。这些数字取自主引导记录中的分区表，这通常是它们被创建的顺序，不一定与它们在磁盘上出现的顺序相同
这是真的吗？因为从我的角度来看，我似乎只是通过替换 MBR 中的分区条目 1 就更改了分区号。
记录显示，partedWindows XP 分区确实是 2 号，并且fdisk告诉我它是/dev/sda2（尽管我并不完全相信设备编号方案与 MBR 分区号完全对应）。即使删除和替换分区 1 的操作确实导致重写整个 MBR 分区表那么，这个输出肯定可以确认 Windows 分区确实位于正确的位置吗？
我在这里是否理解错了什么？
答案1
在我看来，您的帖子包含了理解答案的所有要素，尽管可能适用多条计数规则（如您的评论中所述）。
如果分区的创建顺序是分配数字的决定因素，那么原因是您删除了分区＃1，因此将＃2 变成新的＃1。
您创建的新扩展分区将按照其创建顺序遵循所有其他条目，因此现在可能是一个更高的数字（也许是＃4，因为它现在是最后一个）。
需要澄清的是，您给出的引文提到了创建日期，但它实际上可能是指分区顺序。如果表中已删除的分区条目在删除后未重新使用，情况也是如此。
分区号分配算法似乎非常简单：Windows 根据其命令在分区表中，而不是通过他们的位置。因此，如果条目号 1 为空，或者是 BIOS 将忽略的类型（我怀疑是否存在此类类型），则可能在表条目 2 中找到分区 #1。
答案2
请记住，boot.ini 中的整个“ARC 路径”功能并非 BIOS/MBR 系统所固有的。它来自ARC 型固件它存在于 DEC Alpha 系统（Windows NT 最初构建的平台，也是当今 EFI 类型固件的前身）中，而整个 Windows NTLDR（和 boot.ini）只是对更高级平台上的固件通常提供内容的模拟。
因此，当 Windows 引导加载程序解释 BIOS 系统上的 ARC 路径时，它会尝试隐藏 MBR 特定的怪癖，例如“扩展分区”，并提供通用的扁平视图卷内（因为没有更好的术语）。由于扩展分区并不直接表示保存数据的东西，因此这里将其忽略。
我有一种可怕的感觉，我的答案就在引用的句子中“扩展分区（逻辑分区的“容器”）本身不算数”......
巧合的是，泄露的 Windows XP 源代码仍可在 Microsoft 的 GitHub 上找到。深入研究后，ARC 路径中的分区号最终由 处理HardDiskPartitionOpen()，其中的代码会故意跳过 MBR 分区槽，如果它们是 a) 空的（类型 0x00）、b) EFI 保护分区（0xEE）或 c) IsContainerPartition()（0x05 或 0x0F）。换句话说，它不计算除了直接保存数据之外还有其他用途的分区槽。
（此外，“扩展”分区的位置无关紧要；它总是被处理后基本 MBR 插槽已经处理完毕。