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

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，是不含外置程序的。外置程序另外下载后，放在任意一个硬盘分区的根目录即可被找到。

不点

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

再分享一点思维活动。

Windows 的 bootmgr 仅仅是个 “启动管理器” 而已，它只在启动阶段存在。启动阶段过后，它就完成了任务，被撤销了。当它被撤销的时候，那就不会有虚拟光盘了。

也就是说，bootmgr 并未把虚拟光盘真正交给 Windows 内核。Windows 内核完全接管控制以后，bootmgr 可能就消失了，虚拟光盘也就消失了。

而在真实光驱的情况下，Windows 内核能够找到 “光驱” 这个设备。所以，用 iso 虚拟出来的实模式光驱，还不能成为 Windows 的光驱。从这个意义上说，bootmgr 临时虚拟出来的保护模式光驱，其寿命很短暂，无法与 svbus 之类的 Windows 虚拟光驱相媲美。

甚至，就连 bootmgr 究竟是否建立了保护模式下的虚拟光盘的访问，也是不能 100% 确定的。有这样的可能性（假定内存够大）：在实模式的时候，Windows 的内核和数据都拷贝到内存了，这样，就不需要从保护模式来调用实模式的 int13 了。

但核心的问题没有变：int13 肯定是要使用的，即便只是在实模式下使用。在实模式下，只要 Windows 初始化程序（bootmgr 等）在实模式的时候就已经破坏了 int13 的代码或数据，那就同样会出问题。

是的，我们的结论该调整了。Windows 并未集成 svbus 之类的虚拟光驱的驱动程序。Windows 可能并不在意到底 int13 是虚拟的光驱还是真实的光驱。它只管去调用 int13，调用完了之后，扬长而去，不再搭理，所以，后面也就没有光驱了。

不点

好的，假定不存在 svbus 之类的驱动，那么，用 iso 虚拟出来的光驱是 “短命” 的。

因此，map --mem 的方式，会消耗掉系统内存，这些内存被 iso 文件的内容占据，而 Windows 却不使用它，这是一种浪费。

浪费！浪费！浪费！

重要的事情，强调三遍。

因此，尽量使用不带 --mem 的 map 来建立虚拟光驱。

尤其是，如果您把 PE.iso 当作日常使用的桌面操作系统而不只是修电脑的工具，那就应该保证 iso 是连续的，以便顺利地用不带 --mem 的 map 来启动它。

不点

wintoflash 说：

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

确实如此，因为我们的 e820 保护的 int13 代码空间，就被废弃掉了。当时我们用 e820cycles 来解决，就是，不挂 int15，而让 e820 调用回归 ROM bios 的调用。

当时认为，int13 处理程序的空间内容，可能并未毁掉，只是不再被 Windows 承认。

现在出现了一种新的认识，就是：

int13 处理程序的尾部，很可能是实实在在地被破坏掉了！

【我想让 yaya 看到这个帖子】

int15 的处理程序，就位于 int13 代码空间的尾部，它很容易被破坏掉。

大家可能有疑问了：为什么尾部的，反而容易被破坏？难道不是 int13 的开头容易被破坏吗？

诚然，按照常规思维，通常是开头容易被破坏，因为开头的地址更低，而尾部的地址更高。

但在特殊情况下，那就是尾部被破坏，开头反而安全！

在什么情况下？

在堆栈的情况下。

如果 Windows 的 bootmgr 之类的初始化程序，把堆栈设置在 int13 空间的尾部，那就毁掉了尾部的 int15 代码，造成死机！

现在，尾部是 yaya 的碎片！

同样的逻辑，碎片被破坏了！

好了，先说这么多，以免大家看得太累了。下面再开个帖子，谈更深入、更细节、更技术性的问题。

2011yaya2007777

请 yaya 留意这个：

我个人的看法，EBDA 与 grub4dos 没有什么关系。grub4dos 的 int13 驻留内存代码的位置是由 0x413 确定，
他已经包含了 EBDA。通常情况，grub4dos 的 int13 驻留内存代码之后就是 EBDA。