支持含有碎片的文件仿真

mdyblog

不点 发表于 2014-11-18 12:11
烦请您再做个试验，运行下面的命令，将软盘个数恢复为原始状态，看看还会出错吗？

map --floppies=1

map --floppies=1
具体加在 mp144.sh 中什么地方？

mdyblog

不点 发表于 2014-11-18 12:11
烦请您再做个试验，运行下面的命令，将软盘个数恢复为原始状态，看看还会出错吗？

map --floppies=1

grub4dos 0.46a 20141103 -----[debug on ]----- -----[map --floppies=1]----- -----[displaymem ]----- EISA Memory BIOS Interface is present Address Map BIOS Interface is present Lower memory: 638K, Upper memory (to first chipset hole): 1047488K [Address Range Descriptor entries immediately follow (values are 64-bit)]   Usable RAM: Base: 0x0, Length: 0x9F800   Reserved: Base: 0xF0000, Length: 0x10000   Reserved: Base: 0xFEC00000, Length: 0x1400000   Reserved: Base: 0x9F800, Length: 0x800   Usable RAM: Base: 0x100000, Length: 0x3FEF0000   Reserved: Base: 0x3FFF3000, Length: 0xD000   Reserved: Base: 0x3FFF0000, Length: 0x3000 -----[map --mem /1_44M.IMG (20) ]----- FAT12 BPB found with 0xEB (jmp) leading the boot sector. probed C/H/S = 80/2/18, probed total sectors = 2880 -----[map --rehook ]----- Re-map the memdrive (0x14):         map --add-mbt=0 --heads=2 --sectors-per-track=18 (md)0x1FF440+0xB40 (0x14) -----[ls (20)/ ]----- get_diskinfo int13/41(14), version=0, int13/08(14), version=60, C/H/S=1024/240/63, int13/02(14), err=1 a.txt -----[displaymem ]----- EISA Memory BIOS Interface is present Address Map BIOS Interface is present Lower memory: 638K, Upper memory (to first chipset hole): 1047488K [Address Range Descriptor entries immediately follow (values are 64-bit)]   Usable RAM: Base: 0x0, Length: 0x9F800   Reserved: Base: 0xF0000, Length: 0x10000   Reserved: Base: 0xFEC00000, Length: 0x1400000   Reserved: Base: 0x9F800, Length: 0x800   Usable RAM: Base: 0x100000, Length: 0x3FEF0000   Reserved: Base: 0x3FFF3000, Length: 0xD000   Reserved: Base: 0x3FFF0000, Length: 0x3000 -----[map --status ]----- floppies_orig=1, harddrives_orig=2, floppies_curr=1, harddrives_curr=2 Number of ATAPI CD-ROMs: 0 ram_drive=0x7F, rd_base=0x0, rd_size=0x100000000 Fr To Hm Sm To_C _H _S   Start_Sector     Sector_Count   DHR -- -- -- -- ---- -- -- ---------------- ---------------- --- 14 FF 01 12 8882 FE 7F 00000000001FF440 0000000000000B40 M=S -----END-----

不点

这个机器有新情况，抓住它，别让它跑掉。

在 grub4dos 下，如果你方便的话，请截获它的 BIOS 数据区的数据，或者把整个实模式 1M 空间全部截获更好。实模式的 1M 空间就是从内存地址 00000 开始直到 FFFFF 结束的全部字节。【其实我并不太需要它，只是希望留着让其他开发者将来研究它，以免将来想找这个机器的资料，却找不到了】。

如果你不方便截获，那么就简单执行

read 0x4C
read 0x54
read 0x40E
read 0x410
read 0x413

把显示结果贴上来。【我目前所需要的就是这几个数据】

在进行以上操作之前，不要执行 map 命令，不要有任何仿真盘存在。

mdyblog

不点 发表于 2014-11-18 15:47
这个机器有新情况，抓住它，别让它跑掉。

在 grub4dos 下，如果你方便的话，请截获它的 BIOS 数据区的数 ...

1M 内存和LOG： test_mem log.7z (252.98 KB, 下载次数: 2)

2014-11-18 19:44 上传

点击文件名下载附件

grub4dos 0.46a 20141103 -----[dd if=(md)0+0x800 of=(hd1,4)/mem.dat]----- buf_size=0x10000, loops=0x10. in_pos=0x0, out_pos=0x0 00000000 00000001 00000002 00000003 00000004 00000005 00000006 00000007 00000008 00000009 0000000A 0000000B 0000000C 0000000D 0000000E 0000000F Bytes read / written = 0x100000 / 0x100000 -----[read 0x4C ]----- Address 0x4c: Value 0xf00096d0 -----[read 0x54 ]----- Address 0x54: Value 0xf000f859 -----[read 0x40E ]----- Address 0x40e: Value 0x54269f80 -----[read 0x410 ]----- Address 0x410: Value 0x7e005426 -----[read 0x413 ]----- Address 0x413: Value 0x27e -----END-----

不点

你给出的机器数据完全正常。是 grub4dos 有个隐藏很深的 bug。

grub4dos 莫名其妙地在 unhook 的情况下访问虚拟盘，这是导致问题的根源。

要找到哪一段代码是在 unhook 的情况下访问虚拟盘，这是不容易的。

不需要你的电脑了，请等着，我自己可以调试。

不点

bug 已修复，请 chenall 尽快更新。

不必等待 mdyblog 确认，我这里已经显示修复成功了。

预计 mdyblog 那里也会显示修复成功。不过，即使不成功，也没关系，只不过需要继续修复罢了。

这是个严重的 bug，因为它导致读写不存在的软盘或硬盘，所以，这会影响到启动成功率。

请尽快修复。

mdyblog

不点 发表于 2014-11-19 16:38
bug 已修复，请 chenall 尽快更新。

不必等待 mdyblog 确认，我这里已经显示修复成功了。

这个版本正确了。

grub4dos 0.45c 20141119 -----[debug on ]----- -----[map --floppies=1]----- -----[displaymem ]----- EISA Memory BIOS Interface is present Address Map BIOS Interface is present Lower memory: 638K, Upper memory (to first chipset hole): 1047488K [Address Range Descriptor entries immediately follow (values are 64-bit)]   Usable RAM: Base: 0x0, Length: 0x9F800   Reserved: Base: 0xF0000, Length: 0x10000   Reserved: Base: 0xFEC00000, Length: 0x1400000   Reserved: Base: 0x9F800, Length: 0x800   Usable RAM: Base: 0x100000, Length: 0x3FEF0000   Reserved: Base: 0x3FFF3000, Length: 0xD000   Reserved: Base: 0x3FFF0000, Length: 0x3000 -----[map --mem /1_44M.IMG (20) ]----- FAT12 BPB found with 0xEB (jmp) leading the boot sector. probed C/H/S = 80/2/18, probed total sectors = 2880 -----[map --rehook ]----- Re-map the memdrive (0x14):         map --add-mbt=0 --heads=2 --sectors-per-track=18 (md)0x1FF440+0xB40 (0x14) -----[ls (20)/ ]----- a.txt -----[displaymem ]----- EISA Memory BIOS Interface is present Address Map BIOS Interface is present Lower memory: 638K, Upper memory (to first chipset hole): 1047488K [Address Range Descriptor entries immediately follow (values are 64-bit)]   Usable RAM: Base: 0x0, Length: 0x9F800   Reserved: Base: 0xF0000, Length: 0x10000   Reserved: Base: 0xFEC00000, Length: 0x1400000   Reserved: Base: 0x9F800, Length: 0x800   Usable RAM: Base: 0x100000, Length: 0x3FEF0000   Reserved: Base: 0x3FFF3000, Length: 0xD000   Reserved: Base: 0x3FFF0000, Length: 0x3000 -----[map --status ]----- floppies_orig=1, harddrives_orig=2, floppies_curr=1, harddrives_curr=2 Number of ATAPI CD-ROMs: 0 ram_drive=0x7F, rd_base=0x0, rd_size=0x100000000 Fr To Hm Sm To_C _H _S   Start_Sector     Sector_Count   DHR -- -- -- -- ---- -- -- ---------------- ---------------- --- 14 FF 01 12 8882 FE 7F 00000000001FF440 0000000000000B40 M=S -----END-----

mdyblog

不点 发表于 2014-11-19 16:38
bug 已修复，请 chenall 尽快更新。

不必等待 mdyblog 确认，我这里已经显示修复成功了。

0.4.6a 20141119也好了。

grub4dos 0.4.6a 20141119 -----[debug on ]----- -----[map --floppies=1]----- -----[displaymem ]----- EISA Memory BIOS Interface is present Address Map BIOS Interface is present Lower memory: 638K, Upper memory (to first chipset hole): 1047488K [Address Range Descriptor entries immediately follow (values are 64-bit)]   Usable RAM: Base: 0x0, Length: 0x9F800   Reserved: Base: 0xF0000, Length: 0x10000   Reserved: Base: 0xFEC00000, Length: 0x1400000   Reserved: Base: 0x9F800, Length: 0x800   Usable RAM: Base: 0x100000, Length: 0x3FEF0000   Reserved: Base: 0x3FFF3000, Length: 0xD000   Reserved: Base: 0x3FFF0000, Length: 0x3000 -----[map --mem /1_44M.IMG (20) ]----- FAT12 BPB found with 0xEB (jmp) leading the boot sector. probed C/H/S = 80/2/18, probed total sectors = 2880 -----[map --rehook ]----- Re-map the memdrive (0x14):         map --add-mbt=0 --heads=2 --sectors-per-track=18 (md)0x1FF440+0xB40 (0x14) -----[ls (20)/ ]----- a.txt -----[displaymem ]----- EISA Memory BIOS Interface is present Address Map BIOS Interface is present Lower memory: 638K, Upper memory (to first chipset hole): 1047488K [Address Range Descriptor entries immediately follow (values are 64-bit)]   Usable RAM: Base: 0x0, Length: 0x9F800   Reserved: Base: 0xF0000, Length: 0x10000   Reserved: Base: 0xFEC00000, Length: 0x1400000   Reserved: Base: 0x9F800, Length: 0x800   Usable RAM: Base: 0x100000, Length: 0x3FEF0000   Reserved: Base: 0x3FFF3000, Length: 0xD000   Reserved: Base: 0x3FFF0000, Length: 0x3000 -----[map --status ]----- floppies_orig=1, harddrives_orig=2, floppies_curr=1, harddrives_curr=2 Number of ATAPI CD-ROMs: 0 ram_drive=0x7F, rd_base=0x0, rd_size=0x100000000 Fr To Hm Sm To_C _H _S   Start_Sector     Sector_Count   DHR -- -- -- -- ---- -- -- ---------------- ---------------- --- 14 FF 01 12 8882 FE 7F 00000000001FF440 0000000000000B40 M=S -----END-----

不点

修复好了以后，就不需要 map --floppies=1 了。

你不要碰 floppies 的数目，它该是多少就是多少。

grub4dos 会根据安全性、健壮性的需要，设置一个合理的 floppies 值。

这个值一般无需改动，除非你有自己的理由。

mdyblog

再反映一个奇怪的现象：
网上 grub4dos-0.4.5b-2011-07-14.7z 及以前的版本没问题。
网上 grub4dos-0.4.5b-2011-07-24.7z 及以后的版本有问题。
为此，我的PE中老留着 0.4.5b-2011-07-14 版 grub.exe

在SATA 的笔记本 上 启动 XPPE， 出现奇怪的错误：

Video driver failed to initialized. .... 错误代码：0x000000B4(0x889AFDF8,....

就是显示初始化失败。 哪跟哪？？？ 错的也太奇怪了。

测试机器：  Acer  ASPIRE  4750G    500G硬盘（设为SATA模式)

FBA中测试菜单：

debug off root (hd0) || root (bd) set _root=%@root% title 20141119-FAIL     map /gminipe.iso (0xff)     map --hook     rootnoverify (0xff)     chainloader (0xff) title 20110714-OK     kernel /grub714.exe --config-file="map %_root%/gminipe.iso  (0xff);map --hook;root (0xff);chainloader (0xff);root;boot"

FBA测试包： http://pan.baidu.com/s/1mgKES2W#2014111920110714-Test.fba.7z

不点

mdyblog 发表于 2014-11-19 18:28
【未写完】
在反映一个奇怪的现象：
网上 grub4dos-0.4.5b-2011-07-14.7z 及以前的版本没问题。

请看 2011-07-24 的更新情况：

https://github.com/chenall/grub4dos/commit/bf410af5500e273a86ecda0729e208f5774081f3

你需要在 map --hook 之前先执行 map --int15nolow=1 才等价于旧版本。

对于正常的电脑，采用默认的 map --int15nolow=0 即可。对于有 bug 的电脑，迫使你使用 map --int15nolow=1，否则，无法正常进入 windows。

旧版本没有 int15nolow 参数，相当于新版本的 int15nolow=1。

旧版本无法适应那些必须采用 int15nolow=0 的电脑。

新版本通过引入的新参数 int15nolow 来适应两种不同的电脑。

与此相关的，还有另外一个参数 e820cycles 用来对付这些 buggy 的电脑。

从本质上讲，这些 buggy 的电脑大多都属于 windows 显卡驱动程序的 bug，而不是 bios 的 bug。

有人曾经说过，只要更新 XP 显卡驱动为 win7 的显卡驱动，即可解决此问题。所以，这本来就不属于 grub4dos 的问题。

在仍旧使用 buggy 的显卡驱动程序的情况下，grub4dos 给出了两个 map 参数，用于对付这些情况。它们是：

map --int15nolow=1
map --e820cycles=0

它们的用法都是一样的，用于 map --hook 或 map --rehook 之前。也就是说，只要在 hook 之后，这两个参数的值才真正开始起作用。记住，如果中途改变了这两个参数的值，你需要执行 map --hook 或 map --rehook 才会让新的值生效。

你也许只需要其中之一即可解决问题，也许需要两个同时使用才行。

这两个参数的默认值分别是

map --int15nolow=0
map --e820cycles=-1

就是说，当你不曾设定它们时，它们默认的动作就相当于执行了上述两条命令。
能以默认值运行的情况，说明你的显卡驱动没有问题。不能以默认值运行的情况，说明显卡驱动有 bug，需要更新显卡驱动才能彻底解决这个问题。

注意，e820cycles 的默认值是负1，它表示 grub4dos 的 int15 处理程序永远接管控制，用来保护虚拟盘，使得虚拟盘不至于被操作系统破坏掉。

e820cycles 的值如果是 0，则 grub4dos 的 int15 处理程序将脱钩，不再接管 int15，这样也就无法保护虚拟盘了。但是这却歪打正着，能够适应那些 buggy 的 XP 显卡驱动程序。

mdyblog

不点 发表于 2014-11-19 20:23
请看 2011-07-24 的更新情况：

https://github.com/chenall/grub4dos/commit/bf410af5500e273a86ecd ...

"map --int15nolow=1"  还是 失败。
Video driver failed to initialized.


倒是 “map --e820cycles=0” 能成功。
好像--e820cycles挺恐怖的（尽量不碰它），没有个一致的说法，打击说法都不一样。

能不能出个版本， 默认参数这样的：默认（就像20110714）直接 map --hook 就可以了。
至于 其它复杂用法，用户自己配参数。

debug off root (hd0) || root (bd) set _root=%@root% title 20141119-FAIL     map /gminipe.iso (0xff)     map --hook     rootnoverify (0xff)     chainloader (0xff) title 20141119(int15nolow=1)--FAIL     map /gminipe.iso (0xff)     map --int15nolow=1     map --hook     rootnoverify (0xff)     chainloader (0xff) title 20141119(--e820cycles=0)--OK     map /gminipe.iso (0xff)     map --e820cycles=0     map --hook     rootnoverify (0xff)     chainloader (0xff) title 20110714-OK     kernel /grub714.exe --config-file="map %_root%/gminipe.iso  (0xff);map --hook;root (0xff);chainloader (0xff);root;boot"

FBA测试包： http://pan.baidu.com/s/1mgKES2W#2014111920110714-Test.fba.7z

不点

mdyblog 发表于 2014-11-20 06:20
"map --int15nolow=1"  还是 失败。
Video driver failed to initialized.

好的，你这个报告很好，说明了 int15nolow 不起作用，已经被新的 e820cycles 取代了。

那以后，我们就更简单了，只使用 e820cycles 来控制即可。

现实世界是复杂的，是不那么理想的。我们都想简单，省事，但有可能办不成事。

我们采用的默认值，是依据一个没有 bug 的电脑的情况的。我们的默认值不可能以一个 buggy 的电脑为准。所以，你的想法不能够实现。不兼容性是应该避免的，但是我们的软件是向前发展的，是不断完善的。旧版本不具有 e820cycles 的调整能力，它就应该被淘汰。既然旧版本淘汰了，那么也就不存在不兼容性了。

mdyblog

不点 发表于 2014-11-20 06:45
好的，你这个报告很好，说明了 int15nolow 不起作用，已经被新的 e820cycles 取代了。

那以后，我们就 ...

谢谢！！

这个不“对旧版的兼容性问题”，而是怎么好用的问题！

能不能 e820cycles=0为默认值，
或者， 来个自动判断的<auto>,(re)hook自动能适应启动。
e820cycles=0   比现在的 e820cycles=-1强。

---
e820cycles=0
有时反倒有副作用，反倒启动不了。这个参数e820cycles很不友好。
能不能换个友好的开关（或者e820cycles的安全子集）。这个开关可不考虑内存盘。
-----------------------------
感觉这台电脑，中规中矩的， 怎么说是 “buggy 的电脑”？。
反过来 什么样的电脑不是“buggy 的电脑”？在哪儿？

不点

不是电脑硬件有问题，而是显卡驱动有 bug。假如你换用另外一个显卡驱动，那就没问题了。

你可以编译一个版本采用 e820cycles=0 作为默认值。但是，这个默认值不保护内存盘，你觉得合理吗？

假如有人用这个错误的默认值启动 Linux 或者 DOS 或者 BSD 或者等等其他系统，那么，这些操作系统以及其上应用程序都不知道内存盘的存在，那不是要产生内存冲突吗？

>>> 什么样的电脑不是“buggy 的电脑”？在哪儿？

你能证明所有的电脑都是 buggy 的吗？要是能的话，而且你也永远不再让用户进入 DOS、Linux、BSD 等系统，而只进入 Windows，那你可以设置 e820cycles=0。这些条件只要有一个不满足，你大概就不敢设置 e820cycles = 0 作为默认值吧？

你自己可以编译一个版本来将 e820cycles = 0 作为默认值，但是，我估计你说服不了 grub4dos 的开发维护者，你找不到足够的理由。

mdyblog

不点 发表于 2014-11-20 12:03
不是电脑硬件有问题，而是显卡驱动有 bug。假如你换用另外一个显卡驱动，那就没问题了。

你可以编译一个 ...

》》但是，这个默认值不保护内存盘，你觉得合理吗？

我上面说了“能不能换个友好的开关（或者e820cycles的安全子集）。这个开关可不考虑内存盘。”
这里不考虑 内存盘。 这只是一个友好的 子集。也就是是说， 如果用到需要保护的内存盘，用户 保护一下。
否则，  默认 就是 不保护。
现在 PE 越来越大， 用内存盘启动PE（低效） 的 是少数 派。
有些好的技术， 只是 BIOS启动阶段 直接 仿真一下（非MEM）。进PE后就不用了； 需要外置，用windows平台更稳定的技术。
真有 “需要保护的内存盘”，用户子集设置下，反正这种情况下 用户一般都要必须设置下。

-----
基于以上分析， 默认0比默认-1强。（或者更精细点，如果有10M以上的内存盘(hd0,fd0)，那个未被改动过的默认值就当作-1否则当作0.）
未被改动过的默认值: 用户设定后，标记为“被改动过”，初始为“未被改动过”。


你觉得分析有理吗？

mdyblog

不点 发表于 2014-11-20 12:03
不是电脑硬件有问题，而是显卡驱动有 bug。假如你换用另外一个显卡驱动，那就没问题了。

你可以编译一个 ...

》》假如有人用这个错误的默认值启动 Linux 或者 DOS 或者 BSD 或者等等其他系统，

Linux 下 还需要吗？
没听说这种用法。
Linux  下 访问不了这种BIOS的内存盘的，作为默认情况，保护它没有意义。 所以 作为默认值，不必考虑LInux BSD。
至于 特别情况， 应该 用户自己 解决（自己加命令）。

DOS 好像 不设 -1 即可。 DOS  本来就兼容BIOS，本来就没问题。

(WIn)PE是G4d的大户， 当以此作为默认值的设计。

------------
简单来说， 处理好  “没有需要保护的内存盘” 这一问题子集， 程序也许就好解决了。
问题简化下，就有可能解决了。

不象目前，面对实际的机器，谁都不清楚 实际设值多少合适。搞一堆的菜单（不同的值）， 试来试去的。

你觉得 这种 思考方式 合适吗？

不点

你的意思，我大致这样理解：由于部分 XP 下的显卡驱动程序的 bug，迫使 grub4dos 以它为标准。

你的篇幅太长，但核心的就是这一点，不知我理解得是否准确。

如果不保护内存盘，那么至少要与 DOS 以及 DOS 下的应用软件发生冲突。你觉得一个 grub4dos 的维护者会这么干吗？你试试问问 chenall 同意吗？

你的那种做法，换句话说，就是要让 grub4dos 为一部分 XP 下的显卡驱动的失误而买单。显卡失误本来事情也不大，算是小事，而你要让 grub4dos 以此错误作为规范，那影响的面积是不是太大了？Win7，win8 下的显卡驱动都正常了，只有 XP 下有这样的问题。假如你想要让大家以 XP 为基准，这个我不反对，我自己就在用 XP。但是，如果以 XP 下的某些错误为基准，这个我不能同意，我相信没人同意你，除非你自己同意。

zhaohj

维护很久，未见异常，胆子大的就加在菜单前面
checkrange 524:-1 calc *0x413 & 0xffff || map --int15nolow=1
map --e820cycles=3

mdyblog

不点 发表于 2014-11-20 14:30
你的意思，我大致这样理解：由于部分 XP 下的显卡驱动程序的 bug，迫使 grub4dos 以它为标准。

你的篇幅 ...

我说的是 “没有需要保护的内存盘”  的情况下。 比如根本没有用  "map --mem" 。

还有一点， 关键的一点： 需要升入到代码中，才知道到底怎么回事，还能怎么优化使用。
这样 看DOC说，不一定正确，说不定，甚至根本不是那个原因。

写程序的重要经验： 不要相信DOC，包括纸面上的源代码（而只相信运行中的CODE）。
长期浮在纸面上，对程序就很快失去了控制力，失误就可能变多了。

----------------
还有， 问问 你是老师吗？ 怎么这么迷信规范（有这个规范吗）？
我觉得 实际的碰到  问题才是要解决的问题。

mdyblog

zhaohj 发表于 2014-11-20 15:37
维护很久，未见异常，胆子大的就加在菜单前面
checkrange 524:-1 calc *0x413 & 0xffff || map --int15nol ...

大哥 0x413 是个什么地址？

zhaohj

mdyblog 发表于 2014-11-20 16:40
大哥 0x413 是个什么地址？

内存偏移 0x413 的低位2字节 保存的是低端常规内存的大小（以 K 为单位）。

不点

>>> e820cycles=0
>>> 有时反倒有副作用，反倒启动不了。这个参数e820cycles很不友好。

您是 grub4dos 发展过程中的强力支持者，您是有功之人。尤其是通过本次您的报告，我终于理清了 int15nolow 以及 e820cycles 的关系，知道了 int15nolow 只是阶段性认识的产物，而 e820cycles 才从根本上定位了根源。所以，int15nolow 参数可以废弃了。

我这个帖子，既是给您作进一步的解释，也是给 grub4dos 的维护者做个彻底的技术汇报。

最开始的时候，在英文论坛上，karyonix、 Shao 以及其他开发人员发现，grub4dos 的 int15 不保护常规内存（中的 int13 代码空间），只保护扩展内存（中的内存盘映像） ，这是导致某些蓝屏（或死机）问题的根源。以前我们保护常规内存的 int13 代码空间是通过 0x413 处的用户可用常规内存量来实现的，原以为这样也就 OK 了，但 karyonix 和 Shao 等人的发现，迫使我们完善 int15 处理程序，把常规内存中的 int13 代码也通过 int15 保护起来。这样就是双重保护，一个是利用BIOS 数据区 0x413 处的内存规范，另一个是利用 int15 规范。

接下来，我们中文区的用户很快报告，新版本引起蓝屏死机，还不如旧版本。寻找问题的根源花费了很长时间，终于知道，是增加 int15 代码处理 low memory（即常规内存）而引起的。所以，发明了 int15nolow 参数来应付这些情况。int15nolow=1 时，不再用 int15 保护常规内存。

与此同时，另外有用户报告，即使设定 int15nolow=1，仍有蓝屏死机发生。这就需要进一步通过试验来确定蓝屏死机的原因。最终确定，只要接管 int15 即可导致蓝屏死机，不接管 int15，则可以进入 Windows。在 int15 处理程序的最开头用一条 far jmp 指令跳转到原始的 ROM int15 的入口，则发生完全相同的蓝屏死机现象，连出错码都一样。这就证明了，int15 是不可以接管的，只要接管就蓝屏死机。需要说明的是，发生蓝屏死机的，也只是一部分机器，其他正常的机器也有很多，似乎正常的机器比蓝屏的机器多，蓝屏的是少数，但蓝屏的机器也占有很大的比例，不能忽略不计。后来有人报告，通过更换显卡驱动为 win7 下的驱动，可以解决蓝屏问题。再加上其他大量的用户报告，给开发者提供了重要信息。我们于是逐步明白了，那仅仅是显卡驱动程序的 bug 而已，一部分显卡驱动有问题，而别的厂家的 XP 显卡驱动却没问题。

那时我还没有意识到 int15nolow 与 e820cycles 其实都是在解决同一个问题。int15nolow 的解决方法没有找到症结，它只是阶段性的成果。最终 e820cycles 的解决办法才是对症下药。

现在我已经明白了 int15nolow 的解决办法是靠不住的，根本有效的解决办法是采用 e820cycles 来控制。

mdyblog

zhaohj 发表于 2014-11-20 17:14
内存偏移 0x413 的低位2字节 保存的是低端常规内存的大小（以 K 为单位）。

谢谢！
好像这个 通用性挺强的！！！！ 好好。

不点

mdyblog 发表于 2014-11-20 16:26
我说的是 “没有需要保护的内存盘”  的情况下。 比如根本没有用  "map --mem" 。

还有一点， 关键 ...

我说的是 “没有需要保护的内存盘”  的情况下。 比如根本没有用  "map --mem" 。

不使用内存盘，也得用 int15 保护常规内存中的 grub4dos int13 代码空间，就是前面提到的双重保护。以前我们只用 BIOS 数据区 0x413 的内存规范来保护，但这不够，karyonix，SHao 等开发者发现必须用 int15 来保护，否则在一些机器上会发生死机。然而，当我们用 int15 保护 int13 代码空间时，必然接管 int15，因而必然造成那些 buggy 显卡驱动的蓝屏死机（请看我前一帖的技术汇报）。这才引出了 e820cycles 的处理方法。

还有， 问问 你是老师吗？ 怎么这么迷信规范（有这个规范吗）？
我觉得 实际的碰到  问题才是要解决的问题。

你是否全都是自学成才，完全不需要老师？如果 “只要是老师” 就 “迷信规范”，这样的结论，打击面太大了吧？一个人迷信不迷信规范，跟他是不是老师，有什么必然的因果关系吗？规范是微软等巨头制定的，它当然不代表真理，你不一定需要完全遵守它。但是，假如遵守它有好处的话，那还是要权衡利弊，加以遵守为好。

一方面，完全迷信规范不行，我们多年来都是以事实工业标准为标准，不是以官方所公布的规范文档为标准。

另一方面，完全抛弃规范更不行。

两种错误，一个是左倾，一个是右倾，都是不可取的。

int15 内存规范，是 DOS、Windows 以及其他所有的 x86 操作系统以及应用程序所遵守的规范。没有它，DOS 下就无法使用 map --mem 以及 memdisk 来建立虚拟盘，因为 DOS 的内存管理软件要使用 int15，它就有可能把未经保护的内存盘毁掉，造成死机或者在读取虚拟盘时失败。

世上没有真理，每个人都掌握着他自己的真理。自己主导自己的行为，自己把握自己的方向。自己认为怎样做合适，那就照着去做好了。可以参考别人的意见，但不一定非得听从别人的意见。自己拿主意，自己做决定。

mdyblog

不点 发表于 2014-11-20 18:22
不使用内存盘，也得用 int15 保护常规内存中的 grub4dos int13 代码空间，就是前面提到的双重保护。 ...

》》不使用内存盘，也得用 int15 保护常规内存中的 grub4dos int13 代码空间，就是前面提到的双重保护。
能不能提供一个开关， 直接去掉这些保护， 干脆利索。
这种情况，grub4dos纯粹是个loader, load完了就完全不用了。
（1）不进到需要仿真盘的DOS，或干脆不进DOS。
（2）永不回头地直接启动window（和linux）， 而进去后也不需要保护原来的内存。 能实现吗？ 这样用户不用费心 考虑参数该选多少！！！！

mdyblog

不点 发表于 2014-11-20 18:22
不使用内存盘，也得用 int15 保护常规内存中的 grub4dos int13 代码空间，就是前面提到的双重保护。 ...

》》还有， 问问 你是老师吗？ 怎么这么迷信规范（有这个规范吗）？
这是有来头的。
迷信规范 是西方文化的特产。(西方文化，从古希腊到今天，是建立在信仰的基础上，是一种极低级的文化。)
我们中国人不迷信这个，我们只重事实。

这种化，是来源最近百年的西化。
而西化的中心这是 教师队伍。
什么哲学教、真理教、科学教、马教，都是老师灌输给我们的 宗教信仰——我们的思考力都因此被抹杀了。
可怜的是，很多国人还不知道自己这样”被“西化了！

我这么说（指”迷信规范“）并没有贬低教师。 这只是一个事实陈述，不是价值判断。

不点

mdyblog 发表于 2014-11-20 18:31
》》不使用内存盘，也得用 int15 保护常规内存中的 grub4dos int13 代码空间，就是前面提到的双重保护。
...

如果你不用 map 命令，那你根本就无需接管 int 15，因而所有的 int15nolow 和e820cycles 设置都是没有意义的。这些参数是用来修改 int15 的状态的，既然你根本都不使用 grub4dos 的 int15，那你又何必使用一个没有意义的 int15nolow 或 e820cycles 参数呢？这些参数都是在 map --hook 以后才有效。既然你没有虚拟盘，那你又何必多此一举，添加一条完全没有意义的 int15nolow 或 e820cycles 命令参数呢？

不点

mdyblog 发表于 2014-11-20 18:43
》》还有， 问问 你是老师吗？ 怎么这么迷信规范（有这个规范吗）？
这是有来头的。
迷信规范 是西方 ...

对于您个人的判断和倾向，我不可以添加我个人的判断。我认为您的想法是有您自己的根据的。

每个人都有自己的独立意识，但要想影响到别人的意识形态，那可不那么容易。

DOS，Windows，Linux，grub，等等，许许多多都来源于西方，如果需要割掉西方的东西，大概现在我们都不该上网了，连电话，手机也不能用，火车也不能用，电灯，电视，都不能用。

其实倒是真的可以割掉这些东西。我准备养老的时候，在农村生活，所有西方的那些现代化工具和技术，都废弃掉。原汁原味回归大自然。但是，要让所有的人都这么做，那可是件困难的事。

mdyblog

不点 发表于 2014-11-20 19:46
如果你不用 map 命令，那你根本就无需接管 int 15，因而所有的 int15nolow 和e820cycles 设置都是没有意 ...

-----有虚拟盘， 但不是内存盘。
------（1）-------
map /pe.iso (hd32)
map --hook
--------------------

-----有虚拟内存盘。（稍微复杂点）
------（2）-------
map --mem /pe.img (fd0)
map --hook
--------------------
其共同特点 是：进PE不再访问虚拟盘， 因此不用在PE运行时保护他们。
只是 BIOS启动阶段 访问以上虚拟盘中的 BIOS启动文件（BCD，BOOTMGR，BOOT.WIM ......）

就这种 简单的情况，能提供一个简单统一的开关。
或者先只考虑（1）这种最简单的情况。