现在的 PE 是用 svbus 还是 firadisk/winvblock？

liuzhaoyzz

不点 发表于 2021-11-23 17:02
liu 版主的帖子很要紧。我正好有疑问想请教。

1. 我似乎觉得 ventoy 是一个启动软件，却同时做了很多 ...

grub4dos/grub2是一个OSloader。
ventoy不单单是一个OSloader，而是一个OSloader+写引导+启动解决一整套方案，所以他做的比g4d做的多，是可以理解的。他的初衷是面向Legacy BIOS会逐渐消亡的未来，他的优点是简单化，傻瓜化，新手上手快，方便，不用写菜单，解决g4d/g4e/grub2写菜单麻烦的痛点，特别是不同的linux发行版的启动参数特别多，ventoy进行了大幅简化，缺点是BIOS模式兼容性有些问题，大不了多准备个优盘就是了。      

不点

liuzhaoyzz 发表于 2021-11-24 06:49
直接map的模式下，没有svbus，firadisk，winvblock这些，PE仍然可以启动呀，前面wintoflash和我都说了PE ...

版主大人，我漏看了 wintoflash 的帖子，谢谢您的提示，同时也和大家说声对不起。

人老了，精力不够使，以为 wintoflash 只是在谈 Windows 本身的 ramdisk 呢。他也谈到实模式 int13 调用了。我正在重新阅读。

不点

好的，看完了 wintoflash 的如下解释（重点部分用红色，【蓝色】是插入我的话）：

bootmgr.exe 运行在保护模式中，如果读磁盘就调用头部提供的回调函数，切到实模式调 int13h，再切回来。【此处 wintoflash 说的很清楚，bootmgr.exe 是用实模式的磁盘访问，这里其实就是 iso 的扇区访问。可是，我们前面已经证明了，在进入保护模式后的某一节点处，不可能是调用实模式！因为，调用实模式，是必然成功的，不可能失败！而在扇区不连续的情况下，却失败了，无法正常进入 Windows 桌面。因此，wintoflash 的这个解释并未回答真正的问题。wintoflash 仅仅解释了 bootmgr.exe 的行为，而未能解释我所描述的现象。】


因此它是可以读取 grub4dos (或者其他引导器) 创建的int13h虚拟盘。【调用实模式int13肯定没问题，无论扇区是否连续，必然是成功的；这是由 yaya 的代码对于不连续扇区序列的支持所保证的。可是，在不连续的情况下，无法正常进入 Windows 桌面，这就证明了：此时不可能是调用实模式！而只能是调用另外的虚拟盘访问代码。此处只是想重复强调一下：wintoflash 仅仅解释了 bootmgr.exe 的行为，而未能解释我所描述的现象。bootmgr.exe 的行为很可能是早期的，而我所描述的失败，则是发生在后来。】


bootmgr.exe 读取 BCD (启动菜单文件)，再根据启动菜单上给出的磁盘编号(MBR签名和分区LBA)和路径，读取boot.sdi，还有 WIM 启动镜像。


boot.sdi 叫 "System Deployment Image"，它里面有个很小的 NTFS 分区，这个分区将来会成为 WinPE 的 X: 盘。


bootmgr.exe 会把 boot.sdi 和 WIM 镜像先后复制到内存，通过一些手段，调整 boot.sdi 里面的 NTFS 分区大小，把 WIM 挂载到 NTFS 分区中。
这个 NTFS 分区完全是一个内存盘，因此 WinPE 在这个阶段就完全位于内存中了，与虚拟光盘中的文件再无关联。
接下来，bootmgr.exe 启动这个内存盘中的 winload.exe，进而启动 WinPE。

WinPE 有专门用来识别这个内存盘的驱动 (ramdisk.sys)，在 Windows LOGO 转圈的时候就会加载这个驱动，所以不用担心 WinPE 找不到内存盘，WinPE 可以正常运行。
但是，在进入 WinPE 系统之后，没有办法读取 int13h 虚拟盘，所以在磁盘列表里面不会看到 grub4dos 创建的这个光盘。【可是，我的测试已经证明了，PE 系统仍然要读取 grub4dos 创建的虚拟光盘！请特别注意这一点！假如 PE 不读取虚拟光盘的话，它就不可能死在 logo（或后来的测试是给出一个黑屏）；连续时正常，不连续时死亡！这完全证明了，PE 仍然需要读取虚拟光盘！不然的话，不可能出现这样的差异！我注意到 wintoflash 一开始就假定不存在 svbus，firadisk，winvblock。而我和 2011whp 在 PE.iso 里面确实找不到这三个驱动。因此，我们就认可 wintoflash 的这一假定，也就是说，我们暂时就认为这是事实。既然没有这三个驱动，而且又不可能是调用 int13，那么，必然得出结论：是微软自己的代码，在保护模式下对于实模式虚拟盘提供了支持，并且这个支持碰巧与 svbus 具有同样的 bug,  即，不支持带有碎块的 iso。希望 wintoflash 能够看到我的分析。】

不点

再多说几句，同时也把要点再重复一遍。

yaya 增添了对于不连续扇区序列的支持（碎片数为 32 个以内）。Windows 下不管以什么方式调用 int13h，那都是调用 yaya 的代码，都是把 CPU 模式切换到实模式来调用，因此也都只能是成功的，不可能失败。而我所描述的现象，却在连续时成功，不连续时失败。这就证明了，这个表现不可能是调用 yaya 的代码。

同时，非常奇妙！连续时成功，不连续时失败——这一事实，恰到好处地还能够证明：它必然要读取虚拟光盘！

大家注意，这同一个事实（连续时成功，不连续时失败），能够同时证明两件事！即如下两件事：

1、出现失败时证明不是调用 yaya 的仿真代码。

2、连续与不连续出现差异时证明必然是在访问虚拟光盘，而不是完全扔掉虚拟光盘（即，不可能只去访问 X: 盘）。


它既然要读取虚拟光盘，那就得驱动这个虚拟光盘。但又不是使用 yaya 的 int13，因此，必然是像 svbus、firadisk、winvblock 那样而使用 yaya 之外的代码，并且很可能是纯保护模式的，即，不使用实模式！


我说得够明白吗？如有疑问，请尽管提出，我会详细解释。

wintoflash

不点 发表于 2021-11-24 11:59
好的，看完了 wintoflash 的如下解释（重点部分用红色，【蓝色】是插入我的话）：

bootmgr.exe 运行在保 ...

报告个不幸的消息, 今天下载新版 iso 试验, 30 个碎片, 不带 --mem 居然成功进入桌面!

昨天我测试某个新的 PE.iso 时，碎块已经不影响了！本来期待它死机，它却不死机，你说气人不气人！

按照你的理论，如何解释这个现象？

可是，我的测试已经证明了，PE 系统仍然要读取 grub4dos 创建的虚拟光盘！请特别注意这一点！假如 PE 不读取虚拟光盘的话，它就不可能死在 logo（或后来的测试是给出一个黑屏）；连续时正常，不连续时死亡！这完全证明了，PE 仍然需要读取虚拟光盘！不然的话，不可能出现这样的差异！

这是在部分BIOS下的偶然现象。
我在帖子里面说了，

Windows 本身比较 "霸道"，它在启动过程中也经常不去管 E820 内存映射信息，直接去读写低地址的一些区域。
因此如果 GRUB4DOS 写的碎片表被 Windows 污染了，但是 WIM 镜像还没有完全读完，那么读到的 WIM 就会有错误，最终造成蓝屏或死机。

你应该在虚拟机上或者找一些不同的电脑进行测试。只要用了第三方的东西，Windows 在启动过程中蓝屏/黑屏/死机都是有可能出现的。
为了尽量避免 Windows 污染 GRUB4DOS 的碎片表，我建议想办法让 ISO 的碎片比较少 (<3个)，同时让碎片位于 ISO 靠前的部分。

不点

wintoflash 发表于 2021-11-24 12:23
按照你的理论，如何解释这个现象？

wintoflash 来讨论，太期望了。

按照你的理论，如何解释这个现象？

可以这样解释：碰巧那个版本的 iso，当进入保护模式后不再访问虚拟盘，那就不会有问题。但后来的版本，仍旧出问题了，我们以出问题的版本为讨论重点。

也就是说，一个版本，如果它不出问题，什么问题也说明不了。而如果它出问题，那就像我先前分析的那样，证明微软提供虚拟盘的保护模式驱动（并非切换到实模式调用 int13）。


等稍后再看您的其它阐述。

wintoflash

不点 发表于 2021-11-24 12:18
再多说几句，同时也把要点再重复一遍。

yaya 增添了对于不连续扇区序列的支持（碎片数为 32 个以内）。W ...

yaya 增添了对于不连续扇区序列的支持（碎片数为 32 个以内）。Windows 下不管以什么方式调用 int13h，那都是调用 yaya 的代码，都是把 CPU 模式切换到实模式来调用，因此也都只能是成功的，不可能失败。而我所描述的现象，却在连续时成功，不连续时失败。这就证明了，这个表现不可能是调用 yaya 的代码。

是的。(如果GRUB4DOS弄的碎片表没有被污染) 用 int13h 读出来的必然是没有问题的。

它既然要读取虚拟光盘，那就得驱动这个虚拟光盘。但又不是使用 yaya 的 int13，因此，必然是像 svbus、firadisk、winvblock 那样而使用 yaya 之外的代码，并且很可能是纯保护模式的，即，不使用实模式！

这些驱动都是读取前1MB物理内存，搜索启动管理器的一些蛛丝马迹。
比如 SVBus 会搜索"$INT13SFGRUB4DOS"这个字符串。

我们先假定这些驱动是通过搜索物理内存中的一些字符串确定GRUB4DOS map的ISO在硬盘上的起始位置和长度(对于 SVBus 确实如此)，
那么如果我们在 UEFI 下也向内存中对应的位置写入对应的信息，SVBus 也能找到这个信息并且挂载 ISO。
(https://github.com/a1ive/grub/blob/master/grub-core/map/lib/g4d.c)
事实上也确实如此，这说明这些驱动和 BIOS int13h 一毛钱关系也没有。

2011whp

更正内容： x盘 是引导 在 读 进度条进  一次性 加载至内存，ramdisk驱动的内存盘  

wintoflash

不点 发表于 2021-11-24 12:40
wintoflash 来讨论，太期望了。

可以这样解释：碰巧那个版本的 iso，当进入保护模式后不再访问虚拟盘，那就不会有问题。但后来的版本，仍旧出问题了，我们以出问题的版本为讨论重点。

也就是说，一个版本，如果它不出问题，什么问题也说明不了。而如果它出问题，那就像我先前分析的那样，证明微软提供虚拟盘的保护模式驱动（并非切换到实模式调用 int13）。

我的看法与你相反。我认为前者(有碎片但不出问题)才是正常情况，后者是在bootmgr int13h读盘阶段就出了意外。
因为我的机器上就是有碎片可以正常启动的，我在虚拟机和其他大多数机器上测试，也是这样的。

不点

wintoflash 发表于 2021-11-24 13:08
我的看法与你相反。我认为前者(有碎片但不出问题)才是正常情况，后者是在bootmgr int13h读盘阶段就出了 ...

现在人老了，不能过多看帖回帖，抱歉，先只回复 wintoflash 一人的帖子。

感谢！非常感谢！您说明白了，只是我没意识到，您所说的，恰恰解决了我的疑问！

我没意识到，您所说的破坏碎片，是导致 int13 失败的一种实实在在的可能性。

liu 版主竟然早早地意识到了。liu 版主不只是个收藏家！至少是强过我的！

下午抽时间再谈其他一些想法。

不点

2011whp 发表于 2021-11-24 12:57
可能 微软在用  ramdisk   时 有智能 判断  （可能 g4d 的map  一直在的）
http://bbs.wuyou.net/forum.ph ...

wintoflash 说是 bootmgr.exe 在对虚拟盘进行 “驱动”，这样就解决了所有的疑问。与 ramdisk 无关，ramdisk 只负责驱动微软自己的内存盘，不涉及实模式虚拟盘的操作。

不点

既然开发者们知道，问题可能出在 “碎片指针表被破坏” 上，那就可以尝试改进了。当然，如果权衡各种利弊以后，觉得应该改进的话，才去改进。

在改进之前，可以先用一些测试手段验证，确实是碎片表被破坏了。如果不是被破坏了，那当然就不去从这方面来改进了。下面假定，已经验证，或者虽然未验证，但就这样认为：确实是碎片表被破坏了。

开发者们肯定知道怎么改进比较好。我这里也只是谈谈技术改进的一种可能性。

碎片表的 32 个指针，占用的空间并不多，竟然都被破坏了！那么，假如上万个指针，岂不是更……

哦！上万个，上百万个指针，常规内存也装不下啊！

嗯，那就把指针放在扩展内存吧！需要多少空间，就分配多少扩展内存给碎片表。

这样，碎片表就不会被破坏了。同时，这还有个好处，就是，可以支持任意多的碎片了。

工作量蛮大的，处理起来相当复杂！别把 yaya 身体整垮了。

---

---

上述方案行不通。隐约记得 grub(legacy) 的文件碎块缓冲区貌似只有 64K，处理不了几千个碎块，更不可能上万。也就是说，遇到那样的文件，grub 就会失败而无法处理。grub4dos 是以 grub 为基础的，具有同样的限制。


还是算了吧，听天由命，不用理会这些事情了。

不点

该是总结的时候了。感谢各位！让我能走到 “总结” 这一步！

有碎片的文件，在不同的机器型号上，其表现是不同的。表现好的时候，一切正常。对于那些表现不好的的机器，它占用了太多常规内存，压缩了 grub4dos 的常规内存空间，导致碎片表被破坏，也可能是 grub4dos 的运行代码被破坏，从而出现死机等问题。

在 grub4dos 的数据结构不被破坏的理想情况下，Windows 本身的 bootmgr 能够提供实模式虚拟盘的保护模式驱动。它是在保护模式下先切换到实模式，然后调用 int13，最后再返回保护模式，这样就驱动了实模式虚拟盘，换句话说，也就是，提供了实模式虚拟盘的保护模式支持。这个过程与 svbus，firadisk，winvblock 是无关的，不需要这三个驱动的参与。

虽然测试时，连续的 iso 都没出现问题，但理论上，即便连续也不保险。只要 grub4dos 的代码或数据被破坏，什么情况都可能发生。即使您使用 --mem，也一样存在失败的可能！用 --mem 的时候，仅仅是把扇区数据拷贝到扩展内存了，但是，grub4dos 的磁盘仿真代码，仍然在常规内存，而它，就有可能被 Windows 的初始化程序破坏掉！正如前面所说，有些机器占用了过多的常规内存空间，压缩了 grub4dos 的生存空间，造成 grub4dos 的代码、数据被 Windows 初始化程序破坏掉的不良结果。

我本人测试所用的这台机器，属于不好也不坏的情况。我想，在一些更差的机器上，其表现应该是更糟糕的。我的机器，在测试连续的 iso 时都正常。设想有某台糟糕的机器，它甚至会在 map --mem 时都可能会出现死机等问题的。


因此，今后若遇到 map --mem 也出问题的情况，开发者们不要感到惊讶，可以拿本帖讨论的结果来给用户一个解释。我们不怕出问题，我们只怕出问题以后没有合理的解释。

不点

先贤们，大师们，开发者们！我似乎发现问题了。

我测试的机器，常规内存占用得不太多，只占用了 37 K。

grub4dos 的仿真代码占用了 11 K。

总共只占用了 37 + 11 = 48 KB。

int13 的段地址为 9400h，这是处于 “安全” 范围的，不应该被 Windows 覆盖。

我用 cat --hex 看 grub4dos 的内存，似乎发现了错误！

这可能是个 bug。

等我再仔细确认 bug 以后，再来向大家汇报详情。

wintoflash

不点 发表于 2021-11-24 17:44
先贤们，大师们，开发者们！我似乎发现问题了。

我测试的机器，常规内存占用得不太多，只占用了 37 K。
...

int13h本身应该是安全的。
但是碎片表所处的位置可能不安全。据yaya说，碎片表位于 0x80000~0x9ffff 之间。
我没有明确的证据证明 Windows 一定会使用这个区域，也没有证据证明 Windows 一定不使用这个区域。
如果yaya要换个位置，我建议参照wimboot的做法： 优先 4GB 以上，不行就 2GB 往下。

不点

wintoflash 发表于 2021-11-24 18:02
int13h本身应该是安全的。
但是碎片表所处的位置可能不安全。据yaya说，碎片表位于 0x80000~0x9ffff 之 ...

wintoflash 对于 Windows 数据结构及内幕有独到见解。就算您不知道某些知识，您也能查阅到某些关键资料，别人不一定能够查阅得到。因此，我想请教，在 EBDA（扩展的 BIOS 数据区）以及常规内存保护的处理 （int15/e820h）方面，有什么规范？

下面就您提到的 4GB 以上以及 2GB 以下放置碎片表，发表一下我的看法。

这都不太合适，前面我曾经说过，碎片太多的情况，根本就处理不了，这是 gnu grub legacy 的缓冲区限定了的。

目前，yaya 把它放在 int13 代码的尾部，占用的字节数很少，本来是不该有问题的。我认为这也是合适的。

我现在怀疑的是，windows 对于 EBDA 和 int15/e820h 的某些要求，grub4dos 未能得到满足，未能让 Windows 高兴，所以，就出现了冲突。

sunsea

不点 发表于 2021-11-24 19:18
wintoflash 对于 Windows 数据结构及内幕有独到见解。就算您不知道某些知识，您也能查阅到某些关键资料， ...

引用W大之前发言：

Windows 本身比较 "霸道"，它在启动过程中也经常不去管 E820 内存映射信息，直接去读写低地址的一些区域。
因此如果 GRUB4DOS 写的碎片表被 Windows 污染了，但是 WIM 镜像还没有完全读完，那么读到的 WIM 就会有错误，最终造成蓝屏或死机。

M$很有可能有此类霸道行为，不怎么理会E820，尤其是在实模式日渐衰落的今天。所以我也提议尽可能把碎片表等放在高地址的安全位置。如果我没有记忆错误的话，之前E820处理也曾经让某些Intel集成显卡（姑且认为M$和Intel是一家）等驱动不高兴、死机（甚至是Hook即死机），从而引入e820cycles等参数。

甚至有时间的话我提案如下测试版：对碎片表进行奇偶校验等容易实现的校验方案，一旦出问题就直接强制诸如让报警喇叭发声、写屏、死机等明显的指标性方案，以确定Windows启动过程中的行为。

至于G4E，我建议直接写入UEFI环境变量等不会被Windows行为干扰的区域，彻底解决这一潜在隐患，因为UEFI下【常规内存】【e820】等都直接失去意义了。

2011yaya2007777

碎片表，g4d是在常规内存顶部，受int15/e820保护。我觉得被污染的几率不大。g4e是在程序内部，除非uefi放弃g4e。为了给svbus传递信息，模仿g4d在常规内存复制了一份碎片表。

sunsea

2011yaya2007777 发表于 2021-11-24 19:58
碎片表，g4d是在常规内存顶部，受int15/e820保护。我觉得被污染的几率不大。g4e是在程序内部，除非uefi放弃 ...

g4e这个还行，不过放在“常规内存”我感觉还是不太保险，复制我还是觉得复制到UEFI环境变量比较好，毕竟在UEFI下常规内存这个东西没有意义了，Windows很有可能随意破坏。

2011yaya2007777

为的是g4e可以使用现成的svbos。因为其作者无意与g4e对接。不过虽然在常规内存顶部，但是受uefi保护。前提是windows没有废弃g4e。

不点

请 yaya 留意这个：

https://stanislavs.org/helppc/ebda.html

EBDA - Extended BIOS Data Area EBDA (PS/2)
    Offset         Size                 Description
        00         word           number of bytes allocated to EBDA in Kbytes


- EBDA is located in highest memory just under 640K on PS/2
- word at BIOS Data Area 40:0E is segment address of EBDA


http://www.kryslix.com/nsfaq/Q.6.html

Subject: What is in the extended BIOS data area on a PC?
Date: 09/13/97

---

    Extended BIOS Data Area

Format of Extended BIOS Data Area (see 40:0Eh for ptr) [PS only]

Offset  Size    Description
  00h    BYTE    Length of EBDA in kilobytes

偏移 0 处的一个字节或 word（双字节），是“扩展的 bios 数据区” EBDA 的长度，用 KB 做单位。

它应该指示整个 EBDA 空间的长度，而不只是 grub4dos 仿真代码的长度。

这可能是我当时的失误，也可能是后来的某个补丁引入了 bug，把本来正确的长度，变成了错误的长度。

无论如何，yaya 可以试试把它纠正过来。

map --hook 的时候，应该修正这个长度值为正确的值。

sunsea

2011yaya2007777 发表于 2021-11-24 20:18
为的是g4e可以使用现成的svbos。因为其作者无意与g4e对接。不过虽然在常规内存顶部，但是受uefi保护。前提 ...

受保护那确实是个好消息。

不点

Sunsea 版主确实是高手，记性也好，能记得 e820cycles 那一段往事！而且，细节都记得清清楚楚！

是的，那段往事，当时我们很困惑，用 e820cycles 来变通。

但是，今天，假如我们能够确认，我们的 grub4dos 存在 bug，那就可能重新下结论了。

高手们，加油啊！明天会更好！！

2011yaya2007777

2011whp：我把你提供的svbus.iso放在U盘，在实模式通过map启动，没有碎片，大约转圈圈3分半才进入桌面。看来与碎片无关，另有隐情。使用map --mem启动，几秒钟进入桌面。查看目录，有CDROM挂载为h盘，是svbus.iso。这时读h盘要通过svbus驱动。因为他不支持碎片，所以有碎片的话，会读错。

2011yaya2007777

使用不点在本帖提供的win11.iso，放在U盘，实模式通过map启动，很快进入桌面。没有svbus之类的驱动，目录里面也没有CDROM挂载，不能读win11.iso里面的内容。所以我觉得windows的驱动并没有svbus之类的功能。

不点

2011yaya2007777 发表于 2021-11-24 21:40
2011whp：我把你提供的svbus.iso放在U盘，在实模式通过map启动，没有碎片，大约转圈圈3分半才进入桌面。看 ...

就像我前面猜测的那样，修复 map --hook，让 int13 数据段的第一个字节的值等于整个 ebda 的长度（包括 int13 代码长度再加上通电自检后的原始 EBDA 长度），这样就有可能 OK 了。

2011yaya2007777

关于碎片：1.  如果windows挂载了map出来的实模式盘，由于svbus不支持碎片，所以会出错。  2.  在启动之初，仅使用map，如果有碎片，会影响启动，也可能成功，也可能失败。比如第一碎片包含整个boot.wim，估计是成功的。也就是说，只要windows找到他需要的文件并加载成功，就进入虚拟模式了。至于其他的，比如外置应用程序，就算有碎片表，他也废弃了，因为那是在实模式，他自己不会转到实模式通过int13读磁盘。

不点

2011yaya2007777 发表于 2021-11-24 21:40
2011whp：我把你提供的svbus.iso放在U盘，在实模式通过map启动，没有碎片，大约转圈圈3分半才进入桌面。看 ...

这件事可能受 Windows 的影响，svbus 本身也在微软的系统代码之下运行。所以，微软的代码，会影响最终的结果。

在连续的情况下，都能正常进入桌面。这说明，碎片指针未被破坏，因为本来就没有碎片指针。

在不连续的情况下，存在碎片指针，所以，被破坏的可能性增加了。但也有不被破坏的案例，wintoflash 就提到过这种情况。当然，wintoflash 说的不是 svbus，而是 Windows 自己。不过，Windows 会影响一切，包括也可能影响到 grub4dos 代码和数据，这样就间接地影响了 svbus 的表现。

为什么会被破坏？我前面提到，可能是因为 EBDA 长度错误，导致微软不承认 grub4dos 代码空间的合法性。

不点

2011yaya2007777 发表于 2021-11-24 21:47
使用不点在本帖提供的win11.iso，放在U盘，实模式通过map启动，很快进入桌面。没有svbus之类的驱动，目录里 ...

好的，Windows 有没有 svbus 之类的功能，暂且悬挂起来，不讨论。

但是，Windows 启动过程需要调用 int13 来读光盘，这是肯定的。而假若 Windows 一边读光盘，一边破坏 grub4dos 的数据结构，那结果会怎样？死机、失败，对吧？而实际上真的发生了死机、失败。所以，我们反过来就可以说，Windows 是在读光盘，而且，根据 wintoflash 所说，是提供了保护模式的读盘能力（切换到实模式、调用 int13，再切换回保护模式）。虽然没有分配盘符，但这并不表示 Windows 不去读光盘扇区。

不点

2011yaya2007777 发表于 2021-11-24 22:06
关于碎片：1.  如果windows挂载了map出来的实模式盘，由于svbus不支持碎片，所以会出错。  2.  在启动之初 ...

wintoflash 说清楚了，Windows 是通过 bootmgr 的代码来读光盘的。bootmgr 建立了一个保护模式与实模式的通道，能够调用 int13 来读盘。当然，其目的，可能仅仅是为了加载 boot.wim 之类的。

你下载到的 kuer 的 PE.iso，是不含外置程序的。外置程序另外下载后，放在任意一个硬盘分区的根目录即可被找到。