无忧启动论坛

标题: grub4dos-0.4.5b-2011-08-18 [打印本页]

作者: 不点 时间: 2011-8-18 16:19
标题: grub4dos-0.4.5b-2011-08-18
时空被攻击，试试上载这里。

grub4dos-0.4.5b-2011-08-18.7z

264.17 KB, 下载次数: 1079, 下载积分: 无忧币 -2

作者: tingyue-wu 时间: 2011-8-18 16:22
这儿上传没问题已下载

作者: 不点 时间: 2011-8-18 16:34
谢谢。

补上说明：

新版本把 “空格井号” 作为 menu.lst 的行内注释符。

受影%

作者: tingyue-wu 时间: 2011-8-18 16:40
明白多了一种注释功能

作者: 不点 时间: 2011-8-18 16:40
谢谢。

补上说明：

新版本把 “空格井号” 作为 menu.lst 的行内注释符。

受影响的 menu.lst 仅限于那些含有 “空格井号” 这个组合的。

如果你以前的菜单含有 “空格井号” 这个组合，请把它改成 “空格\井号”，也就是，在 “井号” 前用反斜杠来转义，这样就不会当作注释符了。

请测试，看有无问题。如有问题，尽快报告。

作者: zhaohj 时间: 2011-8-18 16:49
行内可以注释了，不用换行了。
call不知是否受影响，如
call :label1 # this is call

作者: 不点 时间: 2011-8-18 17:07
标题: 回复 #6 zhaohj 的帖子
这只是在 menu.lst 读行（read line）的时候解析的。原来只有行首的 # 号当作注释符。现在把行内的 " #" 也当作注释。

读行（read line）函数会忽略从注释符开始到行尾的这部分内容，就像根本不曾存在过一样。

这个注释符起作用的范围是在 menu.lst 中（当然，在预置菜单中也起作用）。

作者: zhaohj 时间: 2011-8-18 17:17
只在预置菜单（menu.lst）中起作用啊？！
那目前用户自定义菜单及P处理中还不起作用，是这样吧。

看来得下一步会考虑全局。

作者: zxw 时间: 2011-8-21 18:12
这个变动会造成很多麻烦。如，在许多脚本或菜单中，有这样的语句：
if #~1==#
if /i #~x1==#.img
如srsf6n、grub4dos工具箱等的脚本和菜单已集成到各pe中。
……
故建议不宜作这个变动。
======================================
想了一下，“ #”的情形也不是很多，变动也没有多大关系。

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

作者: xianglang 时间: 2011-8-21 18:18
原来不是说“ ##”作为行内注释的么，怎么现在又少一个“#”号了？如果是两个“#”，就不至于与现在的脚本中的“ #”相冲突了。

作者: arloan 时间: 2011-8-22 13:28
的确，我也认为这个改动是不合理的。如果真需要行内注释，用 c++/java/c# 的 // 就可以，或者 SQL 的 --
或者楼上说的 ## 都比 # 要好，实现起来无难度，而且也没有副作用，更不影响之前的应用。

作者: yelangpp 时间: 2011-8-23 08:43
8.18貌似有问题，
用8.18的.mbr与grldr制作U盘启动，启动0pe会提示SRS错误，
改为8.9或以前的.mbr与grldr，就OK。

作者: 不点 时间: 2011-8-23 13:17
谢谢报告。

请暂时不要使用这个补丁。而有关注释符的处理，我也不再参与讨论了，由 chenall 等人去处理吧。

作者: chenall 时间: 2011-8-23 20:05
这事不急.目前可以保留现状..

要使用行内注释,我比较习惯用 //

作者: dihuo0 时间: 2011-8-24 14:50
在公开的readme changelog等文件中，#本来就是单行注释符，无论是在行首，还是在行中，都代表注释的开始，这样的例子很多，我们无意之中已经在这样使用了。只是目前这一功能实现的不完整，把#用作行内注释只是把这一功能完整地实现而已。
以前虽然没有禁止在行内把#用作其他功能，但是#用作行内注释符使原有功能最自然的延伸与完善，用户应该很容想到这点的吧。情况同样的还有从批处理引入的;注释符，应当通盘考虑，也一并实现行内注释功能。
grub4dos已经有两种单行注释符了，已经带来了一些混乱，不应当再引入第三种了。

[ 本帖最后由 2011_dihuo0 于 2011-8-24 14:55 编辑 ]

作者: 不点 时间: 2011-8-25 08:37
是的，我也同意 dihuo 的看法。有时候，我们考虑兼容性比较多一些，但有时候却考虑逻辑性多一些。这就是一个权衡问题。

其实，甚至完全可以直接把 # 当作注释符。所付出的代价是，原来菜单中所有的 # 都需要改变。因此采用 “ #” 本来也就是一个权衡的结果。

菜单中固然也可能有 " #"，不过其数量要少很多了。世界上哪有绝对完美的事情？都是某种权衡和变通。

如果把这个问题仓促决定了，比如说，就采用了 // 或者 ##，那这个决定的影响是深远的，一旦采用，那么就意味着今后不可改变了。

所以，如果决定不了，还是不要决定好了。等到将来大家讨论成熟了，意见趋于一致了，再做决定。

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

有了 dihuo 的支持，我甚至认为，现在是 “忍痛割爱” 必须采用 " #" 的时候。Linux 的 shell，Linux 的 asm ，以及 Linux 其他许多脚本中，都大量采用 # 作为注释符。就连 C 语言的预处理程序（无论在 Windows 还是 Linux 中），也有 #if 之类的符号，说明 # 这个符号就是一个广泛使用的特殊符号。所以，不适合把它用作菜单中的一般符号。换句话说，菜单中用它，本来就是不合理的。因此，假如我们采用它作为注释符，也是很自然的，很多人都可以接受的。

符号 # 一般只用于需要把它写入某个字符串的场合，即 write 命令中才可以用它。title 命令行也许会用到它。这两种情况如果有 " #" 这个组合，就直接在中间插入一个反斜杠变成 " \#" 就可以取消注释的作用了。在其他场合，大家应该有意识地避免使用 # 这个符号。

采用 // 和 ## 的缺点：1. 不太自然。除了 C 语言以外，其他常用的脚本语言很少采用 // 注释符。## 更是少见。2. 多占用一个字节。3.程序处理也更繁琐一些。

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

在键盘上找找，可用的符号并不多。列举如下：

~ ! @ # $ % ^ & * ( ) _ - + = ` ' " { } [ ] | \ : ; < > , . ? /

复制代码

我数了数，总共有 32 个。其中，有很多都有别的用途，例如，作运算的加(+)，减(-)，乘(*)，除(/)，乘方(^)，问号冒号（?:用于条件运算），括号，大于，小于，等于，或者（|），而且（&），非（！），引号。而逗号，分号往往也被用于分隔变量或者分隔语句。反斜杠常被用于转义。（微软很讨厌，它把反斜杠用作路径分隔符）。斜杠（/）是除法符号，前面已经提到了。下划线通常当作字母来使用，作为变量名字的一部分。有的还把 ~ 当作“逐位取反”的运算符号。而 % 又是“求余数”运算的符号。* 是乘号，前面提到的。把这些排除掉，剩下的只有 @ # $ 这三个符号了。

看看 $ 这个符号，微软的 BASIC 语言已经把它用作字符串变量的符号了。Linux 的 shell 也用它来表示一个变量。因此，候选者只剩下 @ 和 # 了。只有这两个，似乎较少被用到。也只有这两个，适合作为注释符。微软并不采用这两个中的任何一个作为注释符。那并不意味着，这两个不适合作为注释符。微软用 REM 以及分号作为注释符，这并不是很合理的。而 Linux 已经大量采用了 # 作为注释符，因此，采用 # 是很自然的选择。

[ 本帖最后由不点于 2011-8-25 10:24 编辑 ]

作者: dihuo0 时间: 2011-8-30 14:44

原帖由 chenall 于 2011-8-26 23:11 发表

目前所有GRUB4DOS的接口函数都可以直接在命令行下使用

call #n 的方式来调用,关键是参数要正确,有些函数还需要自己组装参数.

这可能就是不点行内注释补丁出错的原因了，“ #”已经被挪作他用了，看来行内注释只能使用“ ;”了。

作者: zxw 时间: 2011-8-30 15:07
@2011_dihuo0 :
不点行内注释补丁在先，
chenall开发call #n在后。

作者: chenall 时间: 2011-8-30 15:30
这个行内注释号符 " #"打了补丁之后也只有在菜单中才可以使用....

而 call #n的方式一般在批处理中使用,所以没有什么影响.

不过为了以后把行内注释符扩展到任意脚本,下个版版考虑修改一下
call #n
为 call @n的方式

不知有多少人在使用
call #n了?

我自己最早使用算一个..目前是没有什么影响,暂时可以让两者共存.

[ 本帖最后由 chenall 于 2011-8-30 15:33 编辑 ]

作者: 不点 时间: 2011-8-30 18:19
我不知道 chenall 的开发进程，我不了解已经用 call #n 了。

但是，有一点是可以明确的，那就是，# 是一个广泛用于“注释”目的的符号，它不适合用作特殊的用途，例如 call #n 之类的。

我个人觉得，为了 call 而浪费一个特殊符号 @ 也不合适。不如设计一个不使用任何特殊符号的语法（诸如 call addr n 之类的）。

作者: 2011bigbarry 时间: 2011-8-30 19:23
不建议作此改动
不建议作此改动

作者: dihuo0 时间: 2011-8-30 22:04
标题: 回复 #18 zxw 的帖子
抱歉，我最近比较忙，没有注意到。
不过我提一个建议，我感觉grub4dos现在已经发展成一个软件平台了，有很多的软件在使用它，我们是否也应该以软件平台的角度来设计它呢？比如未来可能会加入什么功能？以什么样的形式加入？加入之后是否会原有的功能相冲突？使用起来是否方便自然？
安装部署后，文件结构是什么样的？/boot/目录下应当有哪些目录和文件？外部命令和第三方应用程序是否应该放在别的目录里，比如/boot/bin/？重名的冲突怎么解决，比如sratlf大和zxw大的run目前不方便共存。pe合盘时，pe映像是放在/boot/imgs/，/boot/ADDONS，还是/xppe/，/03pe/， /o7pe/ ，linux放在/linux/？我可否讨论出一个大致的规范，这样grub4dos开发者、第三方开发者、最终的用户都方便自然。

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

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

作者: 不点 时间: 2011-8-31 12:11
标题: 回复 #23 zxw 的帖子
没错，谁也不敢保证 grub4dos 能活几年。

看厂家支持不支持了。

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

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

作者: 不点 时间: 2011-8-31 19:57
我不是悲观，我是在说一种可能性。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 编辑 ]

作者: feiyl 时间: 2011-8-31 21:53
不點的論述非常精綵，贊！

作者: chenall 时间: 2011-9-1 14:53
我还是把call #的调用方法先改成

call FN.xx 的方式

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

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

作者: zxw 时间: 2011-9-1 15:20
个人认为，对于这种特殊方式，以区别于外部命令和标签，还是用个符号为好，将#换为@吧.

作者: zhaohj 时间: 2011-9-1 15:39
call 1.func 这样也比较直观，也一目了然知道是调用内部的功能号。

作者: chenall 时间: 2011-9-1 16:11
标题: 回复 #30 zhaohj 的帖子
前辍处理起来比较简单.后辍不方便.

作者: dihuo0 时间: 2011-9-1 19:16
新增一个命令func如何？语法形式为func NUMBER，NUMBER是调用功能号。

作者: dihuo0 时间: 2011-9-1 19:19
还有一种方法，但是要动大手术了，增加函数调用功能，把这一功能实现为函数func()。

作者: zxw 时间: 2011-9-1 20:18
本来就是函数，写为函数是最合理的。

作者: chenall 时间: 2011-9-1 21:07
新增命令，没有必要。

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

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

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

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

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

作者: hhh333 时间: 2011-9-1 22:15
标题: 回复 #35 chenall 的帖子
我同意这种加点的方式，直观高效！

作者: dihuo0 时间: 2011-9-1 23:25
我又想到几种语法：
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 编辑 ]

作者: chenall 时间: 2011-9-2 08:40
汗，也扯得太远了．．

我还是使用call Fn.xxx吧．

作者: dihuo0 时间: 2011-9-2 09:18
标题: 回复 #39 chenall 的帖子
未雨绸缪嘛，迟早也得加入函数功能，现在讨论一下，到时候也做好准备了。

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

作者: chenall 时间: 2011-9-2 09:31
我还没有明白你所谓的函数功能具体是如何使用的.

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

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

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

作者: 不点 时间: 2011-9-2 10:03
未公开的好处是开发者很自由。只要保持未公开状态，可以任意尝试。未公开的东西，将来都可能变，随时都可能变。

作者: dihuo0 时间: 2011-9-2 12:30
回复 #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 时间: 2011-9-2 16:37
函数形式看起来是比较直观些，不过太浪费代码了．
若是用函数名的方式就更浪费了，需要保存所有要调用的函数名．以后再考虑．

目前还是简单一点好．

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

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

大家觉得呢？

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

作者: wannaknow 时间: 2011-9-2 16:51
标题: 回复 #44 chenall 的帖子
要不 call func# num arg...?
将来还可以添加 call func name arg...

作者: zxw 时间: 2011-9-2 16:57
作为不公开的功能，变数应该还多。目前，就如chenall所说简单处理一下就行了。

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

作者: dihuo0 时间: 2011-9-2 19:17
标题: 回复 #44 chenall 的帖子
我支持call func number arg...形式，
我反对call Fn.xxx arg....的形式主要就是因为破坏了整体语法风格的统一。

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

作者: chenall 时间: 2011-9-2 19:54
新的版本已经上传，删除了相关的信息，这个功作不公开。

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

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

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

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

作者: zxw 时间: 2011-9-3 08:23
回复 #49 chenall 的帖子

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

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

作者: chenall 时间: 2011-9-3 09:11
重新上传了,源码改了几次恢复错了.汗..

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

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