grub4dos-0.4.5b-2011-08-18

不点

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

tingyue-wu

这儿上传没问题 已下载

不点

谢谢。

补上说明：

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

受影%

tingyue-wu

明白 多了一种注释功能

不点

谢谢。

补上说明：

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

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

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

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

zhaohj

行内可以注释了，不用换行了。
call不知是否受影响，如
call :label1 # this is call

不点

这只是在 menu.lst 读行（read line）的时候解析的。原来只有行首的 # 号当作注释符。现在把行内的 " #" 也当作注释。

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

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

zhaohj

只在预置菜单（menu.lst）中起作用啊？！
那目前用户自定义菜单及P处理中还不起作用，是这样吧。

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

zxw

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

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

xianglang

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

arloan

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

yelangpp

8.18貌似有问题，
用8.18的.mbr与grldr制作U盘启动，启动0pe会提示SRS错误，
改为8.9或以前的.mbr与grldr，就OK。

不点

谢谢报告。

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

chenall

这事不急.目前可以保留现状..

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

dihuo0

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

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

不点

是的，我也同意 dihuo 的看法。有时候，我们考虑兼容性比较多一些，但有时候却考虑逻辑性多一些。这就是一个权衡问题。

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

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

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

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

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

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

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

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

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

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

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

复制代码

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

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

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

dihuo0

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

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

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

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

zxw

@2011_dihuo0 :
不点行内注释补丁在先，
chenall开发call #n在后。

chenall

这个行内注释号符 " #"打了补丁之后也只有在菜单中才可以使用....

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

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

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

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

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

不点

我不知道 chenall 的开发进程，我不了解已经用 call #n 了。

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

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

2011bigbarry

不建议作此改动
不建议作此改动

dihuo0

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

zxw

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

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

不点

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

看厂家支持不支持了。

dihuo0

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

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

不点

我不是悲观，我是在说一种可能性。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

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

chenall

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

call FN.xx 的方式

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

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

zxw

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

zhaohj

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