wee的help文件

dihuo0

写在前面的话
经过多次修改，我所能找到的错误基本上已经都修正了。为了方便大家纠错，本文已经发到wiki百科上,地址是zh.wikipedia.org/wee。wiki百科是人人都可以修改的，有人发现了错误可能直接修改，而不回来本帖通知，因此， wiki百科可能更正确，更权威。建议大家直接去wiki百科。

wee最新版的下载地址是：
http://code.google.com/p/grubutils/downloads/list

————————正文开始————————
asm
asm命令用来提供与dos里debug相类似的功能。
语法：
asm [地址] db [字节] [字节] ...
asm [地址] go
1. asm [地址] db [字节] [字节] ...
“地址” 和 “字节”都是整数。
如果存在“地址”参数，则从“地址”处开始汇编。如果不存在“地址”参数，则从当前汇编地址开始汇编。系统初始的默认汇编地址是在地址 16M 处。每执行汇编一条指令，当前汇编地址指针会随着发生变动。
“字节”参数主要意图是用来编写机器指令，只有最低的字节起作用，其余的高位字节都被忽略。
2. asm [地址] go
如果存在“地址”参数，则从“地址”开始运行汇编程序。如果不存在“地址”参数，则从地址 16M 处开始运行汇编程序。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝
asm 命令只实现了必要的 db 和 go 子命令。真正的汇编指令，一个也没有实现。其实，由于 wee 的空间紧张，也确实无法实现了。需要等以后腾出空间了再实现。
db 伪指令可以实现机器码的编程。这对于熟悉机器码的人是有用的。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝
注：
1. 汇编默认的地址正好是外部命令运行时的代码空间。如果运行外部命令，就毁掉了你的汇编程序。所以，汇编期间，不要执行外部命令。
2. 在执行 go 之前，应该用 hexdump 命令检查汇编代码是否正常。否则，盲目地执行 go，有可能发生死机。
3. 你的程序应该保护所有的寄存器，最后用一条 ret 指令返回到 wee 的环境下。
4. 尤其要注意堆栈，不可有丝毫差错，否则就要死机。
5. 作为 asm 命令的应用，你可以调用 wee 的 API。不过，目前你得自己用 db 来写机器码，而且要熟悉各个 API 的调用格式。
http://bbs.znpc.net/viewthread.php?tid=6107
示例：
asm 0x1000000 db 0xC3
asm go
＃这个程序很简单，只有一个 ret 指令（ C3 就是 ret），什么也不做，立即返回。
————————————————————————————————
command
command命令用来执行外部可执行文件。
语法：
command [FILE [ARGS]]
wee不再需要 chainloader 和 kernel 命令了，取而代之的是用 command 本身的功能。command 命令把可以引导的文件（示例如单扇区文件、NTLDR、IO.SYS、vmlinuz 等）都当作可执行文件来对待了。单单在命令行之下敲入 ntldr、 io.sys或者 vmlinuz 等，就可以启动相应的文件了，它们已经是wee的可执行程序了。这就是说，启动那些不同的格式，有了统一的调用方式，不再像以前那样分为 chainloader 和 kernel 两个不同的类别了。
http://bbs.znpc.net/viewthread.php?tid=5838&page=7&fromuid=12697#pid44230
注：
1. command 命令不支持 --set-path 参数。默认时，使用当前当前目录作为命令文件的路径。如果未找到，将提示 wee 17>。
2. 菜单文件不是可执行文件。
3. 在wee中也没有boot命令，command命令将立即执行，不再需要附加boot命令了。
4. wee支持 FAT、NTFS，EXT2/3/4文件系统。
示例1：
＃启动linux
command (hd0,0)/vmlinuz (hd0,0)/initrd.img root=UUID=XXXXXXXXXXXXX ro quiet splash acpi=noirq
＃注意，由于这不是 chainloader 启动的，所以，你需要在 vmlinuz 之后紧跟一个 initrd.img，然后才是命令行的其他参数。
＃command 命令将同时加载两个文件到内存，一个是 vmlinuz，一个是 initrd.img。加载成功以后，把控制交给 vmlinuz。
http://bbs.znpc.net/viewthread.php?tid=5838&page=7&fromuid=12697#pid44101
示例2：
＃启动mbr
(hd0)+1
示例3：
＃启动dbr
(hd0,0)+1
————————————————————————————————
default
default命令用来设置默认启动的菜单项
default NUM
设置默认启动的菜单项为 NUM 号菜单。
注：
第一项菜单是0号菜单。
————————————————————————————————
exit
exit将立即终止当前命令的运行，将控制返回给调用者。
语法：
exit
当一个外部命令调用内部的命令处理器进入命令行手动输入命令的时候，如果没有 exit 命令，则永远无法退回到外部命令中。有了 exit 命令，当前的命令处理就可以结束了，控制可以回到调用者。
在wee和grub4dos中，每个命令都会返回一个ERRNUM。成功返回 0,如果返回一个非 0 值,通常情况下都会被认为是一个错误码，每个ERRNUM值都有特定的含义，详情请参阅grub4dos.h c/c++或bash的相关文档。一个编写良好的命令,程序,和工具都应当返回一个 0 来表示成功。
将来，wee可能会提供脚本功能。脚本中的函数和脚本本身都会返回ERRNUM。在脚本或者是脚本中的函数中执行的最后的命令会决定ERRNUM。
注：
在wee命令行中，提示符wee和>之间的数字就是上一个命令的错误码。
示例：
wee 0>echo
#echo是外部命令，如果当前目录下不存在echo，那么提示符将是：
wee 17>
————————————————————————————————
find
本命令用来查找符合条件的文件或分区。
语法：
find [--set-root] [--active] [FILENAME] [CONDITION]
1. 参数 --set-root，找到第一个匹配后马上停止，并且把该设备设为根设备。
2. 参数 --active，查找激活的主分区。grub4dos的find没有此参数。
3. CONDITION 是一个返回值是 true 或者 false 的命令。
注：
违反直觉的是，0代表true，非0代表false，但是却符合脚本语言的内部逻辑，大多数脚本也都是这么规定的。
示例 1:
find
这会列举所有的硬盘分区，软驱和 (cd) 等。
示例 2：
find +1
这会列举文件系统已知的所有设备。
————————————————————————————————
hexdump
本命令用来显示内存数据。
语法：
hexdump [地址] [长度]
地址和长度都是整数，以字节计算。
如果在一个命令行的开头按下 Delete 键，则此时也会执行 hexdump 命令。因此，可以认为 Delete 键是 hexdump 的快捷键。
————————————————————————————————
map
本命令是一个简单的设备映射命令
语法：
map (FROM_DRIVE) (TO_DRIVE) [--hook] [--unhook]
1. --hook 参数表示仿真立即生效，即使是在命令行模式中。
2. --unhook 参数仅仅是断开 INT13 的挂钩（在中断矢量表中），它不会影响到驱动器映射表。
map命令不支持--rehook，建议使用--unhook参数，并自行恢复驱动器映射表.
另外，127扇区版的wee127.mbr 之中所实现的 map 命令，几乎与 grub4dos 里面的 map 完全一样只有两点差别：
1. 不支持加载到 4G 以上。
2. 不支持加载压缩的映像（gz，lzma）格式。
注：
wee不支持从 iso9660 光盘文件系统中启动，因此，wee不能用作 ISO 的启动引导程序。
http://bbs.znpc.net/viewthread.php?tid=5838&page=19&fromuid=12697#pid47891
示例1：
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
示例2：
map --unhook
map (hd0) (hd0)
map (hd1) (hd1)
map --hook
————————————————————————————————
pause
暂停，按任意键后继续。
语法：
pause [MESSAGE]
暂停，按任意键后继续。如果有MESSAGE，则把它输出到屏幕上
注：
pause命令不支持--wait参数。
示例1：
pause This is a test。
This is a test。
#按任意键后继续
————————————————————————————————
root
设置并加载根设备。
语法：
root [DEVICE_OR_PATH]
将指定设备(DEVICE_OR_PATH)设置为根设备，然后尝试挂接该分区以得到分区大小。
注：
根设备和根目录是两个容易混肴，但是实际上不同的两个概念。
示例：
root (hd0,0)/boot/grub
#这条命令执行之后，根设备是(hd0,0)/boot/grub，而根目录是(hd0,0)/boot/grub/，两者相似但是还是有一些细微的差别。
————————————————————————————————
rootnoverify
设置但不加载根设备。
rootnoverify [DEVICE]
类似 'root' 指令, 但不试图安装该设备。这用于有些系统装在 wee 不能访问的磁盘分区之上, 但仍需要设置正确的根分区的情况。有些需要安装分区才能确定的参数可能会有问题。
————————————————————————————————
timeout
timeout SEC
设置在自动启动缺省菜单前所等待的秒数。超时后，将启动默认菜单项。在菜单头部使用，不能用于菜单项中。
————————————————————————————————
title
title [NAME]
菜单标题,即加载菜单后菜单项的标题。
目前最多只支持 20 个有效的 title 行。
当存在连续的 title 时，仅仅把最后一个 title 作为有效的 title 来计算，其余的只显示出来而已，并且不能用箭头键来访问。这是一种添加注释的方法，这样，用户想怎么添加注释都很随意了。
这是与grub4dos不同的地方，grub4dos不支持此功能。
示例：
title
title Wee Boot Menu
title =============
title  GRLDR
http://bbs.znpc.net/viewthread.php?tid=5838&page=13&fromuid=12697#pid46877

——————————————————————————————————
本文写作的过程中参考了grub4dos-help-2011-05-27、ABS_Guide(高级 Bash 脚本编程指南)、grub2入门基础教程修订版、批处理阶段教程奥运最终版[英雄出品]以及系统时空和无忧启动论坛的相关帖子，并得到了不点等人的帮助，在此一并致谢。

[ 本帖最后由 2011_dihuo0 于 2011-8-22 09:15 编辑 ]

dihuo0

=== 名字的由来 ===
http://bbs.znpc.net/viewthread.p ... muid=12697#pid45404
wee：很少的，微小的，极小的，很早的。
有很多词汇都曾经被用于小的操作系统，比如 mini，tiny，nano，micro 等等，这类常用词都被用光了。
所以就找到这个无人问津的 wee 了。如果将来真的成为了一个操作系统，中文名字可以叫做“微”，与英文语音相近，词义也相近。
起初找这个 wee 不是想把它当作一个操作系统的名字，而是想把它当作一个后缀（wee是三个字母，作为后缀很合适，也很难得；其他的同义词都要超过三个字母）：grldr.wee 以区别于 grldr.mbr。但是，后来，grldr 的开头 16 扇区不能存在了，精简为 2 扇区了，这样，就不能再用 grldr 作为主要名字了。所以，我就想，干脆就把主要名字叫做 wee 得了。
目前，第一扇区中代码启动失败时的提示字符串就是 “Urr! wee...”。
————
http://bbs.znpc.net/viewthread.p ... muid=12697#pid45408
grldr.wee 不好，因为将来不利于区分 63 扇区和 128 扇区的版本。也不容易区分 ROM 版和 MBR 版。
grldrwee 也存在一样的问题：
grldrwee63.mbr、grldrwee63.rom 显然超过了 8.3 文件名的要求，不美观。
这个 wee，如果看成是一个独立的操作系统的话，它是从 grub4dos 发展而来的，或者说，是基于 grub4dos 的。一个东西基于另一个，新的不一定非得在名称上与旧的有牵连。ubuntu 基于 debian，但在名称上从未体现出 debian 字样。

=== 近况 ===
http://bbs.znpc.net/viewthread.p ... muid=12697#pid43940
按照我目前的想法，微型grub有一套API，而grub4dos也有一套API。可以肯定的是，微型grub的API数量很少。这样就有两种情况：
1。grub4dos 的API 严格与微型grub的API一一对应，都是少量的几个。这样，少量的API只提供系统中极其特别的几个功能接口。
2。grub4dos 的API多于微型grub的API。这就有了两者共有的 API 以及grub4dos专有的API之分。那么应用程序肯定也得考虑两种不同情况。将来我们会公布究竟哪些API是共有的，而哪些是grub4dos专有的。这样一来，应用程序的编写者就能决定是否同时支持两者以及如何在两种情况下都能运行。
注意我们仅仅涉及的是内核提供的API，不讨论由其他扩展模块所提供的API。API就是系统调用。grub内核代码和变量是高度透明的，这些API函数就是内核本身必不可少的函数。把这些变量、函数和数据结构的地址放在固定的内存位置，就等于向外部程序提供了访问的手段。内核用了多少个函数，外部程序也就能够用多少个函数。因此，内核的代码是充分地被利用了。你不可能做到，让内核中没有的函数，也作为API供外部程序使用。内核中所有的函数都可以被外部程序（作为API）来调用，这一点，不就是最好的代码重用吗？这已经达到最大化（100％），你不可能做到更高的代码重用率了。我们的内核（代码和数据）没有丝毫的保留，全都贡献出来，供外部程序使用。这就是core-lib。所谓的core-lib，就是内核所提供的系统调用罢了。但是我们不同于Linux的系统调用的方面在于，我们是把内核中全部的代码和数据都提供给外部程序了，这一点，Linux是不会这么做的。Linux是一个操作系统，注重安全，所以，它不会像我们那样去做。而我们就像DOS那样，没有安全机制，所以，我们就可以把内核完全暴露在光天化日之下，你可以调用它，你也可以破坏它，那都是你的自由。
至于说将来的扩展（内核模块和TSR程序），也都可以提供API，那是比较遥远的事情了，我们现在去讨论，还不是时候，因为就连现在我们都处于摸索阶段。应该一步一步来。如果一步还没走稳，下一步就不容易看得清楚。我们是“摸着石头过河”。
=== 发展目标 ===
== 主要用途 ==
http://bbs.znpc.net/viewthread.p ... muid=12697#pid46840
wee 本来就是为硬盘设计的。它的主要用途就是在硬盘上，防止因丢失分区上的引导文件而死机。这是 wee 目前最大的用处。将来可以被主板生产商用在 ROM 上那是另外一个话题。
当你去给客户或朋友修理机器的时候，通常他的机器还没彻底死掉，这时候，你首先把 wee 安装在 MBR 上，这样就放心了。即使后来折腾坏了，只要 MBR 上的 wee 还在，启动不至于死机，于是就还能尝试挽救。如果 MBR 上没有 wee，那么启动失败之后，你必须用 U 盘或者光盘或者 PXE 等手段了，而对于具体的情况来说，那些手段不一定行得通，比如说，机器没有光驱，不支持 U 盘启动，也不支持 PXE 启动。那就得拆卸硬盘了，很不爽吧。wee 的最大用处就是方便对付这类问题的。
每个软件都有其用途、目的。wee 的主要用途应该是为电脑修理人员提供方便的。它不可以代替 grub4dos。它也不可以代替 pt 的 63 扇区引导软件。
http://bbs.znpc.net/viewthread.p ... muid=12697#pid31282
这些裁剪掉的内容，将来有可能再添加上，如果确有必要的话（同时也得在我们有相应的开发能力的情况下）。mini grub 的裁剪将很多，最后，保证软件大小在 30K 以内（也可以同时推出30K和60K两个版本）。mini grub 的用途大概是在 MBR 上以及 ROM 扩展卡上。
对于 30K 的 mini grub，我们到时候可以考虑融合 grub.exe 和 grldr 了。因为 grub.exe 就可以变成 grub.com 了，这样，它就有可能与 grldr 合并了。到那时，它们统一称作 grub.com。
————
http://bbs.znpc.net/viewthread.p ... muid=12697#pid45316
精简版的主要目的，就是应用于硬盘的 MBR，使得查找 grldr 失败时，能够进入命令行，而不是 Ctrl＋Alt＋Del。
命令行之下能够运行外部命令，使得精简版就像一个微型的操作系统。这是这个精简版的另外一个特色。
如此小的操作系统，目前还不多见。

[ 本帖最后由 2011_dihuo0 于 2011-8-3 10:33 编辑 ]

iwjq7tts

百年不遇的好帖子，不得不顶











交友：我是个小女生，21岁，独生子女，还没谈过恋爱，长相较好，反正带出去不会给你丢脸，身高165cm，体重50kg，现在是一家公司的文员。希望找个比我大几岁的男生，不需要你有非常好的条件，但一定要有上进心，会体贴女生，不花心。因为我是第一次恋爱，所以希望找的就是那种能结婚的。如果你是我说的那个他，那就加我微信吧：pndrwx

不点

调用 bios 属于执行实模式代码。用 realmode_run 函数（C 语言函数）即可。不需要 asm 之类的手段。

realmode_run 函数在 wee 和 grub4dos 下都存在。用 google 搜 realmode_run 看看能否找到相关说明。

pseudo

asm，可以调用bios中断么？要注意什么？grldr有类似功能么？

不点

看来占位后的沙发让我抢到了。

sgw888

dd 跟 write 命令在写盘操作时，是调用的BIOS 吗??

不点

这当然是的了。但是，你这个问题，与 pseudo 的问题完全不是同一种性质的。pseudo 是想让自己（也就是“用户”）能够调用自己所选择的“任何” BIOS 调用，而不仅仅是读盘或者写盘。dd 和 write 相当于一个应用程序，它们被用户直接使用，来完成某个任务。但 realmode_run 就不是一个应用程序了，而仅仅是一个函数，它的“用户”，只能是编程人员。编程者利用 realmode_run 函数，可以调用任意一个 BIOS 的中断，来完成自己的某个任务。

dihuo0

请大家帮我检查一下有没有错误，有的话，我会尽快修改免得误导别人。
另外，有没有熟悉维基百科的，我打算把这个贴子发到维基百科上去。

不点

首先就发现拼写有错误：

waring -> warning

席位的差别 -> 细微的差别。

建议再锤炼一段时间，你自己说不定就能发现很多毛病。

不点

exit 命令不支持携带 errnum 参数。

title 命令不支持如下的用法：

“在文本模式的菜单显示模式下可以在菜单标题后使用\n 添加该项菜单的注释信息（多余一行的注释信息可以使用 \n\r 来换行输出）。”

即，不支持注释信息。

[ 本帖最后由 不点 于 2011-7-7 17:24 编辑 ]

不点

发现今天有了 Wee 的 wiki 百科条目，在这里：

http://zh.wikipedia.org/wiki/Wee

我觉得，其中有些描述过于激进。就是说，没有完成的工作，不可以夸大。wiki 百科是很严肃的。

比如：
        1. 支持内存管理。        2. 支持进程管理。

这两条可以去掉。内存管理不存在。进程管理也应该算是没有。只不过有运行程序的功能而已，都是很初步的，处于发展之中。

觉得在“抓本质”方面，有待改进。要突出 wee 的特点，讲出 wee 的优点在哪里，以及 wee 的局限性。让人看了之后，心中有个明确的印象。

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

dihuo0

这是我写的，我希望能够起到抛砖引玉的作用，能够吸引更多的人来改进完善它。
对wiki 百科，我怀有敬畏的心理。这是我建的第一个词条，初次使用，很不熟悉。

我曾经在系统时空论坛上浏览过有关wee的大部分的帖子，从mini grub到mini gub到grub63到wee，这些帖子时间跨度4～5年，太长了，我只留下一个初步的印象。

现在我没有重新看那些帖子，只是根据记忆来写的。欢迎大家前去改进它。
另外，wiki 百科上有grub4dos条目：
http://zh.wikipedia.org/wiki/Grub4Dos
不知道是谁写的，也太过简略了。希望大家前去改进它

[ 本帖最后由 2011_dihuo0 于 2011-7-7 20:21 编辑 ]

不点

我也估计是你写的。因为我似乎在 ubuntu 上也看到了你的推介，有类似的描述。作为一个推介资料，确实很好。但作为维基百科的条目，还需要再加锤炼。

grub4dos 的条目，我个人觉得写得比较符合维基的规范。因为它做到了最重要的一点，那就是“准确”。它的文字很精练，高度抽象，基本涵盖了所有重要的方面。

“Grub4DOS将焦点放在兼容性上”，这一句，就抓住了要害。这是 grub4dos 区别于 GRUB 的关键之处。同时，这一句也是高度抽象的。grub4dos 为沟通各个操作系统所搭建的桥梁，以及为躲避 BIOS bug 所进行的艰苦努力，如此种种，全都归结为“加强兼容性”，因此，我认为这是高度的概括和抽象。有此特点，就标明了这是 grub4dos，而不是其他。这是区别于其他软件的标志所在。

Plantsoot

grub4dos 又多了一位得力干将，呵呵，而且有不点的指导，相信会发展的更好。

不点

共同学习，共同探讨。任何人，他的知识都是一点一滴积累起来的，都是从零开始的。任何事情也是从无到有，逐渐发展壮大的。这是普遍的。学海无涯，大家也都同处于不断学习的过程中。

dihuo0

grub4dos条目我也修改了好几次，但是与gnu grub相比还是太简略了。

不点

我个人觉得，写维基百科的条目确实比较难。看到 dihuo 修改后的条目了。比原来的要更准确、更忠实。

每个人都有自己的视角，所以，按照自己的理解去写，都是可以的。

首先就是从无到有，然后再逐步改进。是的，大家都可以参与编写。

不点

wiki条目要具有权威性，必须做到准确。准确就不允许有错误，否则失去权威性。

发现以下描述不够准确：“wee是grub4dos团队在grub4dos代码的基础上用汇编语言重新开发”，其中，用汇编语言开发，不完全正确。其中有大量的 C 语言代码，并未改写为汇编。但终极的目标是全部用汇编，目的是减少代码的体积，为功能性代码增加可用的空间。“因为是重新开发的，摆脱了复杂的代码负担...”，既然是基于 grub4dos 的，就不能说是“重新开发的”。可以参考如下的描述“因为在 grub4dos 的基础上对代码进行了大幅删减，所以功能有所减弱，但体积更小巧，启动更快捷。”

关于 grub4dos 的描述，“目前活跃的开发者主要是中国人，其成员有tinybit，bean，chenall，roy和karyonix等。”感觉没必要提到“中国人”，因为随时都可能有不同国别的人加入。而 tinybit 和 karyonix 也并非项目维护团队的正式成员。可以参考如下的描述：“目前活跃的开发者主要有 tinybit，bean，chenall，roy 和 karyonix 等。”保证语言的严谨性，做到准确无误。

虽然软件开发的主战场是在中国。但这是一个全球性的项目，受益者是全球，协助者也是全球。与硬件 bug 进行斗争，这 bug 的始作俑者，也来自全球各大公司。这些公司由于某种原因，千方百计给软件设下陷阱，破坏软件的运行。项目还有一个英文论坛（是哪国的，我也没弄得太清楚），对项目的运行也有着巨大的支持。这一切都表明，这个项目具有“全球性”这一属性。所以，不要用狭隘的民族主义情结来看待这个项目，那样会掩盖了它的全球性属性。项目代表的是全球民众的利益，也招来了来自全球的敌人的攻击。

刚刚看到修改后的条目已经很好了：
http://zh.wikipedia.org/wiki/Wee

[ 本帖最后由 不点 于 2011-7-8 11:59 编辑 ]

dihuo0

只是一个大纲，我先把框架搭建起来，这样方便别人进行修改，有利于吸引更多的人来改进。
grub4dos条目，我也做了相应的修改。
http://zh.wikipedia.org/wiki/Grub4Dos

dihuo0

可以把wee的command命令移植到grub4dos吗？
与grub4dos相比，command命令可以说是wee最大的特色了，如果能够移植过去就是好了。
我这两田翻阅以前的帖子，发现曾经有过这样的计划。
如果不方便的话，那能不能做成外部命令呢？

不点

新的 grub4dos 条目确实不错，很好了。

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

关于 wee 的 command 命令的设计，其实，也确实是不得已而为之——因为空间的限制，只能如此。把原来的 kernel 命令以及 chainloader 命令都整合在 command 命令之下，确实节约了逻辑步骤，也节约了代码空间。针对 wee 的具体情况，我也觉得，这个设计确实很令人满意。

而 grub4dos 不怎么需要这个设计。要说移植的话，应该也能移植，只不过，移植的需求并不强烈。好像也没人（有时间）去做这个工作。

135956

realmode_run 能否提供一下使用说明？网上也找不到。

不点

在 google 中输入 realmode_run，碰巧找到了一个例子 vfont.c ，你可以仿照它来编程：

http://code.google.com/p/grubuti ... e/trunk/src/vfont.c

该函数的详细介绍在时空论坛的“MBR 嵌入微型grub，有问题一起讨论”中。时空论坛现在正被攻击，无法访问。

-----------------找到了，干脆复制过来，以免时空论坛再次被攻击时无法访问--------------

初步这么设计：函数调用方法是 int realmode_run ( struct realmode_regs * regs_ptr )

函数名称是 realmode_run，有一个参数 regs_ptr。函数成功执行后，返回 1。失败时，返回 0。

regs_ptr ------ 32位线性地址空间指针，指向用户提供的寄存器数据包，该数据包可以存放在用户的32位保护模式的空间中（不必放在实模式可访问的常规内存空间中），具有如下结构：

struct realmode_regs {
unsigned long edi; // as input and output
unsigned long esi; // as input and output
unsigned long ebp; // as input and output
unsigned long esp; // stack pointer, as input
unsigned long ebx; // as input and output
unsigned long edx; // as input and output
unsigned long ecx; // as input and output
unsigned long eax;// as input and output
unsigned long gs; // as input and output
unsigned long fs; // as input and output
unsigned long es; // as input and output
unsigned long ds; // as input and output
unsigned long ss; // stack segment, as input
unsigned long eip; // instruction pointer, as input,
unsigned long cs; // code segment, as input
unsigned long eflags; // as input and output
}

用这个接口，用户可以方便地定制自己所希望运行的实模式代码。调用前，用户必须把实模式代码拷贝到目的地。目的地应该位于实模式可访问的空间以内（即，通常是在常规内存中）。CS：EIP 应该指向这个位于实模式内存空间中的代码。EIP 的高字应该是0。用户提供的实模式代码，将会被 grub4dos 的实模式代码用一条 far jmp 指令跳转到。用户代码执行完之后，用户必须用一条 far jmp 返回到 grub4dos 中。返回的地址是 0000:8200。建议用户把实模式的代码放在 0000:7C00 至 0000:7FFF 之间的 1024 字节空间中，也可以放在 0000:0580 至 0000:05FF 的 128 字节空间中。用户应该保证不破坏 grub4dos 的代码、堆栈。grub4dos 的实模式代码位于 0000:8200 至 0000:FFFF，堆栈位于 0000:7000（向下扩展，大约至 0000:2000）都不应该被破坏。以上提到的空间，都在第一个 64K 以内。64K 以外的实模式空间（至常规内存的结尾处，位于0000:0413 的一个字表示了常规内存的 KB 数），可以被用户程序任意使用，但使用前应该备份，使用后应该恢复。64K 以内的 0000:7000 至 0000:7BFF 这段空间也是同样的处理，如果要使用，首先应该备份，使用后再恢复。

如果用户不提供自己的代码，而只是希望运行一条简单的 int 软中断指令，则用户应该设置 CS=0xFFFFFFFF, EIP=0xFFFFXXCD。其中 XX 表示中断号。

如果不需要设置 SS 和 SP，请将 SS 和 ESP 都设置为 0xFFFFFFFF。
如果不需要设置 EFLAGS，请将其设置为 0xFFFFFFFF。
如果不需要设置 DS，请将其设置为 0xFFFFFFFF。
如果不需要设置 ES，请将其设置为 0xFFFFFFFF。
如果不需要设置 FS，请将其设置为 0xFFFFFFFF。
如果不需要设置 GS，请将其设置为 0xFFFFFFFF。

成功返回时，所有标明为 as output 的域都更新，即使它们在输入时标明为“不需要设置”，也要在输出时被更新。

如上所说，如果实模式程序的执行破坏了某些实模式的内存，那么，成功返回之后应该及时恢复原来的内存。


[ 本帖最后由 不点 于 2011-7-9 11:50 编辑 ]

快雪时晴

终于见到wee命令使用文档了，还有编程接口，对于某些人来说，很强大

135956

早上我在时空论坛里找到相关说明了，不过，还没看完，就访问不了了，现在又能打开了。似乎还是无忧这里稳定哦。

dihuo0

如果没有什问题。明天我会发到wiki百科上。

dihuo0

== 历史与发展 ==
=== 缘起 ===
http://bbs.znpc.net/viewthread.php?tid=2461
GRLDR.MBR作为通用的引导程序的一些想法
不少的启动管理器或系统的启动部分，主要的功能是在一个启动文件里实现，而MBR或启动扇区的功能是把该文件读入内存并运行。这和GRLDR.MBR引导GRLDR的方式非常相似。不同启动文件使用时的差别在于：
1、启动文件名字不同
2、启动文件在内存里存放的地址不同
3、启动文件运行的入口参数的差异
我们可以用一个中间层的启动程序来处理这些差别，从而使GRLDR.MBR成为通用的引导程序。其启动的流程如下：
1、装载GRLDR.MBR
2、从GRLDR.MBR引导中间启动层启动程序
3、中间层启动程序选择最终的启动文件。其选择可以通过一个简单的选择菜单，或使用嵌入中间层启动程序中的值。
4、中间层启动程序把自己移动到较低的内存处，并且，把最终的启动文件的名字填入启动扇区适当的位置中。
5、中间层启动程序跳回7C00:0000，该地址是原来启动扇区的内容。
6、启动扇区第二次运行，它从分区中里装载新的启动文件(文件名字在中间层启动程序里填入的)。
7、装载成功后，启动扇区返回较低的内存处的中间层启动程序。
8、中间层启动程序把最终启动文件的内容复制到恰当的位置，然后设置入口参数，并且运行最终启动文件中的代码。
现在的GRLDR.MBR已经可以直接使用，只需要写一个处理不同启动文件的中间层的启动程序就行了。
如果要更好地配合这一方案，GRLDR.MBR的代码可以作以下修改：
1、存取分区的代码分为初始化，搜索文件和装载文件三部分。在第二次运行时可以跳过初始化的代码。
2、中间层启动程序可以调用启动扇区里的搜索文件函数。这样中间层启动程序可以对于每种支持的启动文件都测试一下，并且显示可以启动系统的列表。
使用该方案的好处是能够在不同的分区动态搜索启动文件。而且，GRLDR.MBR也能在Windows NT系列系统的启动管理器中引导。
该方案适用于GRLDR, GRUB2，NTLDR，io.sys, syslinux.bin, kernel.sys(FreeDOS)等启动文件。
http://bbs.znpc.net/viewthread.php?tid=4146
GRUB4DOS中启动代码分离的构思
这个想法我以前也曾经提过，现在把它总结一下：
1、启动代码和GRUB4DOS分离
启动代码的主要功能是把pre_stage2的代码装载到内存的某一位置，然后进行调用。除此之外，启动代码和GRUB4DOS的交互是很少的。而把文件装载到内存这一功能，可以用于启动其他一些文件，如io.sys, ntldr, kernel.sys, grub2等等。因此，启动代码可以独立于GRUB4DOS而存在，作为一个通用的启动管理器。
2、采用模块化的设计
目前启动代码比较混乱，不适合于将来的扩展。主要体现在：
a、多功能集合导致代码复杂度提高
现在grub.exe和grldr都是集合了多个功能于一身。这看上去好像很方便，但其实使得代码的复杂度大大提高，增加了修改和调试的难度。我想应该对于每种不同的启动环境使用不同的启动文件，而代码的共用通过子模块来实现。
b、存在过度优化的现象
我看过一篇名为 Optimization: Your Worst Enemy 的文章：
http://www.codeproject.com/tips/optimizationenemy.asp?msg=2259746
我觉得启动代码里也存在过度优化的现象。优化的确是需要的，但是它应该局限于子模块内，不同模块间的交互应该是简单和明确的。
我想启动代码应该尽可能细分为模块，每个模块只实现单一的功能，最终把不同的模块连接起来而成为最终的启动文件。模块可以粗略分为以下几类：
1、启动模块
这相当于启动文件的头部，不同的启动方式对应于不同的头部。启动模块还可以根据具体的启动方式，导出启动设备。例如，如果从光驱里启动，则可导出光驱设备(cd)，从pxe启动，则可导出设备(nd)。而通用的设备(hdN)和(fdN)在独立的模块里实现，它们用于读取硬盘和软盘。
2、分区模块
这部分模块处理不同的分区格式。它们通过读取底层的设备(hdN)，分析里面存在的分区，从而生成新的设备(hdN,M)
3、文件系统模块
这部分模块处理不同的文件系统。它们使用(hdN,M)来访问底层的设备，并导出文件读取的函数。特殊设备(cd)和(nd)跳过这一步骤，直接导出文件读取的函数。
4、格式处理模块
不同的启动文件，其启动的方式略有不同，这些差异在这些模块里进行处理。
5、扩展功能模块
这部分模块提供扩展的功能。它们类似于GRUB4DOS里的命令。每个命令对应于一个模块。
6、通用函数模块
这部分模块提供公用的函数。比如说，开启/关闭A20的代码，访问扩展内存的代码，等等。
7、脚本解析模块
启动管理器可以使用配置文件的形式来设置启动选项，于是在启动时就需要解析执行。还有一个比较简单的方式，就是
利用外部程序把配置文件转化为容易使用的二进制形式，然后把它添加到启动文件中。
如果使用配置文件，其格式可以参照GRUB4DOS，例如：
timeout 10
title Windows XP
root (hd0,0)
ntldr /ntldr
title DOS
root (hd0,1)
msdos /io.sys
title Grub
root (hd0,0)
grub /boot/grub/stage2
title Grub 2
root (hd0,0)
grub2 /boot/grub2/core.img
在这里，不同的启动文件使用不同的格式处理模块进行处理。
至于这个启动管理器的名字，我本来想使用miniboot，但这名字好像已经有人使用了。我想是不是可以使用tinyboot，这和miniboot的意思差不多，而且和不点的名字有点像，呵呵。
http://bbs.znpc.net/viewthread.php?tid=3576
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.
http://bbs.znpc.net/viewthread.php?tid=3576&page=2&fromuid=12697#pid20480
GRUB2 是 GRUB1 的开发理念的继续发展。虽然开发形式上不同了，但开发者的开发理念、开发哲学、开发重点，是没有变的。这就是 GNU 的开发理念。这是和微软的所建立起来的生存发展环境不相融合的。世界上最难改变的东西，不是山水，而是人的哲学、人的理念。任何一个人，都会根据自己的理念，把自己归入不同的群体。比如说我，当初就喜欢 Mandriva：非常喜欢，非常欣赏，非常佩服。但是后来我的理念发生了变化，转到一个技术并不比 mandriva 好的 ubuntu 上了。理念第一，技术第二。
我来开发 grub4dos，一个明确的理念，就是要以事实工业标准为依据，着力打造一个良好的 PC 运行环境。我很明确不会照顾其他非 PC 的系统，甚至也不会照顾 MAC 机。这是我的侧重点，当然 GNU 不会这么做了。GNU 恰恰相反，GNU 要照顾的是“非微软”的环境（虽然GNU没有明确这么说，但我认为他们始终是这么做的）。这就是理念的差异。GNU 有一种背叛的精神，这很好。但在某些情况下，这种背叛可能容易做过了头、容易过分理想化，从而与现实发生某些脱节。
grub4dos 无论成功与否，都是与此理念相关的。如果成功，那是因为这个理念，如果会失败，那也是因为这个理念。为什么呢？因为我们的技术实力，远远不如 GNU 的技术实力，因此，如果我们成功了（当然我们现在还不算成功），你就无法解释我们为何会成功。只能从技术之外找原因──于是很容易就找到“理念”这个原因了。
http://bbs.znpc.net/viewthread.php?tid=5838&extra=&page=1
MBR 上总共有 31K，原来的 grldr.mbr 要占据 8K，所以，其实剩下的空间只有 23K 了。
当 grldr.MBR 搜索 GRLDR 失败的时候，就进入微型 grub。
虽然只有 23K，但微型 GRUB 还是有可能做一些简单的工作的。
首先，FAT 的驱动，按照 C 代码的生成结果，大概有 10K。如果用汇编，则（估计）可以减少到 2K。其它的文件系统不打算支持（也可以用外部模块来实现，放在 FAT 分区中）。
然后就是磁盘读取disk_io.c（磁盘缓冲），以及命令行的处理（键盘输入和屏幕输出）。
最后就是添加几个必要的内部命令。添加的内部命令，要求占用空间很小。像 map 这样的大命令就不能作为内部命令了。
以上这几项改用汇编也不是说就特别困难，因为整个的代码量很小。
至于说外部命令，就全部用 C 语言来写了。
http://bbs.znpc.net/viewthread.php?tid=4156&extra=&highlight=%E5%86%85%E5%AD%98%E7%AE%A1%E7%90%
关于新一代GRUB4DOS的想法
目前0.4.*系列GRUB4DOS已经基本上稳定，功能比较完善了，除了A20的兼容问题外，其余需要改动的地方不是很多了。但在结构上而言，GRUB4DOS还是存在一定的问题，不容易进行扩展。我想在新一代的GRUB4DOS里可以作以下的改动：
1、启动管理器分离
把启动管理器的代码从GRUB4DOS里分离出去，形成软件tinyboot。而在GRUB4DOS里，生成单一的二进制代码文件stage2，在不同环境里启动GRUB4DOS是通过tinyboot里实现。
2、使用Unicode，不区分中英文版本
摒弃现在打中文补丁的方法，采用统一的代码。配置文件里使用UTF-8的编码，这样可以兼容ascii的菜单，也可以在一个菜单里同时使用不同的语言。
3、利用gettext实现多语言支持
现在显示中文帮助需要在源代码基础上进行补丁，这个方法使得修改变得困难，而且很难支持多种语言。一个较为简单的方法是使用gettext进行转换，把英文转为相应的语言。文本的映射从外部载入，这样可以节省内存空间，也使得语言的动态改变成为可能。
4、内存管理器和动态模块
使用内存管理器可以更好的利用内存空间，特别是扩展内存。动态模块是在GRUB4DOS启动后加载的模块，它们可以和GRUB4DOS的主体进行通信，实现扩展的功能。模块的设计可以参考syslinux里的comboot api：
http://syslinux.zytor.com/comboot.php
5、图形界面的改进
修改目前图形显示的一些问题，实现可定制的图形界面，支持更多的图片格式。

当然，要完全实现以上的功能是一个很漫长的过程，但无论如何，需要有一个起点。我想可以启动一个新的分支，0.5.*，来逐渐实现以上的功能。而目前的代码，则作为 0.4.* 分支，继续进行维护。不知道大家的意见如何。
http://bbs.znpc.net/viewthread.php?tid=4988&extra=&page=1
准备再一次对 grub 的主体程序进行大幅度删减
我对 grub2 有畏惧之感。觉得它牵着鼻子走，跟上它是一件不轻松的事情。
grub4dos 的精简，最终不会与 grub2 一样。grub2 适合专业高手去开拓，而 grub legacy 则需要较少的技能，基本上就是 c，asm，makefile，只要这三个能掌握个差不多就行。虽然是无结构的编程，但初学者还比较容易适应，比较平民化。
在 mini 中，我准备只保留 fat, ntfs,ext2,iso9660,pxe 等较少几个文件系统的支持，而把其他的全部去除。如果以后实现了某种机制，也可以把它们重新加入支持，但这是后话了。
这肯定损失一些功能，但干任何事情都要有一个宗旨。我的宗旨就是，以事实工业标准为依据，因此那些很少用到的东西，都将被边缘化。我不想面面俱到，把所有的方面都照顾得很好。没有理由为了照顾少数几个人的偏好，而浪费公众的资源。
我相信，一个无结构的 grub 是仍然有前途的。
当初我还在为 grldr 的引导代码未能支持其他文件系统而苦恼。经过近几年的实践，我的观念发生了转变。现在我不认为这是一个缺点了。grub4dos 的用户群，目前大致上只限于 Windows 用户，包括 ubuntu 里面的 wubi，也只是为 Windows 用户而设计的，ubuntu 在安装之后，它的主要引导管理器仍然是 grub legacy， 而不是我们的 grub4dos。这说明我们的 grub4dos 未能在 Linux 的世界中立足。一开始的时候，我也为此事感到头痛。但是，现在我不觉得这是一个问题了，因为 grub4dos 已经在健康发展了，逐渐被 Windows 群体所承认。这个群体，其人数要远远超过其他操作系统的人群。只要我们把握住这个人群，我们的发展前景是无可限量的。
还是这样一个主题：事实工业标准为依据。进入我们视野的，只能是有着事实工业标准基础的东西。那些偏离太远、非常渺茫的东西，都将从我们的视线中消失。
http://bbs.znpc.net/viewthread.php?tid=4988&page=1&fromuid=12697#pid30302
grub4dos到目前为止，发展得还算正常吧？其实就 grub4dos 本身而言，可做的事情仍然很多。我在考虑，如果发布一个终结版 0.4.4，而一个新的版本 0.5 开始 朝向 mini 发展，这样也算是两个分支了。如果 0.4.4 需要改进，我们也可以（与 0.5.x 一起）同时发布 0.4.x 的后续系列。两个系列（两条线索）最后有可能融合到一起，变成一个，也即功能全面同时又是 mini 的 grub4dos，到时候我们可能就称其为 0.6.x 了。
其实我很有信心的。grub4dos 目前达到的目标，其实已经是不容易了。任何一个软件，要想达到 grub4dos 目前这样的成熟度和用户接受度，都需要开发者付出成倍的努力，这不会是一件轻松的事情，碰壁是正常的。我的业余时间几乎全部都用来开发 grub4dos 了，是的。待到软件开发完成，用户逐渐多了起来，而用户也开始报告各种各样莫名其妙的问题，到那时候，恐怕开发人员才会真的遇到难题。按照目前的发展势头，grub4dos 应该是稳步取得成功。如果掉头转向别的软件，我觉得那带有冒险性，我不能肯定我会成功。
http://bbs.znpc.net/viewthread.php?tid=4988&page=1&fromuid=12697#pid30303
pt：
不点兄也不必太强迫自己，bug 是解决不完的，没有完美的事情
到了一定程度，不再是开发者迁就硬件，而应该是硬件商向 grub4dos 靠拢
时常我也在想，GRUB4DOS 的核心竞争力是什么？？当然开源软件的理念是 just for fun ，没有担保，没有强迫，然而开发到一定程度，就不仅仅是 for fun 那么简单，涉及到荣誉感，责任感，成就感，自然而然就会希望它赢得更多用户，获得更多认可，达到更好的兼容性，实现更强的功能，这时往往就陷入一种强迫，一种执着，有时并不值得 —— 这是我的切身体会。人有时必须傻一点，俗一点，马虎一点，才能快乐生活
扯远了，还回到核心竞争力，我觉得关键有两点：1. 能通过 ntldr 启动；2. 强大的磁盘仿真。正因有了这两个功能，才得以被各种系统维护软件采用从而广为传播
这两个功能都不是首创，最早见到是 vfloppy ，syslinux 中也有 memdisk ，然而不点将这两个功能大大完善。现在，g4d 的其它功能都有替代品（光盘启动有 isolinux ，dos引导linux 有loadlin ，作为普通引导器，原版的 grub 也已够用），唯独这两个，而且集二者于一身，唯有G4D 。
http://bbs.znpc.net/viewthread.php?tid=4988&page=2&fromuid=12697#pid30316
emutemp：
不点曾花了那么多时间去解决在某种机型出的故障，这些故障比较特别，不具有普遍性，只在某品牌甚至某种主板上出现，对广大用户来说，属于少数。那为什么不点你愿意花时间去解决这些少数人的问题呢？只是一种爱好，希望自己的程序更完善还是希望用户在使用这个程序时能有更好的兼容性？
GRUB4DOS是一个系统引导的管理工具，它的定位最主要在于维护人员维护时方便，而不是一个普通用户做为自己操作系统的引导工具使用。
对于一个普通用户来说，他面对的是一个固定的软硬件环境，只要系统能够启动，引导工具对他来说就是一件可有可无的东西，无论这个工具有多强大，他用不上，他甚至可能更愿意用系统自身的。
而维护人员需要面对的是不同的硬件环境，而在这种情况下，最需要的是强大的兼容性，就拿压缩软件举例，你是愿意用压缩率最大的ACE还是更愿意用普及性最强的RAR？
不点在解决GRUB4DOS在某些主板或某些使用方法下的故障时，最重要的价值在于扩展了它的兼容性而不是增加了多强大的功能。一个功能够用就行，能更强大当然更好，但是更重要的是在什么环境下它都能用。
我想说的是GRUB4DOS做为定位在维护人员使用的工具上，有一个漂亮界面是次要的，有强大的功能是必要的，而拥有最大的兼容性是最主要的，我不赞成删除程序中的功能，特别是减少文件系统格式支持的种类。
http://bbs.znpc.net/viewthread.php?tid=4988&page=2&fromuid=12697#pid30350
zw2312419：
所谓兼容性，对grub4dos来说是包括硬件兼容和软件兼容两个层面。
对于硬件兼容性，有目共睹grub4dos几乎做足了有关bios方面的东西，在对付bios缺陷机和常规软硬盘支持上表现优异，只是在目前流行的usb和cdrom以及其他接口的支持方面是有待加强。我想，精简后的grub4dos应该还是会保持其强项，而继续改善和强化那些薄弱的环节。
对于软件兼容性，实际上主要是指grub4dos对不同文件系统的支持度。任何一个开发者应该是不会傻到把几个常用文件系统删掉，而不与支持的。对于那些极不常见，普通用户几十年都不见得用得上的文件系统，精简掉它难道不是明智的吗？反过来看，那些使用量极少的文件系统，从来也没看到过有bug报告，即使现在对它支持了，能说明grub就是真正兼容了它吗？——不能。因为它从来就没有经过长时间实践的考验。所以多了对那些系统的支持，并没有什么实际意义，唯一的好处是在readme和宣传页上多写一排“xxxx文件系统也被支持。”

到现在，都看得出grub4dos已取得了阶段性成果，是到了要考虑何去何从的时候了。有些话真的是不知道该不该由一个菜鸟来说出来。
在我们敬仰的几位大侠里，从不同的帖子都隐约婉转的表达出不点可以考虑罢手，和他们一样转投某个新项目的意思。但对于把grub4dos几乎看做是自己还未茁壮的孩子一样的不点来说，也许真的有点欲罢不能，左右为难。——“开发到一定程度，就不仅仅是 for fun 那么简单，涉及到荣誉感，责任感，成就感，自然而然就会希望它赢得更多用户，获得更多认可，达到更好的兼容性，实现更强的功能，这时往往就陷入一种强迫，一种执着，有时并不值得”—— pt 的话无疑是个真朋友才有的坦率告白  ——但是，面对grub2的自由定制，面对PLOP Boot Manager在usb上的捷足先登，面对syslinux光鲜的界面，面对其它软件一刻不曾停止的步伐，面对所有这一些各具特色但又总有欠缺的软件，我们还是首选了经过无数机型验证了成熟度的grub4dos，我们还是希望它坚持它自己的方向，继续不断前行。——白驹过隙，草木一春，就象人终究会老去，软件也会更频繁的更迭，但那些经受过考验而坚持住的东西往往成为经典。
从grub一路到grub4dos，看到一个个bug的消失，它明明在说，grub4dos性能是稳定而优秀的，bug修正是迅速而及时的，应用是不断丰富和延伸的。——这，难道不是它的生命力吗？这难道不是它的竞争力吗？这难道，不是用户真正需要的吗？
http://bbs.znpc.net/viewthread.php?tid=4988&page=3&fromuid=12697#pid31307
GRUB4DOS在2004年小有名气以来，就是 不点、老渝 两个人在做，后来有了bean，现在最多3、5个在参与开发。
http://bbs.znpc.net/viewthread.php?tid=4988&page=4&fromuid=12697#pid31356
grub4dos 只在 Windows 用户群中有一定的基础，而在 Linux 群体中基本上处于被冷落的地位。无论是在中国还是在其他地方，讨论 grub4dos 很热烈的，全都是 Windows 相关网站，而讨论 grub4dos 的 Linux 社区，我连一个都没见到（ubuntu除外，它也只是在与windows相关的部分才采用grub4dos）。不否认有个别的 Linux 用户也来使用 Grub4Dos，但是，在 Linux 社区远未形成群体效应。我们应该了解事实，尊重事实，勇于面对事实。
我作为 grub4dos 的维护人员之一，对 grub4dos 的现状和未来都报以平常心。我们现在只问我们自己：我们究竟该做什么？现在的 grub4dos 的开发，已经不再是一个人想怎么做就怎么做的时候了，而是大家共同的开发项目，由论坛提出来而未完成的任务太多了。有需求，就有发展。grub4dos 目前主要是靠需求而发展的，需求是主要的推动力。我甚至认为，即便我本人因为身体原因而退出了开发，那么我相信论坛上一定有人会接续开发，并且差不多就是按照我现在的思路去做。为什么呢？正是因为需求如此，是众人的需求在推动，而不是个人在推动。像我这样技术水平的人，到处都有，所以，由别人来接替开发不是难事。我唯一与人不同的，是我个性鲜明，不容易受人左右。不过，无论是谁，经过锻炼之后都会是这样的。
grub4dos，做现在该做的。这就是 grub4dos。我曾经十分反对***的 “摸着石头过河” 的理论，觉得没有理论指导的实践是盲目的实践。可是，我们现在的情况，似乎就有 “摸着石头过河” 的味道了。所以，世界上没有绝对的真理，也没有绝对的谬误。
http://bbs.znpc.net/viewthread.php?tid=4988&page=4&fromuid=12697#pid31361
到目前为止，我仍然不认为 grub4dos 被 linux 社区冷落，与 grub4dos 这个名称有着本质的联系。如果这个软件特别好，即使叫做臭狗屎，都有人去用的（当然这话有点过分，不过，其道理应该是差不多成立的）。之所以没有被采用，其原因应该还是在这个软件自身的发展上。到目前为止，我们仍然在解决那些 bug，正是这些诸多的 bug，阻止了这个软件被更多的人采用。
把 grub4dos 自己的工作做好，做该做的事便可。至于说是否有更多的人去用，不要想这些事情。有些事情是不可强求的。世界是多元化的，大家都是很自由的，想用哪个软件就用哪个软件。grub4dos 被人接受的速度确实是不太令人满意的。但是，也要看到，grub4dos 是在缓慢的被人接受。从 sarovar 上的点击下载率就可知道，grub4dos 在进步。我仍然认为，假如不靠实力，光有一个好的名称，那是不能解决根本问题的。名称坏了当然也不好，不过，半道上更改名称，也不是一件好事。两下扯平，一比一，还是维持现状吧。
另外，DOS 并不可恶。歧视 DOS 也是不该的。多元化的世界，需要相互的理解，而不是相互的隔阂。如果说 grub 是来源于 Linux，那么 DOS 却是古老的工业标准。这么看来，grub4dos 的名称正好把两者联系起来，应该看成是它的亮点，而不是缺点。grub4dos 这个软件的精神实质就在于沟通。离开了这一点，你还能从 grub4dos 身上找到什么优点吗？我觉得很难了。有人歧视 Linux，那么 Linux 的用户就不高兴。有人歧视 BSD，那么 BSD 的 fans 也不高兴。多元化的世界中，难免存在歧视。而 grub4dos 也不是来解决相互歧视的问题的。grub4dos 以事实工业标准为基础，开发出一个大多数人都可用的一个启动管理工具。grub4dos 不支持什么，并不表示那个事物就没有发展前途，而是表示，在目前的情况下，支持那个事物的理由并不充分。换句话说，那个事物还没有发展到这样的阶段，即，让我们迫不得已，必须支持它。
一个人可能一开始由于某种思想的障碍而拒绝接受 grub4dos，但是，一旦他接受了，他可能会获得更多的东西（消除偏见，消除隔阂），而不仅仅限于 grub4dos 的技术层面。
自然界优胜劣汰的法则是普遍适用的。如果一个操作系统有生命力，那么许许多多的软件都来支持它。反之，如果一个操作系统的发展相对缓慢下来处于劣势，那么其他软件也可能较少考虑对它的支持。这件事对于启动类的软件也是一样的。众多的启动类软件之间也存在竞争，其中有一些可能会在竞争中失利。一个启动软件，它至少要做到以下两点才不至于很快被淘汰：第一，适应于尽可能广泛的硬件，尤其是主流硬件。第二，适应于主流的操作系统（文件系统）（那些与操作系统和文件系统无关的启动软件，不考虑这个因素）。如果为了适应某些并不主流的操作系统或者文件系统而影响到了软件的稳定性和可靠性，那么这样的适应，就属于有得有失，在我看来，是“失”大于“得”。尤其是，当某个问题影响到该软件主流应用中的某个环节并最终证明是很难解决、或者是不能解决的时候，那样的损失就是很惨的了。软件通常都是有 bug 的，修复 bug 是一件很艰苦的事情，有时候，bug 会存在很多年而不能解决。软件的功能越强，出现 bug 的几率就越大。显然，为了适应某个罕见的硬件或者软件而增加了该启动软件的 bug 产生的几率，那是得不偿失。grub4dos 在这方面尝尽了苦头。我们因为功能强大而付出了很大的代价。法网越密，其漏洞就越多；软件越复杂，其问题就越多、开发就越困难。如果某个软件（尤其是启动类的软件）声称它创新了某个功能，我并不会觉得世界马上就要变样了。新生事物要走向成熟并最终被认可和接受，通常需要有个过程，这个过程通常也不会很短。
一个软件要获得良性的发展，其实并不容易。用户使用软件的时候，他通常是只想用用罢了，他并不想报告 bug。那些前来报告 bug 的人，占用户总数当中很少很少的比例。甚至其中有不少的 bug 报告者本身就是开发人员，或者是比较熟练的电脑老手或者称为（相对的）高手。在 bug 报告者很少的情况下，一个软件要想走向成熟，被市场最终认可和接纳，那不会是一帆风顺的。所以，一个软件通常需要若干年的时间，才能慢慢地、逐步地被认可。反过来再看，一个（从某种程度上说）已经被认可了的软件，它已经有了它存在的基础，它站稳了脚跟，它有了立锥之地，那么另外一个后起之秀要想赶上或者加以超越，那同样也是不容易的。用户的习惯（强大的惯性），也是不容忽视的。那么软件怎么样才能良性发展呢？首先，要保持自己的优势，不要丧失了优势。如果软件的主要优势已经几乎不存在了（被其他软件赶上和超越了），那么这个软件的进一步发展也就失去其意义了。如果是开源的、自由的软件，不如直接转而支持新的软件开发项目，把老的彻底放弃掉。其次，要吸收别的软件的长处，把用户迫切需要的功能加以实现【并在可能的情况下，尽量兼容旧的软件，这是对用户的尊重；除非实在无法兼容，这时候才放弃兼容性。】【提到兼容性，并不是说一切都得兼容。那些对用户的日常使用影响较大的、用户使用很频繁的功能或者界面，需要保持兼容，而那些不常使用的功能，则可以不兼容。】【如果开发人员有意无意地给用户制造兼容性障碍，那么这就给用户拒绝使用你的软件找到了一条合适的理由，说不定就有那么一部分用户会始终拒绝使用你的软件。】最后，解决用户所报告的问题。最后这条最重要，用户报告的问题，必须认真对待。用户能够前来报告问题，这是很可贵的，应该十分珍惜，不能轻易放过。如果解决不了，开发者应该给用户一个答复，说明为什么解决不了，这样才算是严肃认真负责的态度。如果最后这条（即对待用户的 bug 报告）懈怠了，即使前两条都打满分，也很难保证软件能够持续良性地发展下去。
http://bbs.znpc.net/viewthread.php?tid=5838&page=11&fromuid=12697#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/viewthread.php?tid=2984&page=7&fromuid=12697#pid44725
微型grub与grub4dos相互兼容的问题（给chenall）
最近通过一个时期的思考，在微型grub的开发方向上终于有了一个明确的目标。
由于微型grub占用的实模式常规内存可以很小，所以，微型grub有可能设计为只占用磁盘仿真的 int13 handler 的内存空间。也就是说，它的实模式代码和数据仅仅占据常规内存顶端的若干个 KB 的空间，与 int13 handler 的代码共同占有那一部分内存。由于 int13 将不再处理 cdrom，而且其他代码也都简化，所以，int13 的代码加上微型 grub 的实模式内核，总共大致仍然保持 12K 左右。
微型grub 当然也有位于扩展内存的保护模式内核代码部分。这部分用来执行常规的功能，例如，运行内部命令和外部命令。扩展内存空间的占用不再是 16M 以内了，而是位于扩展内存的顶端，目前暂时设计为占用 32M 的扩展内存空间（只使用4G以内的部分，而64位的大内存是不考虑的）。
由于微型 grub 只占用原来 int13 仿真代码的空间，所以，它可以与其他所有的操作系统共存。它不再占据 0x8200 开始的内存空间了，而把这些主要内存空间都让给操作系统来使用了。
这样一个设计，就注定与 grub4dos 不兼容了。不兼容的部分主要是那些固定内存地址，都不会被微型 grub 支持了。那些地址必须挪动到别处，有可能挪到扩展内存中。
将来会设计一个兼容模式，让 grub4dos 和 微型grub 的可执行程序可以通用。目前就不要考虑兼容性问题了，该怎么开发，你就放开手脚大胆开发吧，没有任何后顾之忧。一般情况下，对于 grub4dos 我就不再花费过多的精力了，除非是有人要设计 grub4dos 的进程管理（或者类似的大的动作）的时候，我再（根据自己的身体情况）考虑是否参与设计和实现。
＝＝＝＝＝＝＝＝＝＝＝
长远来看，将来的微型grub可以移植一个调试器。那时候，微型grub很可能已经变成一个调试器了。在操作系统之下，热键呼出微型grub调试器。理想的调试器是 SoftICE，但它不是开源的。在 google 上找 SoftICE 的替代品，居然有两个，一个是rr0d（Rasta Ring 0 Debugger），另一个是 LinICE（softice for linux）。在理想的情况下，能够把其中之一移植到微型 grub 中。这两个调试器都有源代码的，如果你有兴趣的话，你也可以研究如何把它们移植到 grub4dos 之下。
http://bbs.znpc.net/viewthread.php?tid=5948&page=2&fromuid=12697#pid45573
整合 wee 和 grub4dos 的接口函数
关于操作系统的设计（例如进程管理），如果按照我目前的设想，我是打算设计一个极其简单的操作系统，就像 DOS 那样单纯。而可执行文件的格式，当然也是异常简单的，甚至比 DOS 的 EXE 格式更简单。我们不用 EXE 格式，而只用（类似于） .com 格式。我们在 DOS 的 .com 文件格式中，增加一个输出函数的列表，供 TSR 程序使用。这个系统并不很 “专业”，也没打算让它很 “专业”。确切来说，这个系统是很 “业余” 的。由业余的程序员开发，（也希望）由业余的程序员来使用的——这么一个操作系统。整个的开发理念就是 “越简单越好，越单纯越好”。
而且我似乎还发现，这么一个开发理念，还没有人去做过，连尝试者都没有。一个东西存在的价值，就在于它不同于别的东西。既然没人沿着这条路去走，那就更显得这条路是重要的。因此，我们应该尝试把这条路走通，看看其结果怎么样。我们中的很多人，都喜欢探索未知世界的奥秘。在探索未知世界的奥秘的时候，有时可能需要我们具有一定的反叛精神。任何东西都可以怀疑。我们不要被套上一个框框，脑子里面不要有太多的禁区。地球上的生物有多种多样，每一种生物都有其自身的特点和逻辑，都能够生存、发展下去。软件也一样，都是按照其自身固有的逻辑去发展的。
希望我们的开发过程，也能够是 “探索未知世界奥秘” 的一次很好的实践。
http://bbs.znpc.net/viewthread.php?tid=5948&page=2&fromuid=12697#pid45574
netwinxp:
从编程的角度来讲，32位.com是个不错的主意(姑且把它称作32位com格式)，而且也能比较良好地执行DOS的COM(如果没有使用DOS功能调用的话)，不过为了不至于和G4D冲突，可能要解决一些问题:
1、DOS的COM(更确切的说是CP/M的)好解决，只要不调用DOS功能，随便扔给它一个64K段限制一下段寄存器就可以了。(windows执行.com也不需要NTVDM支持)，采用此法最为妥当，不用修改程序就可以重定位。
2、采用类似windows的方法不错，所有程序都可以看成TSR，只是激活程序得想想办法，比如事件驱动。
3、32位程序的话得限制地址范围，既不能与低端的1M和g4d冲突，也不要与高端的硬件占用的内存地址冲突。
不过2和3恐怕得编个专用编译器...
***另外从G4D底层扩展性考虑，最好能采用分层架构(每个层可以根据情况分几个子层，层与层之间要隔绝(现在各部分之间关联太多)，并统一层之间存储函数和参数，建议只留open、close、get、put、post、seek，如不支持部分EAX(AX)返回-1)，大致分为:介质层(比如INT 13、SCSI、ATA、UFI、网卡接口等)、协议层(含分区文件系统层)、文件层，酱紫容易扩展到网络或新的存储介质，比如TFTP、FTP、HTTP甚至是流媒体获取文件。
http://bbs.znpc.net/viewthread.php?tid=5948&page=3&fromuid=12697#pid47018
未初始化的变量，放在叫做 BSS 的内存（进程空间）区域，这些变量在 grub4dos 的可执行程序中并未假定具有 00 之类的初始值，它们的初始值是 “未定义” 的。这些变量的实际存放位置是在asm(".long 0x03051805"); asm(".long 0xBCBAA7BA"); 的后面。编译器中的 get_code_end (参见 asm.S 中的代码) 所得到的代码结尾，包括了 BSS。因此，BSS 的结尾处，也是 malloc 开始分配动态内存的地方。
在开始的时候，grub4dos 为一个进程分配所有的可用空间，因为 grub4dos 根本不知道进程已经具有了多大的 BSS 空间。编程者自己知道进程的 BSS 是在什么地方结束，因为外部程序的编写者可以利用 gcc 的汇编语言中的 $end 常量来了解 BSS 的结尾。
由于 grub4dos 不知道程序使用的 BSS 终止在哪里，所以，grub4dos 在开始的时候只能分配全部内存给程序使用。程序自己需要调整自己所需要的内存的大小。这一点恰恰类似于 DOS 的 .com 程序的情况。
http://bbs.znpc.net/viewthread.php?tid=5873
earthengine的63s-grub工作报告
http://bbs.znpc.net/viewthread.php?tid=5941
讨论下目前grub4的mbr安全性
http://bbs.znpc.net/viewthread.php?tid=4311
关于迷你grub4dos的想法
http://bbs.znpc.net/viewthread.php?tid=4335
测试：迷你版grub4dos

[ 本帖最后由 2011_dihuo0 于 2011-8-3 10:33 编辑 ]

wangziqiang

我来晚了  辛苦了楼主啊啊

135956

楼主辛苦，多谢整理，有你这样的同志，wee会普及得更快。

devilma

辛苦，多谢整理，很不错，方便阅读，希望早日完善