无忧启动论坛

标题: 现在的 PE 是用 svbus 还是 firadisk/winvblock？ [打印本页]

作者: 不点 时间: 2021-11-13 09:36
标题: 现在的 PE 是用 svbus 还是 firadisk/winvblock？
我最近试用了几个 PE 的 iso，它们在 bios 下都能通过 map 启动到桌面。我想，既然它能支持 grub4dos，就一定内置了保护模式的驱动来访问 grub4dos 的虚拟盘。

我想知道，这些 PE 一般采用的是较新的 svbus 呢，还是以前的 firadisk、winvblock？

另外，在此通报一下我用 map 时碰到的一个情况，希望引起开发者和用户的注意。

在测试某个 PE.iso 时，我用

map (...)/.../PE.iso (255)
map --hook
chainloader (255)
boot

启动 PE，出现 Loading ...... 的进度条。但是，在即将进入桌面时，死机了！

反复好几次，都是同样的结果。

于是加上 --mem 试试：

map  --mem (...)/.../PE.iso (255)
map  --hook
chainloader  (255)
boot

结果，顺利进入桌面！一切正常！

现在人老了，脑子迟钝了，研究了好几天，终于弄明白问题在哪里了——是 PE.iso 文件有碎块导致的！

我用 blocklist (...)/.../PE.iso 列出了 3 个碎块（或 4 个碎块，记得不很准确），

在碎块不多的情况下，不带 --mem 的 map 命令是可以成功执行的，不会报错。

然而，进入保护模式后，svbus、firadisk、winvblock 却不一定支持含有碎片的映像文件！所以就失败了、死机了！

我用 contig.exe 对 PE.iso 进行碎块整理，让它连续。再用不带 --mem 的 map 来测试，成功进入桌面，没有任何问题。

这个情况，估计你们都知道其缘由。只是由于我老了、痴呆了，才费劲去做了这个 “二次发现” 的工作。

这个工作对你们来说，可能没有价值，属于马后炮。

无论如何，我花了时间、做了这个工作，向大家通报一下，应该也是有好处的吧。

作者: ku588 时间: 2021-11-13 09:56
本帖最后由 ku588 于 2021-11-13 09:58 编辑

通常我打包ISO时先用WinContig对WIM整理碎片，打包完ISO再次对ISO整理碎片，目的就是为了解决碎片带来的启动问题！，有碎片的WIM和ISO在载入内存阶段就非常的迟钝缓慢！

作者: 2011yaya2007777 时间: 2021-11-13 10:40
本帖最后由 2011yaya2007777 于 2021-11-13 10:47 编辑

svbus不支持碎片。有网友向其开发者反馈，希望能解决此事。开发者回复说研究研究，没了下文。其实我的补丁已经打好，只是无法编译。本来想让开发者编译一个测试版本，但是人家没有接茬。

作者: liuzhaoyzz 时间: 2021-11-13 11:23
本帖最后由 liuzhaoyzz 于 2021-11-13 14:26 编辑

一般情况下还是用map --mem模式兼容性更好，我基本不用直接map模式启动PE。各种碎片整理程序对于有足够空间腾挪的iso文件整理有效，对于sata-ssd,NVME-ssd，不一定那么有效，因为ssd有FTL逻辑转换电路，外加动态磨损平衡算法优化，导致的结果逻辑层连续，物理层不一定连续存放，需要看ssd主控芯片逻辑，优盘的情况估计类似。

作者: 不点 时间: 2021-11-13 11:29
yaya, 不用太纠结这个事。

我再报告一个情况：

由于我最近测试了好多 PE.iso，所以我就有很丰富的第一手资料。

我碰上许多有碎块的 iso，碎块太多，无法用不带 --mem 的 map 来启动。

整理碎块需要一些步骤，而且要花不少时间。人懒了，就不想整理碎块。

进入 grub4dos 去 map 它，这才发现 too many fragments。然后我就 blocklist，你猜它有多少个碎块？

满屏！而且，还没显示完！提示按任意键继续。我按了无数个任意键，不知道过了多少个屏，才结束！

估计有几千个碎块，说不定是几万！

因此，一般来说，还是让用户尽量整理碎块吧。尤其是，当 svbus 不支持碎块时，必须要整理碎块，否则，虽然不带 --mem 的 map 命令能够成功建立虚拟盘，但进入保护模式后 svbus 会导致死机。

这些注意事项可以写到文档里面，让用户明白，有这个问题存在。

作者: 不点 时间: 2021-11-13 11:44

liuzhaoyzz 发表于 2021-11-13 11:23
一般情况下还是用map --mem模式兼容性更好，我基本不用直接map模式启动PE。各种碎片整理程序对于有足够空 ...

我似乎觉得版主大人的理解是不正确的。

按照我的理解，逻辑转换，属于硬件层面。它转换的结果，就是 bios 能看到的结果。只要 bios 看到的是连续的，那就是连续的。跟物理介质是否连续，没有任何关系。

只要 bios 看到的是连续的，windows 下的 contig.exe 也同样会看到连续的结果。

所以，连续性是一致的，不管什么软件，都会作出同样的判断。

你说的逻辑转换，那是 bios 不可见的，也是操作系统不可见的。因此，我们完全可以当作不存在。

只要用 contig.exe 整理好碎块，就不会有任何问题。你若有兴趣，可以抽时间试试看。

作者: 2011whp 时间: 2021-11-13 12:12
本帖最后由 2011whp 于 2021-11-13 12:14 编辑

pe 来说，svbus 失败，没什么影响，wim已打包好了，只是回挂不上设备

pe 启动 winload 以后所有启动资源都能访问（wim内）

系统的话，不 --mem 或不连续的话，就启动不了（启动过程的资源，依赖svbus回挂的设备）
win内核启动的资源，可以在引导阶段，准备好，再住后启动，依赖svbus回挂的设备
（winload大部分代码是引导阶段的）

pe制作者，默认是没有虚拟设备驱动的

作者: liuzhaoyzz 时间: 2021-11-13 12:21

不点发表于 2021-11-13 11:44
我似乎觉得版主大人的理解是不正确的。

按照我的理解，逻辑转换，属于硬件层面。它转换的结果，就是 b ...

实战上来讲，用wincontig已经尝试了很多次了，wincontig碎片整理是第三方软件，对于SSD没有很好的效果，wincontig也不建议将它用于ssd，这是很多次实战的效果，不是纯理论。
对于SSD，复制粘贴重命名，也是要看固件芯片写入逻辑。

而你所说的contig.exe这个命令行小程序，根本不能改变碎片分布，只能用于检测是否有碎片。

作者: 不点 时间: 2021-11-13 13:06

liuzhaoyzz 发表于 2021-11-13 12:21
实战上来讲，用wincontig已经尝试了很多次了，wincontig碎片整理是第三方软件，对于SSD没有很好的效果，w ...

你的意思是，contig.exe 不能对 ssd 盘进行碎块整理？我确实没有用它来操作 ssd 盘，因为我接触到的电脑，很少有 ssd 的。

不知其他人有没有在 ssd 盘上试验 contig.exe？

我感到不可思议，contig 不能对 ssd 进行碎块整理？

我貌似听说过，最好不要对 ssd 进行碎块整理，那会增加写入次数，影响磁盘寿命，这个道理讲得通。

但是说 contig 无法对 ssd 进行碎块整理，我觉得这说法不靠谱。

作者: 不点 时间: 2021-11-13 13:18
本帖最后由不点于 2021-11-13 13:22 编辑

2011whp 发表于 2021-11-13 12:12
pe 来说，svbus 失败，没什么影响，wim已打包好了，只是回挂不上设备

pe 启动 winload 以后所有启动资 ...

我最近接触到的，都是可以办公、上网的 PE。我测试的几个 PE.iso，它们统统含有grub4dos 实模式虚拟盘的保护模式驱动。

很容易证明它们有保护模式驱动。

1、用含有碎块的 iso 来做 map （不带 --mem），无法启动到桌面，死在 Windows logo 界面（就是，屏幕中央显示一个大大的 logo 图像）。【这里假定只有少数碎块，这种情况下，还能运行 map 命令。如果碎块太多，map 就会报错，无法执行 map 命令。】

2、整理碎块后，同样的命令，成功进入桌面，其他后续操作都正常。

以上两点，100% 证明了，这个 PE.iso 含有 grub4dos 实模式虚拟盘的保护模式驱动。

但无法确定，究竟是 svbus，还是 firadisk，或者是 winvblock。

作者: xianglang 时间: 2021-11-13 13:34
本帖最后由 xianglang 于 2021-11-14 12:15 编辑

ISO镜像碎片整理？是怎么做到的？

作者: 2011whp 时间: 2021-11-13 13:41
本帖最后由 2011whp 于 2021-11-13 13:46 编辑

不点发表于 2021-11-13 13:18
我最近接触到的，都是可以办公、上网的 PE。我测试的几个 PE.iso，它们统统含有grub4dos 实模式虚拟盘的 ...

map 是基于碎片的吧，不是基于文件吧，这个不清楚
我的理解是基于碎片的（磁盘 lba区段表，或内存区段表）

如果是基于文件，碎片多少没影响
只能说明：map 是基于碎片工作的，iso文件的碎片超了（一般超不了）

和驱动没关系，map出的虚拟设备只在引导阶段，有作用，win内核开始执行，就消失了（不认可，除非有驱动接上）

总得来说是 map 的工作方式问题（内幕不懂）

svbus 是上层读扇区，它转成读硬盘lba 或内存扇区地址，map 是不是这样的？

作者: 不点 时间: 2021-11-13 14:09

xianglang 发表于 2021-11-13 13:34
ISO镜像碎片占理？是怎么做到的？

微软自家的 contig.exe 就能整理文件的碎块。别人的工具，比如一个叫做 wincontig 的，也具有同样的功能。这是很多年前都有的工具了。只不过微软操作系统没有默认安装 contig 而已。但可以从微软的网站下载它。

你这么问，说明你不曾试用过。

作者: 不点 时间: 2021-11-13 14:16

2011whp 发表于 2021-11-13 13:41
map 是基于碎片的吧，不是基于文件吧，这个不清楚
我的理解是基于碎片的（磁盘 lba区段表，或内存 ...

不需要了解很复杂的原理。

很简单，你只要看看 iso 里面有没有 svbus、firadisk、winvblock 的相关文件，就清楚了。

如果有发现，你把它们删除掉，再重新打包 iso，那么，这样的 iso 就不支持用 map 来加载了（加载后会在启动的某个环节失败，比如，无法进入桌面）。

作者: liuzhaoyzz 时间: 2021-11-13 14:21

不点发表于 2021-11-13 14:09
微软自家的 contig.exe 就能整理文件的碎块。别人的工具，比如一个叫做 wincontig 的，也具有同样的功能 ...

实战上来讲contig.exe对于机械硬盘、ssd都无效，你用着个小工具有效吗？

作者: 2011whp 时间: 2021-11-13 14:22
本帖最后由 2011whp 于 2021-11-13 14:25 编辑

pe制作，默认没有别的第三方虚拟盘，只有微软自家的，wim 支持

（进pe里再安装的除外，像 pecmd imdiisk）

具我理解，回答标题：都没有

作者: liuzhaoyzz 时间: 2021-11-13 14:24

xianglang 发表于 2021-11-13 13:34
ISO镜像碎片占理？是怎么做到的？

wincontig.exe或者复制粘贴重命名的新文件就是连续存储的，前提是硬盘要有足够多的连续空间用于腾挪这个文件。

作者: 不点 时间: 2021-11-13 14:28

liuzhaoyzz 发表于 2021-11-13 14:21
实战上来讲contig.exe对于机械硬盘、ssd都无效，你用着个小工具有效吗？

我用了一辈子了，怎么会无效？

你有实战吗？版主大人，我严重怀疑呀。（老朋友了，滑稽一下，莫怪）

作者: liuzhaoyzz 时间: 2021-11-13 14:32
本帖最后由 liuzhaoyzz 于 2021-11-13 14:38 编辑

不点发表于 2021-11-13 14:28
我用了一辈子了，怎么会无效？

你有实战吗？版主大人，我严重怀疑呀。（老朋友了，滑稽一下，莫怪）

我真心用过contig.exe啊，他对我来说属于已经放弃的命令行方案。wincontig.exe或者复制粘贴重命名的办法都比contig.exe靠谱啊，这是很多次实战的结论。为啥你那边可靠？

请问下不点大，您用的contig.exe命令行参数是怎样的？能给个demo吗？

作者: 不点 时间: 2021-11-13 14:33

2011whp 发表于 2021-11-13 14:22
pe制作，默认没有别的第三方虚拟盘，只有微软自家的，wim 支持

（进pe里再安装的除外，像 pecmd i ...

问题是，我下载的这些 PE，都含有 grub4dos 虚拟盘的驱动。这些作者，都是以某种方式安装了那些驱动。

我就是想知道，究竟他们安装的是哪一种驱动：svbus、firadisk、winvblock，三种之中的哪一种，到目前为止，没有一个人能够说清楚。

作者: 不点 时间: 2021-11-13 14:39

liuzhaoyzz 发表于 2021-11-13 14:32
我真心用过contig.exe啊，他对我来说属于已经放弃的命令行方案。wincontig.exe或者复制粘贴重命名的办法 ...

貌似你不该说，你不用的东西都是垃圾。

contig 是经典的工具，你不爱用，那就算了。可是，你不应该把你不了解的东西，说成是很了解。那样是误导大众。

作者: liuzhaoyzz 时间: 2021-11-13 14:43
本帖最后由 liuzhaoyzz 于 2021-11-13 15:52 编辑

不点发表于 2021-11-13 14:33
问题是，我下载的这些 PE，都含有 grub4dos 虚拟盘的驱动。这些作者，都是以某种方式安装了那些驱动。

...

用7z打开pe.iso，再继续展开里面的wim文件，\windows\system32\drivers\目录下，如果含有svbus,firadisk,wvblk32/64.sys这样的关键字，那么就采用了相应的驱动，一般不会采用两种，可能会冲突。

当然注册表也有与之匹配的部分，一般地单单从pe.wim里面的文件就可以推断了。

作者: liuzhaoyzz 时间: 2021-11-13 14:44
本帖最后由 liuzhaoyzz 于 2021-11-15 13:32 编辑

不点发表于 2021-11-13 14:39
貌似你不该说，你不用的东西都是垃圾。

contig 是经典的工具，你不爱用，那就算了。可是，你不应该把 ...

您误会了，可能是我多次尝试contig.exe命令，参数没有写对，没有掌握其用法导致的，恳请指教下，我晚点再试试。话说我也没有用垃圾这个词来形容它啊。

作者: 不点 时间: 2021-11-13 14:51
本帖最后由不点于 2021-11-13 15:15 编辑

liuzhaoyzz 发表于 2021-11-13 14:44
您误会了，可能是我多次尝试contog.exe命令，参数没有写对，没有掌握其用法导致的，恳请指教下，我晚点 ...

contig 命令本身自带帮助，敲入 /? 开关，应该会显示。既然版主大人你不用它，那就算了，不多说了。

和大家要说的是，contig 是命令行工具，一般来说，命令行工具有它的好处，就是体积小，可以用于批处理。微软自家的程序，可靠性比较高，使用微软的工具，不至于把磁盘结构损坏了。所以，本人一直使用它，而从未使用过别的工具。

补充一点，顺便贬一贬你这个版主大人（咧嘴笑）：

从软件名称上就能看出，WinContig 本身就是模仿 contig，是从 contig 偷师学艺来的。版主大人记住了偷师者，却忘了源头的老师。

嗯，你没说是垃圾，可那意思就是贬义，那还不等于说是垃圾啊！（跟你这么说，没关系；跟别人，我不敢这么添油加醋开玩笑）

作者: 2011whp 时间: 2021-11-13 15:09

不点发表于 2021-11-13 14:33
问题是，我下载的这些 PE，都含有 grub4dos 虚拟盘的驱动。这些作者，都是以某种方式安装了那些驱动。

...

wim 的 pe 没有svbus、firadisk、winvblock 这三个驱动，也可以 map 启动的

微软的引导，就能做到

不和以前一样了，没有驱动，就不能用

现在，能map，不代表有第三方驱动（pe发布区，下载的pe 都不含第三方驱动的，底层是 boot.wim 或 winre.wim）

作者: 不点 时间: 2021-11-13 15:11

liuzhaoyzz 发表于 2021-11-13 14:43
用7z打开pe.iso，再继续展开里面的wim文件，\windows\system32\drivers\目录下，如果含有svbus,firad ...

还是版主大人熟悉这些东西。我不怎么接触，不知道如何找到它们。

好的，我按照你这个指引，自己应该能解答自己的疑问了。

谢谢。

作者: liuzhaoyzz 时间: 2021-11-13 15:15
本帖最后由 liuzhaoyzz 于 2021-11-13 15:22 编辑

不点发表于 2021-11-13 14:51
contig 命令本身自带帮助，敲入 /? 开关，应该会显示。既然版主大人你不用它，那就算了，不多说了。

...

Long long ago，Contig 程序是由 Windows Sysinternals 的Russinovich 编写的另一个实用程序。Sysinternals这个公司，也是个第三方的，写了很多很多小工具用于维护微软的windows系统，他最初就不是微软的，后来的后来微软好像是把这个公司给收购了。他源头上可不是微软的哟。

我在外面，手机回帖，电脑没在手边，晚点再试试。

作者: 不点 时间: 2021-11-13 15:18

2011whp 发表于 2021-11-13 15:09
wim 的 pe 没有svbus、firadisk、winvblock 这三个驱动，也可以 map 启动的

微软的引导，就能做到
...

可靠吗？你能保证吗？

是 100% 确定的呢？或者只是你猜的？

作者: 不点 时间: 2021-11-13 15:24

liuzhaoyzz 发表于 2021-11-13 15:15
Long long ago，Contig 程序是由 Windows Sysinternals 的Russinovich 编写的另一个实心实用程序。Sysi ...

看来版主大人对 contig 还很了解呀！竖起大拇指！

微软收购了，那就算是微软的了，微软就要为它的质量和可靠性负责了，对吧？

作者: 2011whp 时间: 2021-11-13 15:29
本帖最后由 2011whp 于 2021-11-13 15:33 编辑

不点发表于 2021-11-13 15:18
可靠吗？你能保证吗？

是 100% 确定的呢？或者只是你猜的？

99%吧，

没遇到过，自带三方驱动的 win10pe，（极个别的是自己弄的，比如我网盘里的）

遇到的特例是哪个贴，发布的？

作者: 不点 时间: 2021-11-13 15:42

2011whp 发表于 2021-11-13 15:29
99%吧，

没遇到过，自带三方驱动的 win10pe，（极个别的是自己弄的，比如我网盘里的）

是你不曾留意这个问题呢？还是你明确知道结果？

有时候，是自己不曾留意、不怎么关心某类问题，潜意识地认为，某情况一定是怎么怎么样子的。

这不表示真实情况究竟是不是那样的。

你是不是就像我说的那样——不曾留意这个问题，也不能确定真实的结果？

作者: 2011whp 时间: 2021-11-13 15:46

不点发表于 2021-11-13 15:42
是你不曾留意这个问题呢？还是你明确知道结果？

有时候，是自己不曾留意、不怎么关心某类问题，潜意识 ...

嗯，是的

我是 7pe 关注的少，xp pe 没怎么用过，

作者: 不点 时间: 2021-11-13 15:51

2011whp 发表于 2021-11-13 15:46
嗯，是的

我是 7pe 关注的少，xp pe 没怎么用过，

好的，那我接下来就按照 liuzhaoyzz 版主的指引，看看答案究竟是什么。其实每个人都能用版主的这个方法来检验，如果感兴趣的话。

作者: 江南一根葱 时间: 2021-11-13 15:58
现在还加Svbus之类的pe应该是找死了吧，那些东西都过不了安全启动，应用场景非常有限
现在svbus只适合pe进入桌面后安装上，用来加载外置用

作者: 2011whp 时间: 2021-11-13 16:15

江南一根葱发表于 2021-11-13 15:58
现在还加Svbus之类的pe应该是找死了吧，那些东西都过不了安全启动，应用场景非常有限
现在svbus只适合pe进 ...

好像能啊，用你的 vm 设置开启安全启动，挂上iso 能启动。
不知道你，是否, 精简了安全启动

确实是，没什么得力的应用方向。

作者: 不点 时间: 2021-11-13 16:19

江南一根葱发表于 2021-11-13 15:58
现在还加Svbus之类的pe应该是找死了吧，那些东西都过不了安全启动，应用场景非常有限
现在svbus只适合pe进 ...

你说的有道理。

不过呢，有另外一层，也许你没考虑到吧：

legacy bios 启动的情况，是没有安全启动的。

因此，我就暂时理解为，你这可能也属于“猜测”的范畴，不属于 100% 确定某情况一定发生，或一定不发生。

作者: 江南一根葱 时间: 2021-11-13 16:21
本帖最后由江南一根葱于 2021-11-13 16:23 编辑

不点发表于 2021-11-13 16:19
你说的有道理。

不过呢，有另外一层，也许你没考虑到吧：

一个巨大的pe，如果加载外置什么的只能在legacybios下使用，个人认为纯粹是浪费u盘容量，，
除非这辈子不用uefi或愿意一台一台去关闭安全启动。之前预先注入Svbus试过，容易无限转圈圈，还是在ramos玩这些比较好，一般pe就算了

作者: 江南一根葱 时间: 2021-11-13 16:30

liuzhaoyzz 发表于 2021-11-13 12:21
实战上来讲，用wincontig已经尝试了很多次了，wincontig碎片整理是第三方软件，对于SSD没有很好的效果，w ...

contig一直有用的啊，我u盘上用了十多年的
.\Contig.exe -s G:\*.*
pause

作者: 江南一根葱 时间: 2021-11-13 16:32

2011whp 发表于 2021-11-13 16:15
好像能啊，用你的 vm 设置开启安全启动，挂上iso 能启动。
不知道你，是否, 精简了安全启动

加了svbus的话，那这个iso可能就只支持这样启动了，
如果加了svbus的pe在grub4dos下map启动，或者uefi下用新的grub2启动，可能就出现楼主说的情况，启不了。哈哈

作者: gailium 时间: 2021-11-13 17:42

不点发表于 2021-11-13 16:19
你说的有道理。

不过呢，有另外一层，也许你没考虑到吧：

某些机子的安全启动可以设置用户模式，任何签名的efi都可以启动只要导入证书

作者: 2011whp 时间: 2021-11-13 18:39
本帖最后由 2011whp 于 2021-11-13 18:41 编辑

江南一根葱发表于 2021-11-13 16:32
加了svbus的话，那这个iso可能就只支持这样启动了，
如果加了svbus的pe在grub4dos下map启动，或者uefi下 ...

你的VM，没有精简掉安全启动。

找了个导入证书的安全启动，启动 g4e ，再 map --mem /svbus.pe
是可以正常启动，有回挂的 iso 光盘的。

只是应用面的问题，svbus本身还是能行的。

win内核工作阶段，估计安全启动，不归 bios管了，还有 svbus 是签名的。

作者: 江南一根葱 时间: 2021-11-13 19:03

2011whp 发表于 2021-11-13 18:39
你的VM，没有精简掉安全启动。

找了个导入证书的安全启动，启动 g4e ，再 map --mem /svbus.pe

不是这个意思，一般来说iso里的pe加svbus，为得是挂载iso本身，加载外置，
或者启动类似img之类的ramos，所以需要grub之类启动器，这样就不支持安全启动了
pe基本就用来维护，启不同的机器我肯定懒得去关安全启动
那会累死的，得不偿失

作者: 不点 时间: 2021-11-13 19:09
本帖最后由不点于 2021-11-13 19:10 编辑

好了，先生们，

我按照 liuzhaoyzz 版主所说，找了半天，没发现 svbus、firadisk、winvblock 的踪影！

请注意下文描述的细节，然后请各位给出一个合理的解释。

（我暂时离开弄点吃的，稍后再回来看大家的发言。）

1、这个 PE.ISO，当它有 3 个碎块的时候，用 map 启动，无法进入桌面，死在 Win Logo 图像显示界面。

2、当消除碎块以后，用 map 成功启动，一切正常。

【这里所说的 map 都是不带 --mem 的。也都是在 bios 下操作，不是 UEFI。】

上述死机的这种情况，说明了，仅靠实模式驱动，是不行的。所以据此可以断定：必然有保护模式驱动。也就是说，在保护模式下，windows 仍然需要访问虚拟光盘，这个虚拟光盘是 grub4dos 在实模式下建立的。而保护模式驱动（假定它是 svbus）是有 bug 的，它无法驱动含有碎块的虚拟光盘，所以，死机了。

而整理碎块以后成功进入桌面，说明它访问虚拟光盘上的文件没有遇到障碍，也就是说，svbus 之类的驱动程序起作用了。

可是，我没找到 svbus 之类的驱动程序的踪影！

希望能看到 grub4dos 开发者们的发言。我这就先撤退了。

作者: 江南一根葱 时间: 2021-11-13 19:20

不点发表于 2021-11-13 19:09
好了，先生们，

我按照 liuzhaoyzz 版主所说，找了半天，没发现 svbus、firadisk、winvblock 的踪影！

我去年试过bootmgr是完全可以访问iso里的内容的，
换句话说，我用bootmgr启动过iso
里的东西

作者: 不点 时间: 2021-11-13 19:46

江南一根葱发表于 2021-11-13 19:20
我去年试过bootmgr是完全可以访问iso里的内容的，
换句话说，我用bootmgr启动过iso
里的东西

能否分享一下细节？

怎么做的？如何配置的？

也可以指出，有什么文档可以参考学习的。

作者: 江南一根葱 时间: 2021-11-13 20:15

不点发表于 2021-11-13 19:46
能否分享一下细节？

怎么做的？如何配置的？

就是把iso当做ramos加载，vhd的那种，或者你假装iso是wim
但是启动的时候有个问题，只能请求一次iso里的某一个文件，比如Grldr

作者: 不点 时间: 2021-11-13 20:26

江南一根葱发表于 2021-11-13 20:15
就是把iso当做ramos加载，vhd的那种，或者你假装iso是wim
但是启动的时候有个问题，只能请求一次iso里的 ...

这个过程能重复再现出来吗？如果能，你给个操作步骤和说明，我试试看能否做到。

作者: sunsea 时间: 2021-11-13 20:38
本帖最后由 sunsea 于 2021-11-13 20:54 编辑

目前可以明确的是svbus不支持碎片相关处理。我没有g4d/g4e对碎片相关处理的细节也无法打补丁。所以导致按svbus的内部处理逻辑的话是只认第一个碎块或者不知道什么东西的。

另外有可能驱动文件会有改名等情况。可能还是进入PE后检查驱动、虚拟设备所使用的驱动等比较准确。

——————我是分割线——————

好久不搞具体的PE制作，有些细节有生疏，但是现代的PE应该普遍都是bootmgr将boot.wim整个读入内存的。M$的可启动WIM不是固实的。按照此表现，很有可能现在的bootmgr普遍是读一部分然后直接先取出磁盘驱动、SYSTEM等必要要素进保护模式、加快启动速度。这样就会导致不认识g4d的直接map的碎片处理的功能的保护模式驱动直接爆炸。

作者: 不点 时间: 2021-11-13 21:32
本帖最后由不点于 2021-11-13 21:34 编辑

我想再详细解释一下，以便大家能有个共同的立足点。

grub4dos 的 map 把 ISO 文件所占据的磁盘扇区序列，虚拟成一个 BIOS 磁盘的号码，也就是 0xFF，或者用 16 进制的表示是：255。

这个虚拟的磁盘号码，在实模式的时候，是可以访问到的，用 int13、DL=0xFF 就能访问虚拟光盘上的任意扇区。操作系统只要调用实模式的 int13，就毫无困难，轻松访问虚拟光盘上的任意内容。

好啦，注意，当 ISO 有 3 个碎块时，我们的实模式光盘号码 255 仍然是工作的，也就是说，只要操作系统以某种方式调用实模式的 int13，我们的实模式代码就会提供光盘的扇区数据给调用者。只有当操作系统不是用实模式来访问虚拟光盘时（也就是用保护模式时），才可能出错。而死机，就说明它不是调用实模式，而是调用保护模式的驱动代码。这个保护模式的驱动代码，要么是 svbus、firadisk、winvblock 提供的，要么是微软自己提供的。

后来在整理碎块后，成功了。这倒没什么奇怪的。最关键的，就是上述这段话。只有在保护模式下访问虚拟盘，它才可能失败。如果在实模式下访问虚拟盘，那接管控制的是 grub4dos 自己的仿真代码，这是不可能失败的。

整理碎块后成功了，则说明，这个虚拟光盘是要在保护模式被读取的，而不是进入保护模式后就被抛弃了。如果抛弃了的话，就不可能在有碎块的时候发生死机了。有碎块时死机，说明操作系统是要去读虚拟光盘的内容，但驱动程序却给出失败信息，所以死机了。如果进入保护模式以后不再去读虚拟光盘的内容，那怎么会出现死机呢？解释不通。所以，这就证明了，进入保护模式后，操作系统还要去读虚拟光盘的内容。当它顺利读取的时候（扇区序列是连续的情况）就不死机；当它读取光盘失败的时候（ISO 文件有碎块的情况），就发生死机。

作者: wintoflash 时间: 2021-11-13 22:32
本帖最后由 wintoflash 于 2021-11-13 22:34 编辑

不点发表于 2021-11-13 21:32
我想再详细解释一下，以便大家能有个共同的立足点。

grub4dos 的 map 把 ISO 文件所占据的磁盘扇区序列 ...

你分析得对，但是事实是可以启动的。
你没有启动成功可能是电脑 BIOS 的原因。在虚拟机或者其他电脑上试试。
也有可能是这个WinPE有SVBus驱动，但你没有找到。

作者: 不点 时间: 2021-11-13 23:16
本帖最后由不点于 2021-11-14 02:34 编辑

SunSea 版主说，驱动有可能被改名（换个马甲），认不出来了。

这当然是一种可能性。

Wintoflash 说，驱动可能确实存在，但我可能没找到它。

先说改名，这可能性有多大？我认为，几乎没有可能性！这些驱动都是开源免费的，任何人使用它，不需要花一分钱，不可能有人在法律上找你的麻烦，完全没有必要偷偷摸摸地改名。改名还不尊重原始作者，把本来是光明正大、堂堂正正的使用，变成了偷鸡摸狗的行为，自降人格，完全不划算！所以我认为不可能改名！其可能性是极低、极低、再极低！

再说说另一种可能性：它是存在的，但我功力不够，没能找到它。那只能说，我老年痴呆，老眼昏花，不中用了。但我确实认真搜索了，几乎把每个文件都捋了一遍，没发现那三个驱动程序的踪迹。它还能藏在哪里？它还能藏多深？我觉得，可能性也不大了。它要是真在眼皮子底下，我却找不到，那我确实痴呆、不中用了。

好吧，我们不能停留在一个地方，原地踏步。我们该向前推进了——现在正式提出这样一种新的可能性，即：正是微软自己支持了实模式的虚拟光盘！微软不一定专门支持 grub4dos 所建立的虚拟光盘，但至少没有封杀 grub4dos 所建立的虚拟光盘！结果就是支持了呗。甚至微软有可能支持任意的实模式软件所建立的虚拟光盘。对于微软来说，做这样的支持，在技术上毫无困难，是很简单的事。

作者: 不点 时间: 2021-11-14 00:11
我对于开发 Windows 软件，没有兴趣。即便有兴趣，也没有能力，不具备必要的知识。Windows 的驱动程序，我开发不了。我不仅不能开发，甚至连看懂代码、修改代码的工作都做不了。但是，yaya 、 wintoflash、chenall 你们可能具备开发的知识，至少能够看懂和修改别人的代码。现成的三个驱动程序，都有源代码，都可以参考。当然了，要是不愿意，那就不去做这个工作了。尤其是，假如微软已经做了这个工作，那就更不可能再去重复这个劳动了。微软做了吗？我们目前还不能给出肯定或否定的答案。

只有两种情况：做了，和没做。

我们假定微软做了，前面我们已经探讨过了，这种可能性蛮大的。

假定要实现一个实模式虚拟光盘的保护模式驱动，技术上可能怎样去实现？

首先，在进入保护模式之前，先搜索实模式的光盘信息，记录这些信息。最重要的信息是：光盘的第一个扇区对应于硬盘的哪个扇区号。这个信息能够找到。可以这样找：尝试读虚拟光盘的第一扇区，然后用 CPU 指令单步跟踪执行过程，在访问硬盘的地方，结束跟踪，此时已经找到了虚拟光盘在硬盘上的起始位置。至于说光盘的长度，这个可以假定是无限大，不必确定它。如此一来，就可以编写保护模式的虚拟光盘驱动了（前提是懂得编写 Windows 驱动程序的知识）。当然，这里只支持连续的扇区序列。如果不连续，那情况比较复杂，这里不深入探讨。

注意我刚才描述的这个过程了吗？根本没提到 grub4dos 建立的数据结构！也就是说，这个驱动程序，一旦编写出来，是支持任意实模式的虚拟光盘软件的，不一定是 grub4dos 所创建的虚拟光盘！

而 svbus 、 firadisk、winvblock，都是只支持 grub4dos 所建立的虚拟光盘而已，因此，它们都有改进的余地。

作者: 不点 时间: 2021-11-14 01:03
刚才假定微软做了虚拟盘的支持工作。接下来，我们得验证这个假设。

首先，我们有办法能够肯定，究竟微软是不是支持了实模式软件所建立的虚拟盘。

什么办法？办法很简单，但需要 PE 开发者给出答案！

PE 开发者，你弄出来的 PE，包含了谁的工具？包含不包含 svbus、firadisk、winvblock？如果不包含，那很简单，一定是微软支持了！

只要 PE 开发者能够斩钉截铁地说：根本不包含 svbus、firadisk、winvblock，那我们就能肯定，一定是微软做了这个工作！

好了，这第一个问题就这样解决了。

接下来是第二个问题：微软何时开始支持实模式虚拟盘的？

这就需要大家逐个追踪 PE，看看今年的、去年的、前年的 PE，......, 等等，哪一年的 iso 不支持 map。这样就能确定，微软是从啥时间开始支持 map 的。

发动大家都来试验，才能快速得到结果。

作者: 不点 时间: 2021-11-14 02:59
微软是否做了实模式虚拟盘的保护模式支持工作？这个问题也与 grub4dos 的开发有着间接的关系，甚至在某些情况下，可以认为是有直接关系的！

如果微软支持了，那就等于说，存在了第四种驱动程序（前三种是 firadisk、winvblock、svbus）。所以，grub4dos 的开发者应该知道这个事。

更有甚者，这不仅是第四种，还是内核级的，比其它三种都更有先天优势。所以，grub4dos 的开发者就更应给以重视。

grub4dos 从现实性和客观性上来讲，是服务于微软的。到目前为止，没有任何一个 Linux 发行版采用 grub4dos。

既然 grub4dos 是服务于微软，而那三个开源驱动更是服务于微软了。假如微软自己又做了这个工作，那么，整个工作（实模式的启动软件 + 实模式的虚拟盘 + 保护模式的虚拟盘）都是一体化的，全都顺畅地服务于微软。所以，我在开头说了，这可以看成是 “直接相关” 的。我说明白了吧？

作者: 2011whp 时间: 2021-11-14 09:52
引用 2015版帮助，说明，启动阶段的 map 本身就不支持碎片

map /0PE/0PE.ISO (0xff) || map --mem /0PE/0PE.ISO (0xff)
#先尝试将iso镜像直接仿真为 (0xff)（要求镜像连续存放），失败的话再将iso镜像载入内存仿真为(0xff)
map --hook
chainloader (0xff)

下面是g4d 启动有svbus的 pe.iso启动（ logo那转了好长时间）

？？？ @2011yaya2007777 g4d 现在插槽写的是什么信息，是以前的firadisk/winvblock，还是现在的 svbus

作者: 2011whp 时间: 2021-11-14 09:59
本帖最后由 2011whp 于 2021-11-14 10:05 编辑

假如第一个碎片，太小的话，肯定启动不了，太随机了，

作者: 2011yaya2007777 时间: 2021-11-14 10:08
g4d当然是以前的了。看截图，svbus是起作用了。那 --mem 到底起作用了吗？现在大家都在关注 svbus 支持不支持碎片。我建议，不加载到内存测试一次；加载到内存测试一次。希望能给一个明确的说法。

作者: 2011whp 时间: 2021-11-14 10:20
本帖最后由 2011whp 于 2021-11-15 12:05 编辑

2011yaya2007777 发表于 2021-11-14 10:08
g4d当然是以前的了。看截图，svbus是起作用了。那 --mem 到底起作用了吗？现在大家都在关注 svbus 支持不支 ...

加上 --mem 的话，一切正常， logo 那没出现卡顿

作者: 2011yaya2007777 时间: 2021-11-14 10:26
没有听说svbus的作者更新呀

作者: 不点 时间: 2021-11-14 10:29
@2011whp

你重复的试验，再次验证了我这些天多次验证的结果。

PE 里面，不管是 svbus、firadisk、winvblock，还是微软自己的驱动，总之，它不支持含有碎片的 iso 文件！

另外，你怎么知道你的 PE 里面是 svbus？我在某个 PE 里面使劲找都找不到它！你能告知它具体在什么文件夹下吗？

甭管它是不是 svbus，总之，它不支持碎片，只支持连续的。

map /0PE/0PE.ISO (0xff) || map --mem /0PE/0PE.ISO (0xff)

这行命令已经无法适应这个新情况了！

左半部分成功执行时，进入 PE 有可能死机。

确切地说，当 iso 有碎片时，若左半部分成功执行，则 PE 肯定死机，无法进入桌面。

所以，你只能加上 --mem 来运行，这样就不会死机了。

如果你能保证 iso 是没有碎片的，则不带 --mem 也能成功进入桌面。

作者: 2011whp 时间: 2021-11-14 10:31
svbus 旧的，g4e那会，朱玛签名的

这个 pe 在教程（抄作业）贴，二楼刚开始，我的网盘里有，lightning的pe,

作者: 不点 时间: 2021-11-14 10:36

2011whp 发表于 2021-11-14 10:31
svbus 旧的，g4e那会，朱玛签名的

抱歉，是我老眼昏花，没看见。您的图片已经显示出 svbus 的文件位置了。

但我在新的 Win11 PE 里面可找不到这个驱动！

作者: 2011whp 时间: 2021-11-14 10:41

不点发表于 2021-11-14 10:36
抱歉，是我老眼昏花，没看见。您的图片已经显示出 svbus 的文件位置了。

但我在新的 Win11 PE 里面可 ...

现在 pe制作者，99.9%，不加的，

那个是我自己注入的驱动（极个别，用于试验 svbus）

作者: 不点 时间: 2021-11-14 10:55
好的，看到了。

你说的 svbus 支持碎片。没有死机，只是加载太慢了。

但我提到的 Win11 PE，那可是死机了！不支持有碎片的文件！

好的，这就证明了，Win11 PE 里面，不是 svbus 的驱动。

作者: 2011whp 时间: 2021-11-14 11:09

不点发表于 2021-11-14 10:55
好的，看到了。

你说的 svbus 支持碎片。没有死机，只是加载太慢了。

试了几次，logo 那  大约三分钟

你等 10 分钟看下，如果还死机，说明  确实是svbus 有作用

制造碎片：小vhd 或者小分区  复制几次，估计，会有碎片。

得 yaya 下载pe 或自己弄一个，试。（不懂代码，只会试）

作者: 不点 时间: 2021-11-14 11:15

2011whp 发表于 2021-11-14 11:09
试了几次，logo 那大约三分钟

你等 10 分钟看下，如果还死机，说明确实是svbus 有作用

好的，就按照你说的去弄。

作者: 不点 时间: 2021-11-14 11:16

2011whp 发表于 2021-11-14 11:09
试了几次，logo 那大约三分钟

你等 10 分钟看下，如果还死机，说明确实是svbus 有作用

好的，就按照你说的去弄。

作者: 2011yaya2007777 时间: 2021-11-14 11:17
本帖最后由 2011yaya2007777 于 2021-11-14 11:24 编辑

“假如第一个碎片，太小的话，肯定启动不了，太随机了，”
这句话说的太好了！终于搞明白了，svbus不支持碎片！
如果第一个碎片太小，信息太少，windows没有弄明白是个什么物件，在那里使劲弄，转圈圈。
如果第一个碎片比较大，信息足够说明这是个iso磁盘镜像，就挂载了，顺利启动。

麻烦你再测试一下，在挂载成功后，看看能不能读出靠后的文件，比如一个txt文件，在windows下面是否可以打开，看到里面的内容。

作者: 2011whp 时间: 2021-11-14 11:34
本帖最后由 2011whp 于 2021-11-14 11:39 编辑

2011yaya2007777 发表于 2021-11-14 11:17
“假如第一个碎片，太小的话，肯定启动不了，太随机了，”
这句话说的太好了！终于搞 ...

换算了下碎片：149MB + 53MB +8 MB = 210 （实际 win 下 244MB），可能换算不准确

看来是，第一个碎片够大，logo时间长，是因为发生了无数次错误，

作者: 2011yaya2007777 时间: 2021-11-14 11:36
我猜猜，windows也和grub4dos一样，挂载的时候只获取必要的信息，搞明白是iso还是img，是fat还是ntfs，等等，再做一些必要的复核，就行了。至于这个镜像完整否，有没有坏道，一共是多少扇区，可否都可以读出来，也就不管了。

作者: 2011whp 时间: 2021-11-14 11:37
本帖最后由 2011whp 于 2021-11-15 11:35 编辑

依这样看的话：
1. svbus 不支持碎片
2. svbus 兼容以前的插槽

作者: 不点 时间: 2021-11-14 11:44
本帖最后由不点于 2021-11-14 11:47 编辑

2011yaya2007777 发表于 2021-11-14 11:17
“假如第一个碎片，太小的话，肯定启动不了，太随机了，”
这句话说的太好了！终于搞 ...

他说了，转转转，但最后还是进入了呀，这说明还是正确驱动了呀，对吧？

至于说慢，那可能是别的原因。

比如说，它不是读取 grub4dos 数据结构，而是自己以某种方式探测 iso 的真正扇区序列，结果就是很慢了。

我前面已经提到过，探测 iso 的扇区序列，在技术上是可行的。就是在实模式下采用 CPU 单步跟踪技术。这样的探测，肯定大大减低运行效率。

作者: 不点 时间: 2021-11-14 11:52

2011whp 发表于 2021-11-14 11:34
换算了下碎片：149MB + 53MB +8 MB = 210 （实际 win 下 244MB），可能换算不准确

看来是，第一个碎 ...

你这个图片，显示出光盘了！而我的 Win11 PE 进入后，没有光盘盘符！

这还是不同啊！说明 Win11 PE 不是采用 svbus。

作者: 2011whp 时间: 2021-11-14 11:53
加上 --mem 话，boot.wim 是完整的，可以 7z 打开。

作者: 2011yaya2007777 时间: 2021-11-14 12:07
在那里转圈圈，肯定是搜索什么。也可能如不点所说，windows通过其他途径搜索，也可能是由于镜像不连续，搜索到其他地方了。最终定时器看门狗把他拽回来，认为是个不重要的事，忽略了，然后挂载。

作者: 不点 时间: 2021-11-14 12:08

2011whp 发表于 2021-11-14 11:53
加上 --mem 话，boot.wim 是完整的，可以 7z 打开。

哈哈！说明 svbus 只支持第一个碎片！

而 Win11 的 PE 却根本不支持碎片，会在 logo 界面处死机。这个有待进一步验证，我准备等待 2 小时，确认它是不是死机了。

作者: 2011yaya2007777 时间: 2021-11-14 12:10
再说，如果windows通过其他途径搜索，那第一块碎片小，也不影响他通过iso结构搜索，也应当在转圈圈后进入桌面呀。纯属瞎猜测。

作者: xianglang 时间: 2021-11-14 12:20

不点发表于 2021-11-13 14:09
微软自家的 contig.exe 就能整理文件的碎块。别人的工具，比如一个叫做 wincontig 的，也具有同样的功能 ...

WinContig 我在用啊，但是不知道如何用它整理 ISO 内部的文件碎片——是不是我又理解错了，你们说的整理ISO文件碎片，是指ISO放在硬盘中的碎片，而不是ISO内部的文件碎片？或者做成ISO，内部的文件根本就没有碎片？

作者: 2011yaya2007777 时间: 2021-11-14 12:24
不加--mem的话，boot.wim是打不开，还是？其实，打开只是搜索了文件目录，这个肯定在第一碎片，但是读后面碎片的真实文件就有问题了。

作者: 9001 时间: 2021-11-14 12:27

不点发表于 2021-11-13 13:18
我最近接触到的，都是可以办公、上网的 PE。我测试的几个 PE.iso，它们统统含有grub4dos 实模式虚拟盘的 ...

SSD的存取机制决定了它不希望连续存放。大容量文件连续存放到SSD盘上对它来说是个灾难，多次下去很容易提前挂掉

作者: 不点 时间: 2021-11-14 12:27

xianglang 发表于 2021-11-14 12:20
WinContig 我在用啊，但是不知道如何用它整理 ISO 内部的文件碎片——是不是我又理解错了，你们说的整理I ...

ISO 内部的文件，全都是连续的，不可能有碎片。所谓整理 iso 碎片，就是整理 iso 文件本身在盘上的碎片。

作者: 2011yaya2007777 时间: 2021-11-14 12:28
纠正一下，map是支持碎片的。问题是windows在虚拟模式是通过svbus读光盘镜像，而不是通过g4d读光盘镜像。

作者: 2011yaya2007777 时间: 2021-11-14 12:32
iso文件肯定是连续存放的。是他保存在磁盘上被碎片化了。

作者: 不点 时间: 2021-11-14 12:34

2011yaya2007777 发表于 2021-11-14 12:24
不加--mem的话，boot.wim是打不开，还是？其实，打开只是搜索了文件目录，这个肯定在第一碎片，但是读后面 ...

根据 2011whp 的描述，我理解为，svbus 只支持第一个碎片。或者说，它认为 iso 是连续的，就是说，从第一扇区开始，直到文件长度指定的结尾处，就是 iso 的扇区序列。尾巴部分肯定是错的。它把错误的扇区数据提供给上层的调用者，这当然会出现各种错误了。

不过，比 Win11 PE 的还是要好一点。Win11 PE 干脆是死机。等我今天下午进一步确认的结果。

作者: 不点 时间: 2021-11-14 12:39

2011yaya2007777 发表于 2021-11-14 12:24
不加--mem的话，boot.wim是打不开，还是？其实，打开只是搜索了文件目录，这个肯定在第一碎片，但是读后面 ...

他的图片已经显示出来错误信息了。7z 打开 boot.wim 时报错，说这个文件格式不对，无法打开。

作者: 2011yaya2007777 时间: 2021-11-14 12:42
不点，如果w11 pe 加 --mem 可以启动的话，那启动以后，像2011whp的那张截图，可以看见与挂载iso镜像有关的驱动，看看是些什么。

作者: 不点 时间: 2021-11-14 12:50

2011yaya2007777 发表于 2021-11-14 12:42
不点，如果w11 pe 加 --mem 可以启动的话，那启动以后，像2011whp的那张截图，可以看见与挂载iso镜像有关的 ...

我前面已经说过了，win11 PE 启动后，看不见光盘盘符。它隐藏了光盘盘符。

不过，我用 liuzhaoyzz 版主的办法，可以直接在 iso 文件中浏览文件。

其结果是，根本找不到 svbus、firadisk、wvblk 之类的名字！

下午我再专门测试一遍，尽量保证测试结果准确可靠！

作者: 江南一根葱 时间: 2021-11-14 12:58

2011whp 发表于 2021-11-14 09:52
引用 2015版帮助，说明，启动阶段的 map 本身就不支持碎片

下面是g4d 启动有svbus的 pe.iso启动（ ...

加了是会转半天，所以坚决不加svbus
我一般在确定进入桌面后开svbus

作者: sunsea 时间: 2021-11-14 12:58

不点发表于 2021-11-14 12:50
我前面已经说过了，win11 PE 启动后，看不见光盘盘符。它隐藏了光盘盘符。

不过，我用 liuzhaoyzz 版 ...

svbus从代码层面我反复确认过是默认连续，意思是应该只认第一个碎片。

（手动删除线）真正的确认方法是找一下你说的那个win11PE，用mem进一次系统，右击虚拟光盘盘符，在设备里看看是什么搭载的。然后非mem等待2小时或者类似时间排除进行搜索的可能性。（手动删除线）

可否分享一下这个win11 PE以供测试？突然对这个PE的结构好奇了，想做一些分析。

作者: 江南一根葱 时间: 2021-11-14 12:58

2011whp 发表于 2021-11-14 10:20
加上 --mem 的话，一切正常， logo 那没出现卡顿

map --mem后，可能就不存在碎片了吧，我猜的

作者: liuzhaoyzz 时间: 2021-11-14 13:02
我电脑上面的很多文件，都是连续存储的，没有什么碎片。
我写了个批处理用于批量测试，支持文件拖放。
实测contig.exe确实是支持碎片整理的，只测试了机械硬盘上面的1个文件。ssd上面的文件都是连续存储的，可能是之前被我整理过了，找不到碎片文件，没法更进一步地详细测试。
测试的办法是用everything搜索大于100MB的文件，搜索栏输入size:>100MB，大文件下载的时候更容易出碎片，然后根据提示拖放到批处理上。

contig.exe整理文件碎片实在是太慢了，慢得无法接受，不如直接复制粘贴重命名来得快。当时RAMOS一键的时候，可能是考虑到contig.exe整理文件太慢了，放弃的，不是因为contig.exe无效放弃的。抱歉误导人了。

测试contig.rar

101.71 KB, 下载次数: 9, 下载积分: 无忧币 -2

作者: 不点 时间: 2021-11-14 13:05

sunsea 发表于 2021-11-14 12:58
svbus从代码层面我反复确认过是默认连续，意思是应该只认第一个碎片。

（手动删除线）真正的确认方法 ...

这种 Win11 PE 多得很，随便找一个试试就知道了。

在 “PE作品发布区” 随便找一个就行。比如这个：

[分享] 2021.11.10更新【252M】WIN11PE_X64_22000.282、自制自用、办公、影音、网络版纯净...
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=427561

作者: 2011whp 时间: 2021-11-14 13:12
本帖最后由 2011whp 于 2021-11-15 11:41 编辑

江南一根葱发表于 2021-11-14 12:58
加了是会转半天，所以坚决不加svbus
我一般在确定进入桌面后开svbus

现在是讨论，有碎片的，不点大的，不加svbus 有碎片，启动不了

没有碎片（或者加 --mem），没问题的

作者: liuzhaoyzz 时间: 2021-11-14 13:28

不点发表于 2021-11-14 10:29
@2011whp

map /0PE/0PE.ISO (0xff) || map --mem /0PE/0PE.ISO (0xff)
这个命令，基本属于无效命令，因为如果前半句直接map 0PE.ISO挂了，就会死机了，哪里有机会执行后半句？论坛里大家都是抄菜单，没有实际验证过吗？

如果先执行blocklist (...)/.../PE.iso，根据结果判断没有碎片，再执行map /0PE/0PE.ISO (0xff)，这样子的判断才是有用的，但是这样子菜单太麻烦了，简单起见，还是map --mem /0PE/0PE.ISO (0xff)这样子用方便，一个维护型的PE.ISO能有多大？一般在1GB以内，一般地能够直接放在内存中了。

作者: liuzhaoyzz 时间: 2021-11-14 13:30
本帖最后由 liuzhaoyzz 于 2021-11-15 06:37 编辑

关于map命令，不点大，这个命令可是您原创的呀，怎么很多事情反而忘了。
g4d的直接map pe.iso (0xff)仿真命令，要求pe.iso在磁盘上必须连续存放，如果磁盘上找不到pe.iso这么大小的连续存储区域，碎片整理就无法完成，pe.iso就无法启动；
g4d的map --mem pe.iso (0xff)或者map --mem --top pe.iso (0xff)仿真到内存命令，要求pe.iso在内存上必须连续存放，如果内存上没有连续区域存放这个仿真的pe.iso，就无法启动。

pe.iso即使没有firadisk/winvlbock/svbus驱动，也可以启动，因为PE有自己的ramdisk.sys驱动，这个驱动是微软的，用来搭配boot.sdi创建的内存盘并从内存盘上面启动，bootmgr/bootmgfw.efi认识这个内存盘，g4d/g4e+map PE.ISO/map --mem PE.ISO启动的过程，是仿真出一个虚拟盘/内存盘，然后g4d把控制权移交给虚拟盘/内存盘里面的bootmgr/bootmgfw.efi，由微软的bootmgr/bootmgfw.efi加载boot.sdi挂载pe.wim+ramdisk.sys驱动创建的内存盘，并从这个内存盘继续启动。
这个启动过程中，不需要firadisk/winvlbock/svbus驱动参与，那为什么有人的PE里面要加这样子的驱动？
firadisk/winvlbock/svbus驱动可以把g4d在实模式下创建的仿真盘或者内存盘带入windows下，使之继续有效，结果就是PE.ISO启动过程中，可以继续访问这个仿真盘或者内存盘，利用pecmd挂载PE.ISO里面的外置程序，如果没有firadisk/winvlbock/svbus驱动加持，PE.ISO里面的外置程序可能找不到，无法加载。

当然，全内置版本的PE会把软件全部放到pe.wim中，用bootmgr/bootmgfw.efi+boot.sdi+ramdisk.sys加载，也就不需要firadisk/winvlbock/svbus这样子的第三方驱动了，由此带来的副作用就是pe.wim较大，启动较慢，大小也有限制，bootmgr/bootmgfw.efi似乎只能加载1.5-3.25GB大小的wim到内存，因不同的电脑不同而不同。

只有外置版本的PE需要firadisk/winvlbock/svbus这样子的第三方驱动，由此带来的副作用就是pe.iso里面的外置程序用map --mem启动会占用内存。

作者: wintoflash 时间: 2021-11-14 13:57
本帖最后由 wintoflash 于 2021-11-14 14:24 编辑

以下讨论先限定一下范围：
1. NT6 及以上版本的 Windows (Windows VISTA 及以上版本)。
2. 启动 ISO 里面 WIM 格式的镜像 (WinPE)。
3. ISO 里面启动 WIM 用的引导是微软官方的 bootmgr，而不是 wimboot/freeldr 等第三方引导器。
4. ISO 里面的 WinPE 没有安装 firadisk/winvblock/svbus 等第三方驱动。

bootmgr 是由两部分组成的，头部是一些启动代码，后面是一个压缩的 bootmgr.exe 。
头部的代码可以被其他引导程序加载(比如 GRUB)，进入的时候是实模式的。

头部切换到保护模式，解压 bootmgr.exe。
bootmgr.exe 是个标准的 32 位 PE 文件，头部加载这个 PE 文件，并执行这个文件。
入口函数是这样的：void entry_point (struct bootapp_descriptor *bootapp)。
头部会生成 struct bootapp_descriptor 这个结构体，把它传递给 bootmgr.exe。
这个结构体里面包含了 E820 内存映射，还有两个回调函数，以供 bootmgr.exe 未来使用。

struct bootapp_descriptor {
char signature[8];
uint32_t version;
uint32_t len;
...
// 内存映射
struct bootapp_memory_map mmap[n];
...
// 回调函数
void (*call_interrupt) (struct bootapp_callback_params *params);
void (*call_real) (struct bootapp_callback_params *params);
...
}

复制代码

回调函数的形式是这样的: void callback_func (struct bootapp_callback_params *p)。
bootmgr.exe 可以用第一个函数来调用各种中断。
很容易就可以想象到，传递的 struct bootapp_callback_params *p 这个指针里面包含了中断的编号，还有各个寄存器的值。

struct bootapp_callback_params {
uint32_t interrupt;
uint32_t eax;
uint32_t ebx;
uint32_t ecx;
uint32_t edx;
uint32_t esp;
uint32_t ebp;
uint32_t esi;
uint32_t edi;
uint32_t cs;
uint32_t ds;
uint32_t ss;
uint32_t es;
uint32_t fs;
uint32_t gs;
uint32_t eflags;
}

复制代码

这个函数会切到实模式，设置各个寄存器的值，执行对应的中断，再保存各个寄存器的值，切回保护模式。
第二个函数用来调 PXE 功能 (或者其他东西)，这个与讨论没有什么关系。

bootmgr.exe 运行在保护模式中，如果读磁盘就调用头部提供的回调函数，切到实模式调 int13h，再切回来。
因此它是可以读取 grub4dos (或者其他引导器) 创建的int13h虚拟盘。
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 创建的这个光盘。

-----------------------------

如果 WinPE 装了 SVBus 驱动，在转圈的时候加载了这个驱动，这个驱动也会读取 GRUB4DOS 写在低地址的 map 信息。
但是这个驱动图省事，没有读取碎片列表，也不对信息的有效性做检查，因此如果文件不连续，那生成的虚拟盘就会出问题，可能导致死机。
-----------------------------

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

作者: 2011yaya2007777 时间: 2021-11-14 13:58
这解释的很好。

作者: wintoflash 时间: 2021-11-14 14:15

2011yaya2007777 发表于 2021-11-14 13:58
这解释的很好。

不知道 GRUB4DOS 的碎片表一般在内存的什么位置？
我知道以下位置是有可能被 Windows 在启动过程中占用/污染的 (仅供参考)：
0x20000 - ？ bootmgr 的基地址是 0x20000
0x30000 - 0x40000 bootmgr.exe 会用这个地址存放int13h磁盘读写数据
1MB-8MB (不确定), 2GB-4GB (似乎 Server 版系统会用这个区域)

作者: 2011yaya2007777 时间: 2021-11-14 14:39
在0x9ffff以下，一般在0x80000以上。

作者: liuzhaoyzz 时间: 2021-11-14 14:46

wintoflash 发表于 2021-11-14 13:57
以下讨论先限定一下范围：
1. NT6 及以上版本的 Windows (Windows VISTA 及以上版本)。
2. 启动 ISO 里 ...

超级棒的解释！

欢迎光临无忧启动论坛 (http://wuyou.net/)