关于KonBoot加载的疑问，感谢不点大大提示，我想了个办法，求鉴定！

不点

顺序好像没有太大影响，因为所涉及到的虚拟盘没有互相覆盖的情况。

chainloader （fd0）+1 这条命令需要在某个 map --hook 之后才行，否则虚拟盘 （fd0）就不存在，无法执行 chainloader （fd0）+1 命令。

此例中，可以只用一条 map --hook，但正如刚才所说，chainloader 命令需要放在 map --hook 之后。

两种菜单的效果也有不同。第一个菜单，创建了两个虚拟硬盘 （hd0）和 （hd1），实际上是交换了两个硬盘。

第二个菜单只创建了一个虚拟硬盘 （hd0），它覆盖掉了原来的真实硬盘 （hd0）。仿真生效以后，（hd0）将代表原来的真实硬盘 （hd1），而原来的真实硬盘 （hd0）将无法访问了。


至于说哪个更好，我分辨不出来。感觉似乎都可以达到目的。

其他一些基本问题，可以搜教程，一般都会有讲解。

补充：这两个菜单都有一个共同的毛病。它们都只能适用于当 bios 把 u 盘当作硬盘 （hd0）的情形。如果 bios 把 u 盘识别为软盘 （fd0），那么，由于真实的 （hd0）是本地硬盘，它被 map （hd1） （hd0） 命令覆盖掉了。因此，仿真生效以后，konboot 将无法找到本地硬盘。konboot 所找到的 （hd0）其实是原来的 （hd1）。如果系统中不存在 （hd1），则 konboot 有可能死机。回忆一下：对于那些 buggy 的 bios，如果你尝试访问不存在的设备，它就会死机。

不点

zyphio 发表于 2015-3-7 22:40
谢谢不点大大回复得这么详细！完全明白了！但不点大大有更好的建议或办法么？

我曾经是开发者，但不是应用者，我对于 grub4dos 的应用，没有经验。尤其是到了后来，我身体不行了，因此，逐步放弃了开发，甚至也放弃了对新功能的了解和掌握。比如说，chenall 为 grub4dos 添加了变量的功能，也添加了批处理功能，这我都不曾应用过。

以下是仅仅凭借我以前所掌握的知识，使用较旧的功能，来试图满足你的要求。其实方法有很多，只要能够确定并区分出启动盘究竟是软盘还是硬盘，即可达到目的。当启动盘是软盘时，本地硬盘是 hd0，就不要动它了。当启动盘是 hd0 时，则需要把本地硬盘 hd1 仿真为虚拟硬盘 hd0。这算是一个总思路吧。刚才说了，下面只是一种具体的实现方法，其他方法也有很多种。

        map --mem /konboot.img (fd0) 这条命令把启动盘上的 /konboot.img 文件仿真为 fd0。此时，我们不管、也不知道启动盘究竟是 fd0 还是 hd0。
        map --hook 这条命令让仿真生效，因此，如果启动盘是 fd0，则真实的启动盘 fd0 将无法访问了，只有虚拟的软盘 fd0 才能被访问到。反之，如果启动盘是 hd0，则 hd0 仍可访问，它仍旧是启动盘。
        chainloader (fd0)+1 不管三七二十一，现在先加载虚拟软盘的第一扇区到 0000：7C00 处，准备启动它。
        ls /konboot.img && map (hd0) (hd1)
        ls /konboot.img && map (hd1) (hd0)
        ls /konboot.img && map --hook
ls 列出当前盘上的 /konboot.img 文件，如果能列出，则表明当前盘是 hd0, 即，它未被虚拟盘 fd0 覆盖掉。此时，执行交换 hd0 和 hd1 的命令，目的是保证本地硬盘 hd1 成为虚拟的 hd0, 让 konboot 软件能够正常操作本地硬盘, 而不是误把真实的 hd0 ( 它是 usb 启动盘 ) 当作本地硬盘。
反之，当 ls 列不出 /konboot.img 时，这表明启动盘是 fd0, 它已经被虚拟盘 fd0 覆盖掉了，所以找不到原来的 fd0 上的 /konboot.img 文件了。此时，本地硬盘是 hd0, 无需执行、也不应该再执行多余的交换硬盘的步骤。
        rootnoverify (fd0) 这条命令是为 boot 命令服务的。boot 命令会把当前 root 盘的盘号赋值给 DL 寄存器，并把控制权交给位于 0000：7C00 的启动代码。
        boot 既然一切准备就绪，现在可以启动了。

不点

zyphio 发表于 2015-3-8 11:36
不管不点大大您还有没有在开发，您曾经的贡献和创造，以及无私的互联网分享精神，我们都不会忘记，你对 ...

我前一个帖子所写的，就是一个完整的菜单内容。你又加上 find 命令，那就变味了。

不过，我的菜单也有局限性。我没考虑usb 为 ud 启动的情况。

假如你是从 ud 启动，你需要写个专门针对 ud 的菜单。

你可以参考 0pe 里面的菜单。或者向经常使用 ud 的人请教。

不点

最难对付的是 ud 启动。你只要能搞定 ud 启动，其他都容易了。

ud 启动时，当前 root 是 （ud）。假如你 find --set-root 得到的是 （ud），那是不是你的程序代码就一定要交换硬盘？因为你现在还不知道 ud 盘的宿主盘（或者叫做母盘）是不是 hd0。如果是的，你应该交换，如果不是，则不应该交换。

不点

看不太懂你说的话。

假如你从 USB 启动了 ud，此时，又假定主板已经把 USB 当成了 fd0，那么，你交换 (hd0) 和 (hd1) 只会让 konboot 错把 （hd1） 当成 hd0，甚至会在去读 hd1 时发生死机。

不点

但假如你 find --set-root 的结果是 (ud)，这就回到前面的话题了，那么，你又该如何？

ud 所在的宿主盘有可能是 fd0，也有可能是 hd0。

很简单，你可以试验一下，试试从 ud 启动后，%@root% 的值究竟是什么？

如果 %@root% 的值是 (ud)，那么你的菜单根本就没解决问题。

如果 %@root% 的值是 (fd0) 或 (hd0) 或 (fd0,X) 或 (hd0,X) 之类的，那么你的菜单或许还能有点用。

不点

请 chenall、yaya 留意这个问题。

当 grldr 或 grub.exe 接管控制时，在 asm.S 的最开头，我设置了一个 WORD 变量，用来存放此刻的 DX 寄存器值。其目的是，在用户的系统出问题时，这个域的值可以帮助开发者确定问题的根源。DX 寄存器保存的位置是内存地址 0x8206，覆盖掉 GNU GRUB 原来的（2字节的） stage2 version 域。这个 stage2 version 域本身还是有用的，它好像在某种情况下被 grub4dos 用来作为合法 grub.exe 格式或合法 grldr 格式的判断标准。但是，那只是静态的判断，也就是说，只是用于判断 grldr 和 grub.exe 的文件格式，而在 grldr 或 grub.exe 接管控制以后，那个位于内存 0x8206 的 stage2 version 域，已经完全不起作用了。所以，我就把它用作 DX 的备份空间。

在 ud 启动的情形，应该把 ud 的宿主盘的盘号放在位于 0x8206 的字节当中（也就是相应于 DL 的位置；也可以同时把 0x8207 处的字节修改为 0xFF，即相应于 DH 的位置，代表分区号），这个工作我没有做。chenall、yaya 可以考虑把这个弄一下。如果照这样弄好了，那么可以公开这个字节的意义，即，位于 0x8206 的一个字节的值，代表着由 BIOS 或者由 boot sector 传来的真实盘号。（然而在 grub.exe 启动的情形，这个 DX 值是没有什么意义的，所以，这也是个毛病。）

由于当前 root 盘和 boot_drive 都已经被初始化为同一个值，所以，在 ud 启动的情形，用户无法直接得到 BIOS 所传递的盘号，只能通过 fb_status 变量间接得到，这不利于让用户的菜单编程简单化。所以，这个问题需要权衡。

初步考虑，有以下几个办法：

1、正如刚才所说，可以把 ud 的宿主盘盘号记录在 0x8206 的字节上。它的毛病是，此字节并非总是代表 BIOS 的启动盘盘号。

2、创建一个新的变量，用来保存经由 fb_status 修正后的 boot_drive 值。

3、干脆就根据 fb_status 直接修改 boot_drive 的值，让 ud 启动后的当前 root 为 (ud)，而 boot_drive 和 install_partition 变量的值分别修正为真实的  BIOS 启动盘盘号和 0xFFFFFF（即分区号为 0xFF，代表着从 MBR 开始的整个盘）。如果最终确定真的要这么修改的话，可以在 init_bios_info() 函数中进行修改。假如我们暂时不考虑经由 DOS 或 Linux 来 “第二启动” grub.exe 的情况，那么，这个 boot_drive 的值就差不多可以说是完全准确的了，它完全反映了 BIOS 所传递的真实启动盘盘号（它有可能是 pd，也有可能是 cd，也有可能是 fd0 以及 hd0，其实大致也只有这几种情况）。那么用户也就可以方便地用它来确定 BIOS 是否把 USB 当作硬盘 hd0 了。

目前我倾向于采用上述第三种方案。由于 ud 本身的特殊性，我觉得这个方案是比较合理的。但这会不会带来某些兼容性问题？它会带来多大的好处和坏处？都需要你们来评估。请 chenall 你们来权衡和决定。

不点

chiannet 发表于 2015-3-9 20:29
捣鼓成这样可否？

貌似不错。至于说可靠与否，由熟悉的人来鉴定。

但这个写法，仍然太复杂，技术性太强。需要有个简单的处理方案，也就是说，有必要讨论 grub4dos 的改进方案。

既然说到了改进，那就顺便说说我的另外一个改进建议。

那就是稍稍改进一下 boot 命令，让它带一个设备参数，目的就是为引导扇区传递 DL 寄存器的值。用法大致如下：

boot [ device ]

例如：boot (hd0) 相当于执行 rootnoverify (hd0) 和 boot 两条命令。这样大家就可以简化某些菜单程序了。

不点

zyphio 发表于 2015-3-11 15:05
发现之前一直在绕弯路，总把问题复杂化：

本意——

你好像掉进漩涡了——开个玩笑。

82b9 处是 fb_status 的一个字节。假如不是从 ud 启动，这里的字节都是 00，无意义。

因此，假如不是从 ud 启动，你就不该访问这里的字节。

不点

如果不是 ud 启动，那当然比较容易做了。此处我就不想再重复说了。

关键就是 ud 启动时，用户不能方便地获得原始的 bios 启动盘盘号（00h 或 80h），所以，才有这样一些问题的出现。虽然说用一条菜单语句可以完成这个检测，但是，这个方法不容易被初次接触的人理解和掌握。所以，我觉得这有改进的余地。改进的目的是让 grub4dos 的用户更容易理解和掌握。

对于开发者来说，可以仔细研究这个问题能否改进以及如何改进。

对于用户来讲，假如开发者由于某种原因（或者某种权衡）没能采取任何改进措施，那么用户应该学习有关 ud 的一些知识，理解那些变量的意义，写好自己的菜单。

另外，有些用户其实是可以避免使用 ud 的。zyphio 曾经谈到，他自己使用 ud，只在 ud 区放置一个 grldr 文件，其他文件都在可见区。一句话，zyphio 不需要 ud 的隐藏功能。既然如此，我觉得 zyphio 可以用我去年开发的 multimbr 来代替 ud，这样就不会出现上述所讨论的那些与 ud 有关的问题了。

不点

zyphio 发表于 2015-3-11 18:56
谢谢不点大大，我确实太小白了，菜鸟一个，纯纠结啊。。哈。。。

我觉得启动盘首要因素是兼容性，其次 ...

http://bbs.wuyou.net/forum.php?mod=viewthread&tid=320244