无忧启动论坛

标题: wee-MBR 嵌入微型 grub，转发自挂了的Sysoft [打印本页]

作者: liuzhaoyzz 时间: 2018-10-15 17:01
标题: wee-MBR 嵌入微型 grub，转发自挂了的Sysoft
wee-MBR 嵌入微型 grub，有问题一起讨论
http://bbs.znpc.net/forum.php?mo ... amp;page=6#pid43989
翻看电脑记录，看到了这个，Sysoft挂了，wee的开发过程，里面的记录我当时保存了下来，现在转帖上来，看对未来的开发者有没有帮助吧。

对 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?mo ... amp;page=7#pid44115
http://bbs.znpc.net/forum.php?mo ... muid=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?mo ... muid=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?mo ... amp;page=9#pid45314
功能就如上面所说，很难再有增加。除非将来把更多的 C 代码转成汇编，节约空间，然后才可以增加命令。

但是 map 命令很大，应该把它写成外部命令，否则，即使能够挤在 63 扇区以内，也给空间造成太大压力。

文件系统支持 FAT、NTFS，EXT2／3／4，很完美。

http://bbs.znpc.net/forum.php?mo ... amp;page=9#pid45316
不支持 (ud)

当 CHS 都不再被支持的时候，支持（ud）就没有意义了。

对于一个支持 LBA 的设备来说，根本就不需要用 (ud) 来增加引导的成功率。

精简版的主要目的，就是应用于硬盘的 MBR，使得查找 grldr 失败时，能够进入命令行，而不是 Ctrl＋Alt＋Del。

命令行之下能够运行外部命令，使得精简版就像一个微型的操作系统。这是这个精简版的另外一个特色。

如此小的操作系统，目前还不多见。

新鲜出炉，绝对值得尝试一下。
http://bbs.znpc.net/forum.php?mo ... amp;page=9#pid45319
一个附带的特性，这次把 grldr 放在任意深的目录下是可能的了：
复制内容到剪贴板代码:
find --set-root /boot/grub/grldr
/boot/grub/grldr
得益于 find 的查找功能。好多人以前希望 grldr 不放在根目录，那时候是不可能做到的。现在可以了。而且也支持 ext4 分区的 grldr 文件（当然任何别的文件也一样）的查找了。

http://bbs.znpc.net/forum.php?mo ... muid=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?mo ... muid=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?mo ... muid=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?mo ... muid=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?mo ... muid=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?mo ... mp;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?mo ... mp;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?mo ... mp;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?mo ... muid=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?mo ... mp;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?mo ... mp;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?mo ... mp;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?mo ... muid=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?mo ... muid=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?mo ... mp;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?mo ... mp;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?mo ... muid=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

作者: zlq_hysy 时间: 2018-10-15 20:06
码字好多，看起来研究很深入

作者: qaz1015 时间: 2018-10-15 22:54
11111111111111111111111111111111111111111

作者: 2011yaya2007777 时间: 2018-10-16 08:55
可否把 list_partitions 函数源码贴上来?

作者: liuzhaoyzz 时间: 2018-10-16 09:57
你自己下载看下吧，好像在ASM.S里面有。
这是不点2012-6-10上传的。
http://bbs.wuyou.net/forum.php?m ... &fromuid=298214

wee的项目空间好像打不开了。源代码不点应该有吧。不知道后来chenall更新没有。
请问下新版wee在哪里下载 - GRUB4DOS - 无忧启动论坛 - Powered by Discuz! http://bbs.wuyou.net/forum.php?mod=viewthread&tid=272510

wee-no-ext2.zip

398.93 KB, 下载次数: 8, 下载积分: 无忧币 -2

作者: liuzhaoyzz 时间: 2018-10-16 10:19
http://bbs.znpc.net/forum.php?mo ... age%3D33&page=1
A smaller grldr in size?

Can I download a small size grldr anywhere? the best is the size is 63k or less.
Can the grldr be packed, then it decompress itself inside the memory? anyone?
thanks, uleak
现在没有的。要 63K 这么小的好处是什么？能否讲一讲？
thanks tinybit.
I am doing a small experiment. If grldr is that small, then I can simply put it in a img file,
embedded into ROMOS. Thus I can embed grldr in a single option rom. this is eliminate
problems such as the need of writing to mbr or lossing grldr, etc.

This is the method:
the ROMOS embeded an img file, which img contain a menu.lst and grldr.
The internal boot-strapper relocate grldr.mbr to 7c00:0000,
then grldr.mbr  chain-loading the grldr from that in-memory img file.
Because the img file is within the ROMOS body, which is located in c000:0000 to c000:ffff (64K).
_OR_
compress the grldr. I tried to upx the grub.exe and results ~90K grldr may be the same.
etherboot offer a upx alike program and the decompression source. this is decompression is
a 32bit sub-routine that can act as prefix.

one more thing to add. please think about vista. The sequency of boot->grldr->ntldr->grldr is clumsy, it need to modify much file. this embedded method may reduce the steps. and most importantly flashing into the nic boot rom is easier than cbrom into bios.

uleak说的确实是一件重要的事情。GRUB 中的文件系统驱动程序占了大量的体积。把那些无关的驱动程序去掉，GRLDR 才有希望变小。

我觉得只要保留 FAT，NTFS，EXT2 以及网络驱动就够了。把其他那些驱动都去掉。另外，把 C 程序改成 ASM 程序，可以大大缩小体积。精简到 63K 应该不成问题。甚至可以精减到 30K，而完全放在 MBR 磁道上。
其实可以考虑grub2，grub2的内核可以定制，需要哪些模块就加哪些。没有包含在内核的模块可以从外部装载。而且，绑定在内核的模块是压缩的，这可以减少内核的大小。
根本的解决之道，我觉得不能是压缩。压缩只能有大约二分之一的压缩率。如果用 C 语言编写文件系统驱动模块，始终逃脱不了“体积”这一话题。不管是 GRUB 还是 GRUB2，如果要小到 30K，而不用汇编，那么这里面放置不了太多的文件系统驱动程序。GRUB legacy 虽然是无结构的，但是，也许从体积这个角度来看，无结构反而是一个优点了。而 GRUB2 的模块化、结构化，不一定能够带来代码的精简（在具有同样功能的前提下），相反，它还要消耗一些额外的代码空间。因此我的结论刚好相反：GRUB2 无助于压缩代码总量。
今天一直琢磨一个问题：做一个 mini grub ？？

体积要小于32K，也就是能装进一个磁道

功能精简，只保留最基本的，splash 不要，磁盘仿真不要，中文支持不要

但要有搜索功能

这样设计，是针对 gnu grub lagecy 的缺点： gnu grub lagecy 的功能主体 stage2 文件存放于分区中，而且安装后其MBR引导代码被设置为从固定的分区加载stage2，不灵活，健壮性打了折扣 —— 一旦文件被误删，或分区被删除、格式化，或分区序号改变，将无法引导系统，连命令行都进不去，令人束手无策，必须借助急救盘等来恢复。而且修复起来步骤繁琐。

grub 几乎是每个新手都要过的一道关卡

而 mini grub 功能主体全在0磁道，即使启动失败，至少可以进入命令行。可以动态搜索硬盘上的 menu.lst 而不拘泥于某个特定分区。MBR 因重装 win 而被改写，也可以较容易地修复——无需指定 stage1.5 stage2 所在分区，重写一下 0 磁道即可，甚至可以更简单，只重写 mbr 即可。

限于体积，不可能支持太多文件系统，支持一两种即可。比如，可以默认支持 fat ，因为这种格式 win 、linux 都能读写；另一种可由用户指定，或根据 linux 根分区的文件系统格式自动装配。

有点像 grub2 ，但如不点兄所说，我们没有 grub2 那么多功能，体积可以更小

又像 gnu grub lagecy 写在 0 磁道的 stage1 + stage 1.5 ，不同的是，我们把 stage2 也写进去了

还可以融入之前 bean 设想过的 iboot 功能，作为一个桥梁，能加载各种引导器。
你们两位可能都没有注意看第 11 楼 uleak 所说的话。pt 所说的方法，和 uleak 说的基本是一回事。而且 uleak 说的更明白、更好、更彻底：uleak 说不仅 grub 能够精简后放在 grldr.mbr 中，而且还可以像现在的 grldr.mbr 一样自动搜索硬盘分区上的 GRLDR 文件，一旦找到，就启动硬盘分区上的 GRLDR 文件。也就是说，GRLDR.MBR 的功能一点都不减少，而是增加了一个功能，使得它自己本身就是一个微型的 GRUB。

这个当然是有可能实现的，而且技术上并不存在实质性的障碍。我最为头痛的，是硬件兼容性。和硬件兼容性相比，上面这些都不是难题。现在就开始做前期准备工作，把这一思路付诸实施。而其他别的工作，暂且都停下来不做了，由别人去做。
恩，还是有点区别，我的设想，重点在 GRUB 功能，也就是首先保证 0 磁道的代码有启动 LINUX 系统的能力，目标是克服 GNU GRUB LAGECY 的缺点

GRLDR.MBR 的功能我也有提到，
引用:
原帖由 pt 于 2007-6-8 21:32 发表
还可以融入之前 bean 设想过的 iboot 功能，作为一个桥梁，能加载各种引导器。
但这是次要的，能实现最好，一时实现不了也没关系，因为毕竟功能越多代码就越大

先把 MINI  GRUB 实现再说 —— 要求放低点，希望可以不用汇编那么费劲
这个其实就是我以前提到的miniboot (或者应该叫minigrub ?) 的功能，是可以实现的，不过有点麻烦。

由于大小限制，只保留文件系统访问和chianloader的功能，菜单转化为容易使用的形式，嵌入到启动文件中。整个loader的大小在8K以内，可以在NT管理启动启动，也可以安装到MBR。
bean:

8K 的代码只能用来搜索 GRLDR，不能再做别的事情了。如果 8K 不再搜索 GRLDR 了，当然可以拥有一点功能。不过，这好像也不会好到哪里去。我记得 Smart Boot Manager 就有 18K 之多，所以，如果限定 8K，则很难有功能性可言了。一个文件系统的驱动就能占据 8K。所以，8K 之中无法加入文件系统驱动（即使是汇编，也难）。但 30K 就应该可以了。相信将来有人改造 NTLDR，让它像 VISTA 那样可以装入 64K 的引导文件。

pt:

uleak 的意思并没有说要减去一些重要的功能。可以启动 Linux，这是当然应该支持的功能了。
其实8K也可以做不少事情了，以现在grldr.mbr为基础，把FAT12/16/32的处理合并，并且去掉前面BPB的空间，这样的话文件系统代码只占6个扇区的空间，其余扇区足够处理装载启动扇区，ntldr, grldr, io.sys等启动文件了。如果空间足够的话还可以处理linux内核和initrd。这样的话，基本上可以满足一般启动的要求了。而且，功能和大小不可能两者兼顾，如果要达到小的内核，就必须去掉一部分的功能。

顺便说一下，grub中最大的部分是builtins.c，编译后的有70多K，而最大的文件系统模块ntfs，编译后只有5K，因此如果不减少功能的话，很难把grldr缩小到30多K。
text          data          bss          dec          hex       filename
  15633             0             0       15633          3d11       pre_stage2_exec-asm.o
2945             0             0          2945          b81       pre_stage2_exec-bios.o
5355             0          1620          6975          1b3f       pre_stage2_exec-boot.o
  69167          1620          592       71379       116d3       pre_stage2_exec-builtins.o
4877          296             8          5181          143d       pre_stage2_exec-char_io.o
1614             0             0          1614          64e       pre_stage2_exec-cmdline.o
5391          392          16          5799          16a7       pre_stage2_exec-common.o
   90          12             4          106          6a       pre_stage2_exec-console.o
8081          360          68          8509          213d       pre_stage2_exec-disk_io.o
2350             0             8          2358          936       pre_stage2_exec-fsys_ext2fs.o
2007             0             0          2007          7d7       pre_stage2_exec-fsys_fat.o
1384             0          12          1396          574       pre_stage2_exec-fsys_ffs.o
1347             0             0          1347          543       pre_stage2_exec-fsys_iso9660.o
2590          64          44          2698          a8a       pre_stage2_exec-fsys_jfs.o
1390             0          12          1402          57a       pre_stage2_exec-fsys_minix.o
5291             0          176          5467          155b       pre_stage2_exec-fsys_ntfs.o
3173             4          212          3389          d3d       pre_stage2_exec-fsys_pxe.o
3590             0             0          3590          e06       pre_stage2_exec-fsys_reiserfs.o
1729             0          28          1757          6dd       pre_stage2_exec-fsys_ufs2.o
881             0          20          901          385       pre_stage2_exec-fsys_vstafs.o
3514             6          140          3660          e4c       pre_stage2_exec-fsys_xfs.o
2622          16          4976          7614          1dbe       pre_stage2_exec-graphics.o
4530          252       44920       49702          c226       pre_stage2_exec-gunzip.o
520          16          12          548          224       pre_stage2_exec-hercules.o
1803          16          96          1915          77b       pre_stage2_exec-md5.o
1300             4          24          1328          530       pre_stage2_exec-serial.o
2010          240          548          2798          aee       pre_stage2_exec-smp-imps.o
6742             0          32          6774          1a76       pre_stage2_exec-stage2.o
685          200          512          1397          575       pre_stage2_exec-terminfo.o
2368             2          964          3334          d06       pre_stage2_exec-tparm.o
8K 当然也有可能做好，但是，似乎难度较大。我们可以先把 30K 的做完，积累一点经验，如果发现 8K 的也可以搞定，再做 8K 的也不迟。这样做的好处有两点：一是可以有更大的成功把握，二是可以等待别人把一个 NTLDR 的替代品弄出来（让它载入 64K，而不是 8K。我估计一些 hacker 应该可以完成这个任务，到时候我们就可以省略做 8K 的这个步骤了）。做 30K 还有一个好处，那就是不再照顾低于 63 个扇区的每磁道扇区数了。这有助于促成大家都朝每道 63 个扇区靠拢。那些杂牌的 U 盘竟然使用每道 32 扇区，实在是一个遗憾。

微软的 NTLDR 已经是不再维护了，因此，这个产品就是大家的、是社区的了。我这么说虽然有点过分，但仔细想想，这其实也是实话。我因此相信有人会把它改造好（我希望情况会是这样的，就像 Wengier 改造 DOS 那样）。

作者: liuzhaoyzz 时间: 2018-10-16 10:20
http://bbs.wuyou.net/viewthread.php?tid=167593&extra=page%3D1
MBR 嵌入微型 grub （2010年12月19日更新，不点大师加菜单）

本文和所有文件来自时空论坛“不点”大师！在此致谢！

这个 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 是不能用这种方法来启动的。

一个附带的特性，这次把 grldr 放在任意深的目录下是可能的了：复制内容到剪贴板代码:find --set-root /boot/grub/grldr
/boot/grub/grldr
得益于 find 的查找功能。好多人以前希望 grldr 不放在根目录，那时候是不可能做到的。现在可以了。而且也支持 ext4 分区的 grldr 文件（当然任何别的文件也一样）的查找了。

需要说明，精简版不支持 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://nufans.net/grub4dos/wee/ 底下

原文地址：  http://bbs.znpc.net/forum.php?mo ... &extra=page%3D1
--------------------2010年12月19日更新-----------------------------

地址：http://nufans.net/grub4dos/wee/
菜单如下：
（最大支持20个菜单条，恳请各位测试反馈）

title                         WDC-500G-wee
clear
title                         01  WinXP
root (hd0,1)
+1
title                         02  WIN7
root (hd0,0)
+1
title                         03  D_PAN
root (hd0,4)
+1
title                         04  E_PAN
root (hd0,5)
+1
title                         05  XORLDR
52628941+1
title                         06  GRLDR
2104000+490
title                         07  FBINST.MBR
557134253+1
title                         08  PLoP Boot Manager
2103900+100
title                         09  GMY-GHOST
/memdisk /ghost.img img raw
title                         10  SYSLINUX
find --set-root /boot/IBM.ICO
+1
title                         11  SSXF-WinPE
find --set-root /boot/SSXFLDR
/boot/SSXFLDR
title                         12  SSHY-WINPE
find --set-root /boot/SSHYLDR
/boot/SSHYLDR
title                         13  VISTA
find --set-root /boot/IBM.ICO
/boot/bootmgr
title                         14  SKTQB
2101000+480
title                         15  WIN NT/2003/XP
find --set-root /NTLDR
/NTLDR
title                         16  Win7/VISTA
find --set-root /BOOTMGR
/BOOTMGR
title                         17  WinPE.ISO
/memdisk /winpe.iso iso raw

注意：
1.不要用chainloader 命令，仿上述命令即可！
2.也请各位测试

title                         03  D_PAN
rootnoverify (hd0,4)
+1
title                         04  E_PAN
rootnoverify (hd0,5)
+1
即 rootnoverify 命令是否有问题？

3. 【改造】可以将U盘可见分区的BPB复制到MBR，可能提高安装到U盘的启动兼容性。
如果U盘启动电脑成功，则不需复制BPB如果U盘启动失败，再试试这个方法。欢迎大家测试反馈！
将可见分区（最好是FAT分区）的引导扇区从偏移0X02到偏移0X59止，复制到MBR的0X02到偏移0X59后再按不点大师指导的方法稍作修改即可！
【不点大师指正：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，只有这样才算一个完全的欺骗。但是，欺骗得完全，不一定能提高启动的成功率。这就要靠实践来证实了。】

4. 【应用之绝对扇区启动】
将某文件写入绝对扇区，如：plpbt.bin，位置是8388000扇区，大小约85个扇区
菜单写入：command (hd0)8388000+85 （注意command后空一格）
即可从本机启动plpbt.bin。。。目的是加载USB启动

【其他】若想启动grldr完整版也可以，类似：
command (hd0)X+Y                                        X是grldr的绝对扇区位置，Y 是grldr占用扇区数
目的是系统或分区损坏，从绝对扇区启动加以维护。。
请大家测试反馈，谢谢！
[ 本帖最后由天涯海角1216 于 2010-12-21 14:13 编辑 ]

你还可以将分区PBR备份为：c.bin（1个扇区即可），放在根目录
用：
find --set-root /c.bin
/c.bin
即可成功启动该分区

或
find --set-root /boot/IBM.ICO
+1

也可以启动该分区！
find --set-root /boot/IBM.ICO
是定位分区的！

可以直接启动文件或分区PBR，支持子目录查找和支持 ext4 分区的 grldr 文件（当然任何别的文件也一样）的查找了

很想知道假如全新安装XP的话会不会覆盖掉嵌入的微型Grub

如果是GHOST，则不会覆盖掉嵌入的微型Grub，
如果是安装版的，则会覆盖掉嵌入的微型Grub的第一扇区。。

ghost我不担心，担心的就是安装版的，每次安装安装版XP后都要重写MBR，这个要是不受安装版XP的影响就好了

其微型grub是安装到mbr上，它的mbr是专为微型grub使用，若0扇区被修改，同样无法启动此grub，其他mbr也是一样！

原来的grub安装到mbr，占用18个扇区，只是能够搜索grldr，其本身不能启动分区或文件，而此微型grub则具有启动分区和文件的功能了！
这个63扇区的grldr用在PXE上不错，可以引导grldr/ntldr/bootmgr/pxelinux/...，看成是引导的引导
但目前不支持菜单，这很难办。

时空论坛的原帖“不点”提出微型grub后不久，时空论坛PT版主就做了一个63S-GRUB，并在无忧发布，见http://bbs.wuyou.net/viewthread. ... highlight=63%2Bgrub
，Pauly 为其制作了一个 63S-GRUB 安装设置程序，见：http://bbs.wuyou.net/viewthread. ... highlight=63%2Bgrub
天涯能否将现在发布的与之做个对比?让我等菜鸟能更容易理解和应用，谢谢！
用 Pauly的 BOOTICE 能带参数直接安装吗？如果BOOTICE带参数恢复比较安全，怕不小心把分区表搞坏了。
不放心的话，可以先备份MBR到U盘，再用BOOTICE写入就可以了！

将里面的 grldr 第一扇区除分区表外写入硬盘MBR，再从第三扇区开始复制并写入硬盘第三扇区开始处！
因为其大小不是512字节的整数倍，所以BOOTICE会拒绝写入。。。

我将其写入硬盘，加上菜单再备份出来，一定是512字节的整数倍了，所以才可以用BOOTICE写入硬盘了。
6月20日更新，欢迎测试反馈！
我觉得不点大师如果推出一个介于完整版和此微型版之间的GRUB（GRLDR）更实用些，我相信多数都是“中间选民”。
这个过于精简了，不支持标题和CHS都是令人不快的事，我还是用以前的绝对扇区GRLDR法。
不点大师的本意是安装到MBR及其以后的62个扇区内，再加上简单的启动系统和其他功能的，所以只有不足31.5KB(63个扇区就是31.5KB大小)

http://bbs.wuyou.net/viewthread. ... p;page=4#pid1982652
感谢天涯海角哥们，你为此付出了很多。你的文档，弥补了软件的不足之处。你的介绍很周到、很细致。

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

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

http://bbs.wuyou.net/viewthread. ... p;page=4#pid1982804
发表于 2010-6-21 11:42
另外，关于 BPB 这个概念

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

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

个人觉得无需考虑BPB，在wee启动的前提下（EBIOS）根本不存在这方面的困扰。在U盘上最好还是用fbinst及全功能的grub4dos较好。这个wee只适合于本机硬盘并且在紧急救援的情况下
http://bbs.wuyou.net/viewthread. ... p;page=4#pid1983038
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配一个类似bootlace之类的安装工具，第三方的总觉得可能没有官方的可靠。
现在顾不上这事，只能先依靠第三方的工具了。只要经过充分的测试，都不会有问题的。

wee 的重头戏，还在于如何与 grub4dos 接轨，让两者共用相同的外部程序。目前这也没时间考虑。
试用能正常，如果命令行下，能记忆上次输入命令就好多了，真正机器出问题，进入命令行对于我们新手，经常输错命令，又要重新输入，又急又烦，能用上或下方向键补回上次命令再修改多爽，比Tab补全还实用。
这等以后再作修饰。现在不求完美，但求能用。

目前没有命令历史功能。

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

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

[ 本帖最后由不点于 2010-6-22 12:01 编辑 ]
请问不点大师  Wee安装在usb设备上不能成功启动时屏显内容是什么

我昨天把Wee用jianliulin的安装工具写入到一个U盘  在本上启动成功

在一台古董机上启动时  明显失败  usb设备能识别  但是引导其启动时提示Mem fail 且一直在刷屏

强行关机后再用这个U盘插在本上启动  也启动失败了  提示和古董机提示相同  mem fail 刷屏

按不点的规划，wee是用在硬盘的辅助工具，在U盘建议使用FB，在其他场合可以使用G4D

因为wee没有自动探测功能，楼上把它用在U盘是靠不住的
回复 #51 esxcfr 的帖子

好像没有规定不能用在USB设备上吧  我只是在尝试

FB不是很喜欢  UD区不能被大多数常规程序读取  造成PE的外置类还是需要放在可见区  容易被破坏

主要想知道的是Wee装在U盘上启动失败的错误提示  以及

为什么开始时安装Wee的U盘在A机上启动正常  在B机启动失败后  再启动A机时也失败  难道被改写了
把这2次MBR备份63个扇区，用WINHEX比较，就可以知道代码是否修改了
得找时间试试了  这周是没时间测试这个了  昨天是有人要装系统  顺手把Wee写U盘上试了下
http://bbs.wuyou.net/viewthread. ... p;page=6#pid1991818
有迹象表明，笔记本的 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，或许是某种未公开的秘密。

回复 #56 不点的帖子

回不点大师

古董机内存是256M  BIOS支不支持LBA我也不太清楚  是台联想品牌机  这台还好点  能USB启动  同批的其他联想机连USB启动都没有

出错信息Urr! wee... 这个是一直有还是只有第一行提示  因为出现mem fail后一直在刷屏  我不确定错误提示第一行是什么

改写U盘扇区那个我再看看  用Wee出现问题用grldr.mbr就没有问题  能正常启动

还有就是这台机子的U口是1.1的  速度不是一般的慢  后置U口还有问题  只能用前置U口  不知道和这个有没有关系
到显示 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 编辑 ]
回复 #58 不点的帖子

哦  理解错误  以为会在提示Urr! wee... 后再提示mem fail

mem fail无限循环那个我也比较怀疑  所以想问问这种出错是否正常  现在看来问题还不少

我尽量抽时间再用U盘试一下  把前后两次63扇区内容传上来

回复 #58 不点的帖子

很郁闷的问题  今天再用那个写入Wee的U盘启动那台古董机居然成功了  没有提示fail  引导进了grldr  试了好几次都没能重现昨天的错误

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

刚刚又试了下  这次重现了  附件里是扇区备份  确实被改写了  不点大师看看吧

normal.bin是写入Wee后的备份  error.bin是出错后扇区的备份
很抱歉，我最近没有时间。而关于对比扇区字节的事情，这谁都能做。你只要报告，有多少个字节被改写了，起始于何处，终止于何处。改写的规律是什么？为什么有时改写，有时又自动复原了？另外，U 盘有防写开关（写保护），是不是不起作用？或者你根本就没有试验？除了BIOS 会改写以外，会不会是病毒干的？
回不点大师  具体哪一段被改写了我还真没来的及看  测试出错后就直接保存扇区传上来了

不是有时改写  有时自动复原  是写入Wee后开始几次正常  再启动就报mem fail  以后的几次也都是mem fail  没有成功的  有什么规律我也不知道

U盘没有写保护  也没有用diskpart设置磁盘只读  病毒的原因应该不太可能  那台机子很少有人用  U盘也确认没有病毒

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

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

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

作者: 金 时间: 2018-10-16 11:30
uefi时代了还在研究mbr吗，大家一起研究下 grub4dos 支持uefi启动吧。哈哈哈哈

作者: liuzhaoyzz 时间: 2018-10-16 11:39
本帖最后由 liuzhaoyzz 于 2018-10-16 11:58 编辑

金发表于 2018-10-16 11:30
uefi时代了还在研究mbr吗，大家一起研究下 grub4dos 支持uefi启动吧。哈哈哈哈

现在都是高铁时代了，为啥街头上到处都是共享单车？

引用麦克阿瑟的名言：老兵不死，他们只会慢慢凋零！

作者: 不点 时间: 2018-10-17 18:46

金发表于 2018-10-16 11:30
uefi时代了还在研究mbr吗，大家一起研究下 grub4dos 支持uefi启动吧。哈哈哈哈

我也认为，grub4dos 没劲，因为 BIOS 已经被封杀了。但我与你有不同想法——我认为 EFI 也没劲，因为 EFI 迟早也是被封杀的命运，这是注定的。想想看，若干年前，win98 被封杀，然后 XP 被封杀，现在是 Win7 被封杀。

因此，我更看重（或看好）某些开源的硬件制造商，比如生产 Librem 系列产品的那个叫做 Purism 的公司，它生产的产品不会封杀 Linux——它甚至只支持安装 Linux，而不支持安装 Windows、iOS 或 Android。而其它那些既支持 Linux 也支持 Android 的产品，表面上看似是个优点，但我觉得那是缺点。道理很简单：支持 Android 会伤害 Linux。这是因为，设计 Android 操作系统的主要目的之一，就是要与 Linux 不兼容。把故意制造不兼容性的 Android 与 Linux 进行 “共生”，只会给 Linux 带来麻烦。因此那些支持 Linux + XXX 双系统的厂商都靠不住，迟早也要封杀 Linux。现在没封杀，那是时候未到。

yaya 问 list_partitions 函数在哪里。chenall 的网站上已经保存了最新版的 wee 的代码。在汇编语言的代码中就有这个函数。

作者: liuzhaoyzz 时间: 2018-10-18 07:54
chenall的网站上除了有weesetup，是个类似bootlace的安装器，没有wee的项目空间了，原来的网址打不开了。

作者: chenall 时间: 2018-10-18 09:05
https://github.com/chenall/grubutils

作者: liuzhaoyzz 时间: 2018-10-18 09:14
原来http://chenall.net/右上角有个github，github里面有个grubutils，代码都搬到github上了。

作者: jianliulin 时间: 2018-10-18 10:28

不点发表于 2018-10-17 18:46
我也认为，grub4dos 没劲，因为 BIOS 已经被封杀了。但我与你有不同想法——我认为 EFI 也没劲，因为 EFI ...

微软已经免费共享几万个专利给linux使用了，windows都能运行linux的程序了，时代变了。

作者: 不点 时间: 2018-10-18 11:28
本帖最后由不点于 2018-10-18 12:08 编辑

jianliulin 发表于 2018-10-18 10:28
微软已经免费共享几万个专利给linux使用了，windows都能运行linux的程序了，时代变了。

在 Linux 圈里，恐怕没什么人承认吧。时代变了，也不能仅仅看微软不再说 “Linux 是癌症”，就真的有了什么实质性的变化。该打压的，照打不误。对此 “变化”，不同的人，有不同理解。我的理解就是：嘴上说说而已，假支持，真打压。微软换了个掌门人，有一些调整。但大方向是不会变的。美国总统可以换，但都代表美国大财团的利益，因此，该往哪里投放炸弹，照投不误。

补充一点。微软以前可以让 Linux 与 Windows 共存，大家可以方便地 “双启动”。如今微软要消灭双启动，仅仅只让 Windows 启动。有人说了，Linux 也能启动。但是，微软封杀的途径不仅仅是启动程序，还有驱动程序。Linux 启动以后，声卡、网卡、显卡，有一样不能驱动，照样是无法使用。所以，微软 “在实质上” 已经封杀了双启动。既然控制了硬件生产商，那么一切都在控制之下。既然微软能让 XP 和 Win7 转不起来，就能让 Linux 也转不起来。表面上没把 Linux 封死，其实更具欺骗性。因为实质上是封死了。转起来毛病百出，我理解为，那就是封死了。至于说在 Windows 之下运行 Linux，就不要提了。那样的 Linux 是在闭源的 Windows 控制之下的 Linux，失去了开源的意义。就跟在 Windows 的虚拟机下运行 Linux 是类似的。这里的任何内容，都在 Windows 监控之下。如果不想被监控，那就不会接受它。

就是说，以前可以双启动，现在不行了（看上文的解释，别被假象迷惑）。微软现在让大家 “二选一”：要么 Windows，要么 Linux；互不通融。这个情况不只出现在 Windows 的世界里，在其它世界里也一样（谷歌、苹果都不例外），都是不再通融，要封杀 Linux。

作者: jianliulin 时间: 2018-10-18 11:37

不点发表于 2018-10-18 11:28
在 Linux 圈里，恐怕没什么人承认吧。时代变了，也不能仅仅看微软不再说 “Linux 是癌症”，就真的有了什 ...

你之前不也很反对grub4dos往uefi方向发展, 现在不也改变了

作者: 2010techon 时间: 2018-10-18 12:10
不管怎么说，WEE做硬盘启动管理真的不错。可内置菜单，占用扇区少，可以说是精简版的G4D

作者: 不点 时间: 2018-10-18 12:21

jianliulin 发表于 2018-10-18 11:37
你之前不也很反对grub4dos往uefi方向发展, 现在不也改变了

你看到的是表面现象。实质没变。当我发现新电脑封杀了 BIOS 以后，自然想让电脑能够启动。而 grub4dos 完全无用，因此，只能寻找 EFI 的启动工具——用户是没有选择权的。

但我立刻又发现，EFI 下的问题一点也没减少。它制造的问题更多。EFI 的目的，大概也就是为了只让 Windows 运行。那些 grub2 之类的方案，或许暂时能够喘息一段美好时光，但终究还是会被折腾死。要知道，BIOS 可是会随时偷偷更新的。

这就迫使我下定决心，弃掉 Windows，寻求纯 Linux 的方案了。我不知道这个过程会持续多长时间，也不知道最终能否如愿。但我知道，没有第二方案，这是唯一的出路了。

作者: 2011yaya2007777 时间: 2018-10-18 16:17
git clone git@github.com:chenall/grubutils/tree/master/grubutils/wee.git wee
不能下载

作者: liuzhaoyzz 时间: 2018-10-18 16:24
可以下载啊。

QQ截图20181018162348.jpg (47.85 KB, 下载次数: 120)

grubutils-master.zip

1.22 MB, 下载次数: 2, 下载积分: 无忧币 -2

作者: 不点 时间: 2018-10-18 16:32
你的做法可能不正确吧？

用浏览器进入这个页面：

https://github.com/chenall/grubutils

点击 “clone or download” 按钮，会显示

https://github.com/chenall/grubutils.git

因此，试试：

git clone https://github.com/chenall/grubutils.git

作者: 2011yaya2007777 时间: 2018-10-18 18:00
本帖最后由 2011yaya2007777 于 2018-10-19 09:25 编辑

明白了。原来是从这里下载。下载了一大堆。在 wee 界面没有下载链接。
不能从grub4dos_dev命令行下载。

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