MBR 嵌入微型 grub，有问题一起讨论
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=6#pid43989
对 grldr 的裁剪已经进行了一段时间了，目前大小已经在 22K 了。还有若干个 C 函数没有改写成汇编，所以还有一些工作要做。可以从 nufans 下载 grldrtmp 文件，用grub4dos的chainloader --force 来测试启动它。
目前裁剪的目的是探索最必要的基础函数有哪些？把可有可无的都删除。以下是相关问题的考虑和处理。
1。把命令行的编辑删除了，命令的历史也取消了，确切地说，get_cmdline 是用汇编重新编写了。
2。把图形模式去掉了，现在只有标准的 80x25 字符模式，而且颜色控制的代码都不存在了。
3。有关时钟的函数都删去了，我们不再能够控制时间。
4。把 CHS 模式相关的代码都删去了，只留下 LBA 访问方式。
5。把确定内存大小的代码都去掉了，现在我们不知道总内存量。
6。把有关菜单处理的代码全都去掉了，现在只能进入命令行（像DOS的情况）。
7。CDROM的相关代码也全都去掉了，因为从MBR启动的时候，不能访问CDROM。
8。PXE的情况类似，从MBR启动的时候，PXE是用不上的，因此去掉了。
9。类似地，fb 的代码也去掉了，因为此时没有 fb。由于 USB BIOS通常很 buggy，所以本来就不抱希望访问 USB。根据前面的描述，凡是不支持 LBA 的设备都无法访问了。软盘和 USB 设备如果支持 LBA，仍旧可被访问。否则，都将无法访问了。
10。去掉了访问 4G 以上内存空间的代码，我们只能利用 4G 以内的空间。
11。去掉了所有其他的命令，只留下一个 command 命令用来测试文件系统访问的可靠性（实际上也就是为了测试文件名的自动补全功能），同时验证外部命令 echo 可以正常打印一个字符串。
12。文件系统驱动程序只保留了最简单的 FAT，用来作概念测试。而其他的，例如 NTFS， EXT2， ISO9660 等，都删除了。
13。gzip 的代码当然也去掉了，因为它太大了。
14。加强了磁盘读写函数，假定LBA 可以访问64位的扇区号码，于是，访问2T以上的磁盘空间是可能的了。
15。保留了文件名的自动补全功能，因为这个实际上相当于 dir 或 ls 命令，而没有它是万万不可以的。
16。磁盘缓冲的代码保留了，因为发现缓冲的代码消耗很少，而且去掉缓冲并不能带来明显的好处。
以上是阶段性的研究报告。
更新：去掉了 next_partition 函数，增加了 list_partitions 函数。
next_partition 函数频繁地访问分区表和各级扩展分区表，是一个设计上的缺陷。
list_partitions 函数把当前盘的各级分区表信息放在内存缓冲区中，后续的分区枚举就不再访问硬盘了。
更改之后，分区访问的逻辑更加简明、清晰，容易看懂了，同时还节约了 200 多个字节的代码（一个惊喜）。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=7#pid44115
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=2&fromuid=12697#pid43701
原帖由 不点 于 2010-1-17 22:49 发表
天涯海角所说的 Pauly 是不是已经实现了我们所要的一切呢？如果是的，那么我们当然就没必要再做重复工作了。
呵呵，我的 XORLDR 远不及你们讨论的微型 grub，没有任何 map 功能，你们继续讨论
根据我的设计，对 FAT 和 NTFS 分区的只读代码用汇编来实现不会占据太大的空间，我现在所有的程序代码加起来才占用 10 个扇区（当然功能也有限）。我觉得占据前 32 个扇区是比较理想的状态，如果能容纳下的话，这样可以在 USB-ZIP 磁盘上也可以使用
对 Pauly 的这段话，我想说点意见。
U盘如果不存在 CHS 问题的话，那么用任何一个软件，都是一样的。你选择 syslinux，grub legacy，grub4dos，fbinst，等等，全都能成功。那是属于没有 bug 的主板。特别是，你用 grub4dos 作为 MBR，一样能成功，也就无需现在的【63 扇区微小启动软件】的讨论了。一个推论就是，无需制作 32 扇区的版本。
但从最糟糕的情况来看，32 扇区和 63 扇区的微小启动软件都不会有太大的意义。从 bean 对 fbinst 的研究过程可以发现，BIOS 是很难对付的，其糟糕的情况，即便用 bean 的最强的手段，尚不能保证 100% 的成功。bean 动用了很多扇区来应付 BIOS 的混乱情况。
就是说，如果你的 U 盘想用来启动别人的机器，包括那些很难启动的机器，你大致上必须安装 bean 的 fbinst 软件。其他一些手段的强度都弱太多，根本无法与 bean 的技术相比。改造 U 盘是容易的，因为 U 盘是你自己的，你想怎么格式化都方便。因此，你把 U 盘格式化为 fbinst，并无困难。
但硬盘就不同了，你要去修理的硬盘可能是别人的，人家可能不让你安装 fbinst。同时，硬盘上也没必要安装 fbinst。硬盘上磁道长度很规范，都是 63 扇区，并且肯定支持 LBA，无需处理糟糕的 CHS 问题。这早已形成事实工业标准。因此，63 扇区的【微小启动软件】在硬盘上是可能的，也是有意义的。
而 U 盘就不同了。主要的麻烦在于 CHS 的混乱。你制作好了一个32或者63扇区的【微小启动软件】，放在 U 盘，却很容易碰到无法启动的情况。为什么？因为没有动用与 fbinst 相当的强劲兼容技术。而动用 fbinst 技术，就等于开辟更多的扇区，专门用于这样的技术。一旦动用了 fbinst 技术，你已经很容易地获得全功能的 grub4dos 支持（或者与此等价的其他技术的支持）了，也就不需要功能较弱的其他【微小启动软件】了。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=8&fromuid=12697#pid45312
不点发表于 2010-6-14 21:58
今天又有了关键的改进。
去掉了 cat 和 map 命令。体积缩减到一个磁道（63扇区）以内了。
这个 grldr 的头部不再是 16 扇区，而是 2 个扇区。只有这样，体积才可能减小到 63 扇区以内。
现在说说这个新的 GRLDR 精简版的结构：
1。第一扇区是为了放置在 MBR 上的。你只需要将开头的 440 个字节复制到 MBR 就可以了。分区表当然不能被破坏，这和以前的做法是一样的。
2。第二扇区仍然是为了备份先前的 MBR，这个也与以前一样，不多说了。
从第三扇区，一直到文件结尾，就是放置在 MBR 上的相应扇区上的。也就是说，MBR 为第一扇区，紧接着是第二扇区（放置先前的 MBR 的备份），再接着，就是第三扇区，放置的当然应该是 GRLDR 的第三扇区以后的全部扇区（总共放置的扇区数不超过 63 个，因为 GRLDR 的长度就在 63 扇区以内）。
大家先在虚拟机下测试，以免有什么 bug 把你的硬盘破坏掉，那我可不负责。
然后，再说说 grldr 文件结尾处的 echo weeeee 命令。这仅仅是一条测试用的命令。你在这里放置任何命令都可以的。grldr 启动之后，首先就要执行这里的命令序列。是的，很多命令都可以放在这里，不同的命令之间，用回车或者换行分隔都可以。
如果你放置的是如下两条命令：
复制内容到剪贴板
代码:
find --set-root /grldr
/grldr
那么启动时会自动寻找 grldr，如果找到，就启动 grldr。当然这个 grldr 就是常规的、非精简版的 grldr 了。而精简版的 grldr 是不能用这种方法来启动的。
你甚至还可以这样：
代码:
find --set-root /grub.exe
/grub.exe
find --set-root /grldr
/grldr
find --set-root /ntldr
/ntldr
find --set-root /bootmgr
/bootmgr
这就先尝试启动 grub.exe，然后再尝试启动 grldr，ntldr，bootmgr。
如果都找不到，当然是进入命令行了，此时，你还有手动查找的机会，而不是死翘翘了。
需要说明，精简版不支持 title 等命令，也不支持 && 和 || 逻辑符号。其实只支持 root, find, command 这三条内部命令。其他的都是外部命令。例如，grldr，grub.exe，ntldr，bootmgr，vmlinuz，io.sys，kernel.sys，echo 等，统统都是外部命令。
提醒一下：不要安装在 U 盘的 MBR 上。有很多主板对于 U 盘不使用 LBA 模式。而我们这个精简版的 GRLDR 只支持 LBA 模式，而完全不支持 CHS 模式。所以，放在 U 盘就不行了。当然，如果你知道你的主板 BIOS 在你的 U 盘上确实提供了 LBA 支持，那倒是可以试一试的。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=9#pid45314
功能就如上面所说，很难再有增加。除非将来把更多的 C 代码转成汇编，节约空间，然后才可以增加命令。
但是 map 命令很大，应该把它写成外部命令，否则，即使能够挤在 63 扇区以内，也给空间造成太大压力。
文件系统支持 FAT、NTFS，EXT2／3／4，很完美。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=9#pid45316
不支持 (ud)
当 CHS 都不再被支持的时候，支持 （ud） 就没有意义了。
对于一个支持 LBA 的设备来说，根本就不需要用 (ud) 来增加引导的成功率。
精简版的主要目的，就是应用于硬盘的 MBR，使得查找 grldr 失败时，能够进入命令行，而不是 Ctrl＋Alt＋Del。
命令行之下能够运行外部命令，使得精简版就像一个微型的操作系统。这是这个精简版的另外一个特色。
如此小的操作系统，目前还不多见。
新鲜出炉，绝对值得尝试一下。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=9#pid45319
一个附带的特性，这次把 grldr 放在任意深的目录下是可能的了：
复制内容到剪贴板代码:
find --set-root /boot/grub/grldr
/boot/grub/grldr
得益于 find 的查找功能。好多人以前希望 grldr 不放在根目录，那时候是不可能做到的。现在可以了。而且也支持 ext4 分区的 grldr 文件（当然任何别的文件也一样）的查找了。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=9&fromuid=12697#pid45323
支持几个扇区的菜单？
有多少菜单都可以的，只要使得整个 grldr 的长度严格控制在 63 扇区以内。菜单文件的结尾之后应该多添加一个 00 字节。00 表示菜单文件结束。这里其实不能再叫做菜单了，因为这无非是一些命令的简单堆积，就像 DOS 的批处理，甚至连 DOS 的批处理都不如，因为 DOS 的批处理还有 FOR 和 IF 命令，而我们是没有的。非常简单，这些内置的菜单命令就完全相当于是你在键盘上一条接着一条敲入的。当执行完所有这些菜单命令之后，仍然要等待你在键盘上敲入其它命令。以后可以不再叫做内置菜单了，而叫做内置脚本，或者内置批处理，或许这样更好一点。建议不要让这个内置菜单占用太多的空间，因为将来 grldr 的主体也可能变大，这样，菜单就只能变小了。这是因为两者合在一起，也只能有 63 扇区。
现在再进一步说说新的 GRLDR 的结构。
GRLDR＝头部 header（两个扇区）＋pre_stage2（最多61扇区）
pre_stage2 的结构与以前大致是一样的。注意，pre_stage2 本身的开头，也有一些变量。其中有一个变量是指示尾部的菜单的位置的。pre_stage2 起始于 grldr 的偏移 0x400 处。它的开头是这样的：
00000400 EA 70 82 00 00 00 03 02 FF FF FF 00 00 00 00 00 .p..............
00000410 00 00 30 2E 39 37 00 2F 6D 65 6E 75 2E 6C 73 74 ..0.97./menu.lst
00000420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000460 00 00 00 00 00 00 00 00 00 00 00 00 40 F6 00 00 ............@...
00000470 E9 CD 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
其中，位于偏移 0x46C 的蓝色部分（四个字节），表示尾部的 bootlace 指示符的位置。以下的偏移 0x7840 处，就是 bootlace 指示符（四个字节）。在 bootlace 指示符之后，有 12 个字节的空白，再接着就是菜单命令的开始了。整个菜单完成了之后，又有一个 00 字节。为什么 F640 却指向 7840 呢？是这样的：
0xF640 - 0x7E00 ＝0x7840
这里为什么使用 0x7E00？是因为此时我们心中假定 GRLDR 被放置在 7E00 之处，pre_stage2 才正好起始于 0x8200（0x7E00再加上两个扇区，就等于0x8200）。pre_stage2 必须位于 0x8200 才能正常运行。不管别的，你只要记住，对于新版的 grldr 来说，上述的减法中的减数应该是 0x7E00 就可以了。而得到的 0x7840 再加上 0x10（也就是 16），就等于 0x7850 了。这个偏移地址 0x7850 就是菜单的起始地址了。
00007840 B0 02 1A CE 00 00 00 00 00 00 00 00 00 00 00 00 ................
00007850 65 63 68 6F 20 77 65 65 65 65 65 65 65 65 65 65 echo weeeeeeeeee
00007860 65 65 65 65 65 3A 29 0A 0A 00 eeeee...
引用:
可以优先启动某菜单吗？
刚才已经解释过了，没有优先的菜单，全都是命令的堆积。先执行的命令，当然是优先的。后执行的命令，当然就是不优先的了。
引用:
可否
find --set-root /boot/IBM.ICO
chainloader +1
启动某分区？
当然可以。请翻阅以前的帖子，command 能够加载什么文件。不过需要指出，在精简版中，我们不再有 chainloader 命令了。取而代之的是用 command 本身的功能。所以，你这个命令序列应该改成这样
复制内容到剪贴板
代码:
find --set-root /boot/IBM.ICO
command +1
或者
复制内容到剪贴板
代码:
find --set-root /boot/IBM.ICO
command ()+1
或者
复制内容到剪贴板
代码:
find --set-root /boot/IBM.ICO
+1
或者
复制内容到剪贴板
代码:
find --set-root /boot/IBM.ICO
()+1
解释一下，此处的 +1 表示一个单扇区的文件，它以 55 AA 结尾，就被认为是精简版 grldr 的一个合法的可执行文件。所以，所有的单扇区引导扇区文件，都是可执行文件。其他的可执行文件还有 NTLDR，IO.SYS 等等。
引用:
有一事请求：我将这个GRLDR发布到无忧论坛可以吗，让更多的人了解和使用，也便于您改进，谢谢！
这当然可以。贴在任何地方都可以。谢谢你介绍给其他人。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=9&fromuid=12697#pid45327
请问从mbr哪里可以判断硬盘已经安装了精简版的grub？
【不点的回复】目前还没仔细研究这个问题。但是，好像也有办法。从第三扇区入手，就差不多可以确定了。前面已经解释过了，在第三扇区中，偏移 6C 处有一个四字节的指针，它指向一个 bootlace 的 signature（也就是十六进制的字符串 b0 02 1a ce，这个四字节的标签在 pre_stage2 的尾部附近，正好位于内置菜单开始之前的 16 字节处。）根据这个，就可以确定精简版的 grldr 是否已经安装在 MBR 磁道上。
但是，也存在另外一个问题。万一有的安装程序把第一扇区改写了，而保持其余不变，则上述测试仍然认为精简版的 grldr 被安装了。显然是不行的。所以，你可能还得确定，精简版的第一扇区确实是被安装了，不曾被破坏掉。目前我还没有想好，究竟应该用什么特征能够可靠地确定第一扇区是我们的精简版的。
【再次回复】在接下来的新版本中，第一扇区将具有如下特征。
复制内容到剪贴板
代码:
/* begin characteristics distinguish this sector from others */
.byte 0x8E, 0xDB //movw %bx, %ds
.byte 0x68, 0xE0, 0x07 //pushw $0x07E0
.byte 0x07 //popw %es /* ES=0x07E0 */
//cmpl $0xCE1A02B0, (grldr_signature - _start1 + 4 + STAGE2_SIZE - 4)
.byte 0x66, 0x81, 0x3E //cmpl
.byte 0x40, 0x78 //(grldr_signature - _start1 + STAGE2_SIZE)
//this word is a pointer to the bootlace
//signature near the end of pre_stage2
//this word varies according to STAGE2_SIZE.
.byte 0xB0, 0x02, 0x1A, 0xCE //this is the bootlace signature.
//it should also appear at near the end
//of pre_stage2
/* end characteristics distinguish this sector from others */
你可以搜索到这个结构。具有这个结构的，就是精简版的 MBR 了。这个结构中有两个字节是可变的，即 0x40, 0x78 这两个字节所代表的指针 0x7840。这个指针指向尾部的 bootlace 标签。所以，对于不同的版本，这个指针是不一样的。在这 15 个字节的结构中，只有这两个字节是可变的，其它的 13 个字节都是固定不变的。
随着不同的版本，这个结构可能会平移的，所以，你应该搜索这个结构，而不是假定这个结构一定起始于某个固定的偏移地址。
这就解决了“如何确定第一扇区已经被安装了”的问题。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=10&fromuid=12697#pid45338
关于刷入主板扩展卡，再补充一些技术说明。grldr 的前两个扇区，仅仅是头部，不是主体。第三扇区以后，才是 pre_stage2 主体。所以，当刷入主板或者扩展卡时，你甚至不需要前两个扇区。你需要自己写一些头部的代码，来用于扩展卡的加载。只需要把第三扇区以后的代码加载在 0000:8200 就可以移交控制权了。此时，pre_stage2 的代码不一定要限制在 61 扇区，它甚至可以接近 64K（因为 64K 是 ROM 扩展卡程序的上限）。因此，你可以编译一个功能更加完善的 grldr 版本（放在 ROM 中）。不过，需要特别注意的是，这个 grldr 完全不支持 CHS 模式，它永远不会调用 CHS 模式的代码（例如int13/AH=02h常规 CHS 读盘调用）。取而代之的是，调用 EBIOS（int13/AH=42h）。所以，如果你的BIOS本来就不能用 EBIOS 来访问某个磁盘，那么，这个 GRLDR （以及相应的 pre_stage2）就不能访问这个磁盘。
感谢不点大的详细回复。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=10&fromuid=12697#pid45342
请问，mini grldr.s的第二扇区有代码，如果用原先的mbr覆盖，不是不能启动了吗？
【不点的回复】你是谁？怎么不留名字？你也够细心的。谢谢。
第二扇区的代码是为了用于不安装到 MBR 的时候的。当安装到 MBR 时，第二扇区就用不到了。因此它可以被覆盖。
当 grldr 不安装在 MBR 的时候，它作为一个独立的引导文件，仍然可以被某个引导器加载执行。比如可以被 grub4dos 的 chainloader 加载执行，也可以被 VISTA 的 bootmgr 加载执行。（此时，第二扇区的代码就有用了）。
进一步解释。bootmgr 最大可以加载 64K 的文件。所以，bootmgr 可以加载 63 扇区的 grldr（在理论上，这是没问题的。实际上行不行，要靠大家的测试）。
但是，ntldr 的 boot.ini，大家以前就知道，它只能加载 8K 的文件，多余的部分被截掉了。所以，这个 grldr 不可以 被 ntldr 加载（加载之后不能正常启动）。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=10&fromuid=12697#pid45345
mini grldr以后会有对应的mini grub.exe吗（io.sys加载）？
现在就等几个常用的外部命令了，如：map、write、dd、chainloader...
【不点的回复】
这个精简版目的就是放在 MBR 上。在 DOS 命令行下没有意义。DOS 命令行下可以启动很大的文件，没有 63 扇区的限制。所以，DOS 命令行下应该使用完整版的 grub.exe。
等基本功能都稳定了，再考虑编写外部命令。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=10#pid45400
我其实已经准备了一个名称，就叫做 wee。因为新的 grldr 结构不同于完整版的 grldr 的结构，所以，有必要更改一下名字。
将来 wee 可能有 63 扇区的版本以及 64K 的版本。也分放在 MBR 上还是给 ROM 用。
放在 MBR 上的就叫 wee63.mbr 和 wee128.mbr
放在 ROM 中的就叫 wee63.rom 和 wee128.rom
我在考虑，是不是把提示符也改成 wee>
wee 翻译一下是“极小”，故名“小不点”，哈哈。
觉得精简版意义重大，万能启动。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=11#pid45404
wee：很少的，微小的，极小的，很早的。
有很多词汇都曾经被用于小的操作系统，比如 mini，tiny，nano，micro 等等，这类常用词都被用光了。
所以就找到这个无人问津的 wee 了。如果将来真的成为了一个操作系统，中文名字可以叫做“微”，与英文语音相近，词义也相近。
起初找这个 wee 不是想把它当作一个操作系统的名字，而是想把它当作一个后缀（wee是三个字母，作为后缀很合适，也很难得；其他的同义词都要超过三个字母）：grldr.wee 以区别于 grldr.mbr。但是，后来，grldr 的开头 16 扇区不能存在了，精简为 2 扇区了，这样，就不能再用 grldr 作为主要名字了。所以，我就想，干脆就把主要名字叫做 wee 得了。
目前的第一扇区中启动失败时的提示字符串就是 “Urr! wee...”。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=11#pid45408
grldr.wee 不好，因为将来不利于区分 63 扇区和 128 扇区的版本。也不容易区分 ROM 版和 MBR 版。
grldrwee 也存在一样的问题：
grldrwee63.mbr、grldrwee63.rom 显然超过了 8.3 文件名的要求，不美观。
这个 wee，如果看成是一个独立的操作系统的话，它是从 grub4dos 发展而来的，或者说，是基于 grub4dos 的。一个东西基于另一个，新的不一定非得在名称上与旧的有牵连。ubuntu 基于 debian，但在名称上从未体现出 debian 字样。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=11&fromuid=12697#pid45412
不点发表于 2010-6-20 04:05
上载了新版本到 http://nufans.net/grub4dos/wee/ 底下。
请注意测试，看看已经报告的问题，是否都解决了。也看看会不会出现新的问题。
本次改动，增加了调试手段。启动之前，快速按 c 键可以跳过内置命令脚本。按 Insert 键则逐一询问内置脚本中的每条命令是否执行。
补充说明：内置脚本中不可以用 Tab 来代替空格。在内置的脚本中，请不要使用 Tab 的 ASCII 码。
Tab 有自动补全的功能，所以，内置脚本中的 Tab 也会尝试进行自动补全。通常这不是你想要达到的效果。所以，通常不要在内置脚本中使用 Tab，以及其他容易引起混乱的字符（如退格键的 ASCII 码）。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=11#pid45456
加菜单有其好处和坏处。坏处是占用了代码空间。
wee 的最初目的，或者说，目前的主要目的，都是仅仅替代 grldr 的 18 扇区 MBR 代码。如果能够达到此目的，就算成功。
18 扇区的 MBR 代码，并未菜单功能。它仅仅只能查找 grldr 而已。而且，查找的过程也没太多的显示信息，仅仅
try (hd0,0)
try (hd0,1)
.........
而已。
所以，本来就没有支持菜单的功能。所以，这不能看成是我们把菜单功能去掉了。
菜单众口难调，有人喜欢这样，有人喜欢那样，简直没辙。甚至有人对于菜单的位置、大小、显示的项目个数，是否分左右栏显示，以及是否支持中文，都有要求。这些要求，不可能在一个很小的空间中实现。
菜单就像 map 那样，是个很大的命令。它应该用外置的方式来实现。
这个小型的操作系统，它的主要用户，应该是对功能更有要求的，而不是对界面。当失败进入命令行的时候，他最需要的是执行某个必要的功能，而不是看到一个美丽的界面，而缺乏所需要的功能。由于本来主要就是针对失败后进入命令行的这一特殊情况的，所以，本来就只针对熟悉命令行的（高级）用户，而不是针对普通桌面用户。只要搞清对象，开发就有目的，就不会被一些假象所迷惑。比较一下：微软的 DOS 在 CONFIG.SYS 中支持菜单，但是，DOS 的体积大到 200 多K，即使经过 Wengier 精减，也有 100 多K。我们这个才只有 31.5K，连三分之一都没有。（补充一句：DOS的菜单功能，本人连一次都不曾用过，本人根本不会编写 config.sys 中的菜单项目。我相信，网络上像我这样的用户，应该也有不少吧。因此，DOS的菜单，对于这类的用户来说，都是浪费了。）
结论：不照顾那些只能依赖菜单界面的用户。至少，目前在刚开始的时候不考虑这些。除非将来确实发现空间有多余的空闲，才会考虑这一点。不要与其他软件比界面。不可能做好的，就暂时放弃。而能够做好的那些方面，就尽力把它做到完美。所以，软件开发首先要确定目标用户群。针对不同的目标，开发的方向就不同。同理，如果面面俱到，可能每个方面都难以达到理想的结果。软件开发有目标，有选择。用户也有目标，也有选择。这就是双向选择。大家都能找到自己所需要的软件。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=12#pid46823
这个wee不晓得能否以文件方式加载，我很喜欢这个微型的grub。
放在ud分区内安全。安到mbr不能与ud共存，毕竟fbinst的启动兼容性要好点。
当然可以啊。比如 chainloader 就可以加载 wee63.mbr ，如果出错，试试 --force 参数。
不过，这样加载没有太大的意义，因为 wee 只支持 LBA，而很多 USB BIOS 不支持 LBA，对于那些不支持 LBA 的 BIOS 来说，wee 是无法访问那些 USB 设备的。这个问题的关键点就在这里。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=13#pid46840
交换磁盘通常用于 USB 启动的情况。此时 USB 盘占据了 hd0。
不过，如果 USB 能启动 wee，这已经表明 USB 支持 LBA 了。在 USB 上可以放置一个全功能的 GRLDR 来执行交换磁盘的功能。
在这种情况下，其实使用 grldr.mbr 更好。wee 本来就是为硬盘设计的。它的主要用途就是在硬盘上，防止因丢失分区上的引导文件而死机。这是 wee 目前最大的用处。将来可以被主板生产商用在 ROM 上那是另外一个话题。
当你去给客户或朋友修理机器的时候，通常他的机器还没彻底死掉，这时候，你首先把 wee 安装在 MBR 上，这样就放心了。即使后来折腾坏了，只要 MBR 上的 wee 还在，启动不至于死机，于是就还能尝试挽救。如果 MBR 上没有 wee，那么启动失败之后，你必须用 U 盘或者光盘或者 PXE 等手段了，而对于具体的情况来说，那些手段不一定行得通，比如说，机器没有光驱，不支持 U 盘启动，也不支持 PXE 启动。那就得拆卸硬盘了，很不爽吧。wee 的最大用处就是方便对付这类问题的。
估计 wee 不容易添加 map 功能了，因为体积的限制。以后的发展也许可以实现。目前不考虑。创建一个外部命令 map 应该不难，但这不是你想要的。因为 wee 已经能够启动 grldr 了，所以，启动一个外部的 map 命令，与启动 grldr 的麻烦程度是一样的。你希望的是 wee 里面集成一个小的 map 命令，这我明白。但以后再考虑这些。
补充一下：每个软件都有其用途、目的。wee 的主要用途应该是为电脑修理人员提供方便的。它不可以代替 grub4dos。它也不可以代替 pt 的 63 扇区引导软件。
wee 的调试手段 Insert 和 C 按键，目前是不可禁止的。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=17&fromuid=12697#pid47034
不点发表于 2010-12-29 12:01
grubutil 上的 wee 似乎也是 chenall 弄的。让 chenall 把补丁打上就行了。
你可以把 changelog 也同时放在补丁里面。
而且我本人没有多少时间来维护 wee，而 chenall 又有 grub4dos 在维护，恐怕也没有太多时间来照顾 wee。因此，我在想，不如由 Roy 来做 wee 的日常维护好了，当然在 Roy 愿意的前提下。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=18&fromuid=12697#pid47220
刚刚上载的 wee 版本，支持运行 16 位的实模式程序。关于 16位实模式程序的运行机制，在 readme 有详述。
ctmouse 已经改造成能够在 wee 下运行了，叫做 weemouse。
下载地址：http://nufans.net/grub4dos/wee/
weemouse 也可以在 DOS 下运行。用法与以前精简版的 ctmouse 一样。
weemouse 在 wee 下启动后，如果进入 MS-DOS，则在 MS－DOS 下这个 weemouse 驱动不起作用。原因是 IO.SYS 在启动过程中把 mouse 中断 int33 抹掉了。这个问题以后再想办法解决，目前暂时请使用其它 DOS。
在 wee 下安装 weemouse 的命令是 /weemouse。
在 wee 下卸载 weemouse 的命令是 /weemouse /u。
虽然 weemouse 已经建立了鼠标驱动，但目前只有 DOS 才能使用这个驱动（如上所述，暂不支持 MS-DOS）。在 wee 之下还没有建立 “如何使用鼠标驱动” 的方案（机制）。所以，weemouse 目前只能用于 DOS。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
更新： 最新版的 wee 已经可以阻止 IO.SYS 抹掉 int33 了。这样，在 wee 下运行 weemouse 加载鼠标驱动，再启动 IO.SYS，此时 DOS 下已经可以使用鼠标了。
补充： 在 wee 下直接启动 io.sys 时，可以阻止 io.sys 抹掉 int33。如果间接通过某个引导扇区来启动 IO.SYS（例如用 “()+1” 这样的命令），则不能阻止 io.sys 抹掉 int33。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
关于 wee 之下鼠标编程的问题，进行了一些思考，有以下几个方面的考虑。
1、鼠标驱动是工作于实模式的，应用程序如果要尽快响应鼠标事件，那么传给鼠标驱动的事件处理程序应该也停留在实模式。假如切换到保护模式，恐怕效率不高。当然，切换到保护模式也不是不可以的，这由应用程序的设计者来决定。如果事件处理程序切换到保护模式，那么，处理结束后，应该再切换到实模式，返回到实模式的处理程序。
2、实模式的事件处理程序由用户在需要的时候建立。有些应用程序不需要同步响应 BIOS 所发出的鼠标事件，它们可能仅仅需要不断地查询鼠标的状态（int33有查询鼠标状态信息的功能）。
3、由于鼠标驱动本质上完全就采用 DOS 下的鼠标驱动，因此，wee 之下的鼠标应用程序的编写者很容易使用。只需熟悉 int33 的一些常用规范便可。应用程序如果需要接管鼠标事件的处理，可以利用 int33 的功能，把应用程序自身的实模式鼠标事件处理代码挂上。应用程序可以利用常规内存来放置鼠标事件处理代码。一般可以放置在可用常规内存的顶部。可用的常规内存的大小（KBytes）由 0x413 处的双字节来确定（参见 “BIOS 数据区” 相关描述）。如果程序修改了 0x413 处的常规内存大小，那么，应用程序退出时，应该恢复它原来的值。
4、不仅 wee 的 32 位保护模式应用程序可以使用鼠标，wee 的 16 位实模式应用程序也能够使用鼠标。这是因为 wee 下的鼠标驱动本身就是一个 BIOS 软中断服务（int33），与其他 BIOS 软中断服务（例如 int13，int10）一样。
5、实模式应用程序当然很直接就可以调用 BIOS 服务（int10，int13，int33）了。保护模式之下的应用程序也能调用 BIOS 的中断服务，即通过接口函数 realmode_run 来实现。关于 realmode_run 的使用方法，前面曾经有详细描述。这里简单提醒一下，realmode_run() 就相当于 int86() 之类的功能，只不过其功能比 int86() 有所延伸。
说到这儿，也就说完了。其结论就是，目前的 weemouse 已经可以作为 wee 下的鼠标驱动了。而 wee 之下具体的鼠标编程，完全是应用程序设计者的事情。无需设计另外的一套机制，因为 int33 规范是一个完整的机制，本身就够用了。
期待着某一天有人能够设计出 wee 下的鼠标应用程序（比如说，一个下棋的程序，或者一个扑克牌程序）。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=19#pid47654
既然这样，我也对此问题谈谈我个人的更深一层的认识。
cpio 格式是新版 Linux 内核所支持的 initrd 格式。Linux 内核其实只支持加载一个 cpio 文件。而 Linux 加载 cpio 文件的过程却在实际上有能力加载多个 cpio 文件的简单堆积。syslinux 的作者了解 Linux 内核的这个加载过程以及加载方法，所以他利用了 Linux 的这个特性，而在 syslinux 中也把多个 cpio 文件连接成一个大文件，然后交给 Linux 内核去处理。这样，syslinux 就支持了多个 cpio 文件的加载。
我个人认为，利用 Linux 内核未公开的特性并不是一个值得称道的事情。加载多个 cpio 客观上鼓励了那些使用者把一个 cpio 文件分成几个。这个做法不能说没有一点好处，但它所带来的好处，我认为不大。
由于 syslinux 支持多个 cpio 文件同时加载，于是就有某些软件制造者把两个 cpio 文件交给 syslinux 去启动。这些软件当然无法被 grub legacy 加载，因此也无法被 grub4dos 加载。为了解决这个问题，我被迫兼容了 syslinux 的这个做法，也让 grub4dos 能够加载多个 cpio 文件。
wee 的空间紧张，支持这个可有可无的功能，我个人觉得实在不该，所以，一开始就决定不支持这样的功能。
需要声明一下，这都是个人的一些见解，不代表真理。真理在哪里？在我们每个人自己手里攥着，你认为是什么样的，那就是你的真理了。你的真理和我的真理，可以完全不同，甚至可以完全相反、相抵触。但那都是真理。这就是多元化的理念。只承认自己的是真理，别人的都是谬误，那样太武断，太霸道了。
我对于 BSD 自己的分区格式 (hd0,0,a) 也有类似的看法，以前我多次表明了这个看法。开源软件，尤其是 UNIX，我看到的教科书都说，UNIX 以简单为美，做事都是简单的，不拖泥带水。然而我理解不了 (hd0,0,a) 这样的分区格式，它与简单又怎能挂上钩？有时候，也得考虑与现有的设计相兼容吧？现在世界上各个国家和地区总共有6800种语言，这对于国际交流是有害的。许多语言注定要淘汰。其实，哪怕只留下 5 种语言，人们可能还觉得太多。不同的语言，就相当于不兼容。而语言数目的减少，则相当于大家需要兼容，渴望兼容。
当然，我水平可能低，不能够达到认识 (hd0,0,a) 的必要性和重要性的程度。对于认识其必要性与重要性的人，或许有着完全不同的理解。
但是既然我这么理解了，那就一定要按照我的理解去做事。所以我在 wee 中排除了对于 (hd0,0,a) 的支持。
任何人，你是怎么理解的，你一定要按照你的意思去做。你不要违背你的意思，去做你本来不想做的事。那样的话，你可就完全搞错了，或者说，真的傻了。
不同的理解，就是多元化。我现在很崇尚多元化。假若有人与我的观点完全相反，我觉得这太好了，这证明世界是多元化的，不是只有一个声音。
＝＝＝＝＝＝＝＝
呵呵，再多浪费一点笔墨。论坛上往往禁止谈论政治。其实，不用政治的参与，光是技术上的不同见解，就可以打得头破血流，可以搞的四分五裂、不欢而散。而实际上，打架的双方很可能都是开源软件的贡献者，都信奉相同的开源理念。这大概就是多元化赖以存在的基础了。不能说它对，也不能说它错，它是一个存在。想让它消失？那恐怕很难很难了。
＝＝＝＝＝＝＝＝
今天兴致来了，竟然还可以再说几句。以前我经常犯一个错误，那就是把自己的说成是真理，或者虽然没有明说，却在下意识中把自己的当成真理，而试图去驳倒一个又一个的反对者。结果，自己费了九牛二虎之力，达到精疲力尽的程度，也不能驳倒哪怕是一个反对者。反对者总有反对的理由，你要驳倒他的所有的理由，才能彻底驳倒他。可想而知，那该多累呀！所以，后来我终于认识到，要去驳倒反对者，那是一件极其愚蠢的事情。反对者自有反对的理由，根本没有必要去驳倒人家。让人家自由，不要让人家受到压迫。这既尊重了反对者，又尊重了自己，两全其美。在哲学上提高了认识水平以后，反过来又用这一哲学成果来指导自己的实践，自己原来理解不了的事情，豁然开朗，理解了。理解了我周围的同事、朋友、亲人，原来与他们发生矛盾、摩擦的，现在没有矛盾、摩擦了。理解了原来那些与我有隔阂的人，原来都是有原因的，这错误原来是在我自己身上。我找到了原因，调整了自己，那么隔阂逐渐消除。人类从诞生之日起，就在受教育。如果受到的不良的教育，那结果也是痛苦的。我先前之所以有这样那样糟糕的表现，则是因为没有受到很好的教育。这根本原因，就在于儿童时期没有受到必要的教育，结果长大以后，仍然不能够领会那些简单的与人相互和平共处的道理。这又离题太远了。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=19#pid47891
上次介绍得不详细，现在再补充一下。
wee127.mbr 之中所实现的 map 命令，几乎与 grub4dos 里面的 map 完全一样。只有以下两点差异：
1。不支持加载到 4G 以上。
2。不支持加载压缩的映像（gz，lzma）格式。
其他功能都有了。比如说，--mem 可以用，不带 --mem 的磁盘仿真也可以用。磁盘的映射当然也可以用。
map 支持的参数与 grub4dos 完全一样，例如，--hook, --unmap, --unhook, --rehook, --status, --ram-drive, --rd-size, --rd-base, --floppies, --harddrives 等等。所以，map 占用了大量的代码空间。
但是，wee 不支持 iso9660 光盘文件系统，因此，wee 不能用于 ISO。
－－－－－－－－－
而将来在 wee63.mbr 上，只能实现一个简单的磁盘映射之类的功能，不会有 IMG 仿真的功能了。
http://bbs.znpc.net/forum.php?mod=viewthread&tid=5838&page=20&fromuid=12697#pid49922
可以把memdisk当做一个外部命令在wee中启动img，试试看：
title 2. MaxDOS
find --set-root /BOOT/IMGS/MAXDOS.IMG
/memdisk /BOOT/IMGS/MAXDOS.IMG raw img
启动ISO：
title winpe.iso
find --set-root /BOOT/IMGS/winpe.iso
/memdisk /BOOT/IMGS/winpe.iso raw iso
