支持含有碎片的文件仿真

不点

chenall 发表于 2014-11-2 14:16
我这里测试了一下,现在正常了.应该是没有问题了.

那说明，问题的症结找到了，于是就可以提交了。

不点

mdyblog 发表于 2014-11-2 14:51
grub4dos-0.4.5c-2014-11-02.7z (下载这个，如果没问题，就可以提交。)

--------------------

马上就会有。chenall 提交以后，会自动为 0.4.6 打上补丁。

不点

我想不到有什么办法。

大概只能把自己的数据放在内置菜单尾部，自己想办法处理。内置菜单在内存中的位置是公开的。

不点

1。映射的虚拟内存盘，是 BIOS 级的，其作用范围是所有的操作系统，就是说，所有的操作系统都不会破坏虚拟内存盘。因此，你把信息放在内存盘里面，新的 grub 环境也会承认它，不会破坏它。

2。常规内存顶部的一些空间，grub4dos 的内核不用，你可以用，但是，别人也可能会用。如果你不考虑 “别人”，程序始终是你的程序在运行，那你可用的空间还是很多的。但是假如别人也使用这些空闲的空间，那就不好说了。

不点

debug 显示的信息，一般用于排错，定位 bug。看不懂没关系（你图片中的这些内容，我也不太了解），只要平时它不显示出来即可。

关于内存的使用，我印象着，我不使用 0x40000 ～ 0x7FFFF 这段内存。但是，chenall 可能使用了其中低端的一部分内存，你要问 chenall 才行。

0x80000 以上的内存，有可能被 PXE 的 BIOS 占用。grub4dos 的磁盘仿真也占据常规内存顶部的一些空间。所以，你能够自由使用的内存，大致在 0x78000 以下。假定 chenall 使用了 0x40000 至 0x50000 之间的内存，那么，你可以自由使用的内存范围就是 0x50000～0x78000。然而正如前面所说，别人也可能使用这些内存。假如不考虑与别人的冲突问题，你可以使用这段内存。

如果从 grub4dos 环境进入 DOS，再回到 grub4dos 的环境，则上述所说的常规内存段就可能已经被 DOS 破坏了。从 grub4dos 进入 NTLDR 再回到 grub4dos，也是同样的道理，内存都会被破坏。甚至在 grub4dos 下启动另一个 grub4dos 也是会破坏那些内存段的。

不点

目前没有什么公开的办法来获得内存盘的物理地址。

不过你可以自己想办法来弄。你也可以给 chenall 提建议，让他想办法把内存盘的地址弄出来。

不点

pseudo 发表于 2014-11-3 16:52
--mem=RESERV
或有用处

这个一般不能用。固定地址一用，那么在其之上的内存都被看成内存盘了，太浪费内存。

不点

mdyblog 发表于 2014-11-3 18:15
反映一个碰到现象，不知道是否是BUG。
(hd0,2)上的一个连续的HD.IMG还是上次的HD.IMG），有分区表，用扇区 ...

你能否说说 0.4.5 和 0.4.6 哪个有问题？或者是都有问题？

不点

你的步骤标号有点乱，有两个第三步。根据自己的理解，给以答复。

先翻译一下 windows 出错信息，如下：

setup 程序检测到，在你的系统中，要么有多个磁盘无法彼此区分开来，要么有 raw disks。setup 已经纠正了这个错误，但需要你重启动一下。

你创建的 hd1 和 hd2 都是克隆本地硬盘 hd0。hd2 是多余的，windows 无法区分。所以给出错误信息，不再继续运行，以免破坏了你的重要文件。

不点

我看不懂你的解释。但我还是给你的做法加个注释，希望这能够帮到你。

1） 启动后 map  硬盘上的一段扇区序列 为 (hd0)
map   (hd0)0x1000+0x2000  (hd0)  这条命令创建虚拟盘 hd0, 它是用原装的 hd0 的部分扇区序列构成
map   (hd0)  (hd1) 这条命令创建虚拟盘 hd1, 它完全克隆原装的 hd0
map  --rehook
root  (hd0,1)

2) 然后 一程序 又加载 (hd1) 一段扇区序列 为 (hd0)
map   (hd1)0x4000+0xC8000000  (hd0) 创建虚拟盘 hd0, 覆盖掉原先创建的虚拟盘 hd0
map   (hd0)  (hd2) 从 hd0 创建 hd2, 此时，hd2 应该是克隆上次虚拟出来的 hd0，然而，从图片来看，hd2 是克隆了原始盘 hd0, 这是错的，你可以报告 bug. 你对比一下 0.4.5 和 0.4.6, 看看效果是否一样。
map  --rehook
root  (hd0,0)
map --status
就是图1

//下面启动 2003PE
chainloadr  /ntldr
boot

出现上面的 图2的错误.

-------------------
X1）如果没有1）步，直接2）步，启动没问题的。
map   (hd0)0x4000+0xC8000000  (hd0)
map   (hd0)  (hd1)
map  --rehook
root  (hd0,0)
chainloadr  /ntldr
boot
成功

不点

mdyblog 发表于 2014-11-15 10:37
直接 做个Mini测试包(19M) 给你们测试吧， 比码字强多了。
链接: http://pan.baidu.com/s/1bnjdvaR 密 ...

请等待我给菜单加说明。

title TwoStep
        map (hd0,0)/HD.IMG  (hd0)
        map (hd0)  (hd1)
        map --rehook
        root (hd0,1)

此时 hd0 和 hd1 都是虚拟盘，hd0 是原始 hd0 的一部分扇区序列，hd1 是克隆原始的 hd0。

        map --in-situ (hd1,0)/PE.IMG  (hd0)
        map (hd1)  (hd2)
        map --rehook

此时，hd0 是原始盘 hd0 上的 in situ 虚拟盘。它与原始盘 hd0 的分区表不同，其它扇区相同。
此时，hd1 和 hd2 都是原始盘 hd0 的克隆，因此，hd2 是多余的，它有可能让 windows setup 程序感到不愉快。

注意，原始的 hd0 已经被虚拟的 hd0 覆盖、隐藏了，此时只有 hd1 和 hd2 才能用来访问原始的 hd0.


        root (hd0,0)
        chainloader /ntldr
        boot

不点

mdyblog 发表于 2014-11-15 11:21
title TwoStepNew:FAIL
        map (hd0,0)/HD.IMG  (hd0)
        map (hd0)  (hd1)

你这个 hd2 又变成hd.img的虚拟克隆盘了。你贴出 map --status，应该与上次不同。

如果相同，那就是 bug 了。试试 0.4.5 和 0.4.6 是否一样？

不点

mdyblog 发表于 2014-11-15 11:16
菜单我明白， 就是我写的。
1） 就是 map -status 输出的那几行映射表， 看不明白。

map --status 显示信息里面，关键的几个指标是

Fr  ------- 表示创建的虚拟盘的盘号。
To  ------  表示究竟是在哪个真实盘上创建这个虚拟盘的。

start sector ------ 表示用于创建虚拟盘的起始扇区号，这是宿主真实盘上的起始扇区号。
sector count ----- 表示用于创建虚拟盘的扇区数目，这是指宿主真实盘上的扇区数目。

其它信息可以不用关注。

不点

好的，chenall 干得不错，发现了问题。接下来你再试着排解错误。

不点

mdyblog 发表于 2014-11-15 12:19
是这样吗？
+63是第一分区的偏移。

大致应该是这样的吧。

不点

chenall 发表于 2014-11-15 16:16
找到了一个疑似BUG,麻烦不点确认一下,顺便把修改后的编译版本也上传起来.我测试了一下,好像是正常的.

很棒,最近失误太多,大概人老了，力不从心,智力下降。赶快提交吧。

不点

mdyblog 发表于 2014-11-17 13:05
好像和机器有关。
老的台式机有问题。

0.4.5 也有问题吗？

用 --mem 之后，扇区都在内存里，根本不会跑去执行原始 BIOS 的 int13，又怎可能会出错误呢？难以理解。

不点

mdyblog 发表于 2014-11-18 04:26
回复：
2014-1115 0.45c  一样的问题。

检查了 10 月 9 日前后的代码，没发现问题。你能否进一步确定引入 bug 的准确日期？另外也说说老电脑的配置情况，它的内存有多大？主板厂家？生产日期？可以用 displaymem 命令显示其内存分布。另外，用 map --status 显示有关仿真的一些基本信息。还可以用 debug on 打开调试输出，然后再执行 ls 列出虚拟软盘的文件。      

不点

11月3日是我改动的。我就纳闷，为什么最近我总是犯错误？11月3日有什么错误，我还没来得及看。我想让 chenall、yaya 看看，究竟错在哪？

我无非就是屏蔽了 BIOS 数据区的软盘，难道我没有屏蔽掉软盘，而是把别的地方弄坏了？

请 chenall、yaya 仔细检查检查。

不点

mdyblog 发表于 2014-11-18 11:02
1: G4d0.46a 2014-1103 开始有这个问题。 1102没有这个问题

2:

烦请您再做个试验，运行下面的命令，将软盘个数恢复为原始状态，看看还会出错吗？

map --floppies=1

不点

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

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

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

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

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

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

不点

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

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

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

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

不点

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

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

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

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

请尽快修复。

不点

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

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

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

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

不点

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-20 06:20
"map --int15nolow=1"  还是 失败。
Video driver failed to initialized.

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

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

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

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

不点

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

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

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

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

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

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

不点

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

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

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

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

不点

>>> 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 发表于 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，它就有可能把未经保护的内存盘毁掉，造成死机或者在读取虚拟盘时失败。

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