GRUB4DOS更新建议、bug反馈专帖

不点

这个报告提供的有效信息太少，无法确定问题的根源。

应该说说 memdisk 是否存在同样问题。

另外，很容易确定，相同的映像，假如只启动 DOS 之类的实模式程序，是否一样死机？

如果实模式没问题，只有保护模式有问题，那怀疑是保护模式的驱动程序本身的问题。也就是说，保护模式的驱动程序，例如显卡驱动、网卡驱动、USB 驱动，声卡驱动，等等，它们与 grub4dos 的内存盘发生冲突。换句话说，这些驱动不遵守 int15 规范。

特别注意：再多的 PE 的死机，也不能证明 grub4dos 有错。

只要有另外一个软件例如 memdisk 不出错的证据，就足以证明 grub4dos 有错。

-----------

补充：

假定 grub4dos 没错，出错的是某个软件（无论它是实模式还是保护模式的程序）不遵守 int15 内存规范，那么，grub4dos 无法应付这类情况（本来就不支持这种情况，甚至在 grub4dos 方面，也没有任何 workaround 可以作为应急措施）。grub4dos 之所以能够顺利启动很多 DOS 的 IMG，那也是因为这些 DOS 的 IMG 中的软件，全都遵守 int15 内存规范。为了验证这个说法，作为一个练习，你自己可以写一个故意不遵守 int15 规范的 DOS 程序，只要运行这个程序，grub4dos 下的仿真就一定会死机。

[ 本帖最后由 不点 于 2011-5-31 10:35 编辑 ]

不点

find 找到 (hd32)，是因为它是当前设备。但此时 (hd32) 已经 unhook，所以，不再有实际的 “介质”。

你可以试试

1. find     +1

复制代码

就是说，找一个扇区，如果成功，则表示该设备实际是存在的。如果不成功，就表示该设备不可访问。

不点

memdisk 的失败，是一个佐证。这说明，BIOS 或者驱动程序软件，不支持 int15 规范。

如果是 BIOS 不支持 int15 内存规范，则判定为故意捣乱。

如果是32位的保护模式驱动程序软件不支持 int15 内存规范，则判定为驱动程序的 bug。

--------

如果是 BIOS 的问题，性质十分严重。证明了捣乱者还没死心。所以，最好能够确定，究竟是不是 BIOS 在捣乱。

[ 本帖最后由 不点 于 2011-6-2 13:37 编辑 ]

不点

控制标准的业界软硬件厂商，他们在河流的上游。他们可以让河流断流，也可以让河流暴涨，他们有主动权。至于说软件设计者，本来就是他们的附属品，本来就不是一个重量级的，本来就不是对手。不知你以及和你有相同意见的人，是否能够意识到？

这个事情的最终结局如何，只有天知道。但目前可以肯定地说，处于上游的控制者，他们控制着一切。只要这一事实不改变（即这些厂商仍然处于上游），那么结果也不会改变。要想改变结果，必须改变前提。诸位思量一下，处于下游的软件开发人员，究竟有没有能力去改变游戏规则（或者制定游戏规则）？如果有的话，又有多大的能力？通俗地讲，就是说，能不能“翻了天”？如果能，那么何时才能“翻天”？

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

不过，目前所拥有的证据，并不能证明是 bios 不遵守 int15 规范。需要 pseudo 等人寻找一个 int15 的检测程序，测试一下 int15 的实现是否正常。如果正常，那就没问题，可以排除 BIOS 的错误。那么剩下的就是驱动程序的错误，或者是 windows 本身的错误。

如果实在找不到比较好的 int15 检测程序，那么可以用 grub4dos 的 displaymem 命令，来简单显示内存使用情况。

假定不是 int15 的错误，那么，就有理由怀疑是驱动程序的 bug，或者是一种事先设计的“后门”。驱动程序（或者 WinPE）的设计者，很可能一开始就放了“后门”，这个后门就是一个开关。只要控制硬件制造商去“触发”某个条件，就让 WinPE 死机。闭源的好处就在这里，让 hacker 们很难知道机关在哪里，无从破解。

[ 本帖最后由 不点 于 2011-6-2 17:43 编辑 ]

不点

chenall 说的情况属实。我也同意 dihuo 加入开发。其实“过去”和“现在”，都不一定正确。而改造以后，就成为“将来”了。

在我维护期间，我就根据自己的认识，推翻了不少 GNU GRUB 的东西。

我们今天看到有一个叫做 neogrub 的项目，这个项目很好，似乎一直在跟随 grub4dos 的开发进展。而据我的理解，这个项目主要是把 grub4dos 所删除的那些 GNU GRUB 的功能又添加上了。我个人认为，删除的那些东西，都是没错的。它们有问题，不删除是不行的。但这并不表明，删除就是“正确” 的，不删除就是 “错误” 的。尤其是最近我认识到 “多元真理” 这一层，这就更可以说明，世界上有不止一条路。无论走哪条路，都是一种选择。所以，neogrub 也是一种选择，也是一个方向，和 grub4dos 一样。

再者，bean 开发 BURG，也是一种选择，也是一条道路。从“不要把鸡蛋都放在同一个篮子里”这个道理，可以理解各种不同的选择，那其实是互相补充的。如果大家都来开发 grub4dos，没人开发别的，那么，万一 grub4dos 被消灭了怎么办？同样的道理，如果大家都去开发 GRUB2，万一 GRUB2 最终被整死了怎么办？所以，多一条路，是没有坏处的。

每个人都有自己的特长，不能互相替代。比如，Bean，chenall，Roy 所做的工作，我就做不了。grub4dos 的开发人员还是太少了，因此我主张 dihuo 投入开发。

不点

>>> 开放点？

开放多少？为什么要开放？支持开放的理由有哪些？不开放有什么坏处？

不点

>>> 这样find可以找到(fd2)

如果就这点好处的话，还是维持原状吧。

开放以后，将与以往不兼容。也就等于是，自己制造不兼容。虽然这个不兼容性所带来的影响可能不大，但不知道有多少人受影响。假如能够避免的话，还是应该避免。

操作系统 DOS 只承认有两个软盘。因此，实际上，BIOS 也最多只安排两个软盘。如果超出这个限制，很难说，具体的操作系统在启动时会不会出问题。

所以，即使允许 floppies=3 和 4，也应该在启动操作系统之前将 floppies 设定在 2 以内（不超过2，最大可以是2）。

我个人觉得，把 floppies 的上限设定为 4 也是可以的。不过，需要在文档中说明，用户在启动操作系统时，最好应该保证 floppies 不超过2。

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

还有一种解决办法。就是，不改变 BIOS 数据区中 floppies 的设定。但是，给 find 命令增加一个新的参数，让 find 查找的 floppies 的个数能够控制。比如说，可以让 find 找 8 个 floppies，甚至 16 个floppies（前提当然是，要保证这些 floppies 都存在，它们可以是虚拟的；否则对于某些 buggy 的 BIOS 有可能在访问不存在的磁盘时死机）。类似地，也可以让 find 查找的 harddrives 的个数能够控制。甚至还可以让 find 查找虚拟光盘 (hd32) 以及 (0xFF) 等。

以上两种方案，我觉得都是可以的，看看 chenall 的偏爱吧。

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

明确一下，floppies 和 harddrives 的值，是 BIOS 数据区中的。任何操作系统都能看见这些值，也都可能用某种方式来使用这些值。根据虚拟盘的设置情况，floppies 和 harddrives 的值应该作出相应的改动，以便让操作系统能够“看见”虚拟的磁盘。因此，floppies 和 harddrives 的值是很重要的，不应该搞错（这里主要是说，用户应该小心，不要搞错）。

不点

wee 的 root 命令很简单，只支持 root [ device ] 这样的格式。不过，和 grub4dos 一样，此处的 device 可以带有一个路径，表示设定当前目录。例如，root (hd0,0)/boot/grub 是可以的，设定 (hd0,0)/boot/grub/ 为当前目录。root (hd0,0) 其实设定当前目录为 (hd0,0)/，即(hd0,0)的根目录。

command 命令不支持 --set-path 参数。默认时，使用当前 root 设备（的当前目录）作为命令文件的路径。

举例：当你确信 root 为 (hd0,0) 时，敲入 ntldr 命令，则立即执行 (hd0,0)/ntldr 命令。

不点

exit 命令可以用来立即终止脚本运行。

exit 命令之后的命令，都不执行，就像注释掉了一样。

在将来，当一个外部命令调用内部的命令处理器进入命令行手动输入命令的时候，如果没有 exit 命令，则永远无法退回到外部命令中。有了 exit 命令，当前的命令处理就可以结束了，控制可以回到调用者。

不点

新版有问题。

ubuntu 的菜单上经常有一个 quiet 命令，这条命令应该忽略，也就是说，执行这样的命令，应该返回 errnum= 0，而不是返回一个错误。

如果返回 errnum != 0，那么无法兼容 ubuntu 的菜单了。7月8日之前是正常的，只有 7月8日的版本有此问题。

不点

刚才测试过了，已经正常。

不点

干得好，你找到毛病了。

当 sector 只有 1 个的时候，会被当作整个磁盘或者整个分区来处理。(pd) 之类的设备没有磁盘结构，所以，在试图解释为整个磁盘时，出现问题。

其实 pd 之类的设备也没有 part_start 和 part_length 这样的概念，所以，可以通过设定特殊的 part_start 让条件不成立，这就可以跳过这段程序了。或者干脆直接加上判断设备类型的条件，如果是 pd 之类的，就不再执行这段程序。

具体怎么做，你可以试试。

不点

来自 bootland 的反馈说，时空论坛上有关 lbacache 的问题已经解决。可以更新 svn 了。

不点

> 两个文件都是非压缩的IMG格式，第2个是标准的1.44M。实际上我的要求很简单，就是用wee来启动软盘镜像。

你忘了 “大” 前提，只记得上面这些 “小” 前提。

大前提：Wee 只能可靠访问硬盘，不能保证访问 USB 时的情况。注意 BIOS 对于 U盘的 LBA 支持情况。

还有一种可能性，你制作的映像，其 BPB 表中的 H、S 以及 drive number、hidden sectors 的设置不正确，导致启动失败。比如，从软盘启动，其 drive number 不是 0，而是 80h；或者 hidden sectors 不等于 0。这都可能造成 Wee 以及 memdisk 失败。

grub4dos 能够自动处理以上问题，自动替用户修补这些缺陷，所以，grub4dos 成功率高。grub4dos 能够把一个逻辑分区映射为软盘，因此，必须自动修正 BPB 参数。也就是说，grub4dos 必须有自动修复 BPB 参数的功能。

你应该检查 IMG 的 BPB 表，确保这些敏感参数设置不会有错。如果有错，那么由于 Wee 和 memdisk 都不能够自动修正，因此都会失败的。

不点

你搞错了。

ATAPI CDROM 是指经由 cdrom --init 获得的真实 cdrom。它不包括用 ISO 虚拟的 CDROM。

ATAPI 是硬件规范，不是 INTxx 这类软件接口。

不点

find 命令可以很容易改变。问题只在于：究竟是否应该改变，以及有多少人需要改变。

同时仿真 2 个 iso 的情况并不多见。

由于仿真了的 ISO，其盘号可以在一个范围变动，而且是已知的，它就是 map 命令指定的盘号，因此，不适合用 find 命令。直接指定它的设备名即可。

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

另外，关于 cdrom 的盘号，这是“规范制造者”们没有确定的事情。本来没有规范的事情，我们也不能创造一个规范。假如我们创造一个规范，且不说有没有人遵守、承认，就算有人接受了，那“创造规范”这件事本身，是否属于“添乱”，恐怕还是一个疑问，也可能会遭到指责。

我们知道，BIOS 数据区中有软盘的个数以及硬盘的个数。谁听说过有什么规范指定 CDROM 的个数吗？假如我们制造一个规范，把 BIOS 数据区中的某个字节作为 cdrom 个数的记录，那么这会不会与某个主板相冲突呢？有谁会承认呢？这都是问题。

[ 本帖最后由 不点 于 2011-9-13 12:01 编辑 ]

不点

cd_orig=0 什么意思？本来在 BIOS 数据区就不存在 cdrom 个数，而你这个 cd_orig 从哪里得到？

不点

规范的制定者没有规定 CDROM 的盘号用哪个，也没有规定有多少个 CDROM。

如果主机有两个 CDROM 驱动器，你都插上可启动的光盘盘片。此时，从光盘启动后，你预先不知道

（1）BIOS 把启动盘的盘号设置在哪个盘号上。
（2）BIOS 承认几个光盘。如果光盘格式不是 no-emulation 模式，那么有可能 BIOS 不承认所有的光盘。也就是说，有可能没有一个光盘被分配盘号。即使两个光盘都是 no-emulation 模式，也不能保证两个光盘都获得盘号，只能保证启动盘获得一个盘号。那个非启动的光盘，BIOS 可能对它视而不见，不给它分配盘号，用户也就无法访问，除非使用驱动程序。

不点

@hhh333

拿出当年获得诺贝尔奖的勇气，抓住 bug 不让跑掉。

你的报告有很多不清楚的地方。

1、 grldr.mbr 的版本？可别像前几天的报告那样，你还在用 5 年前的 memdisk（2006年的）。所用的 NTLDR 的版本呢？

2、 是不是你修改 grldr 的程序有 bug，导致它改错了地方，让 grldr.mbr 失效了？

3、 你用未加更改的 grldr.mbr 能找到 GRLDR 吗？

4、 你是在什么设备上执行这些操作的？是 USB 设备呢，还是普通硬盘？


补充说明，如果是 USB 设备，则任何事情都可能发生。当 CHS 识别错误时，一切都不用再继续了。安装 fbinst 是一个 “上上” 之选，因为只有 fbinst 能够把 100% 准确无误的 CHS 传递给 grldr。

在 USB 上，如果你的目的仅仅是利用 grldr.mbr 作为一个（中间）工具来启动 bootmgr，我个人认为，你搞错了。你应该直接用 bootmgr 作为第一启动，而不是 NTLDR。也就是说，要么你用 fbinst，要么你用 bootmgr 作为第一启动。


---------

你的 avldr 之所以在 FAT32 上失败，我怀疑，也正是因为它在 CHS 上搞错了。而 avldr 在 NTFS 上成功的情况，则也是因为在 CHS 上“弄对了”。只要 BIOS 的 CHS 是 “混乱不堪”的，没有一个软件能够正确应对（fbinst除外，只有采用与 fbinst 等价的技术，才能突破这个障碍）。无论是 avldr，还是 grldr.mbr 都不行。可以肯定地说，syslinux 等其他软件也都不行，甚至连微软的也包括在内，也都不行，它们都不能应付如此复杂的 USB 环境。大家早就用实践“证明”了，没有一个万能的启动软件。fbinst 之所以也不是万能的，是因为 BIOS “封杀”它，不让它接管控制。否则的话，fbinst 将是不折不扣的“万能启动”。

[ 本帖最后由 不点 于 2011-9-15 08:24 编辑 ]

不点

我确实不知道哪个改名工具更 “可靠”。任何软件都可能犯错误。这只有经过大量测试，才能知道。

既然你已经弄清楚原因了，也就无所谓了。开发人员的视角通常都是这样的，只要软件本身没有 bug，也就不再追究了。

不过，你说的 51 是何意思，我不明白。难道说，grldr.mbr 的文件名空间不够？在 NTFS 引导扇区上应该留足了

8（基本名）+1（小数点）+3（扩展名）+1（结尾的 00 字节） = 13

个字节的空间。

刚才看了，你说的 09eX 处，那根本不是 NTFS 的代码，而是 ext2 的代码。因此，NTFS 应该根本不受影响的。（因此你一定是又搞错了）。

NTFS 引导扇区位于 0A00 以后。存放 grldr 文件名大约在 0bd3 处附近。它后面有足够的空间，为文件名存放 13 个字节，完全没问题。

至于说前些天你提到的 wee127 的 map 问题，你也没说清楚（贴个图呀啥的）。看你无意解决问题，我也就没继续跟帖了。

wee 没有当前盘的概念，这倒是给你猜到了。wee 驻留在 MBR，当然没有当前分区的概念了。

不仅 wee 没有当前分区的概念，grldr.mbr 也没有。只有 GRLDR 才有当前分区的概念。

就 wee 和 grldr.mbr 而言，它们可以被别的软件启动，而他们并不假定别的软件能够传递正确的 DL。因此，它们没有当前盘的概念。

不点

这再次证明了，你改的是 ext2 引导扇区，根本不是 NTFS 引导扇区。再次提醒，你改的地方完全没有影响（完全不起作用），因为你的系统没有 ext2 分区，这永远不会用到的。你能确认你改这就起作用了？那可就真的有神仙相助了耶！

位于 A00 之后的，才是 NTFS 的引导扇区。

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

关于 ext2 中你提到的两个字节，以前专门讨论过。这两个字节对于启动过程不起作用，建议废除这两个字节的原有功能。grubinst 以及其他工具软件，有可能使用这两个字节。建议不要用这些工具来修改。鼓励手动修改，就是，不管这两个字节，直接覆盖。

如果改名工具仍然使用这两个字节，由于这两个字节可能已经被覆盖，因此有可能误导那些改名工具，使得它们把文件名放置在指令代码上，直接造成 grldr 启动失败。

因此建议，用手动改名，这样最安全。

[ 本帖最后由 不点 于 2011-9-15 13:45 编辑 ]

不点

这问题还敢问？

CDROM 只能识别为 CD。

至于说 drive number，那可不一定是什么，由 BIOS 决定。

不点

什么叫 >=0xA0 ????

由 BIOS 传入的 cd 号码，完全没有规范的规定！

你这个 0x9F 就小于 0xA0 了！！

要说规定，含含糊糊的有，就是在 0x80 以上。其实，假如某个垃圾主板故意设置在 0x80 以下，谁也没办法。

不点

我似乎觉得，root (cd) 更好一些。

这是因为，root (cd) 要有 mount 的动作，而这就要检查介质中是否有 ISO9660 文件系统。

因此这样是 “保险” 的（即 “可靠” 的）。

不点

@hhh333

抱歉我前面的帖子有些莽撞。是因为在潜意识中对你的要求过高，所以才那样。部分原因是由于跟你比较熟悉。

你之所以有那些疑问，正是因为你对磁盘、文件系统的结构不熟悉造成的。而这点知识应该算是必备的知识。下面我就简单说说。

最开始的时候，只有软盘。DOS 把软盘弄成 FAT 格式。软盘第一扇区就是 FAT 的引导代码。你要善用 hexedit 工具，看看软盘扇区的模样。

到后来，有了硬盘，硬盘太大，就划分成若干个 “分区”，每个分区就是一个 FAT 文件系统，DOS 把每个分区称为一个 drive。可见，它实际上把每个分区当作一个 “软盘驱动器” 来对待了。每个分区的第一扇区，就是 FAT 的引导代码。由于硬盘需要划分分区，所以硬盘需要有分区表，这个分区表就位于整个硬盘的最开头（MBR）。所以，你还应该熟悉 MBR 的模样。用 hexedit 工具查看一下吧。

再后来，有了光盘。这完全不兼容于软盘、硬盘的结构。光盘上的文件系统叫做 iso9660 文件系统。它没有 MBR，也没有 FAT 的引导扇区。

由于光盘文件系统格式与软硬盘不兼容，而实际上又需要兼容，因此出现了 “模拟软盘” 和 “模拟硬盘” 两种启动格式，再加上 “无模拟” 格式，光盘的启动格式总共也就这三种。这三种格式属于启动规范，它们不是新的光盘文件系统格式，它们只是在 ISO9660 文件系统的框架下，补充规定的、专用于启动的规范。“模拟软盘” （或 “模拟硬盘”），顾名思义，就是在光盘上划出一部分扇区，用来仿真一个软盘（或者仿真一个硬盘）。这些用于模拟的扇区，当然也有 FAT 的引导代码（或者 MBR）。除了这用于模拟的一小部分扇区以外，整个光盘仍然是 iso9660 文件系统，仍然是与旧的磁盘结构不兼容的。

grub4dos 中的光盘 (cd) 是 iso9660 的文件系统，它访问的是整个光盘的全部扇区。用 hexedit 工具查看它吧。

如果没有 hexedit 之类的工具，你也可以用 grub4dos 来查看软盘、硬盘、光盘的扇区数据。举例来说：

查看软盘：cat --hex (fd0)+20
查看硬盘：cat --hex (hd0)+20
查看光盘：cat --hex (cd)+20

[ 本帖最后由 不点 于 2011-9-20 18:18 编辑 ]

不点

configfile 启动一个新的 menu.lst， 相当于一个新的 grub4dos 启动了。启动的设备设置为 menu.lst 所在的设备。也就是说，(bd) 要随之改变。与 menu.lst 处于同一目录的 default 文件（如果存在的话），也要起作用了，它保存的是默认的菜单项的序号。

没有规矩不成方圆。这是以前形成的规范，不是说想改就能改的。

不点

太依赖 bd 是你的错。

本来 bd 就不值得依赖。

设想，当你从 dos 启动 grub 的时候，bd 是什么？当经由 syslinux 启动 grub 的时候，bd 又是什么？当经由 fbinst 启动 grub 的时候，bd 又是什么？当经由 wee 来启动 grub 的时候，bd 又是什么？

基本上说，都是不存在的，或者说，很难确定的。就算确定了，意义也不大。

grub4dos 本身被启动的多重启动方式，必然淡化某一种 “确定” 的思维方式。正如物理学中的 “不确定性” 一样。

不要把自己的思维 “固化”。

不点

错。

bd 不是 “提出来” 的，而是 “遗留” 的。

GNU GRUB 存在一个 “安装” 的问题，它只安装在一个分区，安装的时候，要填写启动的分区。这个启动分区，就是现在所称的 bd。

由于 gnu grub 采用 stage2，所以，安装 stage2 的时候，也修改 stage2 的头部，把启动分区也 “固化”。

grub4dos 已经废除了这个启动逻辑。采用的是动态启动策略。没有固定的启动分区。所以，那个 bd 的性质已经变了，作用也不重要了。只有在引导 GRLDR 的时候，才有确定的 bd。如果通盘来考虑，bd 是没有意义的。前面举例说明的情况，就是如此。

而且，bd 是可以控制的，意思是，可以改变的。用户只要通过 configfile 命令，就可以改变 bd。这本来是灵活性的一个表现，而在你看来，反而是不方便了。

如果你非要让 bd 固定，也有你自己的变通办法。你可以备份 bd（比如备份到某个内存变量），随时就可以找到 bd 在哪里。

而你要求改变 configfile 的逻辑，让 configfile 不再改变 bd，那是制造不兼容。

这下子你该明白了吧？

不点

正如 pseudo 所说，hhh333 需要的是另外一个功能（新功能），而不是改变现有的功能。

改变现有功能的结果，就是制造不兼容。这点很明显，不用多说。

有关 bd 的问题，属于历史遗留问题。

grub4dos 在最初的时候，只有 grub.exe，而没有 grldr。那时候，grub.exe 运行于 DOS 下，而由于 grub.exe 可以位于任何磁盘上，甚至可以位于 DOS 的 RAMdisk 内存盘上，所以，bd 是不存在的。grub.exe 启动以后，就把 bd 设置为固定的 (hd0,0)，这个分区有可能根本不存在。

因此，grub4dos 从开发之初的那一天起，就没有确定的 bd 。后来使用 find --set-root 确定当前目录。大家在很长一个时期主要也就是使用当前目录，不使用 bd。

bd 是很晚由 chenall 封装的。原来虽然有 bd 这个逻辑概念，但用户无法访问。chenall 把它封装以后，用户也可以访问 bd 了。

大概在 grub.exe 诞生一年以后，出现了 grldr。当从 MBR 启动 GRLDR 时，很幸运地，可以确定 bd。bd 就设定为 grldr 所在的分区。

实际上，这个 bd 是由 MBR 代码确定的。MBR 找到哪个分区的 grldr，就把哪个分区设置为 bd。

在其他启动方式的情况下（例如 grub.exe 运行于 DOS 下），仍旧没有确定的 bd。

当 configfile 命令运行时，要从头开始执行 grub4dos 的代码（代码重用，可以节约代码的编写），相当于执行一个新的 grub，进入一个新的 grub 环境。

新的 grub 运行时，它就要检查 bd 等的设置（这是 GNU GRUB 的启动逻辑，只能按照它的逻辑办事，因为我们是基于它的，否则，修改成自己的逻辑，光是哪个设计就不是很容易的，也许需要 n 多年）。所以，我们运行 configfile，就顺便把 bd 设定为 menu 文件所在的分区。想象一下，本来 bd 是不确定的，现在执行 configfile 之后，bd 变成确定的了。这对于大多数情况的使用来说，是大大方便了。大家在 menu 中无需指定 boot 和 root，直接用 /... 就可以指定与 menu 处于同一分区的文件了。这个逻辑已经被广泛使用了 n 年，有 n 多人都在用。如果要取消这个逻辑，指不定会有多少人要 “骂娘” 呢。

不点

原帖由 dihuo0 于 2011-9-28 19:38 发表
回复 #1299 chenall 的帖子
我觉得这是一个bug，如果(ud)区和可见区()都有grldr，从(ud)启动后在启动可见区()的grldr，这时应该是(bd)=()，而不是(bd)=(ud)，这不太合理，不符合人们的自觉。

我认为，启动可见区的 grldr 的时候，应该把 bd 设置为 grldr 所在的分区。这属于 fbinst 的工作。在启动 grldr 之前，应该给 grldr 传递正确的 bd 信息。

这样，grldr 启动以后，会在正确的 bd 下寻找 menu。

不过这个工作可能也是比较费事的。而且弄不好，依然存在 “兼容性” 问题（因为很可能已经有人在使用 fbinst 目前这个 “特性” 了）。