无忧启动论坛

 找回密码
 注册
搜索
一次装机 终生领工资最纯净的「微PE装机优盘」UEPON大师作品卡瑞飞系统和装机二合一超级U盘
诚聘PE工具开发技术员QQ:1607112133系统gho:最纯净好用系统下载站广告联系 QQ:184822951 微信:wuyouceo
楼主: dihuo0

wee的help文件

    [复制链接]
发表于 2011-7-8 22:26:34 | 显示全部楼层

回复 #19 2011_dihuo0 的帖子

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

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

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

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

使用道具 举报

发表于 2011-7-9 09:04:43 | 显示全部楼层
realmode_run 能否提供一下使用说明?网上也找不到。
回复

使用道具 举报

发表于 2011-7-9 10:30:30 | 显示全部楼层
在 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 编辑 ]
回复

使用道具 举报

发表于 2011-7-9 11:00:22 | 显示全部楼层
终于见到wee命令使用文档了,还有编程接口,对于某些人来说,很强大
回复

使用道具 举报

发表于 2011-7-9 14:44:00 | 显示全部楼层
早上我在时空论坛里找到相关说明了,不过,还没看完,就访问不了了,现在又能打开了。似乎还是无忧这里稳定哦。
回复

使用道具 举报

 楼主| 发表于 2011-7-9 22:04:57 | 显示全部楼层
如果没有什问题。明天我会发到wiki百科上。
回复

使用道具 举报

 楼主| 发表于 2011-7-10 16:39:43 | 显示全部楼层

wee资料汇总

== 历史与发展 ==
=== 缘起 ===
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 编辑 ]
回复

使用道具 举报

发表于 2011-7-10 21:25:37 | 显示全部楼层
我来晚了  辛苦了楼主啊啊
回复

使用道具 举报

发表于 2011-7-12 18:18:34 | 显示全部楼层
楼主辛苦,多谢整理,有你这样的同志,wee会普及得更快。
回复

使用道具 举报

发表于 2011-7-13 04:09:50 | 显示全部楼层
辛苦,多谢整理,很不错,方便阅读,希望早日完善
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|手机版|Archiver|捐助支持本站|无忧启动 ( 闽ICP备05002490号-1 )

闽公网安备 35020302032614号

GMT+8, 2019-3-23 13:23

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表