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

liuzhaoyzz

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


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

不点

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 12:58
加了是会转半天，所以坚决不加svbus
我一般在确定进入桌面后开svbus

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



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

liuzhaoyzz

不点 发表于 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

关于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

以下讨论先限定一下范围：
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 未来使用。

1. struct bootapp_descriptor {
   
2.         char signature[8];
   
3.         uint32_t version;
   
4.         uint32_t len;
   
5.         ...
   
6.         // 内存映射
   
7.         struct bootapp_memory_map mmap[n];
   
8.         ...
   
9.         // 回调函数
   
10.         void (*call_interrupt) (struct bootapp_callback_params *params);
    
11.         void (*call_real) (struct bootapp_callback_params *params);
    
12.         ...
    
13. }

复制代码

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

1. struct bootapp_callback_params {
   
2.         uint32_t interrupt;
   
3.         uint32_t eax;
   
4.         uint32_t ebx;
   
5.         uint32_t ecx;
   
6.         uint32_t edx;
   
7.         uint32_t esp;
   
8.         uint32_t ebp;
   
9.         uint32_t esi;
   
10.         uint32_t edi;
    
11.         uint32_t cs;
    
12.         uint32_t ds;
    
13.         uint32_t ss;
    
14.         uint32_t es;
    
15.         uint32_t fs;
    
16.         uint32_t gs;
    
17.         uint32_t eflags;
    
18. }

复制代码

这个函数会切到实模式，设置各个寄存器的值，执行对应的中断，再保存各个寄存器的值，切回保护模式。
第二个函数用来调 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

这解释的很好。

wintoflash

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

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

2011yaya2007777

在0x9ffff以下，一般在0x80000以上。

liuzhaoyzz

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

超级棒的解释！      

2011yaya2007777

liuzhaoyzz  你也解释清楚什么时候需要svbus了。

不点

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

以前的结论, 统统都不可靠了.

暂时我只能无语了. 我投降. 我得不出任何结论!!!!!

你们继续.

2011yaya2007777

liuzhaoyzz说了，svbus用于pe加载外置应用程序。不过，我不知道理解的对不对，不使用svbus，windows加载了光盘镜像的一部分。剩余的部分没有加载，windows下就看不到。而想读剩余部分，必须通过类似svbus这样的驱动来读这些外置应用程序。

2011whp

不点 发表于 2021-11-14 15:20
报告个不幸的消息, 今天下载新版 iso 试验, 30 个碎片, 不带 --mem 居然成功进入桌面!

以前的结论, 统统 ...

第一碎片 ，多大，有没有logo 等待
碎片的 随机性大

map --mem  /pe.iso  是正解方法

2011yaya2007777

是不是这样，pe.iso内部包含内核boot.wim和外置应用程序。先map /pe.iso (0xff)一个仿真盘，然后通过bootmgr加载boot.wim，再加载svbus。进入桌面后，通过svbus读取外置应用程序。要是这样的话，那转圈圈就与光盘镜像连续不连续无关了。只是不加svbus此时无法读外置应用程序；如果加了svbus，而光盘镜像不连续，那就只能读外置应用程序的一部分。

wintoflash

2011yaya2007777 发表于 2021-11-14 15:35
是不是这样，pe.iso内部包含内核boot.wim和外置应用程序。先map /pe.iso (0xff)一个仿真盘，然后通过bootmg ...

转圈的时候windows在读磁盘，如果觉得这个磁盘有毛病就不干了。
所以最好还是别加svbus。

2011whp

pe软件位置：
  内置： 在boot.wim 内部
  中置： 在pe.iso光盘根目录，有软件目录 （这个情况：超版说的 外置）
   外置： 在u盘的  某个 目录，不在 iso内

sunsea

不点 发表于 2021-11-14 15:20
报告个不幸的消息, 今天下载新版 iso 试验, 30 个碎片, 不带 --mem 居然成功进入桌面!

以前的结论, 统统 ...

看以前分析bootmgr/ntldr的行为的帖子，BIOS下bootmgr是用实模式读完启动要件：bcd、SYSTEM、ntoskrnl.exe、必要磁盘驱动等再进保护模式的。boot.wim肯定也算启动要件之一。现在需要排除是：
情况1，bootmgr先从boot.wim里取出相关要件后，进入保护模式，用磁盘驱动读剩下的非要件的东西，比如smss.exe之流。
还是
情况2，bootmgr实模式下完整载入boot.wim到内存，从内存中取出要件（以我个人印象，应该是这个情况，没道理大改，尤其是现在启动盘速度普遍都很快）

目前考虑找一个USB启动速度十分拉垮的属于上古的Native技术应用环境的烂机进行启动测试。如果是情况1，速度应该比情况2快很多。这有理论支持：boot.wim所用格式是不固实的，从其中单独取出文件是非常快的。

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

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

这段解释很好，所以有可能需要对svbus等进行补丁，让g4e把映射插槽、碎片表等写到UEFI环境变量等不受干扰的区域，前640KB实在不太保险。实模式的g4d考虑到目前应用日渐减少，可以不动。或者找个更加保险的地址。但是考虑到g4d是接管int13方式进行map，所以可能也没有太多自由……仅供参考吧？

2011whp

wintoflash 发表于 2021-11-14 15:37
转圈的时候windows在读磁盘，如果觉得这个磁盘有毛病就不干了。
所以最好还是别加svbus。

这个，不会吧

我这  svbuspe 直接 虚拟机挂 光盘，一直这样，没感知

时间长了，各种启动，估计有过，不出问题的 ，搜不到 就不挂，

liuzhaoyzz

不点 发表于 2021-11-14 15:20
报告个不幸的消息, 今天下载新版 iso 试验, 30 个碎片, 不带 --mem 居然成功进入桌面!

以前的结论, 统统 ...

支持含有碎片的文件仿真 - GRUB4DOS - 无忧启动论坛 - Powered by Discuz! http://wuyou.net/forum.php?mod=viewthread&tid=327458
2011yaya2007777 发表于 2014-3-19 11:08:43
也就是说，2014年3月之后，由yaya主导的g4d 0.46a分支，可以支持32个碎片的仿真，这是在实模式层面解决了问题；进入windows保护模式之后，firadisk/winvblock/svbus估计是不支持，在g4e那个帖子，sunsea超版、yaya、wintoflash对这一类驱动有过源代码级别的讨论。

2011whp

直接挂虚拟机启动：无等待，很快


是 怕 挂上 有碎片的 iso，这样会出错

sunsea

2011whp 发表于 2021-11-14 16:13
直接挂虚拟机启动：无等待，很快

SVBus逢碎片出错基本是必然。它只认长度和起始位置，会把一大块无关数据带入或只承认第一个数据，windows很可能碰到这样的不正常的磁盘就不干了。

liuzhaoyzz

2011yaya2007777 发表于 2021-11-14 15:35
是不是这样，pe.iso内部包含内核boot.wim和外置应用程序。先map /pe.iso (0xff)一个仿真盘，然后通过bootmg ...

是的。


不论是什么磁盘，要想在windows下面被识别读取，必须有对应的驱动。
对于boot.sdi挂载的那个X:盘，windows要想识别它，就需要驱动，这个驱动就是微软的ramdisk.sys。
对于g4d仿真pe.iso的那个(0xff)盘，windows要想识别它，就需要驱动，这个驱动就是第三方的firadisk/winvblock/svbus，如果没有第三方的firadisk/winvblock/svbus驱动，windows不认识g4d仿真的那个(0xff)盘，切换到保护模式之后，pe找不到(0xff)盘里面的外置程序，一般人的PE都是pecmd遍历各个分区是否有外置程序，(0xff)盘在windows下面不存在，当然无法找到外置。但是微软自己的ramdisk.sys驱动是存在的，pe.wim挂载到了X：盘，这个盘由于ramdisk.sys驱动的加持，所以在windows下面是能够看到的。

不点

2011whp 发表于 2021-11-14 15:24
第一碎片 ，多大，有没有logo 等待
碎片的 随机性大

第一碎片只有 64 个扇区。快速进入系统，没有任何异常。

我怀疑他的新版在进入保护模式以后不再访问光盘了，因此永远不会出问题。

这就没法找问题了。

江南一根葱

2011whp 发表于 2021-11-14 13:12
现在 是讨论，有碎片的 ，不点大的，不加svbus 有碎片，启动不了

对全内置pe来说，不管是map --mem还是不--mem，svbus都是非常有害的
启动后会占用大片内存，而且。。一般svbus我可以用来网启外置型的pe

zhczf

又看到不点大师的指点。感谢分享经验。

wintoflash

sunsea 发表于 2021-11-14 16:00
看以前分析bootmgr/ntldr的行为的帖子，BIOS下bootmgr是用实模式读完启动要件：bcd、SYSTEM、ntoskrnl.ex ...

boot.wim所用格式是不固实的，从其中单独取出文件是非常快的。

WIM 支持的压缩方式有三种：LZX, XPRESS, LZMS。
前两种是非固实的，LZMS 是固实的，但是微软不支持启动 LZMS 压缩的 WIM。

BIOS下bootmgr是用实模式读完启动要件：bcd、SYSTEM、ntoskrnl.exe、必要磁盘驱动等再进保护模式的。boot.wim肯定也算启动要件之一。

你应该把bootmgr分成两个独立的部分来看。
bootmgr头部 负责实模式/保护模式切换，为 bootmgr.exe 提供磁盘读写 (int13h) 功能。
bootmgr.exe  处在保护模式中，调用bootmgr头部的功能读取磁盘。
其他微软的启动器也有类似的结构，比如 pxeboot.n12, etfsboot.com, ntldr。
这个 bootmgr 头部是有开源实现的，那就是 wimboot。

sunsea

wintoflash 发表于 2021-11-14 21:49
WIM 支持的压缩方式有三种：LZX, XPRESS, LZMS。
前两种是非固实的，LZMS 是固实的，但是微软不支持启 ...

感谢补充和纠正，是我不严谨了。有时间我研究下那个wimboot。

不点

liuzhaoyzz 发表于 2021-11-14 13:30
关于map命令，不点大，这个命令可是您原创的呀，怎么很多事情反而忘了。
g4d的直接map pe.iso (0xff)仿 ...

liuzhaoyzz 大人, 您是 grub4dos 的收藏家。grub4dos 的历史，都在您手上掌握着。将来您开个博物馆，让大家去参观。

grub4dos 是发展变化的。我做过初期的工作，打好了基础，我也承认，这很不容易，十分辛苦。当时的开发、发布，是以天为单位来进行的，甚至一天发布多次。后来，开发团队壮大了，我也就轻松一些。再后来我身体不行，逐渐退出。

开发团队的成员（包括我本人），个个都拿出自己 120% 的能力来开发！这一点，我特别有感触。因此，我对开发团队很满意。如果反过来，一个开发者有 100% 的能力，却只拿出 90% 的水平来开发，那就糟糕了。我们的开发者，都是超水平发挥，超过他本人原有的水平。那是一种精神，不单单只是技术水平。

liu 版主，您不是开发者，但您也是超水平发挥。在我心目中，您也是开发者（此处是指 grub4dos 的开发者）！真的，一点都不虚伪，完全不是客套话！在 grub4dos 上像您这样超水平发挥的人，还有不少，我都很敬佩！

当初，map 只支持连续的、没有碎片的映像文件。yaya 改进后，支持碎片不太多的映像文件。有碎片的文件如果不能 map，这也确实影响 grub4dos 的应用范围。支持碎片以后，大多数映像文件都可以 map 了。这个改进很不容易，yaya 做了超级漂亮的工作。如果 svbus 支持碎片的话，那就没有任何问题了。但是，偏偏 svbus 不支持碎片，所以这才引出问题，这属于节外生枝，责任不应该归咎于 grub4dos 的开发者。当然，也不是 svbus 的开发者的错，只不过是他还没来得及改进罢了。

出了问题以后，那就得找补救措施，也就是 workaround。开发者和用户，都可以开动脑筋，寻找合理的补救措施。

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


就是说，从用户层面，也能有 workaround 的办法，那就是，在保护模式下，尽量不访问虚拟盘，这样，永远都不会失败！这就是一个极好的 workaround 了，这种情况根本就不需要安装 svbus 之类的驱动程序。当然，还会有别的 workaround，从不同的角度来解决问题。

不多说了。谢谢 liu 版主，谢谢朋友们！

2011whp

试了  map 是支持碎片的，
     内部有 svbus 的话，搜不到 挂载信息，还好， 忽略了，一切正常
     但，用 g4d 启动的话，有碎片，svbus就挂上残缺的 设备了( pe.wim 内的程序一切正常）