【转】MBR 嵌入微型 grub （2010年12月19日更新，不点大师加菜单）

不点

感谢天涯海角哥们，你为此付出了很多。你的文档，弥补了软件的不足之处。你的介绍很周到、很细致。

有几个问题我想提出来共同研究、探讨。

1。前面有兄弟提问，说 Windows 重装后，MBR 上的 Wee 是否受到影响。这个问题的答案当然是“会受影响的”。这没有什么办法。Wee 也不是为着解决这个问题而来的。Wee 不可能解决这个问题。任何软件都不可能解决这个问题，除非刷到 ROM 上。Wee 的主要目的、意图，是取代原有的 grldr.mbr 安装在硬盘第一磁道上。这样，当硬盘上的 GRLDR 等查找失败时，还可以进入命令行，手动查找 GRLDR，或者手动进行一些其他的修复。大家对于 Wee 的认可程度，也不是一下子就可以提高的，肯定要经历一个过程。因此，不要夸大 Wee 的作用和能力，否则适得其反。有的人需要 Wee，而有的人不需要 Wee，因人而异。

2。Wee 在 USB 设备上不一定管用，除非你确认，你的 USB 设备能够被主板 BIOS 以 LBA（EBIOS）方式访问。这很要紧，因为 Wee 只支持 LBA（EBIOS），而完全不再调用 CHS 模式的普通 BIOS。只要 Wee 在你的 USB 设备上能够成功启动，那就表明，你的 USB 设备在你的主板上是支持 LBA（EBIOS）的。否则，就是主板不支持。因此之故，Wee 的主要意图，并非安装在 USB 设备上。在 USB 设备上，请使用全功能的 GRUB4DOS，并用 fbinst 来安装，以提高启动的成功率。

3。Wee 是一个非常小的操作系统。其实，grub4dos 也是的。在功能上，Wee 并不比 grub4dos 强。Wee 的优点就是“小”这个字。它能完全嵌入到 MBR 的 63 扇区上，这才是它的亮点。而 GRUB4DOS 则需要两级启动步骤，从 MBR 查找 GRLDR，才可以最终启动成功。

4。天涯海角兄提到在 MBR 上添加 BPB。我提出一点补充意见。BPB 是促使某些 USB 的主板识别 USB 设备的。有些主板需要 BPB。而有些主板，不喜欢 BPB，有了 BPB，它反而会失败了。另外，既然是欺骗主板的，那么 BPB 是不是就要做得很像呢？比如说，位于 0x1C 处的四字节的“hidden sectors”（隐藏扇区数）域，应该清零，才算是一个合法的软盘引导扇区。在第一扇区上的 BPB，其实就是模仿软盘。同时，位于 0x0E 处的两字节的“reserved sectors”（保留扇区数），应该指向第一分区的 FAT 表的开头，此时第一分区最好也应该是 FAT 格式的，这样更容易欺骗成功。通常，第一分区起始于扇区号 63。隐藏扇区数，加上保留扇区数，就是 FAT 表的起始扇区的号码。所以，很容易算出来。那么，位于 MBR 上的 BPB 中的隐藏扇区数，加上保留扇区数，也应该等于 FAT 表的起始扇区号才算完美。不过，有时候（隐藏扇区数和保留扇区数）两者加起来超过了 2 个字节，那就没办法了，没法写入保留扇区数中了，因为保留扇区数只有两个字节的空间。这时，你可以随便设置一个保留扇区数，不过，应该至少是 64（也就是十六进制的 0x40）。而前面已经解释过了，MBR 上的隐藏扇区数应该是 00 00 00 00，只有这样才算一个完全的欺骗。但是，欺骗得完全，不一定能提高启动的成功率。这就要靠实践来证实了。

5。天涯海角兄在 “绝对扇区启动” 中提出启动 plpbt.bin，我不知道行不行。command 的功能比 chainloader 弱。command 不能启动普通的引导扇区文件，只能启动 512 字节 ～ 1024 字节之间的引导扇区文件，而 chainloader 无此限制，可以启动几百K的引导扇区文件。所谓引导扇区文件，就是指它的第一扇区的末尾处含有 55 AA 这个“引导扇区合法标志”，这样的文件，都可看成是引导扇区文件。我不知道 plpbt.bin 是个什么格式，如果仅仅是引导扇区文件，则它不能被 command 启动，因为它太大了，超过了 1024 字节。如果它是 Linux 内核格式，则它仍然可以被 command 启动，因为 command 本身已经设计好了，支持 linux 内核格式的文件的启动。如果 plpbt.bin 不是 Linux 格式，而是 multi-boot 格式，则它不可以被 command 启动，只能被 chainloader 启动。

另外，command 还不能启动 WinMe 的 IO.SYS。所以，整体来看，Wee 的功能比 grub4dos 的功能要稍微弱一些。这是意料之中的，因为它是精简版的。

[ 本帖最后由 不点 于 2010-6-21 07:44 编辑 ]

不点

另外，关于 BPB 这个概念

其实还有偏移 03 到 0A 这 8 个字节。我觉得这也应该算是 BPB 中的，甚至连偏移 02 处的那个字节 0x90 在内，也可算是 BPB 中的。因为有些启动程序就是根据这些特征，来确定 BPB 的。

所以，复制 BPB 的时候，最好提供一些选项，来决定究竟怎么对待这些不同的字节区域。也可以让用户自己决定 BPB 的每个字节。让用户以十六进制的方式来编辑 BPB 中的每个字节。

不点

Climbing,

这完全是两回事。如何让主板承认 U 盘，v.s. 如何让主板支持 EBIOS。

如果主板不支持 EBIOS，那么我们基本上也无法让它支持 EBIOS。当然此时使用 wee 是必然要失败的。

但是，如果主板连 USB 设备都不承认，那就可能与这个 U 盘的扇区数据有关。通过更改扇区数据，或许可以适应主板的要求。在主板支持 EBIOS 的情况下，更改 BPB 数据，有可能改变成功率。

这是两个问题，不是一个问题。

你让天涯海角兄使用 fb 是对的，但是在天涯海角兄愿意尝试在 U 盘安装 wee 的情况下，他的填写 BPB 的步骤也并非完全无意义的。

在我的一台电脑上，U 盘启动时就支持 LBA（EBIOS）。这样的情况确实可以使用 wee。

不点

wee 只支持 FAT12/16/32，NTFS，EXT2/3/4，不支持 iso9660 光盘文件系统。

光盘空间很大，根本不需要考虑安装 wee。

不点

现在顾不上这事，只能先依靠第三方的工具了。只要经过充分的测试，都不会有问题的。

wee 的重头戏，还在于如何与 grub4dos 接轨，让两者共用相同的外部程序。目前这也没时间考虑。

不点

这等以后再作修饰。现在不求完美，但求能用。

目前没有命令历史功能。

这个功能并不很迫切。只有当你试图启动 Linux 的时候，才需要输入长长的命令行。

其他情况下，基本都是很短的命令行。

[ 本帖最后由 不点 于 2010-6-22 12:01 编辑 ]

不点

有迹象表明，笔记本的 USB BIOS 似乎倾向于支持 LBA。那么，在笔记本下使用 wee，估计有一定的成功机会。

wee 不打算支持内存很少的古董机。我记不太清楚，好像内存低于 60M，就要出错了，错误信息确实是 mem fail。

当初想把 wee 的 32 位代码放置在扩展内存的最高端，所以，就需要探测内存量，并且拒绝那些内存太少的机器来使用 wee。但是现在，其实放弃了将 32 位代码放置在扩展内存顶端的努力，所以，此时已经不需要限制内存量了。但是，32 M 的内存还是需要的，因为外部的程序需要从 16M 处开始运行，所以，32M 是一个必须的配置。因此，要求 60M 也不算过分。所以，也就不用改了。你的内存有多大？或者虽然内存足够大，但 BIOS 却不支持 int15／EAX=E820h 这个内存规范，那么 wee 也就无法知道内存的总量了，于是也要出错 mem fail。古董往往正是缺乏对 int15／e820 的支持的。将来我们可以取消这个测试，不再管这些内存总量的问题了，那样，兼容性会提高。

如果 BIOS 本来就不支持 LBA（EBIOS），那么，wee 在第一扇区中的出错信息 Urr! wee... 就会显示出来的。看来你的古董机竟然也能够支持 LBA。因为已经装入了后续的 61 扇区。只要能够装入后续的 61 扇区，那就表明，LBA（EBIOS）是支持的。如果不能装入后续的 61 扇区，那就会显示 Urr! wee...

LBA 的支持，对于 wee 来说是很重要的。wee 永远不会调用 CHS 的功能，所以，一个假想中的 BIOS，完全可以没有 CHS 的支持，只要支持 EBIOS 的功能，便可以正常使用 wee 这个操作系统了。wee 从第一扇区 MBR 开始，就不再调用 CHS 的功能，而完完全全调用纯粹的 EBIOS 功能。因此，wee 可以用来检验一个 BIOS 是否支持 EBIOS 的基本功能。

有的 BIOS 会不会把 U 盘的扇区破坏掉？所以才出现你所说的问题？这有待你进一步确认。很有可能，BIOS 在启动过程中，向 U 盘的开头写入了不该写入的信息。这或许是 BUG，或许是某种未公开的秘密。

不点

到显示 mem fail 的时候，就已经表明，61 扇区的 pre_stage2 核心代码已经开始执行了。前面已经解释了，这就表示，LBA 是支持的。

如果显示的是 Urr! wee... ，那么接下来就是一个 jump 到自己的无限循环，必须 ctrl＋alt＋del 才能启动。

其实，显示 mem fail 之后，也是一个 jump 到自己的无限循环，必须 ctrl＋alt＋del 才能启动。只是不知道究竟为何出现混乱的局面。怀疑 U 盘的磁道被写入了什么信息，破坏了 wee 的代码，导致混乱的发生。

当然，wee 出现 bug 的可能性也有。懂得汇编语言的朋友不妨帮助调试一下，找出问题的根源，解决它。

－－－－－－－－－－－－－－－

wee 考虑加强对 ebios 的支持，放弃对于 CHS 模式的普通 BIOS 调用的支持，是一个无奈的举动。同时也是一种努力（尽管可能是微不足道的努力），希望（从某种程度上）促成 LBA（EBIOS）的普遍采用。EBIOS 在硬盘上早已被支持了，然而对于本来就没有“磁头”“柱面”以及“磁道”的 USB 设备来说，却仍旧采用 CHS 而不支持 LBA，那确实是一件很值得怀疑的事情，显然制造商们把问题搞得太复杂了。LBA 属于线性地址，没有扭曲的三维几何地址的变化。应该来说，支持 LBA 是最容易的一件事情。LBA 是一维的线性地址结构，而 CHS 则是三维的立体地址结构。当然，LBA 最简单。

[ 本帖最后由 不点 于 2010-7-1 22:11 编辑 ]

不点

很抱歉，我最近没有时间。而关于对比扇区字节的事情，这谁都能做。你只要报告，有多少个字节被改写了，起始于何处，终止于何处。改写的规律是什么？为什么有时改写，有时又自动复原了？另外，U 盘有防写开关（写保护），是不是不起作用？或者你根本就没有试验？除了BIOS 会改写以外，会不会是病毒干的？

不点

增加的 exit 命令，本来的目的，只是方便用户从自己写的 32位可执行程序中调用 enter_cmdline 函数的。如果没有 exit 命令，则 enter_cmdline 无法返回到用户自己的32位程序中。有了 exit 命令，enter_cmdline 就可以结束了，控制将能够返回到调用者。

可是天涯海角1216 兄的exit，我还没明白有什么用。

——哦！是不是只要第一条命令是 exit，整个菜单就不会执行了？反正感觉很奇怪，一头雾水。

不点

哦，这个思路挺清晰的，容易明白了。看来还是应该设计一个简单的菜单系统，就像 DOS 的菜单那样简单即可。不追求多么花哨、多么的可定制，只要能够使用便可。不知谁有时间来做一做。