无忧启动论坛

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

作者: zjzaog 时间: 2012-3-17 23:58
标题: 再次修改标题！！新版的grldr已经解决了在某些联想老主板上与KON存在内存冲突的问题
新版的grldr已经解决此问题！以下内容成为过去时了……只要升级就ok！！特别感谢勤勉的grub4dos的团队！
【新版的grldr与KON不兼容，启动的时候提示内存不足，换成老版本的却可以用！但是没有VBE的漂亮换面，纠结啊～～】
【----具体的状况请看#86楼拍的图，对比7-14和3-22的图请看#101楼】
【暂时替代方法：1、可以结合memdisk使用；2、也可以通过FBINST调用7.14版的GRLDR，再通过7.14版的GRLDR调用KONBOOT，】
【现在只要升级就可以。】

原帖由不点于 2012-3-25 17:06 发表
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 编辑 ]

原帖由 幸运的草 于 2012-3-25 20:21 发表
回复 #63 zjzaog 的帖子

通过不点的分析，可以判断是由于新版GRLDR对常规内存进行了控制，KONBOOT与之有内存的冲突。
知道问题所在，可采以下取变通方法加以解决。(该方法只对FB制作的U盘，对其他方式不适用)

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

　下载7.14版的GRLDR，改名为KONBOOT或其他名。修改改名后的grldr内置菜单，在内置菜单中调用KONBOOT。
　　修改FBINST菜单，在FBINST菜单中调用这个改名后的GRLDR（7.14版）。

　　即通过FBINST调用7.14版的GRLDR，再通过7.14版的GRLDR调用KONBOOT。

原帖由不点于 2012-3-26 06:56 发表

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

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 编辑 ]

原帖由不点于 2012-3-29 05:35 发表
回复 #101 zjzaog 的帖子

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

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

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

原帖由 zjzaog 于 2012-3-29 20:54 发表
在时空看到不点大师上传的新版的grldr已经解决了这个问题，大家只要升级就ok，估计不久就能放出新版！完美，这贴可以关了，哈哈

3月29日的GRLDR，测试通过。没有发现与KON冲突。
测试菜单，没有使用多余的参数
map --mem /konboot.gz (fd0)
map (hd0)  (hd1)
map (hd1)  (hd0)
map --hook
chainloader ()+1
rootnoverify (fd0)
大家再通过泛的测试，(非memdisk方式)，看是否有问题。

[ 本帖最后由幸运的草于 2012-3-29 22:00 编辑 ]

附件
2012-3-29 21:35
  下载次数: 2
grub4dos-0.4.5c-2012-03-29.7z.zip (251.66 KB)

[ 本帖最后由 zjzaog 于 2012-3-30 10:11 编辑 ]

作者: 2012哈根 时间: 2012-3-18 03:20
难怪我怎么试都不行，希望c大大改善一下。

作者: chenall 时间: 2012-3-18 10:22
很正常的啊，你是怎么启动的。哪个版本？

[ 本帖最后由 chenall 于 2012-3-18 11:44 编辑 ]

作者: 2012哈根 时间: 2012-3-18 11:41
标题: 回复 #3 chenall 的帖子
报告C大大，我用的是grub4dos-0.4.6a-2012-02-27.7z 版的，

KONBOOT.GZ

6 KB, 下载次数: 131, 下载积分: 无忧币 -2

作者: chenall 时间: 2012-3-18 11:43
请先使用0.4.5测试。

作者: zjzaog 时间: 2012-3-18 22:06
标题: 回复 #5 chenall 的帖子
进系统的这个步骤会提示windows NT 需要最少7mb memory，换成旧版的galdr就完美的进去的，我什么都没有改动，就换了版本

作者: xintiandi 时间: 2012-3-19 11:49
我用的kon没有问题啊。我用的0.4.5c 2012.2.27，只是在有些机子上启动后会蓝屏，但是都可以进入kon的界面和运行他。

作者: 不点 时间: 2012-3-19 13:25
楼主报告问题含糊不清。让人不知道究竟是 0.4.5 的问题呢，还是 0.4.6 的问题。

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

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

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

作者: zjzaog 时间: 2012-3-19 17:01

原帖由 zjzaog 于 2012-3-17 23:58 发表
新版的grldr与KON不兼容，启动的时候提示内存不足，换成老版本的却可以用！但是没有VBE的漂亮换面，纠结啊～～

所以我用的是最新版0.4.6的grldr，在这贴里已经说的很清楚，怎么能说搞不清版本呢？

原帖由 zjzaog 于 2012-3-18 22:06 发表
进系统的这个步骤会提示windows NT 需要最少7mb memory，换成旧版的galdr就完美的进去的，我什么都没有改动，就换了版本

在这里说明了症状，不知不点大师有没有试一下kon与最新版的结合？您是否是看了下面的人说没有问题，所以以为我是乱叫呢？

原帖由 xintiandi 于 2012-3-19 11:49 发表
我用的kon没有问题啊。我用的0.4.5c 2012.2.27，只是在有些机子上启动后会蓝屏，但是都可以进入kon的界面和运行他。

我试用了2012.2.27的0.4.5c和0.4.6a的两个版本，都不行！换成更早的版本却是没有问题的！

[ 本帖最后由 zjzaog 于 2012-3-19 17:26 编辑 ]

作者: chenall 时间: 2012-3-19 17:09
很淡定的路过，没有什么好说的。

作者: zjzaog 时间: 2012-3-19 17:18

原帖由 chenall 于 2012-3-19 17:09 发表
很淡定的路过，没有什么好说的。

十分惭愧，让c大笑了，！上资源贴才发现有2。27的0.4.5c的，
惭愧啊，我是通过FbinstTool升级的，升级界面上没有2.27的0.4.5c，只有0.4.6，唉～～～

作者: chenall 时间: 2012-3-19 17:42
现在知道了两个问题。

1.FbinstTool有BUG不能适应同一天发布两个不同版本的情况。
2.grub4dos0.4.6a和KON不兼容（我还没有试，晚上得空再试试看）。

作者: zjzaog 时间: 2012-3-19 17:46
标题: 回复 #12 chenall 的帖子
实际上我把整个0.4.5c的从1月17号到2月27号的都遍都出现NT需要7mb的问题，直接卡死了，

作者: sratlf 时间: 2012-3-19 17:50
标题: 回复 #12 chenall 的帖子
我试了下没问题。。。

猜测是zjzaog的konboot版本不太一样。。。

作者: 不点 时间: 2012-3-19 17:50
标题: 回复 #11 zjzaog 的帖子
既然是搞错了，那不是你的责任。只是以后注意便可。

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

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

作者: zjzaog 时间: 2012-3-19 18:08
还有，我试用了一下grub4dos-0[1].4.5b-2011-06-19.7z的这个版本是完美进去的，konboot是最新的版本，不是最早的那个

[ 本帖最后由 zjzaog 于 2012-3-19 18:09 编辑 ]

KONBOOTS.rar

2.93 KB, 下载次数: 71, 下载积分: 无忧币 -2

作者: 不点 时间: 2012-3-19 18:24
标题: 回复 #16 zjzaog 的帖子
那你就得搞清楚，究竟从何时开始，不支持 konboot 了。

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

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

作者: chenall 时间: 2012-3-19 20:58
刚试了一下，在我的电脑上一切正常。0.4.5C和0.4.6A都可以使用。

作者: zjzaog 时间: 2012-3-19 22:28
标题: 回复 #18 chenall 的帖子
通过地毯式的换用版本，我发现2011年7月14号的版本是个分水岭，使用之前（包括7月14号）的版本的grldr，kon在我的电脑上完美的进入系统，之后的所有版本都出现错误。并且按任何键都没用，只有按主机上的重启键

[ 本帖最后由 zjzaog 于 2012-3-19 22:33 编辑 ]

SUC50150.JPG (157.25 KB, 下载次数: 110)

作者: zjzaog 时间: 2012-3-19 22:42
我在grldr的升级记录中看到了这句话
http://code.google.com/p/grub4do ... -03-10.zip&can=2&q=
"迟来的更新，针对自2011-07-16至2012-02-27的改动更新说明，重点在 vbe 模式有关的命令，取消外部命令 unifont 说明，增加外部命令 hotkey 说明。"
肯请不点大师，c大，等诸多前辈研究一下这个情况。会否与VBE有关？？特别是7-14之后的版本在我的电脑上都不能用的情况！

[ 本帖最后由 zjzaog 于 2012-3-19 22:49 编辑 ]

作者: sratlf 时间: 2012-3-19 23:02
标题: 回复 #20 zjzaog 的帖子
这个不是更新日志。。。。

ChangeLog_chenall.txt

2011-07-30
1.批处理执行时允许使用Ctrl+C强制中断运行.

2011-07-19
1.内置变量?_WENV=?_UUID=?
   注:1.将来会取消?_UUID,为了保持兼容性,暂时先放一段时间.
         请使用%?%或%?_WENV%代替%?_UUID%来获取UUID.
      2.%?%变量可以获取命令返回的字符串信息.
         目前可用的信息有两个.uuid dev(返回指定设备的UUID字符串),cat --locate= (返回最后一个找到的位置)
2.@random算法修改.

2011-07-13
1.在执行cmain之前初始化变量内存空间。

ChangeLog_GRUB4DOS.txt

2011-07-27 (tinybit)fixed a careless mistake in clean_entry().
2011-07-21 (tinybit)added a map option --int15nolow. Some changes on handler.
2011-07-10 (tinybit)re-enabled int13/ah=16h floppy detection in int13_handler.
2011-06-28 (tinybit)fixed a careless mistake in probe_mbr(missing evaluation on C/H/S). fixed a bug in clean_entry() which return the address of a local variable.

这个才是更新日志

作者: chenall 时间: 2012-3-19 23:02
我自己测试了几台电脑都正常。不排除是你自己使用的问题。

请贴出详细菜单，启动方式，等相关信息。在启动之前最好再贴一下map --status命令的结果。

作者: zjzaog 时间: 2012-3-19 23:44
我是把konboot.img放在ud区，以下是我的详细菜单：
timeout 20
default 0

title [0]LOCAL-SYSTEM
find --set-root --ignore-floppies --ignore-cd /ntldr || find --set-root --ignore-floppies --ignore-cd /bootmgr
chainloader /ntldr || chainloader /bootmgr

title [1]WIN03-PE.ISO
find --set-root --ignore-floppies --ignore-cd /T/WIN03PE.ISO
map /T/WIN03PE.ISO (0xff)
map --hook
chainloader (0xff)

title [2]WINXP-PE.ISO
map (ud)/0PE/0PE.ISO (0xff)
map --hook
root (0xff)
configfile /0PE/M.0PE

title [3]GHOST-CN.IMG
map --mem (ud)/TOOLS/GHOST.IMG (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)

title [4]IMAGE-CN.IMG
map --mem (ud)/TOOLS/IMAGE.IMG (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)

title [5]DISKGENS.IMG
map --mem (ud)/TOOLS/DISKGENS.IMG (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)

title [6]KONBOOT.IMG
map --mem (ud)/TOOLS/KONBOOT.IMG (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)

title [7]PASSWORD.IMG
map --mem (ud)/TOOLS/PASSWORD.IMG (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)

作者: 不点 时间: 2012-3-19 23:46
标题: 回复 #23 zjzaog 的帖子
那就是这条了：

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 来了解详细情况。

作者: zjzaog 时间: 2012-3-19 23:57
标题: 回复 #24 不点的帖子
不点大师您好，
刚刚我下载2012年2月27号0.4.5c的grldr，在菜单中贴加红色的内容，仍然出现一样的错误内容。
title [6]KONBOOT.IMG
map --mem (ud)/TOOLS/KONBOOT.IMG (fd0)
map --int15nolow=1
map --hook
chainloader (fd0)+1
rootnoverify (fd0)

作者: 不点 时间: 2012-3-20 00:10
看来很难定位了。

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

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

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

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

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

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

作者: zjzaog 时间: 2012-3-20 00:16
这个是我map之前先map --status一下的结果

SUC50151.JPG (131.66 KB, 下载次数: 104)

作者: 不点 时间: 2012-3-20 00:39
提醒一下，假如只是 konboot 有问题，那也可能是由于 konboot 的某个隐蔽的 bug 造成的。

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

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

作者: zjzaog 时间: 2012-3-20 00:54
标题: 回复 #28 不点的帖子
注意，这两幅图有一定问题，具体的截图，请看#101楼

我把memcheck和memcheck.c文件放在(ud)\boot\grub和(ud)\boot下面各放一份（为了保险^,^）,用2月27号的0.4.5c，手动运行memcheck，提示no such cmomand！！
用2011-7-14号grldr手动运行memcheck成功，一下两张图片，一张是map之前，一张是map之后再boot之后的截图，

[ 本帖最后由 zjzaog 于 2012-3-29 13:46 编辑 ]

SUC50154.JPG (195.8 KB, 下载次数: 117)

map之前

SUC50155.JPG (211.11 KB, 下载次数: 112)

boot之后

作者: zjzaog 时间: 2012-3-20 00:57
2011年7月14号的版本是能完美进入系统的，而0.4.5c的grldr运行konboot之后不能进去，我再去试试带不带--men的区别

作者: 不点 时间: 2012-3-20 01:04
map 之后的内存不正确。可能是 grub4dos 的 bug。最后两个内存项目是一样的，这是错误的。

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

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

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

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

(...)/.../memcheck

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

作者: zjzaog 时间: 2012-3-20 01:06
标题: 回复 #31 不点的帖子
不点大师您好
刚才试用了带不带mem，结果是一样的！
放在非ud区，结果也是一样的！
都以失败告终，我再去试试0x413和0x40E

作者: zjzaog 时间: 2012-3-20 01:18
标题: 回复 #31 不点的帖子
前两张是map之前的，后一张上是map之后的

[ 本帖最后由 zjzaog 于 2012-3-20 01:57 编辑 ]

作者: zjzaog 时间: 2012-3-20 01:30
接下来请看memchek的结果

作者: zjzaog 时间: 2012-3-20 01:30
memchek的结果，这是0.4.5c 2012-2-27的

[ 本帖最后由 zjzaog 于 2012-3-20 01:58 编辑 ]

作者: zjzaog 时间: 2012-3-20 01:56

原帖由不点于 2012-3-20 00:10 发表
看来很难定位了。

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

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

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

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

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

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

不点大师请注意，以上的图作废，因为我刚刚又忘了运行map --int15nolow=1这一行，请看下面的描述：
我重新拍图，请观察，0.4.5c运行konboot还是进不去系统，会出现错误！
现在按照您的指示，在运行一下菜单前后都拍了图下来，请观察
map --mem (ud)/TOOLS/KONBOOT.IMG (fd0)
map --int15nolow=1
map --hook

===============
请看#86楼更加清楚详细的拍照

[ 本帖最后由 zjzaog 于 2012-3-27 15:22 编辑 ]

作者: 不点 时间: 2012-3-20 02:18
好的，够我消化一阵子了。这些天还有事，可能要等待一些时间才能着手做。

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

作者: chenall 时间: 2012-3-20 21:17
看起来问题挺严重的，我对这些不太了解。暂时没有办法,

对了楼主用的是什么样的主板啊，我这里都是正常的。

作者: zjzaog 时间: 2012-3-20 23:07
2006年的联想整机，这是我的主板名称：下面附带主板的详细报告
主板:
主板 ID 07/13/2005-K8M800-8237-6A7L1E19C-00
主板名称 Muse K8M800-M3

[ 本帖最后由 zjzaog 于 2012-3-20 23:24 编辑 ]

Report.rar

3.3 KB, 下载次数: 24, 下载积分: 无忧币 -2

Report2.rar

30.78 KB, 下载次数: 40, 下载积分: 无忧币 -2

更详细的硬件报告

作者: zjzaog 时间: 2012-3-20 23:34
用7月14号前（包括7月14日）的版本的grldr在map前和map后，memcheck的结果是一样的，但是7月14号之后的版本的grldr在map前后的最后一行不一样！read 0x413的结果也不一样

原帖由 rockrock99 于 2011-7-28 18:00发表在时空论坛
近期版本在戴尔Inspiron Laptop N4030笔记本上遇到问题
如题
启动PE中途蓝屏
错误代码：
STOP:0x000000B4(0x8A08A7F8,0x8A084000,0x89F6A000,0x00050000)

目前已测试版本
grub4dos-0.4.5b-2011-07-28 失败
grub4dos-0.4.5b-2011-07-24 失败
grub4dos-0.4.5b-2011-07-14(含以前) 均成功

怀疑跟"2011-07-21 (tinybit)added a map option --int15nolow. Some changes on handler."此项有关

看来这位仁兄跟我碰到的问题相似，但是他的解决方法为什么不适用于我？？不过我们的相同点是7月14日之前的版本的grldr都能用。

[ 本帖最后由 zjzaog 于 2012-3-20 23:52 编辑 ]

作者: 幸运的草 时间: 2012-3-21 18:14
原来，我运行这个工具在VM中测试正常但在实机出问题，还以为是我机器的问题。
但看了楼主的问题，今天我也下载2011.7.10日的GRLDR测试，调用出现界面并启动WINDOWS成功。
但换新版grub4dos-0.4.5c测试，可以出现kon的界面并检测，然后出现以下提示。
Computer or run a configuration program provided by the manufactu：
Memory Map:
00000000-0009B400
直接卡死（真卡死）。
联想机。主板型号：ms-7102

作者: chenall 时间: 2012-3-21 18:25
也是联想的？？巧合，还是？？？？？？？？？

作者: zjzaog 时间: 2012-3-21 21:58
标题: 回复 #42 chenall 的帖子
C大，在7月14日到24日之间发生了什么样的改变，一定要重点研究哦！！！！似乎map机制有变化呀，memcheck的结果不一样，而14号前（包括14号）的则memcheck的结果一样，似乎以前的map机制更猛一点点……

作者: 幸运的草 时间: 2012-3-22 09:19
标题: 回复 #42 chenall 的帖子
个人认为应该是巧合，因为我的是老机，05年产的机。而新版G4D才只是去年的事。因此，没有理由认为是厂家的人为打压的问题。
对KON这个工具，只是在U盘中带有，实际根本就没有使用过。只是一个偶然的因素，试用了一下，发现真机出问题，也没有在意。而今看了楼主反映的问题。才引起注意，验证了一下。

刚对单位04年产的联想机测试，主板型号：ms-7067.
结果同＃41一样，只是提示信息有变化：
Memory Map:
map:00000000-0009AC00

[ 本帖最后由幸运的草于 2012-3-22 10:11 编辑 ]

作者: chenall 时间: 2012-3-22 11:47
知道了7.14之后的版本出现问题就比较好定位了。

作者: zjzaog 时间: 2012-3-22 11:47
标题: 回复 #44 幸运的草的帖子
你同事的机子，如果用7月14号前的grldr有问题没有呢？

作者: 幸运的草 时间: 2012-3-22 12:12
标题: 回复 #46 zjzaog 的帖子
我＃44已经说了，测试结果同＃41的相同，也就是说7.14前的版本没有问题。
只是提示信息有点变化。但这台机识别U盘是是ZIP，那台机是HDD。

作者: 不点 时间: 2012-3-22 19:30
这个问题属于 grub4dos 仿真代码中 int15 处理程序的 bug。好像 zw2312914 前不久已经发现这个问题了。当时我没在意。

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

请耐心等待。

作者: thttht 时间: 2012-3-22 22:26
大大在这里借用地方请教一个问题！我在用--top的参数加载文件时为什么iso文件类型的光驱镜像可以正常启动，加载img的硬盘镜像里的Win2003系统时就07b蓝屏啊？--top参数的使用有什么要求吗？我的这个 img的win2003是用Firadisk 0.0.1.30驱动做的RAMOS!

我也试了7月10日的版本，不过也不能用 --top的参数启动，同样会蓝屏！不知道我的这个问题是哪里的问题啊？是我系统的问题，还是我主板硬件的问题或是 Firadisk 驱动的问题？

并且zhaohj大让我在菜单头部加入下面这个保护内存再用 --top的参数启动，可这样还是会蓝屏！

default 0
timeout 10
checkrange 524:-1 calc *0x413 & 0xffff || map --int15nolow=1
map --e820cycles=3

------------------------------------------------------------------------------------------------------------------------
说明一下。我的机器内存为：5G

下面是主板内存大小的截图：

现在贴出截图，
这是使用--top的参数加载img的截图：（这部分截图用的是2012年2月27日的版本）

这是没有使用--top的参数加载img的截图：

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

这里是加载iso文件的截图：（这里说明一下，这部分截图用的是2012年3月20日的版本，2012年2月27日的版本情况相同就没有在从新用2012年2月27日的版本截图）

加载iso文件时用不用 --top参数都不会蓝屏，都可以正常启动！

这是使用--top的参数的：

这是没有使用--top的参数的：

[ 本帖最后由 thttht 于 2012-3-24 17:11 编辑 ]

作者: zhaohj 时间: 2012-3-23 11:07
Usable RAM: Base: 0x100000000, Length: 0x80000000
-----------------------
上面计算是否有误啊，他的机器一共5G内存，而这里解释是：可用内存区域4G开始长度是2G的范围。

再看map --mem --top的映射情况：
Start_Sector=b96ff8，即5933M开始的

[ 本帖最后由 zhaohj 于 2012-3-23 11:38 编辑 ]

作者: 不点 时间: 2012-3-25 12:24
好的，现在研究 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 编辑 ]

作者: zhaohj 时间: 2012-3-25 13:50
不点大再分析一下49楼的情况，怎么map --mem --top会跨越5G以上？

作者: 不点 时间: 2012-3-25 14:04
标题: 回复 #49 thttht 的帖子
你的情况与楼主完全不同，你也知道这一点。

使用 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 编辑 ]

作者: 幸运的草 时间: 2012-3-25 16:20
回复 #51 不点的帖子

经多台不同时间生产的联想老机测试，2011.7.14前的GRLDR，运行KONBOOT.GZ没有问题。
　FB制作的HDD格式的U盘

菜单：title [3] >运行 KonBoot 免口令模块 \n

map --mem (ud)/BOOT/IMGS/KONBOOT.gz (fd0)
map (hd0) (hd1)
map (hd1) (hd0)
map --rehook
chainloader (fd0)+1
rootnoverify (fd0)

调用后：2011.7.14以后的出现问题。手机拍图如下。卡死。

而KONBOOT.GZ刚好为6KB。不知是否巧合？

作者: 幸运的草 时间: 2012-3-25 16:26
注：图片中下方四行提示为KONBOOT.GZ运行的正常提示。上方的三行提示，是在下方的四行提示完后出现的。然后卡死。

to 不点

经测试，2011.7.14以后的GRLDR，确实是对KONBOOT.GZ不兼容，相同的菜单，同一个KON版本，只调换一个GRLDR就出问题。
而调用KONBOOT.GZ根本不需要仿真FIRADISK之类的，而楼主上面也报出了加载菜单。所以，造成内存的问题，您推断的理由不能成立，只能从G4D方面查找原因。
　　而KONBOOT.GZ刚好为6KB。是否为巧合？

[ 本帖最后由幸运的草于 2012-3-25 16:34 编辑 ]

作者: 不点 时间: 2012-3-25 16:31
确实有这种可能性。konboot 有可能接管了 int13 或者 int15 之类的。不清楚它干了些什么。

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

mem map：

0 - 9B400

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

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

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

作者: 不点 时间: 2012-3-25 16:35
标题: 回复 #55 幸运的草的帖子
底部那四行，可能正是问题所在。它说，它检测到一个 dummy 的 BIOS，不知它的意思究竟是什么。

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

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

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

作者: 不点 时间: 2012-3-25 16:49
这还得评估一下 konboot 是个什么性质的程序？它为何要接管 int15？

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

作者: 幸运的草 时间: 2012-3-25 16:51
不点大师的回复真快：
现按要求补了两张0x413 及0x40e的图。

未map　konboot.gz 前

map konboot.gz 后.

哦，真如你说的那样，就明白了2011.7.14前后的变化。

作者: 幸运的草 时间: 2012-3-25 16:55
这个工具是要绕过windows登录密码直接启动系统。不知他采取什么技术。
我试过，7.14版前，确实能不要WINDOWS　XP的登录密码，在点用户名后就可以不要密码直接进系统。

作者: 不点 时间: 2012-3-25 17:06
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 编辑 ]

作者: zjzaog 时间: 2012-3-25 19:38
不点大师，这是我的konboot启动画面，卡在这里。7月14日前后的版本都是这样显示的，但是7月14日前的版本能顺利进去。而之后的版本就卡死在这里

[ 本帖最后由 zjzaog 于 2012-3-25 20:19 编辑 ]

SUC50170.JPG (134.85 KB, 下载次数: 157)

作者: 幸运的草 时间: 2012-3-25 20:21
标题: 回复 #63 zjzaog 的帖子
通过不点的分析，可以判断是由于新版GRLDR对常规内存进行了控制，KONBOOT与之有内存的冲突。
知道问题所在，可采以下取变通方法加以解决。(该方法只对FB制作的U盘，对其他方式不适用)

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

　下载7.14版的GRLDR，改名为KONBOOT或其他名。修改改名后的grldr内置菜单，在内置菜单中调用KONBOOT。
　　修改FBINST菜单，在FBINST菜单中调用这个改名后的GRLDR（7.14版）。

　　即通过FBINST调用7.14版的GRLDR，再通过7.14版的GRLDR调用KONBOOT。

作者: zjzaog 时间: 2012-3-25 20:34
标题: 回复 #64 幸运的草的帖子
谢谢您，我试试看，不知道能不能加条什么命令就可以让grldr不对常规内存进行了控制

作者: chenall 时间: 2012-3-25 21:33
可以试试加以下参数
--int15nolow=1
--e820cycles=3
可以试试看

作者: zjzaog 时间: 2012-3-25 23:00
标题: 回复 #66 chenall 的帖子
试了试这两个参数，还是不行，卡死了……，
我只能通过FBINST调用7.14版的GRLDR，这样子也就多用248kb的空间，弄成功了，总之谢谢各位的帮助。谢谢不点、chenall 、幸运的草等诸位大侠

作者: 不点 时间: 2012-3-26 06:56
个人发表一点揣测性意见：

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 编辑 ]

作者: 幸运的草 时间: 2012-3-26 16:52
标题: 回复 #68 不点的帖子
KONBOOT原版是商业软件，是带加密狗的。由ISO和IMG版的。目前网络上流行的6KB的是破解并经修改过的。
这里有介绍：
http://hi.baidu.com/sprite_guo/b ... c2c6b3a50f52e9.html
所以，很难判断是原版就有的问题，还是修改版的问题。
知道了问题所在。解决办法（非GRLDR内部）已经不是问题了。

[ 本帖最后由幸运的草于 2012-3-26 16:54 编辑 ]

作者: chenall 时间: 2012-3-26 16:56
有没有人试一下用MEMDISK能不能启动

kernel /memdisk
initrd /konboot.img

作者: chenall 时间: 2012-3-26 16:57
标题: 回复 #69 幸运的草的帖子
有免费版的,我就是用免费版的,在我的电脑上可以正常使用.

http://www.piotrbania.com/all/kon-boot/index2.html#free

作者: zhs509 时间: 2012-3-26 17:12
标题: 回复 #71 chenall 的帖子
确实有免费的。。。
好像免费版不支持win7，还没测试，昨天翻墙才下载下来。。。

[ 本帖最后由 zhs509 于 2012-3-26 17:16 编辑 ]

kon-boot-all.zip

62.39 KB, 下载次数: 52, 下载积分: 无忧币 -2

官方下载的文件，没有经过任何修改，解压密码：kon-boot

作者: zhs509 时间: 2012-3-26 17:29
vmware虚拟机测试没问题。。。

通过ZXW的RUN模块启动kon-boot绕过winxp 32位系统的密码

作者: 幸运的草 时间: 2012-3-26 17:52
回复 #71 chenall 的帖子
回复 #72 zhs509 的帖子
刚下载测试了＃72的附件两个版本。ISO及IMG。

新版GRLDR，还是出现内存冲突的提示。看来是原版都与新版的GRLDR有内存冲突。

回复 #73 zhs509 的帖子
这个是早就证实的事。在VM中没有问题。

作者: 幸运的草 时间: 2012-3-26 18:09
标题: 回复 #70 chenall 的帖子
怎么把这个给忘了。多谢提醒。
刚测试通过。
菜单：
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
root (hd1)
kernel /boot/imgs/memdisk
initrd /boot/imgs/konboot.img

[ 本帖最后由幸运的草于 2012-3-27 08:08 编辑 ]

作者: zjzaog 时间: 2012-3-26 22:42
标题: 回复 #75 幸运的草的帖子
请问哪个版本的memdisk最稳定？能给个下载的连接那？听说新版的不怎么好

[ 本帖最后由 zjzaog 于 2012-3-26 22:50 编辑 ]

作者: 幸运的草 时间: 2012-3-27 08:16
标题: 回复 #76 zjzaog 的帖子
我在百度找的，好像是最新版的，测试没问题。KON正常通过。

官方免费的KONBOOT是1.0版的。1.1版改成了商业软件，据说能绕过64位系统的密码。谁有条件测试一下6KB的1.1版的KON。看破解的版本能否绕过64位系统密码且不蓝屏，我这没有条件测试。
　　楼主附件的就是。

　　测试注意，如果是HDD的U盘，要保证启用硬盘为(hd0)，否则可能出问题。

[ 本帖最后由幸运的草于 2012-3-27 08:22 编辑 ]

memdisk.rar

13.15 KB, 下载次数: 50, 下载积分: 无忧币 -2

作者: adef 时间: 2012-3-27 08:29
标题: 回复 #77 幸运的草的帖子
1.1的能绕过64位win7，巴基斯坦人发的那个。

作者: zjzaog 时间: 2012-3-27 09:07
标题: 回复 #77 幸运的草的帖子
我用的一直是1.1的kon，嘿嘿
我的常用的菜单式这样写的，所以不管U盘被认为zip或者hdd都能通用，

map --mem (ud)/TOOLS/KON.lzma (fd0)
map --hook
chainloader (fd0)+1
find --set-root --ignore-floppies --ignore-cd /ntldr || find --set-root --ignore-floppies --ignore-cd /bootmgr
map () (hd0)
map --hook
rootnoverify (fd0)

谢谢你的memdisk

=============
刚刚用memdisk测试，使用0.4.5c的grldr也能顺利进入系统！没有卡死
使用的菜单如下

title [8] >>>>> KON <<<<< \n 传奇的绕过系统密码进入电脑的工具
kernel (ud)/TOOLS/memdisk
initrd (ud)/TOOLS/KON.IMG
find --set-root --ignore-floppies --ignore-cd /ntldr || find --set-root --ignore-floppies --ignore-cd /bootmgr
map () (hd0)
map (hd0) ()
map --rehook

[ 本帖最后由 zjzaog 于 2012-3-27 10:11 编辑 ]

作者: adef 时间: 2012-3-27 10:24
77楼发的memdisk是4.04的，附件是memdisk4.05和4.06-pre2。

memdisk.4.05.rar

13.15 KB, 下载次数: 41, 下载积分: 无忧币 -2

memdisk.4.06-pre2.rar

13.15 KB, 下载次数: 41, 下载积分: 无忧币 -2

作者: zjzaog 时间: 2012-3-27 10:32
标题: 回复 #80 adef 的帖子

原帖由 adef 于 2012-3-27 10:24 发表
77楼发的memdisk是4.04的，附件是memdisk4.05和4.06-pre2。

memdisk的测试结果：
4.04 通过，顺利进入系统，使用的是0.4.5c的grldr
4.05 通过，顺利进入系统，同上
4.06-pre2 通过，顺利进入系统，同上

[ 本帖最后由 zjzaog 于 2012-3-27 10:35 编辑 ]

作者: zjzaog 时间: 2012-3-27 11:10
7.14以前的grldr和memdisk似乎比现在的grldr，对于这类软件的map的兼容性(或者容错能力)更强一点，这点的发展似乎背离了grldr的初衷。——仅仅我一个菜鸟的感觉而已，
========================
但是grldr的新功能的开发的发展，比如vbe等，非常棒，加油，这个只是过渡时期的小问题，深信grub4dos的开发团队。

[ 本帖最后由 zjzaog 于 2012-3-27 13:08 编辑 ]

作者: 不点 时间: 2012-3-27 12:36
标题: 回复 #82 zjzaog 的帖子
说说我的不同看法吧。

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

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

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

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

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

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

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

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

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

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

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

作者: zjzaog 时间: 2012-3-27 12:54
标题: 回复 #83 不点的帖子
谢谢不点大师的指正，
看到时空上的帖子里开发人员确实很辛苦，令人敬佩。我深信这个问题在这样无私付出的团队里，肯定最终能被胜过！
我确实是略过了本质去看现象！所以只是从使用者的角度谈感受，因此肯定会有失偏颇。还望海涵。

如果不是从索取者的角度，而是从普通测试者的角度看我的所谓”感受“，也许会自然一些。呵呵，”7.14以前的grldr和memdisk似乎比现在的grldr，对于这类软件的map的兼容性(或者容错能力)更强一点，这点的发展似乎背离了grldr的初衷。——仅仅我一个菜鸟的感觉而已，“

我这样的说话方式如果太重了，那确实是我的错。

[ 本帖最后由 zjzaog 于 2012-3-27 12:59 编辑 ]

作者: 不点 时间: 2012-3-27 13:05
你没错。即使你不说，别人也会说。你只是谈论了一种可能的思想而已。那不是你一个人的思想，而是代表着具有相同认识的一大批人的思想。任何思想，都是正确的。

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

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

作者: zjzaog 时间: 2012-3-27 14:19
今天再一次更详细的拍图，希望有所帮助，我用的是0.4.5c的grldr，我用fb方式启动，kon.img放在ud区，我的U盘识被别为我(hd0)，主机硬盘被识别为(hd1)，因此我在没有交换hd0和hd1的情况下，运行完kon.img会回到u盘，这样有一个好处，我可以在每一个阶段都memcheck一下并拍图下来，利于分析每一个步骤中内存的变化！！请不点大师、c大、各位版主等无忧的朋友仔细看看，或许有点帮助。
注意：有两处（1和6）是U盘的启动画面的图我忘了拍，不重要，就一个图片，所有我用虚拟机里截图代替一下，其他的图都是实机上的实拍，

1、首先是启动到这个界面，在实机模式下忘了拍图，不过不重要，所以我在虚拟里截图一下代替看一看

2、（接下来的都是实机上拍的图！）然后按c进入命令行模式，先运行memcheck看看，并且read两处重要的地方

3、在手动输入
map --mem (ud)/tools/kon.img (fd0)
map --int15nolow=1
map --hook
然后再一次memcheck看看，并且read两处重要的地方！

4、然后手动输入chainloader (fd0)+1，然后再memcheck一下，

5、再接再厉，精彩的在后面，还望看官坚持下去，^o^,
再手动输入rootnoverify (fd0),然后再一个memcheck看看，

6、再手动输入boot，出现kon.img的经典换面，然后发现回到了U盘的启动界面（这个图在实机理我没有拍，跟第一张是一样的，我在补一下图，不重要，）

7、这时kon.img应该已经起作用，按c命令行，然后memcheck，关键变化！！

8、按Esc退出，然后选择第一项，菜单内容如下
title [0] >>>>> LWS <<<<< \n 搜索并加载本地电脑上的Windows系统
find --set-root --ignore-floppies --ignore-cd /ntldr
map () (hd0)
map (hd0) ()
map --rehook
find --set-root --ignore-floppies --ignore-cd /ntldr
chainloader /ntldr || chainloader /bootmgr

9、然后就死机了，请看图

当然如果我先交换了（hd0）和（hd1），就不会回到U盘启动界面而是直接从硬盘启动，但是也会死机，而且画面与9是一样的。我之所以不先交换而是让他回到U盘界面，是为了还可以memcheck一次，发现单单map --hook之后就memcheck，和boot之后memcheck是不同的，说明了kon.img起作用后，本身似乎对内存进行了修改！！但是，似乎单单map --hook前后memcheck的结果就有不同，所以……结果比较复杂。大家可以检查每两幅相邻的图里数据的变化，我觉得至少有两处，map --hook前后变化，boot前后变化

[ 本帖最后由 zjzaog 于 2012-3-27 18:03 编辑 ]

1.jpg (149.02 KB, 下载次数: 165)

1、启动的菜单下

SUC50172.JPG (162 KB, 下载次数: 179)

2、先运行memcheck看看，并且read两处重要的地方

SUC50173.JPG (191.38 KB, 下载次数: 161)

3、在手动输入……再一次memcheck看看，并且read两处重要的地方！

SUC50174.JPG (195.73 KB, 下载次数: 168)

4、然后手动输入chainloader (fd0)+1，然后再memcheck一下，

SUC50175.JPG (189.45 KB, 下载次数: 168)

5、再接再厉……,再手动输入rootnoverify (fd0),然后再memcheck看看，

1.jpg (149.02 KB, 下载次数: 171)

6、再手动输入boot，出现kon.img的经典换面，然后发现回到了U盘的启动界面（补图）

SUC50176.JPG (175.15 KB, 下载次数: 172)

7、这时kon.img应该已经起作用，按c命令行，然后memcheck，关键变化！！

SUC50178.JPG (216.15 KB, 下载次数: 176)

8、按Esc退出，然后选择第一项，菜单内容如下

SUC50177.JPG (133.34 KB, 下载次数: 160)

9、然后就死机了，请看图

作者: 幸运的草 时间: 2012-3-27 15:14
还是内存冲突。
暂时无解。
采用变通办法运行吧。！

作者: 不点 时间: 2012-3-27 19:16
拍照很辛苦。

看到没有 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 的新版本。

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

作者: zjzaog 时间: 2012-3-27 23:15
受教了，
这句话说的真好！“我的意思是说，这是一种理解，是当您以前不曾有过这种理解的时候，您可以考虑的、新增的一种理解。”

作者: adef 时间: 2012-3-27 23:47
下测试版memdisk的人居然要多一点？
memdisk 4.06-pre3，今天的。

memdisk4.06-pre3.rar

13.15 KB, 下载次数: 39, 下载积分: 无忧币 -2

作者: 幸运的草 时间: 2012-3-28 08:50
标题: 回复 #88 不点的帖子
说的不错，KON这个工具就是在G4D环境下的一个密码工具。他的使用环境就是通过G4D来引导的。最新版的是在2010.3.16日发布，这就是为何与新版G4D有冲突的原因。因为自2011.7.14以后，G4D进行变改才导致新版与之冲突。

　　因此，我们既不能把责任归咎于G4D，也不要归咎于KON，G4D没有错，他要发展就会进行变更。KON也没有错，他是根据G4D来开发的，新版G4D变更后，KON没有发布新版，老版的KON与G4D发生冲突也是不为过。

　如果谁对KON的作者比较熟悉，可以向其作者反映新版G4D的变化，相信KON的作者会进行调整。

目前的解决办法，可采取一些变通的办法。（见作者一楼）

作者: zhs509 时间: 2012-3-28 09:16
哈哈或者可以这样认为

之前的grub4dos对内存管理方面一个bug，而konboot刚好由于grub4dos的bug而钻了空子。。。

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

作者: 幸运的草 时间: 2012-3-28 10:45
标题: 回复 #92 zhs509 的帖子
　　也不能说是KON钻了G4D内存管理的“空子”，G4D是大环境，KON是小环境，KON要想通过G4D的引导而运行，不管G4D在内存管理方面有BUG也好，无BUG也好，他必须要与之兼容。这就是老版的G4D运行KON没有问题的原因。
　　而新版G4D调整后，KON没有及时跟进或者是没有来得及发布新版，就出现了与新版G4D的不兼容，这是不可避免的。发布日期就说明这这一点。

　　因此，出现这种问题，本身就是正常的。双方谁都没有错。只是时间给我们开了一个玩笑。
　　

[ 本帖最后由幸运的草于 2012-3-28 10:51 编辑 ]

作者: 不点 时间: 2012-3-28 11:37
想到另外一个问题。

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 的仿真代码发生改变，这种办法也就要受到影响了。

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

作者: jianliulin 时间: 2012-3-28 12:15
kon 也不能在burg下正常运行

作者: zjzaog 时间: 2012-3-28 12:42
标题: 回复 #95 不点的帖子
我测试一下，您说的”第一种情况下map --status 会显示不出…………“说一我试试看：
“第一种，紧接 grub4dos 的仿真代码之下，这是 kon 最有可能采用的方法。但是，如果此后又进入 grub4dos 的环境，则新的 grub4dos 环境有可能找不到前一个 grub4dos 在内存中放置的仿真程序了，因为 int13 以及 int15 可能已经被 kon 修改了，这样 grub4dos 就可能认为自己从前不曾在常规内存中安装过仿真代码。这种情况下，map --status 将显示不出先前的 grub4dos 所建立的虚拟磁盘（或虚拟光盘）。”

所以在手动输入
map --mem (ud)/tools/kon.img (fd0)
map --int15nolow=1
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
boot
在boot完kon.img后，就回到grub启动菜单哪里，然后按c进入命令行，再map --status了一下，有没有显示“先前的 grub4dos 所建立的虚拟磁盘（或虚拟光盘）”？我看不懂，只能晒图

另外顺便问一下，在我map --mem (ud)/tools/kon.img (fd0),回车之后，出现这样的警告，不知有什么影响
fat12 bpb found with 0xeb (jmp) leading the boot sector.
warning: bpb total sectors(2880) is greater than the number of sectors in the whole disk image (12). the int13 handler will disable any read/write operations across the image boundary. that means you will not be able to read/write sectors (in absolute address, i.e., lba) 12 - 2879, though they are logically inside your file system.
probed c/h/s = 80/2/18, probed total sectors = 2880

[ 本帖最后由 zjzaog 于 2012-3-28 13:25 编辑 ]

SUC50185.JPG (134.42 KB, 下载次数: 140)

作者: 幸运的草 时间: 2012-3-28 13:17
标题: 回复 #96 jianliulin 的帖子
经测试，KON可以在BURG下运行。无发现异常。

[ 本帖最后由幸运的草于 2012-3-28 15:56 编辑 ]

作者: 不点 时间: 2012-3-28 13:39
标题: 回复 #97 zjzaog 的帖子
非常好。

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 编辑 ]

作者: zjzaog 时间: 2012-3-28 19:27
标题: 回复 #90 adef 的帖子
这个版本的memdisk，把img或者iso虚拟进内存的速度快的惊人！！！竟然远远快于map --mem的速度，不知是什么原理？！
谢谢adef朋友

欢迎光临无忧启动论坛 (http://bbs.wuyou.net/)