GRUB4DOS更新建议、bug反馈专帖

tuxw

12-06 又出现了引号匹配问题，11-30 正常


这个是11-30的


下面是12-06的

跟以前一样，命令行下正常，批处理不正常

[ 本帖最后由 tuxw 于 2010-12-6 20:56 编辑 ]

tuxw

确认是 12-06 引起的，不一定是引号的问题




整数分区的批处理也不能运行了



11-30运行截图


[ 本帖最后由 tuxw 于 2010-12-6 22:01 编辑 ]

tuxw

insmod/delmod 能否改成
outmod
outmod -i
outmod -u
查看已加载的模块、加载、卸载

最好还能增加一个判断某模块是否加载
outmod wenv，通过返回值判断wenv是否加载

这样在合盘时，不同菜单中跳转时可以判断当前环境

[ 本帖最后由 tuxw 于 2010-12-11 12:45 编辑 ]

tuxw

是否可以直接加载不同版本的同名模？

比如工具1用到了WENV的某个旧版，工具2用到WENV的另一个版本，但对合盘者来说，并不了解工具x所用到的版本，是否可以直接configfile两个工具中的菜单文件？

tuxw

批处理里面，会将WENV字符串截取 ${VAR%%string} 变为 ${VAR%string}，两个%变为一个了

tuxw

应该判断一下，两个%%后面跟的是0-9才作参数替换处理。则一般的替换没有问题，只有替换数字时，才需要多写几个%

tuxw

DOS确实是这样处理的，但明显是一个BUG。比如语句 ehco %% 显然想输出两个%，但它会处理成一个。
从CMD的帮助中也可看出是设计目标不是这样的，因为从来没有哪个帮助里说了批处理需要双写%，只有FOR命令的帮助里才提到“在批处理中使用FOR命令时，指定变量请使用%%VARIABLE ”。
继承用法习惯是重要的，但没有必要固执，非得将它的BUG也承继下来。

WENV check %1==" "，%1为空返回真是BUG。我看到sratlf这样用时，我当时还感到非常奇怪，这样怎么能成功？

这个跟语法没有关系，设计目标本来是这样的：
WENV chekc %1==""  返回真
wENV check %1==" " 返回假，现在这个出BUG了(左右交换则没有这个问题，显然是处理右边引号时出错了)

tuxw

原帖由 chenall 于 2010-12-13 15:37 发表


根据我对批处理的理解,我不认为这是BUG..因为本来就是应该这样处理的.

这个就叫习非成是，习惯了这个用法，它就不是BUG了。
跟老百姓一年一年被加税，几代人都这样交习惯了，觉得本来就应该是这样的一个道理。

tuxw

map 也出问题了，下面是 12-12 和 12-14fix map 同一个文件的截图

[ 本帖最后由 tuxw 于 2010-12-15 00:34 编辑 ]

tuxw

@chenall
可否考虑在 grub4dos 被加载后就自动内置一个变量 ComSpec=builtin(或为空或变量不存在)，默认为内部命令解释器
然后 grub4dos 不认识的命令都交给 shell 执行，这样任一个外部命令都可以将自己注册为 shell，写外部命令菜单时会较方便，中途可以随时更换shell

外部命令子命令和内部命令同名时，内部命令优先，需要执行用外部子命令时不能省略外部命令名
如:
set，不管 CompSpec 是否设置，它是内部命令
wenv set，外部命令
setx，交给 ComSpec 解释

注册 ComSpec 时，它是一个已加载的模块名，不需要路径，即外部命令需要先insmod后才能被注册为命令解释器
外部命令 insmod 后，命令本身被识别为内部命令

==========================================

之所以有这个想法，我想在wee基础上发起一个 MiniG4D 项目，它具有 grldr.mbr 的功能，再加上命令行和Chainloader(可能的话还有configfile)，能控制在63扇区内就再好不过了，其它功能都靠外部命令来扩展，但这个目前还不是我一个人的能力能完成的，所以只能先想想知识储备够了有精力就可以开始。
这个模式看起来有点像grub2，但它不是，grub2目前跟grub4dos并不算兼容，而且它的结构不易控制体积。

目前g4d功能已经很强了，但大家常用的其实就那么几条命令，很多继承下来的命令都没什么用处，杂在里面看代码有点晕，这种模式不利于壮大开发队伍。只有grub4dos有了足够的普及率和影响力，才不怕硬件厂商设置障碍（假定不点的“阴谋论”成立，老实说我想不出硬件厂商这样做的利益点在哪里）

[ 本帖最后由 tuxw 于 2011-5-12 16:41 编辑 ]

tuxw

我的意思是可以让外部命令的子命令直接执行，如 wenv reset 可以直接 reset，这种模式就跟DOS的command.com一样了，用起来方便点

tuxw

我不是说原理，意思是用法外观上，外部命令直接在dos环境下运行

支持这个结构后，以后可以通过不同的解释器来实现某个方向的功能包，比如有可能开发一个外部的图形处理命令集，而并不需要用类似  graphics sub-cmd 这样的结构，只要 insmod 就相当于 grub4dos 多了一些命令。感觉就像DOS的外部命令只要将文件放在 path 下，就可以直用

[ 本帖最后由 tuxw 于 2011-5-12 16:36 编辑 ]

tuxw

批处理参数里 = 当参数分隔符处理的？

今天写个批处理，这样执行始终不正常
ghost.bat -clone,mode=pdump,src=1:1,dst=1:5\t.gho -z2 -sure
进去后=号信息没有了，没法还原命令行了
对这个特定的应用，还有办法恢复，ghost只有几个参数是带＝的，其它情况就没办法恢复了


＝＝＝＝＝＝＝＝
试了下，原来CMD也是这样处理的，这个有点麻烦。目前只有%9以前的参数是处理了＝的，后面的则不会处理
想写个批处理与ghost.exe采用完全相同的语法和参数，转过去不好搞。主要是 -pwd 这个参数处理麻烦些，因为它有可参是带＝号，也有可能没有＝。

[ 本帖最后由 tuxw 于 2011-5-15 13:03 编辑 ]

tuxw

原帖由 chenall 于 2011-5-24 14:52 发表
我考虑了一下，觉得按zhaohj前面的方案也是个不错的选择。
((debug_ori == 3 || debug == 3) && (debug != 4))
debug_ori是执行批处理前的debug值。
即如果在执行批处理前的debug 值等于3或者当前的debug值等于3并且debug的值不等于4的时候才会进入调试模式。

批处理的调试模式比较特殊，应该使用比较高的debug值，比如 debug==99，数值较大取意为最/更详细的输出信息（相当于一个总开关）
一来判断比较简洁，另外其它地方使用debug值影响较小，可以仍然采用 debug > n 或 debug on，可以连续的使用debug值而不必特意跳过 3


cat --locate=\0 ...
我觉得用文本的语法去查找二进制值要求本身就不合理
cat --hex --locate=0x00 ...
用这个语法程序设计上反而好搞一点，充分的利用已有的参数，判断的代码都省了

[ 本帖最后由 tuxw 于 2011-5-26 22:01 编辑 ]

tuxw

原帖由 zhaohj 于 2011-5-25 11:52 发表
下面是动态生成的菜单文件：
帮我看看哪里错了？rd在0x40000 ,大小4K

寻找活动分区的方法不可靠，geometry 的输出信息太长了，一个扇区很悬(增加暂存扇区数，也会受管道缓冲区长度限制)，分区稍微复杂点活动分区又靠后时就会失败
活动分区最多只有4个可能，逐个判断反而更简洁
set ac=
makeactive --status (hd0,0) && set ac=0
makeactive --status (hd0,1) && set ac=1
makeactive --status (hd0,2) && set ac=2
makeactive --status (hd0,3) && set ac=3
if exist ac && echo %ac% ! echo NO ...

或者用外部命令
wenv gpart 0 && if exist GP_G4D_A && wenv echo ${GP_G4D_A} ! echo NO ...

或用原版的wenv
wenv reset ac ]]] for /L %i in (0,1,3) do (call makeactive --status (hd0,%i) ]]& (set ac=%i ; break))

[ 本帖最后由 tuxw 于 2011-5-26 22:32 编辑 ]

tuxw

@chenall
内置变量用什么方式延缓替换？（试过了2个%不成功）

set a=
set a=1 && echo %a%
这样不能显示

我现在只能用wenv来避免
set a=1 && wenv echo ${a}

tuxw

这个不是返回值的问题，而是整命令行被加载时变量就直接替换了
我认为应该先解析命令行，替换到 && 之前，后面的等到命令被执行时再替换，或者支持一种延缓替换的语法

[ 本帖最后由 tuxw 于 2011-5-28 12:51 编辑 ]

tuxw

@chenall
两个内置变量 @root @path 一个后面有/，一个没有
这个是随手写的还是刻意这样的，有什么讲究

另外，批处理标签长度限制是多少？

[ 本帖最后由 tuxw 于 2011-5-30 10:32 编辑 ]

tuxw

if exist (hd0,0)/WINDOWS && echo ok

如果 (hd0,0) 是 FAT 格式，判断会返回假
如果 (hd0,0) 是 NTFS 格式，判断会返回真，它将NTFS上的目录当文件处理了。我试过用 open 函数去打开一个 NTFS 上的目录，函数会成功打开一个长度为 0 的文件

tuxw

将 (bd) 解读为启动设备有很大的误导性，任何时候，(bd)都是当前菜单（没有菜单时它是内置菜单grldr）所在的设备，这样通过(bd)来引用跟当前菜单在同一设备上的文件很方便

在 Grub4Dos 中，要获取“第一启动设备”几乎是不可能完成的任务，虽然在指定环境应用下有些办法，但都有很大的局限性，因为 grldr 也有可能不在“第一启动设备上”。自动搜索grldr提高了启动的“成功率”同时也赠送了一些副作用。

tuxw

原帖由 <i>hhh333</i> 于 2011-6-8 06:36 发表 <a href="http://bbs.wuyou.net/redirect.php?goto=findpost&pid=2250999&ptid=180142" target="_blank"><img src="http://bbs.wuyou.net/images/common/back.gif" border="0" onload="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open(this.src);}" onmousewheel="return imgzoom(this);" alt="" /></a><br /><br />实际上启动到grldr再找真正的“一启”设备，确实是不可能完成的任务，我的目的不是这个，只是希望知道获得控制的grldr所在的设备，也可以说是grldr的“一启”，也即内置菜单所在的位置。当然，将外置菜单内置， ...

这个需求还是自己修改内置菜单好，因为即使Grub4Dos保存了“第一启动设备”，对用户来说它也不是始终有效的，因为用户可能通过map命令改变了磁盘顺序，那原因来保存的设备号就没有意义了（不能通过Grub4Dos保存的设备号去“回初始菜单”），这种情况需要在内置菜单里unmap所有磁盘映射，再通过自己保存的“第一启动设备”回初始菜单。

“回初始菜单”是个比较广泛的需求，如果初始菜单 title 前没有加载大文件到内存这样耗时的应用，一条 reboot 命令是最简单可靠的。

如果确实需要直接回到初始菜单，我一般这样改内置菜单
...
map --unmap=0:0xff
map --rehook
wenv get ?_DEV ]]& (setdev ; setrd)

#初始化
wenv (getdev ; getrd)
...

title 1
...

[ 本帖最后由 tuxw 于 2011-6-9 15:45 编辑 ]

tuxw

因为变量内存空间没有初始化，使用之前调用一次空的set命令即可

tuxw

(bd)的问题就在本帖前面都讨论过很多次了，无非就是一个“第一启动设备的问题”，这是个很实用的需求。
Chenall可以考虑个方案增加一个变量来记录，对于明确用grldr启动的应用，会方便不少。在有新的实现之前，只能通过修改grldr内置菜单来自己记录。

(bd)目前的实现我觉得挺方便，通过合理的组织文件目录，可以用的统一的方式来访问菜单所在设备的文件。比如U盘可能被识别为FDD或HDD时，虽然有其它方法也能判断，但没有（bd）方便。
在多个分区同时存在可用的menu.lst，要命的是它们还有部分文件或目录相同时，第一启动设备相对于目标分区，显然后者更重要。