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

liuzhaoyzz

不点 发表于 2021-11-15 10:39
liuzhaoyzz 大人, 您是 grub4dos 的收藏家。grub4dos 的历史，都在您手上掌握着。将来您开个博物馆，让大 ...

不点大，我对g4d、g4e、wee没有什么实质性的贡献，微薄的反馈不足挂齿。不点、bean、chenall、2011yaya2007777、wintoflash，你们才是真正的大神级人物，正是因为有了不点创立的g4d项目，RAMOS才有了五彩缤纷的玩法；因为有了wintoflash、2011yaya2007777魔改的grub2、g4e，UEFI下面的RAMOS才开启了一片新天地！真的是代码改变世界。

不点

liuzhaoyzz 发表于 2021-11-15 14:33
不点大，我对g4d、g4e、wee没有什么实质性的贡献，微薄的反馈不足挂齿。不点、bean、chenall、2011yaya20 ...

从另一个视角看，世上就是一片虚无，也本没什么叫做贡献的东西。做任何事情，只要自己满意、对得起自己的良心，那就行。有的人，自己掌握着技术，就要迫不及待地拿出来逞凶狂，在世界各地狂轰滥炸，没有丝毫怜悯之情。你说他是人不是人？他也是人，但其行为，却不像是人，至少可说，那是野蛮，不能代表文明。

在年轻时，我曾打死过老鼠。但现在，我连蚂蚁都不会去踩，甚至连草都不踩。它们也是生命，不能够因为我强大、我有能耐，就耍威风，而去伤害它们。它们也是伟大的生命，它们也和我们一样，为生存而奔波，十分艰难。如果我今天救助了一只流浪猫或流浪狗，我晚上睡觉的时候，就特别香甜。我不是在救猫和狗，而是在救自己，我是在救自己的良心。救猫、救狗，不是给别人看的，而是给自己看的。

无论是频频使用炸弹之母的人，还是那些接济贫穷的人，都有一个共同点：自己满意，自己能睡个好觉。大家都在用自己的行为来解释整个宇宙的本质。

2011grassll

心安即自在
禅宗二祖当初已得达摩心印
百多岁时还是讲在调心

liuzhaoyzz

顺便说下PE启动关于相关驱动两个相关的话题。
1.外置版PE不搭配Firadisk/winvblock/svbus也实现map盘的挂载访问，比如USBOS里面的WIN8 10PE，chinanet用的是启动到PE桌面之后，用pecmd调用imdisk挂载pe.iso，这个pe.iso挂载之后，里面的外置就可以访问了。但是这样做的缺点是约定目录下的“USBOSV3.iso”文件不能改名移动位置，而且PE运行之后不能脱盘运行，如果部署在硬盘可能会导致这个文件所在的磁盘不能被格式化。
2.ventoy不搭配Firadisk/winvblock/svbus也可以实现pe.iso外置程序的挂载访问。原理好像是ventoy在pe启动过程中对ISO进行挂载，Windows 8+的版本是通过Win32 VirutalDisk API实现的，Window7是借助imdisk挂载。详见63楼longpanda解释：
http://wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=419840&pid=4027370&fromuid=298214


上面的方案，都不利用Firadisk/winvblock/svbus这样子的驱动，而利用windows API或者imdisk在PE启动过程中挂载ISO，挂载之后能够找到外置程序。
而ventoy在grub2底层做了文件碎片解析识别的工作，类似于g4d在实模式下支持的多碎片磁盘仿真，他是一整套解决方案。

Linux发行版虽多但是bootloader就几种，isolinux grub lilo等，另外也是有几个大系列的，rhel\suse\debian等，目前Ventoy都支持这些系列，而且Ventoy virtual CDROM的原理是底层虚拟重组了ISO文件，有比较大的灵活性。比如对于WinPE，所有的WinPE都遵循一般PE的启动流程，都会有一些公共的文件，比如大部分都会有Winpeshl.exe或WinLogo.exe或WinLoad.exe，Ventoy底层实际上在上层不感知的情况下把Wim文件中的这个exe给换掉了，换成了我的一个exe, 先执行我，再执行原始文件，在这中间就可以有所为。
Linux的initrd也类似，所有的Linux内核都首先执行 init程序，而intird里面的这个程序也是被我底层换掉了，先跑我再exec 原来的。

ventoy的这套机制，“虚拟CDROM”、“重组ISO”、“exe之替换注入”等，使得它可以启动NTFS分区上面的一些livecd-linux.iso，有些livecd-linux.iso直接用g4d/g4e/grub2从NTFS分区是启动不了的，比如以下ISO搭配g4d/g4e/grub2，是不能放在NTFS分区启动的，只能放在FAT32、exfat、ext2、ext3、ext4分区启动,可能是initramfs没有挂载NTFS驱动，不知道linnux5.15新内核支持NTFS3之后会不会好一点。
debian10.8，debian-live-10.8.0-amd64-kde.iso
kali，kali-linux-2020.4-live-amd64.iso
openSUSE，openSUSE-Leap-15.3-DVD-x86_64-Media.iso
newstart,NSDL-V3.3.2-Community-x86_64.iso
Fedora，Fedora-Workstation-Live-x86_64-33-1.2.iso
elementaryOS，elementaryos-5.1-stable.20200814.iso
......

sunsea

liuzhaoyzz 发表于 2021-11-17 09:53
顺便说下PE启动关于相关驱动两个相关的话题。
1.外置版PE不搭配Firadisk/winvblock/svbus也实现map盘的挂 ...

直接处理到如此层次也是一个方案，只不过这个技术层次就非常高了。在此表达一下膜拜。

不过还有个少许的问题，imdisk等还是需要文件系统作为支持才能认识路径（当然直接指定\\.\PhysicalDrive0这种的话似乎也能处理连续扇区序列？）。SVBus之流直接处理到扇区序列所以能够对一些比较IMBA的隐藏方案提供支持。

所以我目前还是希望给svbus打个补丁，让它能够处理碎片。

liuzhaoyzz

sunsea 发表于 2021-11-17 10:56
直接处理到如此层次也是一个方案，只不过这个技术层次就非常高了。在此表达一下膜拜。

不过还有个少许 ...

Grub4dos map命令使用USBOSV3.iso

由于NT 5内核的Windows有WinVBlock（USBOS 2003 PE已集成）及FiraDisk等支持Grub4dos仿真盘的驱动程序加持，用以下G4D代码装载任意目录下的“USBOSV3.iso”，2003 PE或许都能加载到外置工具。即G4D负责从iso仿真盘引导PE，而WinVBlock或FiraDisk负责让PE认知G4D的仿真盘！

title USBOSV3.iso

find --set-root /MYiSO/USBOSV3.iso

map --mem /MYiSO/USBOSV3.iso (hd32)

map –hook

chainloader (hd32)

可是在NT 6.2以上内核的Windows 8/8.1/10下，因已有的上述类似驱动程序（例如FiraDisk、SVBus）存在导致某些机器启动PE特别慢等问题，20211020已从NT 6.2以上内核中去除此类驱动。因此，仅用以上代码启动USBOSV3.iso，这类PE可能无法加载外置工具。USBOS的解决办法是：PE启动的过程中，一旦未能搜索到外置程序，就运行ImDisk装载约定目录下的“USBOSV3.iso”到虚拟驱动器，如果USBOV3.iso被成功地装载到虚拟驱动器，那么PE访问外置软件包就不成问题了。即G4D负责从iso仿真盘引导PE，而ImDisk负责装载iso到虚拟驱动器供PE访问！

USBOS约定用于存放USBOSV3.iso的目录是：

①、任意可见分区的根目录、“ISO”或“ISOS”目录，例如U:\USBOSV3.iso、G:\ISO\USBOSV3.iso或V:\ISOS\USBOSV3.iso等；

②、UD根目录，即(UD)/USBOSV3.iso。

可供参考的G4D代码如下：

title USBOSV3.iso

set O=/USBOSV3.iso

find --set-root %O% && set I=%O%

find --set-root /ISO%O% && set I=/ISO%O%

find --set-root /ISOS%O% && set I=/ISOS%O%

map --unmap=0xff

map %I% (0xff) || map --mem %I% (0xff)

map --hook

chainloader (0xff)

20211021，为USBOS V3 iso添加了 Ventoy Compatible标记。

利用Ventoy整体引导USBOSV3.iso，当启动其中的NT6以上内核PE时，由该PE内的vtoydump.exe 负责挂载iso；当启动其中的03PE时，由WinVBlock识别map的iso。

故在Ventoy引导iso这种情况下，就不再限定iso文件要存储在约定的位置下，也可以对USBOSV3.iso改名。

上面的说明，来自USBOS常见问题及说明.CHM。

不过还有个少许的问题，imdisk等还是需要文件系统作为支持才能认识路径（当然直接指定\\.\PhysicalDrive0这种的话似乎也能处理连续扇区序列？）。

USBOS应该就是找特定位置的特定文件名字“USBOSV3.iso”，确定盘符、路径、文件名，挂载上去就行了。imdisk是支持命令行的，可以直接用pecmd调用。

svbus的打碎片解析补丁，你应该能够胜任了吧。

        

sunsea

liuzhaoyzz 发表于 2021-11-17 11:03
Grub4dos map命令使用USBOSV3.iso
  由于NT 5内核的Windows有WinVBlock（USBOS 2003 PE已集成）及FiraDi ...

驱动部分代码应该没问题，我哪天要细读一下g4e/g4d怎么处理碎片的。这部分大概要请教yaya。

liuzhaoyzz

sunsea 发表于 2021-11-17 11:11
驱动部分代码应该没问题，我哪天要细读一下g4e/g4d怎么处理碎片的。这部分大概要请教yaya。

等你哪天有兴趣了，最快的方式，直接@2011yaya2007777，请他说明原理，贴出关键代码，这样子更加省时间吧。      

2011whp

@liuzhaoyzz

imdisk，有 没有 碎片 问题

我是用 imdisk
挂：\petools\muilt-in\guid\*.txt   最后一行，提定的 iso文件

sunsea

2011whp 发表于 2021-11-17 11:34
@liuzhaoyzz

imdisk，有 没有 碎片 问题

imdisk不存在碎片问题，因为本质是【借助文件系统】的【按名访问】，碎片问题由文件系统处理。所以我说它对一些些IMBA的隐藏方案没什么用，因为这种地方文件系统不做特殊处理不认。

liuzhaoyzz

2011whp 发表于 2021-11-17 11:34
@liuzhaoyzz

imdisk，有 没有 碎片 问题

imdisk肯定没有碎片问题需要处理。imdisk就好比那些个虚拟光驱软件Daemon Tools(精灵虚拟光驱)、虚拟光驱软件UltraISO等等一样，挂载ISO到某个盘符。        

xianglang

liuzhaoyzz 发表于 2021-11-17 11:03
Grub4dos map命令使用USBOSV3.iso
  由于NT 5内核的Windows有WinVBlock（USBOS 2003 PE已集成）及FiraDi ...

这些变量，看得真让人头晕，%O%变量直接用 USBOSV3.iso 去写，不是看着更省事吗？另外，这行 map --unmap=0xff 光驱盘符，不用括号也能识别？

可供参考的G4D代码如下：
title USBOSV3.iso
set O=/USBOSV3.iso
find --set-root %O% && set I=%O%
find --set-root /ISO%O% && set I=/ISO%O%
find --set-root /ISOS%O% && set I=/ISOS%O%
map --unmap=0xff
map %I% (0xff) || map --mem %I% (0xff)
map --hook
chainloader (0xff)

liuzhaoyzz

xianglang 发表于 2021-11-17 13:24
这些变量，看得真让人头晕，%O%变量直接用 USBOSV3.iso 去写，不是看着更省事吗？另外，这行 map --unmap ...

这个菜单，来自于《USBOS里面的说明.chm》，不是我写的，我只会写最简单的菜单。
1、%O%变量直接用 USBOSV3.iso 去写，我理解的是set O=/USBOSV3.iso，如果改名字了，只需要改动这一处，可能原菜单更加复杂，如果要替换，可能会替换不该替换的部分。

2、关于map --unmap=0xff，随便一个版本的grub4dos-0.4.6a-xxxx\docs\README_GRUB4DOS_CN.txt里面都有说明啊：
******************************************************************************
***                   a range of drives can be unmapped                    ***
******************************************************************************

用法：
        map --unmap=RANGE

其中的 RANGE 是一个已被映射的 BIOS 驱动器域。BIOS 驱动器号 0 表示第一软驱，1 表示
第二软驱；0x80 表示第一硬盘，0x81 表示第二硬盘，等等；虚拟光盘(hd32) 对应于
BIOS 驱动器号 0xA0 ,(hd33) 对应于0xA1 ，等等。

关于RANGE 的说明，请参阅前述的“新命令 CHECKRANGE ”这节。

示例 1：
        map --unmap=0,0x80,0xff

这将反映射虚拟软驱 (fd0),虚拟硬盘(hd0)和虚拟光盘(0xff)。

示例 2：
        map --unmap=0:0xff

这将反映射所有的虚拟软驱，所有的虚拟硬盘和所有的虚拟光盘。

注意 1：通常，一条‘map’命令将在驱动器映射表中为虚拟驱动器增加一个表项。而
        ‘--unmap’意味着在驱动器映射表中（具体是指虚拟驱动器）的表项会被删除。

Note 2:        The --unhook option only breaks the INT13 hook(to the inerrupt
        vector table). It will not affect the drive map table. And later on
        execution of a `boot' command, the INT13 disk emulation routine will
        automatically get hooked(to the interrupt vector table) when needed
        (e.g., the drive map table is non-empty) even if it has been unhooked.
注意 2：--unhook 选项仅仅是断开 INT13 的挂钩（在中断矢量表中）。它不会影响到驱
        动器映射表。而且在执行了一个‘boot’命令之后，即使是它已经被反映射了的
        时候，INT13磁盘仿真程序也会在需要的时候（即，驱动器映射表非空时）自动建立挂钩。

注意 3：通常你需要在已经改变了驱动器映射表之后执行一条`map --rehook'命令。



        

wintoflash

liuzhaoyzz 发表于 2021-11-17 09:53
顺便说下PE启动关于相关驱动两个相关的话题。
1.外置版PE不搭配Firadisk/winvblock/svbus也实现map盘的挂 ...

Ventoy向操作系统传递的不只有ISO路径，还有碎片表。
Linux下支持通过碎片表这样挂载，所以可以读exfat等分区里面的ISO。
Windows下不用驱动就不支持这样。

不点

我今天又下载了一个新版 PE.iso，碎块是 64 个太多了。

于是我找上次那个 30 个碎块的文件。我仅仅把它改名了！

可是，它竟然没有碎块了！

我可没整理它的碎块！谁在自动整理碎块？难道是那个 Win11PE.iso 干了这事？

现在邪门了，我想生成一个碎块不多的文件，却总是生成连续的文件！

我删掉一些小文件，再拷贝一个 iso，结果还是得到连续的文件。已经拷了好几个，都是连续的。没辙了。

人老了，电脑也欺负我。

问题是，前两天，我测试的 30 个碎块的文件，今天去看它（仅仅改名了），它是连续的！那么，我先前测试它的时候，会不会是连续的呢？难道也欺负我人老了，精力不够使？弄个连续的，让我以为是 30 个碎块，捉弄我？嗯？？

sunsea

不点 发表于 2021-11-17 17:09
我今天又下载了一个新版 PE.iso，碎块是 64 个太多了。

于是我找上次那个 30 个碎块的文件。我仅仅把它 ...

微软现在有后台计划任务，自动整理碎片。（对于SSD，则是提交TRIM操作）下次测试我觉得可以在SSD上或者U盘等不会被Windows自动【整理碎片】的设备上做，然后每次运行前加一句blocklist实时检查碎片情况。

liuzhaoyzz

不点 发表于 2021-11-17 17:09
我今天又下载了一个新版 PE.iso，碎块是 64 个太多了。

于是我找上次那个 30 个碎块的文件。我仅仅把它 ...

我的感觉也是一样，找到不连续存储的文件比较难，找了一圈又一圈，都是连续存放的，想测试都没办法，感觉NTFS文件产生碎片的几率比以前的FAT32几率低多了。     

sunsea

liuzhaoyzz 发表于 2021-11-17 19:11
我的感觉也是一样，找不连续存储的文件比较难，找了一圈又一圈，都是连续存放的，想测试都没办法，感觉NT ...

NTFS似乎内部对分配算法什么的有优化，FAT32比较一根筋。可能在FAT32上测试更好些。

不点

前两天下载了新版 PE.iso，有 16 个碎块。再现了 map 的问题。

带 --mem 正常。

不带 --mem 出问题。这次的问题不是死在 Windows 的 logo，而是 logo 界面过去了，桌面显示是黑屏，可以移动鼠标，但没有别的响应。

好吧，凡是 “带 --mem” 与 “不带 --mem” 形成差异的，我理解为，都是进入保护模式后需要访问虚拟光盘而造成的。大家认为，我这个理解正确吗？尤其是开发者们，你们认为，我这个理解有毛病吗？

不仅如此，而且上面这个 “差异”  现象，还能够说明（或证明），Windows PE 的保护模式下，存在实模式的虚拟光盘驱动。这个判断也没问题吧？

那么，这个驱动，如果它不是 svbus、firadisk、winvblock 的话，那就一定是微软弄出来的（一个新的驱动），对吧？

对不起大家！我人老了，不像以前那么自信了。需要你们给以确认，我才能确认。

有兴趣者，给以回复和讨论。没兴趣的，当然就略过了。

liuzhaoyzz

不点 发表于 2021-11-23 12:37
前两天下载了新版 PE.iso，有 16 个碎块。再现了 map 的问题。

带 --mem 正常。

应该是这样子吧。 直接用map --mem吧，很稳定。一般的PE都在1GB以内，内存放得下，放不下启动时按e键修改，去掉--mem即可。      

szwp

先生成1000个1KB小文件，随机删除500个，然后再拷个ISO过去试下有没碎片。

不点

liuzhaoyzz 发表于 2021-11-23 15:32
应该是这样子吧。 直接用map --mem吧，很稳定。一般的PE都在1GB以内，内存放得下，放不下启动时按e键修 ...

这一点不是讨论的主题。也许很多人都没明白我的意思，这可能是我没说清楚。

讨论的主题是：PE 里到底是谁在驱动实模式的虚拟盘？其实是研究性质的：是故意制造碎片，然后根据其测试表现来判断某些情况。掌握和了解某些技术细节，这对于开发者和用户，都是有好处的。

kuer 大师制作的 PE，就能用来检查，到底其中有没有 svbus，firadisk，winvblock。

这个 PE 前面曾经给出了链接。如果大家找不到链接，可以在 “PE 作品发布区” 里面找到。

就是这个：

http://bbs.wuyou.net/forum.php?mod=viewthread&tid=427561

谁都可以用自己熟悉的方式来检查 PE 里面到底有没有上述 3 个驱动。我检查了，但没找到。

用别的 PE 来测试也行。估计结果都差不多。

不点

liuzhaoyzz 发表于 2021-11-17 09:53
顺便说下PE启动关于相关驱动两个相关的话题。
1.外置版PE不搭配Firadisk/winvblock/svbus也实现map盘的挂 ...

liu 版主的帖子很要紧。我正好有疑问想请教。

1. 我似乎觉得 ventoy 是一个启动软件，却同时做了很多并非属于启动方面的事情，比如，iso 的仿真（或者说是虚拟光驱）。启动软件究竟该不该做这些事？grub4dos 就做过磁盘仿真，不过只是实模式而已。因此，启动软件做虚拟盘的事，也不算多余。但是，做这事的同时，也会消耗开发者的工作量。开发者照顾的事情多了，就可能忙不过来，影响某些方面的实现，让某些方面的工作受到影响。比如，ventoy 的一个不大不小的问题是，对于 legacy bios 的支持没有做到很周全。这样的话，影响该软件在 bios 启动模式下的表现。启动和虚拟盘，这两者哪个重要？我认为，肯定是启动重要，虚拟盘是“次之”，没有启动那么重要。如果启动不了，那就一切免谈，根本没有虚拟盘的事。如果没有虚拟盘，但是启动的成功率有保证，那只是欠缺了一点方便性而已。哪是主？哪是次？这个问题，我就是这么认为的。

我想用 ventoy 来作为我的单一启动软件（U盘）。但是，由于 ventoy 在 bios 方面的不足，使我不得不再准备另外一个启动软件（U盘）。

2. ventoy 和 grub4dos（bios + uefi）两者都是启动软件，那么两者有什么区别和联系？这我不懂，想请 liu 版主给以解答。如有可能，烦请 liu 版主系统整理一下相关资料，能给一个不太了解的人提供一些帮助，比如，让用户知道，在什么情况该选用 ventoy，而在什么情况下该选用 grub4dos。

2011whp

@不点大，要说有个驱动的话，是这个

你说的这个，现象，pe.iso 碎片 的随机性分布，可能超了 32 了

——————————————————————————
ventoy和g4d 都能 虚拟光盘（历史原因吧，操作系统一般是发布 光盘，而现实是 光驱淘汰了）
随然硬件淘汰了光驱，但bios 都能启动光盘，能看到venhw总线（传统是 中断口方式）
ventoy 也有 办法挂上光驱的，而且是用 win内核 自身的 功能 （vtoydump 要联系下）
现在的系统，大部分能 直接把光盘内容，复制到分区，引导即可安装。

ventoy 的确 能深入到  启动阶段以后了（包括 win  linux）

bios的 传统 与 UEFI 交错期，很长的，这个 什么时代用什么吧
修电脑的 即使现在 ，UD也是必备的，
一般自用，选择容易用的

不点

2011whp 发表于 2021-11-23 19:27
@不点大，要说有个驱动的话，是这个

你说的这个，现象，pe.iso 碎片 的随机性分布，可能超了 32 了

关于 ventoy 、bios、uefi 等相关问题，感谢 whp 大人解惑。

您说的 ramdisk.sys，我觉得似乎不应是负责驱动实模式虚拟盘的。公开的资料似乎是说，ramdisk.sys 是建立内存盘的。而我们的实模式 map 出来的盘，不带 --mem 时，也不会放在内存里面。所以，ramdisk.sys 貌似与我们这里所谈的内容没有关系。当然了，不排除 ramdisk.sys 的新版能够兼做实模式虚拟盘的保护模式驱动的可能性（果真那样的话，那就是证明了微软做了这个工作，答案就揭晓了）。但终究没人能证明或证实这一点（因此，疑问终究还是个疑问，而没有获得清晰的答案）。

如果 whp 大人您也只是找到 ramdisk.sys 而找不到 svbus, firadisk, winvblock 的话，那起码有两人（您和我）证实确实没有 svbus, firadisk, winvblock，因此，就算是犯错了，也不是我一人犯错，而是由您也陪我一同犯错，这就间接地说明，我犯错的几率不太大。

好了，假定确实没有 svbus、firadisk、winvblock，那就肯定是微软的代码在做这个虚拟盘的驱动工作，至于说是不是 ramdisk.sys 里面的代码在做这个工作，本话题目前并不特别关注这一点。本话题目前仅仅想确定究竟是否是微软做了这个工作。只要确定是微软，或不是微软，这就达到目的了。在确定是微软做了这个工作的前提下，进一步确定是不是 ramdisk.sys 在做这个工作，这就更细化和深入了，而这并不是本话题关注的内容。本话题只粗略确定是不是微软，而不细化。换句话说，本话题只做初步的、基础判定的工作，不深入。要是我们的基础判定，都不能下个断言，都不能判定的话，那就根本不能深入下去。因此，这里关注的首要问题，就是这个基础判定问题，即，究竟是不是微软做了这个工作。

liuzhaoyzz

不点 发表于 2021-11-23 15:57
这一点不是讨论的主题。也许很多人都没明白我的意思，这可能是我没说清楚。

讨论的主题是：PE 里到底 ...

直接map的模式下，没有svbus，firadisk，winvblock这些，PE仍然可以启动呀，前面wintoflash和我都说了PE的启动过程和原理，实模式是g4d做的map，进入保护模式就是微软的ramdisk.sys，你回看下前面那几个帖子就知道了。

你说的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 之外的代码，并且很可能是纯保护模式的，即，不使用实模式！


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