既然 int13 handler 无污染，那么，是什么原因造成了在不带 --mem 时，iso 连续与不连续的差异结果（“成功进入桌面” 与 “死在半途”）呢？
本帖最后由 2011whp 于 2021-11-27 19:28 编辑
大约 半年前吧，有篇 官方 的 文章 说 linux，不动 传统的 前1MB
window 同样不会动
必经 efi 是 bios容量 4Mb以上的事了，efi是增量，内存 更不差那点1MB
legacy 才是 靠近 cpu原理的，cpu的指令 以后估计也是 扩充。
对于 传统不兼容，估计是无意的。（主要是 oem 定置 造成的）
本帖最后由 2011yaya2007777 于 2021-11-27 19:33 编辑
wintoflash提供的RW是要钱才能下载的。
2011yaya2007777 发表于 2021-11-27 19:32
wintoflash提供的RW是要钱才能下载的。
百度有吧？http://m.downcc.com/d/24310
好吧，首先怀疑，仿真代码在处理碎块时有 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 命令是很厉害的！万一敲错什么字符，将会产生巨大破坏！！
如果你没把握，不要进行测试！！
2011yaya2007777 发表于 2021-11-27 19:32
wintoflash提供的RW是要钱才能下载的。
你看岔了吧
2011yaya2007777 发表于 2021-11-27 19:32
wintoflash提供的RW是要钱才能下载的。
怪了，怎么不要我的钱？我没捐款，就下载了。
不点 发表于 2021-11-27 19:44
好吧，首先怀疑，仿真代码在处理碎块时有 bug。
我们需要验证，仿真是可靠、无误的。
iso 有3个碎片，不用 --mem 加载到内存，成功启动进入桌面。
用 RW 对比，没有问题。
wintoflash 发表于 2021-11-27 19:47
iso 有3个碎片，不用 --mem 加载到内存，成功启动进入桌面。
用 RW 对比，没有问题。
是全都成功吗？
你多试验几台机子，看看有没有失败的？
不点 发表于 2021-11-27 19:54
是全都成功吗？
你多试验几台机子，看看有没有失败的？
现在我暂时只有自己用的机器。实体机/各种虚拟机启动都没问题。
我之前也说了，以前用各种机器启动带碎片的 ISO，没有出过问题。
所以我才认为你的电脑出现的问题是偶然现象。
wintoflash 发表于 2021-11-27 19:57
现在我暂时只有自己用的机器。实体机/各种虚拟机启动都没问题。
我之前也说了，以前用各种机器启动带碎 ...
那这就有待今后更多的参与者进行检验了。现在我们的检验量还不够多。
可能是使用手机打开链接的吧。
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!
朋友们，暂停测试。
wintoflash 说，是我机子的未知问题造成的，一般不会出现问题。
好的，那就先挂起来。
如果今后有人下载了 kuer 的 PE，在不连续的情况下也出现死机之类的，不要忘了，一定要在这里报告！
请记住，一定要来报告！
谢谢以上参与的各位专家们！
本帖最后由 不点 于 2021-11-28 09:24 编辑
2011whp 发表于 2021-11-27 19:10
大约 半年前吧，有篇 官方 的 文章 说 linux，不动 传统的 前1MB
window 同样不会动
那个 RW 工具实在是太伟大了，让我们能看到实模式常规内存的完整状况。值得庆祝。
但我们面对实模式内存，也只是望洋兴叹，啥事也干不了。
我们只是用它来证明 int13 handler 是否被损坏了。就像小区门口的视频监控，能留下证据。
我们顺便能看到，实模式的内存，完整保留，没有被损坏。
也就是说，不只是 int13 handler 没被损坏，其他任何实模式的关键数据、代码，都没损坏。
但是，实模式下的 ahci 硬盘，是无法访问了。这是垄断者封杀实模式的一种手段。
垄断者不能够从 CPU 的角度封杀实模式，却从设备规范上进行封杀。
所以，我们面对实模式，也只能望洋兴叹了。
没有污染的实模式内存，只管看，不管用。
你看它的时候，就像是穿越到两千年前吧。
澄清：以上是说，从 Windows 返回到实模式，无法访问 ahci 硬盘了。这是前面 sunsea 和 wintoflash 说过的。并非一开机就没有实模式了。
cpu开机是64位的，其余 都是 cpu控制器 变化的
发展 64位 cpu ，主要矛盾 是 存储 发展 太快了 （好像，ia64 是纯纯的64位，只有服务器的，结果 amd64赢了）
https://zhuanlan.zhihu.com/p/69334474
传统的bios,估计是 不发展，也不破坏。（基实 已经 重建过，现在的 传统bios，也不是以前的传统bios，只不过，用着无感觉）
2011whp 发表于 2021-11-28 11:10
cpu开机是64位的，其余 都是 cpu控制器 变化的
发展 64位 cpu ，主要矛盾 是 存储 发展 太快了 （好 ...
道理有很多，看从哪方面去解读。
对于 Windows 来说，如果从半道再切换到实模式，系统还能稳定吗？不知道。于是，垄断者就设法破坏这种可能性。
但是，从另一个角度，在签名机制下，程序的稳定性是由签名者负责的，受微软监督的。切入实模式，做该做的事，小心一点，不破坏系统其它部分，比如说，不向扩展内存中不该写入的地方写入东西，然后再安全返回，应该也是没问题的。但是，这个决定权，不在开发者们手上，而是控制在软硬件系统制造商手上。下游开发者的自由度被压缩了。
就启动而言，这不算个啥事，是小事。就算做不了，也没什么。假如在别的方面还有什么事阻挡了，那就真的给那些开发者带来不方便了。
这就跟政策一样，究竟收紧了好，还是放宽了好，不同的时期，有不同的理解，以及不同的处理。电脑技术也会是这样吧。
我也在等个能有问题的机器。抓到有问题的机器就搞。
sunsea : svbus 的补丁我已经打上了，你再看看有什么问题。下一步编译就看你了。
2011yaya2007777 发表于 2021-12-3 14:21
sunsea : svbus 的补丁我已经打上了，你再看看有什么问题。下一步编译就看你了。
粗看了下，代码除了没加分号之类的问题以外没大问题，感谢！
编译和调试我在搞，尼玛狗屎烂蛋的M$ Win10不准装Win7的DDK，W10的ddk似乎没法给低版本编译，我想想办法（哪位会VS2019+W10的DDK编译给为xp的驱动的我在此也请教下，毕竟VS2019也能算宇宙最强IDE了，我还希望能再VS里搞定联机调试呢），另外最近比较忙，可能要等一会了。
sunsea 发表于 2021-12-4 21:02
粗看了下，代码除了没加分号之类的问题以外没大问题，感谢！
编译和调试我在搞，尼玛狗屎烂蛋的M$ Win ...
https://blog.csdn.net/sanqiuai/article/details/119413564
我没弄过，不知道行不行。
wintoflash 发表于 2021-12-4 21:08
https://blog.csdn.net/sanqiuai/article/details/119413564
我没弄过，不知道行不行。
似乎能用，不过莫名其妙编译出来的启动不了……我去坛子上找个极限精简版Win10装个调试机吧，尼玛XP还不给用来做调试端……M$真的绝了。我以前调试这玩意一直用XP，Win10体积太大了
2011yaya2007777 发表于 2021-12-3 14:21
sunsea : svbus 的补丁我已经打上了，你再看看有什么问题。下一步编译就看你了。
喵的，上调试器整死机了，正常启动没认盘，我就用最土最笨的办法好了：插调试信息。不过这就比较费事了，最近比较忙，等段时间吧。
现在的调试环境和以前不一样了吗？还挺费事的。
2011yaya2007777 发表于 2021-12-5 19:48
现在的调试环境和以前不一样了吗？还挺费事的。
不清楚M$在搞什么。我这下断点后跑起来直接死机了。也可能是我操作问题。
这个 svbus 编译出 svbusx64.sys 和 svbusx86.sys。
关于变量长度有个疑问：
ULONGLONG 在 32/64 位环境应该都是 64 位吧？
ULONG在 32/64 位环境应该分别是 32/64 位吧？还是都是 32 位？
如果ULONG在 32/64 位环境应该分别是 32/64 位，那在 64 位环境使用 32 位整数，怎么表示？
2011yaya2007777 发表于 2021-12-6 08:28
这个 svbus 编译出 svbusx64.sys 和 svbusx86.sys。
关于变量长度有个疑问：
ULONGLONG 在 32/64 位环境 ...
ULONG固定32位，ULONGLONG固定64位，int长度会变。需要32位整数可以固定使用ULONG。
明白了。结构定义没有错误。
本帖最后由 sunsea 于 2021-12-6 23:15 编辑
2011yaya2007777 发表于 2021-12-6 10:49
明白了。结构定义没有错误。
搜了下，int长度是确定的，32位。M$下long的长度也是32位，但是GCC下（包括给uefi编译的时候）就说不准，可能跟的是Linux的规定（见图），不知道g4d按什么编译的。可能要上stdint.h固定长度。
2011yaya2007777 发表于 2021-12-6 10:49
明白了。结构定义没有错误。
初步调试笔记：
↑这个用途不明，但是会让调试的时候出现问题直接跑飞，下一步应该注释掉
此处对碎片的判断似乎出现了问题，没有抓到碎片。下次调试时应该抓常规内存进来确定碎片表在哪，确定是否是对地址的运算有问题。
（最近较忙，估计过段时间才能继续搞了，不过肯定会搞完，以及是否应该单开一个主题？）
同意另开一贴。第一幅画，好像是原程序的内容吧，似乎应该把"!"去掉。有关第二幅图，应当使用最新版本的g4e。
 |