再次修改标题！！新版的grldr已经解决了在某些联想老主板上与KON存在内存冲突的问题

不点

楼主报告问题含糊不清。让人不知道究竟是 0.4.5 的问题呢，还是 0.4.6 的问题。

诸如此类的报告，都白费了工夫，与完全不报告是一样的效果。

我们遇到含糊不清的报告，一般都认为是使用者自己的问题，从而予以忽略。甚至有可能连回帖都不回的。

这是处理此类报告的一般原则。

不点

既然是搞错了，那不是你的责任。只是以后注意便可。

提醒一下，0.4.5 和 0.4.6 是两个不同的系列。因此，最新版也有两个，一个是 0.4.5 的最新版，一个是 0.4.6 的最新版。

0.4.5 处于 c 开发阶段，c 是候选发布版的意思。
0.4.6 处于 a 开发阶段，a 是 alpha 测试版的意思。

不点

那你就得搞清楚，究竟从何时开始，不支持 konboot 了。

开发者有可能犯了某个错误，引入了 bug。但如果不知道从何时引入的 bug，那么，开发人员也很难确定错误在哪里。

因此，你还得进一步测试一下，看究竟从何时开始，首次不支持 konboot。

不点

那就是这条了：

2011-07-21 (tinybit)added a map option --int15nolow. Some changes on handler.

新的 int15 默认对 low memory （即低端的常规内存）进行管理，也许你的 PE 不让管理。那你试试在 map --hook 之前添加一条 map --int15nolow=1 命令，如果成功，就证明是你的机器或者你的 PE 的问题了。你也可以在 google 中搜 int15nolow 来了解详细情况。

不点

看来很难定位了。

先测试一下你的内存布局。有一个外部命令叫做 memcheck，运行于 grub4dos。你在运行了

map --mem (ud)/TOOLS/KONBOOT.IMG (fd0)
map --int15nolow=1
map --hook

之后，手动运行 memcheck 贴出显示结果。

memcheck 命令可以从以下帖子中找到和下载：

http://bbs.znpc.net/viewthread.php?tid=6146

建议你也通读一下这个帖子，以便能够贴出更多的有用信息。

不点

提醒一下，假如只是 konboot 有问题，那也可能是由于 konboot 的某个隐蔽的 bug 造成的。

如果你觉得太麻烦，你也可以放弃查找根源的努力。

总之，首先你自己要多多试验，多多暴露问题。比如说，你以别的方式启动 Windows 成功吗？有 map 的情况，以及没有 map 的情况；带 --mem 的情况以及不带 --mem 的情况，等等等等。也就是说，只要没有了 konboot ，是否全都正常了？这个问题很重要，请一定在经过充分测试后给予答复。

不点

map 之后的内存不正确。可能是 grub4dos 的 bug。最后两个内存项目是一样的，这是错误的。

需要贴出 0x413 以及 0x40E 处的值。

做好准备，这个问题可能需要很长时间才能解决。

请使用新版 GRUB4DOS 来运行 memcheck 命令。

你可以这样来运行它，即指定路径：

(...)/.../memcheck

[ 本帖最后由 不点 于 2012-3-20 01:08 编辑 ]

不点

好的，够我消化一阵子了。这些天还有事，可能要等待一些时间才能着手做。

chenall 或者 yaya，以及 zw2312914 可以看看毛病在哪里。

不点

这个问题属于 grub4dos 仿真代码中 int15 处理程序的 bug。好像 zw2312914 前不久已经发现这个问题了。当时我没在意。

放心吧，这个问题一定能够解决。只是暂时有别的事，忙不过来。

请耐心等待。

不点

好的，现在研究 36 楼的贴图。发现了问题。

在 map 之前，read 0x40e 显示 9F80（只有低 16 位对我们有用），这表示，主板的 EBDA 起始于 9F80:0000 即，0x9F800，它占据多少空间呢？应该占据 2K 的空间，也就是，在 0x9FFFF 处结束。

而 read 0x413 也显示，用户可用的内存是 0x27E，也就是 638，单位是 KB。而我们都知道，总的常规内存是 0 - 0xA0000，共 640 K。因此，位于顶端的 0x9F800 - 0xA0000 之间的 2K 空间是用户不应该使用的内存，而位于它之下的内存 0 - 0x9F800 是用户可以使用的内存，共 638 K。

两者是不矛盾的。

但是，map 之后的显示，就有问题了。大家知道，grub4dos 的代码占据 12 K 的常规内存，因此，map 之后，用户可用的常规内存的量应该变成 626 K（638 - 12 = 626），换算成 16 进制，等于 0x272。但贴图显示的却是 0x26c，相差了 6 K。这是不正常的。grub4dos 本身应该不会犯下这么严重的错误。因此怀疑，用户在 map 之前，还有别的、 grub4dos 之外的仿真程序参与了其中（例如 memdisk 之类）。这 6 K 应该是别的仿真代码（memdisk 之类）所占据的空间。

根据以上分析，楼主的报告，应该隐瞒了实情。也许你不是故意的，但你事实上隐瞒了实情。或者可以猜测，你从 grub4dos 的相关文献中早已知道，grub4dos 的仿真不可以与别的仿真混用，但你又确实想混用，于是不得不隐瞒实情，以图侥幸得到解决。

如果不隐瞒实情，你应该先在没有 map 的情况下 read 0x413，然后立即在 map 以及 map --hook 后 read 0x413。此时，由于保证了中间没有别的仿真程序的介入，那么，读到的值应该是 0x272，而决不会是 0x26C。


当有别的仿真代码与 grub4dos 一起混用的时候，我们不能保证 grub4dos 的代码能够正常工作，尤其是与仿真相关的代码，更可能会发生计算错误。

如果确认了这一情况，那么这个问题到此为止，不要再解决了。因为无法解决。属于 grub4dos 不支持的情况，用户应该自己解决。

任何东西都是有条件的。违反了使用条件，等于超限使用。

超载、超负荷，其结果是不能预料的。




[ 本帖最后由 不点 于 2012-3-25 12:37 编辑 ]

不点

你的情况与楼主完全不同，你也知道这一点。

使用 map --e820cycles=3 时，出现任何现象（注意 “ 任何 ” 二字），都是可能的，因而都是正常的。请详细阅读有关的帖子。

ISO 文件能够正常，可能是因为 ISO 尾部的内存空间遭到破坏后影响不严重。IMG 文件不能正常启动，则可以解释为，该 IMG 文件尾部遭到破坏以后，很敏感，可能使得 IMG 里面的某个关键文件被破坏了。

尝试解决办法：先映射一个无用的 IMG 文件到内存顶端（大小自己试着确定一下），目的是让 Windows 破坏这个文件，从而不至于破坏接下来的、真正有用的 IMG 文件。

注意，“ 任何 ” 可能性都会出现，上述办法不一定解决问题。自己摸索适合的方法。以上是一些试图的解释，而不是完善的理论。

补充说明： 如果在 4G 以上有内存，我估计这是个安全地带。假定 XP 不使用 4G 以上的内存，那么，如果内存盘位于 4G 以上，则它不容易遭到 Windows 的破坏。但是，如果你被迫使用了  map --e820cycles=3 ，则 “ 任何 ” 可能性都有，失败了也不奇怪。


zhaohj:

主板把 5G 内存映射在 6G ，这很正常。只要总共内存加起来是 5G，那就没问题。里面肯定有空洞，即，有些内存是不存在的，或者不可访问的。当你有 4 G 内存的时候，你的主板却指示在 4G 以上还有 几百 M 的可用空间，道理是一样的。主板自己的 ROM 或 RAM 占据了一些内存，因此，它把 4G 中的一些可用内存映射到 4G 以上的内存空间上了。

[ 本帖最后由 不点 于 2012-3-25 14:18 编辑 ]

不点

确实有这种可能性。konboot 有可能接管了 int13 或者 int15 之类的。不清楚它干了些什么。

这个问题需要深入研究了。


mem map：

0 - 9B400

这说明，此处的内存占用存在问题。让 konboot 的作者解决吧，估计作者未处理好 int15。

你的内存在未启动 konboot 时，是怎样的呢？

read 0x413 以及 read 0x40e 的结果很重要。

不点

底部那四行，可能正是问题所在。它说，它检测到一个 dummy 的 BIOS，不知它的意思究竟是什么。

它还说，它正试图修复内存映射图的项目，也就是 int15 的项目。

猜测，正是它的修复，造成了问题。换句话说，可能是它修复坏了。

不点

7月14 日的版本，不处理常规内存。但 7 月 14 日以后，grub4dos 的 int15 就要处理常规内存了。可能是 konboot 作者未处理好 int 15，它可能总是假定 int15 不处理常规内存，所以，它的修复也就是有问题的。情况大致上就是这样的。

不点

这还得评估一下 konboot 是个什么性质的程序？它为何要接管 int15？

目前我还想不通，它为何驻留在常规内存里面。找不到合适的理由。

不点

map 前，内存顶部的 EBDA 占用 1K。

map 后，由于 grub4dos 仿真代码占用 12 K，所以，常规内存顶部总共占用 13 K。

0x280 = 640
0x273 = 627

两者相差 13 K，正常。

0xA0000 - 13×1024 = 0x9CC00

这说明，map 后用户可以使用的常规内存的结尾位于 0x9CC00。

但是，konboot 却报告只有 9B400 的可用常规内存，因此，它自己占用了 6 K 的常规内存。 正是这个占用，导致了问题。它占用内存的同时，还修改了 int 15。它应该修改错了。int15 很复杂，一不小心就要出错。有理由怀疑，konboot 没弄好。

konboot 开源吗？如果开源，我们可以帮它找毛病。如果不是开源的，让其作者解决问题。

[ 本帖最后由 不点 于 2012-3-25 17:15 编辑 ]

不点

个人发表一点揣测性意见：

konboot 有可能建立了一个 int13 的虚拟内存盘。否则，它没必要驻留在常规内存。估计它应该像 grub4dos 以及 memdisk 那样，建立了内存盘。设计者自己设计了一套内存盘，与 grub4dos 步调不一致，产生冲突。尤其是，当它的 int15 代码有漏洞时，还间接地造成死机。

我觉得，作者完全可以优化他的代码，去掉他自己的内存盘。这样，他即不需要写 int13 磁盘仿真代码，也不需要写 int15 内存处理代码，当然还永远不会与 grub4dos、memdisk 等仿真程序造成冲突。

分析如下：

在 map --mem /konboot.gz (fd0) 时，已经把 konboot 的代码加载到软盘上了。他可以修改这个软盘的内容，来达到他的目的。

当然，如果他的程序需要接管键盘输入之类的，那他还是需要另外开辟内存使用区，从而自己处理 int15。


===============

当有人发现 grub4dos 的 int15 有错误时，我们可以纠正。

但是，当任何人都不能发现错误时，那怎么可能纠正呢？

总得有错，才能纠正吧？

代码是开源的，任何人都可以检查。

特别是，konboot 的作者也一定可以检查。如果他发现了 grub4dos 的 int15 代码的毛病，相信他一定会给出报告，甚至直接给出补丁。

所以，这个问题可以先放在这里不管它了。等待 konboot 的作者给出结果。

[ 本帖最后由 不点 于 2012-3-26 14:58 编辑 ]

不点

说说我的不同看法吧。

世界上没有完美的东西，没有万能的东西。

grub4dos 的发展、变化，一定有原因。今天由于变化而导致对某个软件造成影响，这并不奇怪。有可能世界本身就是不兼容的，就是不可兼得的。如果你很看重某个不被支持的软件，你可以舍弃新版，而继续使用旧版。你也可以使用其他间接方式（例如memdisk），达到你的目的。你甚至也可以放弃 grub4dos，而选择更适合你具体需要的、更方便的软件，这，都是应该鼓励的。

如果只有一个软件受到影响，这不足以说明问题。也不容易判断究竟错误在哪一方。

如果有很多软件都受到影响了，那么，我们获得的信息就多了，也就容易定位究竟是什么问题了。

我想，我试图谈论的，是 “ 大哲学 ”。但不知道我所谈的，究竟是对还是错，是好还是坏，以及能否被别人认可。

开发人员都很尽力，也很累。所以，如果有人牢骚，那没有用。如果有人故意给开发人员施加压力，那也是不受欢迎的。

为什么呢？因为这很浅薄。不等你来施加压力，开发人员往往自己就给自己施加了大得多的压力，因此你的压力，可能很浅薄，构不成压力，因而一般也就被无视了，像小儿科问题一样，被无视。我个人认为，真正聪明的办法，是设法给开发人员以帮助。假如你百思不得其解，很动了一番脑筋，仍然不知道如何才能给以帮助，那就说明这个问题你是帮不了的，或者，对你来说，这个问题是很困难的。在这样的困难面前，你选择那条路？对了，有 n 条路，其中之一，便是牢骚和埋怨。但正如我所解释的，这不是一个聪明的做法。你要是帮的了，相信你一定也会帮忙的，这是我们大多数人的想法。但是，帮不了的时候，却也往往容易陷入埋怨、指责的陷阱。对的，这确实是陷阱。当你看到刘翔或者某个乒乓球国手失败的时候，你也会埋怨。为什么呢？因为你很着急，而又没有能力帮他，所以，只剩下埋怨这一条路了。但是，埋怨本身，没有什么好处，不能对于解决技术问题有任何的帮助。

开发者需要的是有人伸出帮助之手，而不是前来索取的双手。

如果大家全都是索取者，那就没有 grub4dos，也没有 memdisk，等等，这些软件了。

以上就是个人的不同看法。当然，我的看法也只是一家之言，与其他任何人的看法一样，都是平等的，没有正确与错误、优与劣、好与坏之分。大家都是正确的，都是有道理的。

[ 本帖最后由 不点 于 2012-3-27 12:58 编辑 ]

不点

你没错。即使你不说，别人也会说。你只是谈论了一种可能的思想而已。那不是你一个人的思想，而是代表着具有相同认识的一大批人的思想。任何思想，都是正确的。

我的谈论，也代表另一种思想。那也不是我一个人的思想，而可能是许多人的思想。

我前面用乒乓球国手来比喻，我觉得挺恰当。足球也一样。

不点

拍照很辛苦。

看到没有 kon 参与的时候，read 0x413 得到的是 0x272，这就证实了先前的推测。有 kon 加入时，再次进入 grub4dos，read 0x413 得到的是 0x26c，这证明 kon 驻留在内存中，占用了 6K 的空间。

注意，这个情况本身就是在走钢丝，已经超出 grub4dos 的安全应用范围了。出现任何异常，都是不奇怪的。

grub4dos 的开发者们，最多也只能 “ 严于律己 ”，无法要求 kon 这个软件如何如何，因为这不属于 grub4dos 的开发人员的管辖范围。

如果开发者们无法从自身找到毛病，或者甚至能够证明自身没有问题，那这个问题也就无解（或者暂时无解）。

为了帮助诸位理解这个情况，我再补充几句。

不要以为 kon 以前能够运行，它就必然没问题。这个观念是不正确的。以前能运行，有可能是因为凑巧了，或者说，其潜藏的问题问题未暴露、未引爆而已，或者说是侥幸。哲学和逻辑很重要，往往能够揭示某些容易进入的误区。严谨的思维，这就是哲学和逻辑要教会我们的。在中国，“哲” 有 “聪明” 的含义。只有思维严谨，才会少犯错误，少走弯路。也才能明辨事理。真理都是相对的。以前 kon 能运行，也能配合 memdisk 运行，那说明，kon 这个软件没问题。注意，“没问题” 也是相对的。并非 “绝对没问题”。以前没问题，只是以前的条件、环境之下的一种表现。它可能只是 “ 表现得没问题 ” 而已。这个概念有点抽象，不太容易理解。

以上这是一种理解，但我的意思绝对不是说，只有这样理解才是正确的。我的意思是说，这是一种理解，是当您以前不曾有过这种理解的时候，您可以考虑的、新增的一种理解。这是一种可能性，而不是必然性。多一种理解，就多一种选择，就多一种思维，就多一种出路。有了这种新的理解，你就更灵活了。因为你的路子宽了。

我看到进入 kon 之后，还可以重新进入 grub4dos，那么新的 grub4dos 环境，已经处于不稳定状态了，因为已经有 kon 的代码参与到系统中了。这种不稳定状态究竟会表现如何，那只能碰运气了。运气好了，一切正常。运气不好，就发生死机。

我还可以猜测，kon 这个软件（的开发者）很可能包含了对于 grub4dos 以及 memdisk 等软件的特别 “ 优惠 ”。意思是说，开发者很可能针对 grub4dos 以及 memdisk 这类 “著名的” 软件而 “优化”，就是特别地给以 “支持” 和处理，使得它自己可以被 grub4dos 以及 memdisk 加载。它是如何支持 grub4dos 的呢？可能是这样的：它假定 grub4dos 一定会怎样怎样，然后在这样的假定之下来开发 kon 这个软件。当 grub4dos 发生变化之后，kon 对 grub4dos 的支持也就可能失去基础了。grub4dos 可能 “不知不觉” 地掉进 kon 的 “不支持条件” 之中，结果导致 kon 无法运行了。对于 kon 的开发者来说，他们不能预测 grub4dos 的变化，所以，他们没有责任。对于 grub4dos 的开发者来说，他们也不知道支持 kon 需要什么条件，因为 kon 的开发人员没有告诉 grub4dos 的开发人员有关 kon 的技术细节。所以，这是两张皮，谁都不负责任的。这个问题也就只能靠它自生自灭。说不定 kon 的作者会主动解决这个问题的，假定他们很希望支持 grub4dos 的新版本。

说得太多，不知道我说明白了没有。希望这些话能够有些用处。

不点

我身体吃不消，不能长时间看代码。zw2312914 看到这个问题之后，主动承担起责任来。他很久没有露面了，大概也很忙。这次他看到 yaya 忙于 0.4.6，chenall 忙于 0.4.5，没有人管 int15 了，于是这个任务也就压到 zw2312914 自己的身上了。的确，也只有他适合处理此类问题，他很严谨，尤其在这方面很有经验。纵使我自己身体好，也不一定能找到 int15 的毛病，因为代码是我自己写的，通常自己是很难发现毛病的。换个人之后，才容易找到毛病。早在本帖报告之前，zw2312914 就在时空论坛提到 int15 的（可能的）毛病了，当时我还不以为然。他确实有一种特殊的敏锐。现在他正在寻找 int15 的漏洞，试图捉住潜藏的任何一个 bug，让 grub4dos 的 int 15 代码是 “ 强健的 ”、“ 坚韧的 ”、“ 可以信赖的 ” 和 “ 牢不可破的 ”。这同时也说明，这个问题是在认真处理、认真对待。开发人员很重视，是毫不懈怠的。我想，关注此贴的人，应该比较放心了。

不点

想到另外一个问题。

kon 在 grub4dos 之后驻留内存。那么，它自己的代码究竟是位于 grub4dos 的代码之下呢，还是位于 grub4dos 的代码之上？

无论哪种情况，都不安全。分述如下：

第一种，紧接 grub4dos 的仿真代码之下，这是 kon 最有可能采用的方法。但是，如果此后又进入 grub4dos 的环境，则新的 grub4dos 环境有可能找不到前一个 grub4dos 在内存中放置的仿真程序了，因为 int13 以及 int15 可能已经被 kon 修改了，这样 grub4dos 就可能认为自己从前不曾在常规内存中安装过仿真代码。这种情况下，map --status 将显示不出先前的 grub4dos 所建立的虚拟磁盘（或虚拟光盘）。

第二种，先把 grub4dos 的代码向下移动 6K，然后把空出的 6K 作为 kon 的驻留空间，并保证中断向量表中的 int13 和 int15 都指向 grub4dos 的代码（而不是指向 kon 自己的代码）。这种情况如果设计得很完美，将不发生任何冲突。但困难在于，很难设计完美，因为移动 grub4dos 的代码之后，还得修改 grub4dos 代码中的某些区域，这些区域是安装 int13 处理程序的时候就计算好的，与 int13 处理程序的代码所处的线性地址有关。如果 int13 代码被移动，那么，这些区域必须进行相应的修补，否则 int13、int15 处理程序就要发生错误。而且，一旦 grub4dos 的仿真代码发生改变，这种办法也就要受到影响了。

究竟是哪种情况？谁了解的，可以确认一下。

不点

非常好。

The int13 hook is off. The drive map table is currently empty.

这已经说明，旧的 map 都失效了。比如说，map --status 也未能列出 (fd0) 这个虚拟盘。

(fd0) 本身应该还是可以访问的，只是新的 grub4dos 已经认不出它是由先前的 grub4dos 建立的了，而认为它是 BIOS 建立的，或者是由别的仿真程序（例如 memdisk 之类）建立的，总之，是外来的，不认为它是 grub4dos 内部建立的。

这证明 kon 是采用第一种情况，与我的猜测一致。kon 采用第一种方式所营造的这个环境不安全，不如第二种方式安全（当然，前提是，它必须得处理好前面提到的那些相关问题）。

你提到的警告没有什么影响，通常可以忽略这个警告。

[ 本帖最后由 不点 于 2012-3-28 13:47 编辑 ]

不点

这次终于找到毛病了，功夫不负有心人，很棒。

map 后，kon 还没开始运行，但 3 月 22 日的已经少掉了关于 9C800 - 9F800 这一段的描述。

要是早贴这个图多好，一下子就找到毛病了，不用浪费这么多的楼层。