grub4dos-0.4.5b-2011-08-18

不点

时空被攻击，试试上载这里。

chenall

重新上传了,源码改了几次恢复错了.汗..

现在用GIT来管理源码,还没有熟悉GIT.

zxw

回复 #49 chenall 的帖子


看源码：
++arg;  → arg += 3;

[ 本帖最后由 zxw 于 2011-9-3 08:48 编辑 ]

chenall

新的版本已经上传，删除了相关的信息，这个功作不公开。

只判断前两个字符Fn，所以你可以用如下语法都是合法的（喜欢怎样就就怎么样用）。

call Fn xxx arg....
call Fn.xx arg...
call Fn#xx arg....

一些函数的用法自己上Google查一下C语言相同函数基本差不多，其它的需要对GRUB4DOS核心比较熟悉才懂得使用。

很多函数我也不懂得用，我都是需要用的时候再临时去看相关源代码。

dihuo0

各个内部函数的功能都是什么？能不能详细的解释一下呢？grub4dos.h太过简略了。或者告诉我们如何查找这方面的资料。

dihuo0

我支持call func number arg...形式，
我反对call Fn.xxx  arg....的形式主要就是因为破坏了整体语法风格的统一。

zxw

作为不公开的功能，变数应该还多。目前，就如chenall所说简单处理一下就行了。

[ 本帖最后由 zxw 于 2011-9-2 17:25 编辑 ]

wannaknow

要不 call func# num arg...?
将来还可以添加 call func name arg...

chenall

函数形式看起来是比较直观些，不过太浪费代码了．
若是用函数名的方式就更浪费了，需要保存所有要调用的函数名．以后再考虑．

目前还是简单一点好．

以下两种我倒是觉得后面的比较直观．

call func xxx arg...
call Fn.xxx  arg....

大家觉得呢？

晚上再更新一下，删除更新记录里面的相关信息，不公开．

dihuo0

回复 #41 chenall 的帖子

如果保留命令的形式，我建议采用下面的形式：

原帖由 2011_dihuo0 于 2011-9-1 23:25 发表
4 call func number arg...，此时，func将是保留字，不能再做标签。call可以调用内部命令，func在某种程度上也可以看作为一个命令，增加某个命令之前的一个实验，如果以后确有必要再增加这个命令。
5 call func FunctionName arg...
其中number是功能调用号，FunctionName是内部函数名。

相当于把你的call Fn.xxx中点（.）换成了空格（  ），
比如：把
call #0 "test string: %s." "my test"                   改为：
call func 0 "test string: %s." "my test"，          这时使用的是功能调用号，或者改为：
call func sprintf   "test string: %s." "my test"   这时使用的是函数名。


至于函数的形式，你看看下面的是否可行：

原帖由 2011_dihuo0 于 2011-9-1 23:25 发表
2 call func(number,arg...)，不实现函数功能的，无函数之实，但有函数之形，为以后函数功能的引入打下一个基础。
3 call func(FunctionName,arg...)

利用call命令调用函数func()，第一个参数是功能调号或函数名，后面是参数列表，参数列表arg...就采用你已经使用的形式。
比如：把
call #0 "test string: %s." "my test"                   改为：
call func(0,"test string: %s." "my test")，         这时使用的是功能调用号，或者改为：
call func(sprintf  ,"test string: %s." "my test")  这时使用的是函数名。

这个例子取自ChangeLog_chenall.txt。
这两种形式在某种意义上是等价的。

[ 本帖最后由 2011_dihuo0 于 2011-9-2 15:00 编辑 ]

不点

未公开的好处是开发者很自由。只要保持未公开状态，可以任意尝试。未公开的东西，将来都可能变，随时都可能变。

chenall

我还没有明白你所谓的函数功能具体是如何使用的.

你可否给一个实例供我了解一下．要如何封装？如何调用？

另外这个功能我本来是要作为一个Undocumented Functions来使用的．只是为了方便．

[ 本帖最后由 chenall 于 2011-9-2 09:35 编辑 ]

dihuo0

未雨绸缪嘛，迟早也得加入函数功能，现在讨论一下，到时候也做好准备了。

我反对call fn.xxx的形式主要就是因为破坏了整体语法风格的统一。

chenall

汗，也扯得太远了．．

我还是使用call Fn.xxx吧．

dihuo0

我又想到几种语法：
1 call --func=number arg...，保持与其他命令语法风格上的统一,我反对call fn.xxx的形式主要就是因为破坏了整体语法风格的统一。
2 call func(number,arg...)，不实现函数功能的，无函数之实，但有函数之形，为以后函数功能的引入打下一个基础。
3 call func(FunctionName,arg...)
4 call func number arg...，此时，func将是保留字，不能再做标签。call可以调用内部命令，func在某种程度上也可以看作为一个命令，增加某个命令之前的一个实验，如果以后确有必要再增加这个命令。
5 call func FunctionName arg...
其中number是功能调用号，FunctionName是内部函数名。

[ 本帖最后由 2011_dihuo0 于 2011-9-2 12:31 编辑 ]

hhh333

我同意这种加点的方式，直观高效！

dihuo0

现在有三套方案：
1 给call增加一个新的参数，代码空间占用最少，但是使用不太方便自然。
2 增加一个新的命令func NUMBER，这会占用一定的代码空间，但是更方便自然了。
3 增加函数调用功能，这是一个大工程，这需要统筹兼顾，好好设计一番。
     这一功能实现的难度如何？是否会与已有的功能产生冲突？已有的功能否充分利用新增的功能，如在复合语句中同时使用新旧功能是否方便自然？增加这一功能是否划算？如果实现了函数调用功能，一些以前命令也可以转化为函数，比如read，write等，那么哪些功能适合设计成命令，哪些功能适合设计成函数，这也需要好好统筹一番。
    既然增加了函数调用功能，grub4dos.h中的函数干脆以原本的样子引入，或者稍微修改一下，遮掩最自然了。
    如果这些都能够实现的话，那么就更像一个完整的编程语言了。这也许是grub4dos未来的样子，我们可以好好憧憬一下。

[ 本帖最后由 2011_dihuo0 于 2011-9-1 21:43 编辑 ]

chenall

新增命令，没有必要。

实现为函数？？？？？？？那你要怎么去调用，再写一个命令？？？

这个功能只供开发者使用，所以我觉得还是简单一点好。

我觉得使用call Fn.xxx的方式挺方便的,也直观。

zxw

本来就是函数，写为函数是最合理的。

dihuo0

还有一种方法，但是要动大手术了，增加函数调用功能，把这一功能实现为函数func()。

dihuo0

新增一个命令func如何？语法形式为func NUMBER，NUMBER是调用功能号。

chenall

前辍处理起来比较简单.后辍不方便.

zhaohj

call 1.func 这样也比较直观，也一目了然知道是调用内部的功能号。

zxw

个人认为，对于这种特殊方式，以区别于外部命令和标签，还是用个符号为好，将#换为@吧.

chenall

我还是把call #的调用方法先改成

call FN.xx 的方式

比如直观也不会冲突. FN = Func Number.

大家有没有更好的建议,晚上会上传新的版本.

feiyl

不點的論述非常精綵，贊！

不点

我不是悲观，我是在说一种可能性。grub4dos 是 BIOS 时代的产物，假如 BIOS 时代结束，那么 grub4dos 也就结束了。这就是逻辑学。当然了，这假定 grub4dos 没有跟上 EFI 的步伐的话，否则，另当别论。

其实，微软早就想摆脱旧的东西了。例如，DOS 就是微软想摆脱的，它竭力推 NTFS，给 DOS 制造麻烦。NTFS 也打击了其他一些公司，让他们不那么容易兼容微软。换句话说，就是制造技术壁垒。一个商业公司要保护自己，最好的手段就是制造技术壁垒。我经常与同事中的几个“高手”讨论，我们几个人都认为，win98 很好，只是微软制造的越来越多的不兼容，才迫使我们转向 XP。本来 BOOT.INI 的启动方式就够 “刁难” 了，后来又在 VISTA 中发明了新的启动方法。所有这一切，都是为了打一道 “墙”。

既然 “墙” 很重要，那么，就要设法建立足够 “安全” 的墙。微软只要感到压力，只要觉得有威胁，它就有可能把它的墙 “加固”，或者增加一堵新的墙。

这么多年来，DOS 还没被灭掉。微软几乎用不着 DOS 了，只有制作启动软盘的时候，才用一下。但现在的电脑没有软驱了，所以，实际上已经完全不用 DOS 了。

但微软没有说服硬件制造商取缔 DOS 以及 BIOS，很可能是因为，制造商自己的程序员也需要 DOS 以及 BIOS。当然还可能有别的一系列的原因。

总之，BIOS 没那么容易消失掉。要得让 BIOS 消失掉，必须付出一些代价（可以折算成 “资金”），如果没人肯花费资金付出这代价，那么 BIOS 不会凭空消失的。

另一种方面，微软消灭 BIOS，似乎对于微软来说，并未有什么好处。微软在 EFI 方面，并不占有先天优势。其他系统（开源的 Linux）早就支持 EFI 了。所以，目前微软消灭 BIOS 的理由不充分。只要微软不想消灭 BIOS，那么 BIOS 就还会存在下去。目前，只有微软的系统对于 BIOS 支持良好。Linux 等系统往往卡在 BIOS 上（Linux 倒是想躲过 BIOS，但可惜是很难躲过的，系统启动的时候，就是 BIOS 在控制，而 Linux 总是需要一个引导器的，这个引导器就可能被 BIOS 卡死）。这尤其会让微软对于 BIOS 更 “钟情”。假如微软下定决心把 BIOS 干掉，那可算是一件大事了，从某种意义上说，还可以算是一件大快人心的事，因为混乱不堪的 BIOS 一去不复返了，以前人为制造的 N 多陷阱，也都一起埋葬了，终于不再有那么多麻烦了，世人可以开始全新的生活了。

[ 本帖最后由 不点 于 2011-8-31 23:39 编辑 ]

dihuo0

回复 #24 不点 的帖子
不点兄也这么悲观吗？我反而很乐观。对于EFI规范，由于不同的厂商的实现不同，EFI实现的兼容性未必比传统bios高。而它们一般都会提供对传统bios的兼容支持，我觉得在相当长的一段时间内，grub4dos的生存应该是没问题的。

回复 #23 zxw 的帖子
以chenall大的作品为参照也是一种规范——不成文的规范，但是有时候chenall大自己也忘了，或者有时候chenall大也会犯错，我是希望总结出一套成文的规范，忘了也能看一看提醒一下自己。
这是一个理想化的想法，我希望grub4dos更完美一些。

不点

没错，谁也不敢保证 grub4dos 能活几年。

看厂家支持不支持了。

zxw

你所说的都不是大问题。
1.目前不存在什么第三方应用程序，不外乎就是外部命令和批处理。比如我和sratlf版主的run都可重命名予以共存，放置在任何位置均可。
目前，暂时建议放置在grub4dos默认指定的外部命令目录即(bd)/boot/grub/目录下。
2.关于统一规范之事宜。目前尚不成熟，grub4dos开发者廖廖，也不存在什么第三方应用程序开发者，我只写两句脚本，至少是谈不上的。
所谓规范最多都是以chenall大的作品为参照。不过，目前，我认为大家都这样“参照”，规范自然而然就会形成的。而且，grub4dos的寿命
倒底还有多长，我相信大多数人都没有底，随着EFI的普及进度，民众的接受程序，grub4dos如不能成功转向EFI，逐渐消亡应是早迟的事。

[ 本帖最后由 zxw 于 2011-8-30 22:48 编辑 ]