wee的help文件

不点

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

不点

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

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

不点

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

不点

首先就发现拼写有错误：

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

不点

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

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

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

不点

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

不点

我个人觉得，写维基百科的条目确实比较难。看到 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 编辑 ]

不点

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

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

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

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

不点

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

不点

失败不重要，重要的是，从中学到了知识。

失败是成功之母。

在我的印象中，维基百科是相当严肃的。提供资料的人（网络上的任何一个人），可以犯错误，可以侵犯版权。但是维基百科是不可以的。因此，维基百科的检查是十分严厉的。

我平时也经常用到维基百科。发现它确实很严肃，确实很权威。它的权威，表现在它对于词条的解释，是很专业的，是有深度的。

随随便便、胡乱写一个词条，简单复制、拼接，都想通过维基百科的检查，那是没有希望的。

写词条的人，应该用自己的语言以及自己的理解，从此入手，才能贡献一个符合要求的、有价值的词条。

如果全都是复制粘贴，我感觉那是亵渎维基百科，也不可能通过维基百科的严格检查。

[ 本帖最后由 不点 于 2012-5-8 23:21 编辑 ]

不点

在我看来，当然有办法重建。

任何一个人，抱着贡献的态度，按照自己的理解，用自己的话，写一个介绍，就有希望通过版权检查。

按照自己的理解，只要能够让人明白 Wee 是个啥东西就行，不要把它想象得很难。甚至只要有三、五句话都可以的，可长可短，取决于自己对 Wee 的理解。

可以参考 grub4dos 的词条。

不点

没有编写屏蔽回显的代码。你自己可以把源代码拿过来改造。

不点

楼上不是已经说过了吗？没办法，除非修改源代码。