现在的 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 来测试，成功进入桌面，没有任何问题。

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

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

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

wuming520

楼主有WIN7X86SVBus驱动文件吗不报错重启蓝屏带签名的，发一下谢谢~~！

2011yaya2007777

新旧版本的g4d，碎片位置不一样。最新版本的g4d与最新版本的g4e，碎片位置一致。

sunsea

2011yaya2007777 发表于 2021-12-22 16:42
同意另开一贴。第一幅画，好像是原程序的内容吧，似乎应该把"!"去掉。有关第二幅图，应当使用最新版本的g4e ...

这样的话碎片处理补丁对于 grub4dos-for_UEFI-2021-12-15 在Win10 x64上测试通过了。不过从刚刚第二幅图来看，g4d和g4e碎片表放置位置有差异？（测试楼上第二幅图的环境是grub4dos-0.4.6a-2021-11-19）

这几天的话我把整理过的源代码发出并编译（然后另开一主题帖），然后大家一起在各种环境上广泛测试，争取经受最广泛地考验、不出bug。

2011yaya2007777

同意另开一贴。第一幅画，好像是原程序的内容吧，似乎应该把"!"去掉。有关第二幅图，应当使用最新版本的g4e。

sunsea

2011yaya2007777 发表于 2021-12-6 10:49
明白了。结构定义没有错误。

初步调试笔记：

↑这个用途不明，但是会让调试的时候出现问题直接跑飞，下一步应该注释掉



此处对碎片的判断似乎出现了问题，没有抓到碎片。下次调试时应该抓常规内存进来确定碎片表在哪，确定是否是对地址的运算有问题。

（最近较忙，估计过段时间才能继续搞了，不过肯定会搞完，以及是否应该单开一个主题？）

sunsea

2011yaya2007777 发表于 2021-12-6 10:49
明白了。结构定义没有错误。

搜了下，int长度是确定的，32位。M$下long的长度也是32位，但是GCC下（包括给uefi编译的时候）就说不准，可能跟的是Linux的规定（见图），不知道g4d按什么编译的。可能要上stdint.h固定长度。

2011yaya2007777

明白了。结构定义没有错误。

sunsea

2011yaya2007777 发表于 2021-12-6 08:28
这个 svbus 编译出 svbusx64.sys 和 svbusx86.sys。
关于变量长度有个疑问：
ULONGLONG 在 32/64 位环境 ...

ULONG固定32位，ULONGLONG固定64位，int长度会变。需要32位整数可以固定使用ULONG。

2011yaya2007777

这个 svbus 编译出 svbusx64.sys 和 svbusx86.sys。
关于变量长度有个疑问：
ULONGLONG 在 32/64 位环境应该都是 64 位吧？
ULONG  在 32/64 位环境应该分别是 32/64 位吧？还是都是 32 位？

如果ULONG  在 32/64 位环境应该分别是 32/64 位，那在 64 位环境使用 32 位整数，怎么表示？

sunsea

2011yaya2007777 发表于 2021-12-5 19:48
现在的调试环境和以前不一样了吗？还挺费事的。

不清楚M$在搞什么。我这下断点后跑起来直接死机了。也可能是我操作问题。

2011yaya2007777

现在的调试环境和以前不一样了吗？还挺费事的。

sunsea

2011yaya2007777 发表于 2021-12-3 14:21
sunsea : svbus 的补丁我已经打上了，你再看看有什么问题。下一步编译就看你了。

喵的，上调试器整死机了，正常启动没认盘，我就用最土最笨的办法好了：插调试信息。不过这就比较费事了，最近比较忙，等段时间吧。

sunsea

wintoflash 发表于 2021-12-4 21:08
https://blog.csdn.net/sanqiuai/article/details/119413564
我没弄过，不知道行不行。

似乎能用，不过莫名其妙编译出来的启动不了……我去坛子上找个极限精简版Win10装个调试机吧，尼玛XP还不给用来做调试端……M$真的绝了。我以前调试这玩意一直用XP，Win10体积太大了

wintoflash

sunsea 发表于 2021-12-4 21:02
粗看了下，代码除了没加分号之类的问题以外没大问题，感谢！

编译和调试我在搞，尼玛狗屎烂蛋的M$ Win ...

https://blog.csdn.net/sanqiuai/article/details/119413564
我没弄过，不知道行不行。

sunsea

2011yaya2007777 发表于 2021-12-3 14:21
sunsea : svbus 的补丁我已经打上了，你再看看有什么问题。下一步编译就看你了。

粗看了下，代码除了没加分号之类的问题以外没大问题，感谢！

编译和调试我在搞，尼玛狗屎烂蛋的M$ Win10不准装Win7的DDK，W10的ddk似乎没法给低版本编译，我想想办法（哪位会VS2019+W10的DDK编译给为xp的驱动的我在此也请教下，毕竟VS2019也能算宇宙最强IDE了，我还希望能再VS里搞定联机调试呢），另外最近比较忙，可能要等一会了。

2011yaya2007777

我也在等个能有问题的机器。抓到有问题的机器就搞。

sunsea : svbus 的补丁我已经打上了，你再看看有什么问题。下一步编译就看你了。

不点

2011whp 发表于 2021-11-28 11:10
cpu开机是  64位的，其余 都是 cpu控制器 变化的

发展 64位 cpu ，主要矛盾 是 存储 发展 太快了 （好 ...

道理有很多，看从哪方面去解读。

对于 Windows 来说，如果从半道再切换到实模式，系统还能稳定吗？不知道。于是，垄断者就设法破坏这种可能性。

但是，从另一个角度，在签名机制下，程序的稳定性是由签名者负责的，受微软监督的。切入实模式，做该做的事，小心一点，不破坏系统其它部分，比如说，不向扩展内存中不该写入的地方写入东西，然后再安全返回，应该也是没问题的。但是，这个决定权，不在开发者们手上，而是控制在软硬件系统制造商手上。下游开发者的自由度被压缩了。

就启动而言，这不算个啥事，是小事。就算做不了，也没什么。假如在别的方面还有什么事阻挡了，那就真的给那些开发者带来不方便了。

这就跟政策一样，究竟收紧了好，还是放宽了好，不同的时期，有不同的理解，以及不同的处理。电脑技术也会是这样吧。

2011whp

cpu开机是  64位的，其余 都是 cpu控制器 变化的

发展 64位 cpu ，主要矛盾 是 存储 发展 太快了 （好像，ia64 是纯纯的64位，只有服务器的，结果 amd64赢了）

https://zhuanlan.zhihu.com/p/69334474

传统的bios,  估计是 不发展，也不破坏。（基实 已经 重建过，现在的 传统bios，也不是以前的传统bios，只不过，用着无感觉）

不点

2011whp 发表于 2021-11-27 19:10
大约 半年前吧，有篇 官方 的 文章 说 linux，不动 传统的 前1MB

window 同样不会动

那个 RW 工具实在是太伟大了，让我们能看到实模式常规内存的完整状况。值得庆祝。

但我们面对实模式内存，也只是望洋兴叹，啥事也干不了。

我们只是用它来证明 int13 handler 是否被损坏了。就像小区门口的视频监控，能留下证据。

我们顺便能看到，实模式的内存，完整保留，没有被损坏。

也就是说，不只是 int13 handler 没被损坏，其他任何实模式的关键数据、代码，都没损坏。

但是，实模式下的 ahci 硬盘，是无法访问了。这是垄断者封杀实模式的一种手段。

垄断者不能够从 CPU 的角度封杀实模式，却从设备规范上进行封杀。

所以，我们面对实模式，也只能望洋兴叹了。

没有污染的实模式内存，只管看，不管用。

你看它的时候，就像是穿越到两千年前吧。

澄清：以上是说，从 Windows 返回到实模式，无法访问 ahci 硬盘了。这是前面 sunsea 和 wintoflash 说过的。并非一开机就没有实模式了。

不点

朋友们，暂停测试。

wintoflash 说，是我机子的未知问题造成的，一般不会出现问题。

好的，那就先挂起来。

如果今后有人下载了 kuer 的 PE，在不连续的情况下也出现死机之类的，不要忘了，一定要在这里报告！

请记住，一定要来报告！

谢谢以上参与的各位专家们！

2011yaya2007777

RWEverything Read & Write Everything Skip to content Home Welcome to the homepage of RW utility. The latest version is v1.7.  This utility access almost all the computer hardware, including PCI (PCI Express), PCI Index/Data, Memory, Memory Index/Data, I/O Space, I/O Index/Data, Super I/O, Clock Generator, DIMM SPD, SMBus Device, CPU MSR Registers, ATA/ATAPI Identify Data, Disk Read Write, ACPI Tables Dump (include AML decode), Embedded Controller, USB Information, SMBIOS Structures, PCI Option ROMs, MP Configuration Table, E820, EDID and Remote Access. And also a Command Window is provided to access hardware manually.  Powerful utility for hardware engineers, firmware (BIOS) engineers, driver developers, QA engineers, performance test engineers, diagnostic engineers, etc.  This utility comes with ABSOLUTELY NO WARRANTY, it allows you to modify hardware settings, this may damage your system if something goes wrong. Author will not take any responsibility about that, you are on your own risk.  This utility should not be bundled (in any form) in commercial or consumer products.   Your donation makes it better!       Donate1 $10.00 USD PayPal - The safer, easier way to pay online!                  

2011yaya2007777

可能是使用手机打开链接的吧。

不点

wintoflash 发表于 2021-11-27 19:57
现在我暂时只有自己用的机器。实体机/各种虚拟机启动都没问题。
我之前也说了，以前用各种机器启动带碎 ...

那这就有待今后更多的参与者进行检验了。现在我们的检验量还不够多。

wintoflash

不点 发表于 2021-11-27 19:54
是全都成功吗？

你多试验几台机子，看看有没有失败的？

现在我暂时只有自己用的机器。实体机/各种虚拟机启动都没问题。
我之前也说了，以前用各种机器启动带碎片的 ISO，没有出过问题。
所以我才认为你的电脑出现的问题是偶然现象。

不点

wintoflash 发表于 2021-11-27 19:47
iso 有3个碎片，不用 --mem 加载到内存，成功启动进入桌面。
用 RW 对比，没有问题。

是全都成功吗？

你多试验几台机子，看看有没有失败的？

wintoflash

不点 发表于 2021-11-27 19:44
好吧，首先怀疑，仿真代码在处理碎块时有 bug。

我们需要验证，仿真是可靠、无误的。

iso 有3个碎片，不用 --mem 加载到内存，成功启动进入桌面。
用 RW 对比，没有问题。

不点

2011yaya2007777 发表于 2021-11-27 19:32
wintoflash提供的RW是要钱才能下载的。

怪了，怎么不要我的钱？我没捐款，就下载了。

wintoflash

2011yaya2007777 发表于 2021-11-27 19:32
wintoflash提供的RW是要钱才能下载的。

你看岔了吧

不点

好吧，首先怀疑，仿真代码在处理碎块时有 bug。

我们需要验证，仿真是可靠、无误的。

一旦验证是可靠、无误的，那我们就把问题的解决向前推进了一步。

验证步骤：

1、在 Windows 下把含有碎块的 PE.iso 复制一份，叫做 PE_tmp.iso 不用管它是否连续。

2、用含有碎片的 iso 来创建虚拟光盘，碎片不超过 32 个：

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

好了，现在 (255) 就是个光盘了，下面可以读它的所有扇区。

3、用 grub4dos 内置的 dd 命令来复制光盘 (255) 的全部内容到 PE_tmp.iso：

dd   if=(255)   of=(...)/PE_tmp.iso

如果仿真代码是有 bug 的，则复制的结果，PE_tmp.iso 的内容将与原始的 PE.iso 不同。

4、进入操作系统，检查两个 iso 文件的内容是否有不同。

以上测试方法可以用在多个电脑上。只要发现有一次出现不同，那就证明了仿真代码有 bug。

如果测试足够多次，都没发现问题，那就认为仿真代码是可靠的。

任何人，用任意一个合法的 iso 文件都可以做上述测试。完全不需要 chainloader 以及 boot 这个 iso。

需要小心！dd 命令是很厉害的！万一敲错什么字符，将会产生巨大破坏！！

如果你没把握，不要进行测试！！

liuzhaoyzz

2011yaya2007777 发表于 2021-11-27 19:32
wintoflash提供的RW是要钱才能下载的。

百度有吧？http://m.downcc.com/d/24310