grub4dos 外部命令 wenv [2010-10-17 ]

不点 · 发表于 2010-5-15 19:41:46

15日我上载了一个版本，为 grub.exe 添加了 --keep-pxe 选项。这样就不再需要一个特别编译的 grubpxe.exe 了。

zhaohj · 发表于 2010-5-15 22:32:23

感谢不点大，这样太高兴了，以后版本可以同步了。

zhaohj · 发表于 2010-5-19 09:19:23

C大，WENV set 命令再加个把小写改成大写的开关，如
WENV set srs=/DRIVERS/srs/a.zip
wenv set srs=$${srs} 得到srs=/DRIVERS/SRS/A.ZIP
考虑到输入时大小写混合GRUB4DOS很感冒。

sgw888 · 发表于 2010-5-19 10:12:43

测试了一下045B的版本, map 小于512字节的文件到 (rd) 时仍然不能成功. chenall给我的回复是,新版的fat 外部命令已经改进,拷贝文件的速度已经提高,先 map 文件到 (rd)再拷贝跟直接拷贝差别不大.

to: zhaohj
SRS_F6光盘SRS_F6目录下的MENU文件应该是用户自定义菜单吧. 为了安全起见,建议直接拷贝吧,不用先map到(rd)再拷贝吧?? 只是一个菜单嘛,又不会太大,如果这个文件小于512字节,先map到内存就会出错的.

zhaohj · 发表于 2010-5-19 10:57:42

原帖由 sgw888 于 2010-5-19 10:12 发表
测试了一下045B的版本, map 小于512字节的文件到 (rd) 时仍然不能成功. chenall给我的回复是,新版的fat 外部命令已经改进,拷贝文件的速度已经提高,先 map 文件到 (rd)再拷贝跟直接拷贝差别不大.

to: zhaoh ...

OK，这个建议不错。干脆都直接拷贝得啦。不过SRS.ZIP好像太大，还是MAP一下。

chenall · 发表于 2010-5-19 19:31:07

试试这个
http://code.google.com/p/grub4do ... ip&can=2&q=
例子：
wenv set a=$u,abcdef
得到a=ABCDEF
wenv set a=$l,abcdEF
得到a=abcdef
wenv set a=$u,$input,Input string:
把输入的字符全部转成大写的

zhaohj · 发表于 2010-5-19 22:22:43

感谢C大，这样以后就方便了，最也不用担心输入时大小写问题了。

不点 · 发表于 2010-5-20 00:27:42

19日终于弄好了 map 一个小文件到 (rd) 的问题。

zhaohj · 发表于 2010-5-20 09:59:40

问不点大一个题外话，G4D的HDD有grldr.mbr，为何CD没有grldrcd.bin（2KB）。
如果有grldrcd.bin引导文件与版本无关，编辑ISO就方便多了。象WIN2000的启动文件一样。

hulongzhuo · 发表于 2010-5-20 13:31:40

要是GRUB的变量,可以传递到DOS,就有质的飞跃了...

不点 · 发表于 2010-5-20 14:30:44

DOS 处于无人维护的状态（包括 FreeDOS在内，也是长期以来几乎没有进展了）。目前主要是以往的 DOS 软件还很丰富，所以，暂时还离不开 DOS。

当其它系统和工具逐渐成熟起来之后，DOS 就有可能真的完成其历史使命。

DOS 长期不开发，导致已有的问题无法解决，新出现的问题（USB 等）又不能适应。

在 BIOS 框架下，DOS 有可能被 grub 系列以及 syslinux 系列所逐步取代。在 EFI 框架下，甚至连目前的 grub4dos 都要淘汰了，dos 也一样不行。所以，DOS 的情况不太乐观。

目前，syslinux 和 grub4dos 都有很强的操作系统功能。syslinux 在网络方面更强，grub4dos 在传统 PC 硬盘本地启动方面更强。syslinux 和 grub4dos 两者的交叉发展也很深入，两者互相吸取长处，开发进展始终都很快。syslinux 和 grub4dos 在操作系统功能方面的增强和发展，客观上就逐步淡化了 DOS 的作用。

－－－－－

grub 与 dos 不是一个系统，因此，严格来说，grub 与 dos 是两张皮，难以融合。不过，grub 与 dos 还算有着比较好的融合了，互操作性比较好。

－－－－－

其实，DOS 是非常关键的。DOS 走到今天这一步，也是历史的安排，是命运的安排。我个人分析，有如下一些关键的因素在内：

1。微软决定放弃 DOS 并逐步放弃以往的所有操作系统，因为利润的驱使，使得微软必须更新操作系统，这样能够获取最大利润。如果像 UNIX 那样，永远与旧的程序兼容，那新的的东西人们就可能不接受了。所以，微软要逼迫人们紧紧跟随微软的步调。虽然大家都在用盗版的 Windows，但是，掌握你家门钥匙的却是微软。不怕你盗，就怕你不盗。这就是微软的高明之处。不盗版的话，微软就没有戏可唱了。

2。微软的 Windows 9x 是一个里程碑，在 DOS 历史上占据决定性的位置。通过 9x 系列，微软淘汰了其他各种 DOS。

3。FreeDOS 不能当作 Windows 9x 的 DOS 来用。这是 FreeDOS 发展的瓶颈。因此之故，FreeDOS 也就不能吸引更多的开发人员投入开发。因为开发人员很聪明，干事情就要讲求“投入产出比”，费了牛劲，如果还是不能与微软最好的产品兼容，那么就不再有人去加入开发了。微软成功地用不兼容手段，间接地葬送了 FreeDOS 的前程。

4。假如 FreeDOS 能够代替微软的 DOS 来与 win9x 兼容，那么情况可能就不是今天这样了。甚至会影响到 ReactOS 这个项目的进展情况。目前，ReactOS 也是不冷不热，进度缓慢。假如 FreeDOS 能够运行 win.com 来启动 win98 的话，那么这就可能鼓舞人们投入精力开发一个类似于 win98 的产品出来，就像 ReactOS 那样。可惜，就差这一点点，其结果也就严重地决定了 FreeDOS 以及 ReactOS 的命运。我认为，那个在现代人看上去并不起眼的 DOS，其实决定着所有这一切的命运。大家可以试问一下自己：如果一个只有 100K 代码的 DOS，其潜藏的秘密都不能被破解，那人们又怎么能破解几个 GB 的 Windows 呢？所以，从这个角度来看，ReactOS 也将是一样的命运。这是符合逻辑的推理。因此我认为，DOS 非常关键。是历史造就了 DOS，又最终毁掉了 DOS。是历史的安排，是命运的安排。

[ 本帖最后由不点于 2010-5-20 15:34 编辑 ]

不点 · 发表于 2010-5-20 14:43:30

G4D的HDD有grldr.mbr，为何CD没有grldrcd.bin（2KB）?
如果有grldrcd.bin引导文件与版本无关，编辑ISO就方便多了。象WIN2000的启动文件一样。

感觉你有一个地方没看透。制作 ISO 的时候，（如果grldr更新了）难道不需要 mkisofs 等来重新生成 ISO ？

ISO 与硬盘和软盘差别太大了。硬盘和软盘，每次只需要 copy 命令更新引导文件就 OK 了。但是，ISO 几时是这样做的？哪次制作 ISO，不是从头用 mkisofs 之类的工具重新生成呢？既然是重新生成，那为何不一起连 grldr 也更新呢？这又不会额外增加操作步骤，只是顺便就把 grldr 更新了。即使存在你所说的 grldrcd.bin，那不照样还是得重新制作整个 ISO？你总不可能把新版的 grldr “拷贝” 到 ISO 上吧？

zhaohj · 发表于 2010-5-20 15:56:34

原帖由 hulongzhuo 于 2010-5-20 13:31 发表
要是GRUB的变量,可以传递到DOS,就有质的飞跃了...

自从有了dd、write命令，传递变量就简单了。问题的关键是看你怎么应用了。

hulongzhuo · 发表于 2010-5-20 16:17:54

DD用法大概知道了,WRITE是怎么用的?

zhaohj · 发表于 2010-5-21 11:36:55

C大，有人报告unifont问题，有空看看
http://bbs.wuyou.net/forum.php?m ... p;page=6#pid1956103

zhaohj · 发表于 2010-5-21 12:10:32

C大：
标题栏 title 能否改造一下。
为了美观，菜单中插入了空行及分隔行，数字就不正确了。
title --key 3 [1] WINPE
如果能这样，按3跳到第4个标题栏。

zhaohj · 发表于 2010-5-22 08:54:57

让不点批评啦，呵呵。为了兼容性考虑就保持原状吧。

不点 · 发表于 2010-5-22 10:15:10

现实世界中有许多矛盾、冲突。有时候需要这样，有时候需要那样。需求不同，导致的开发方向也不同。有时候，照顾了这个，就要损坏另外一个，这就是冲突，需要平衡，需要权衡。世界上没有完全一致的东西。世界到处充满着矛盾。如果不去解决矛盾，那么我们的软件将止步不前。如果去解决矛盾，则有可能造成新的冲突。那么我们制造的新的冲突，是否在可接受的范围之内呢？换句话说，我们是否值得为了某项新功能就损坏现有的另一方面的功能呢？通过仔细分析，一定能找到一个平衡点。

一个活生生的例子就刚刚发生在昨天。

前不久，我们更改了 PXE 启动时查找配置文件算法，首先查找的是 /menu.lst。这个应该算是完美了。但是，有人报告 bug，说此时死机了。原来，当存在 /menu.lst 文件夹 的时候，如果把 /menu.lst 当作普通文件来打开，这在某些环境下就要死机。

这个问题出现之后，按照符合逻辑的方式，应该是保持 /menu.lst 的普通文件属性，而把 /menu.lst 文件夹改名为 /menu （不带扩展名）。然而我们以往一直把 /menu.lst 作为文件夹来处理，所以，我们为了照顾以往的开发者和用户，不能随便把 /menu.lst 更改为 /menu。于是，就被迫把 /menu.lst 普通文件改成了 /main.lst。虽然逻辑上有些别扭，但照顾了实际情况。

所以，世界是不完美的。当初老天爷要是让我们选用 /menu 这个文件夹名字，我们今天就不会出现这样的麻烦了。所以，现实与理想，就是不一致的，不可能做到完全的一致。

[ 本帖最后由不点于 2010-5-22 10:34 编辑 ]

zhaohj · 发表于 2010-5-23 01:48:11

刚理解只对PXE，但带来了新问题。
从使用者多数而言，保留MENU.LST文件的一致性比较好，也做到了启动盘的统一。
使用PXE的人，建MENU.LST目录的总是少数。

有一点我不理解，MENU.LST目录和MENU.LST文件是不能同时存在的，新版PXE启动是先搜索MENU.LST文件，没有再搜索MENU.LST目录下的菜单，怎么会冲突呢？我表示怀疑。
以前我总是MENU.LST目录下建菜单名default，现在先搜索\MENU.LST速度快很多，就删除了MENU.LST目录。

[ 本帖最后由 zhaohj 于 2010-5-23 01:57 编辑 ]

不点 · 发表于 2010-5-23 02:16:49

所以，这也确实是个隐患。毕竟很多人已经认为，查找 menu.lst 文件是理所当然的。

如果改成 main.lst ，后续更多的质疑也会出现。

所以，很难平衡。

现在有两种选择，一种是

menu.lst 文件 + menu 目录

一种是

main.lst 文件＋ menu.lst 目录

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

有一点我不理解，MENU.LST目录和MENU.LST文件是不能同时存在的，新版PXE启动是先搜索MENU.LST文件，没有再搜索MENU.LST目录下的菜单，怎么会冲突呢？我表示怀疑。

看来你真的没明白。对于你来说，你有了 menu.lst 文件，当然就不会再有 menu.lst 目录了。但是，对于习惯了以前的操作方式的人，他们存在的是 menu.lst 目录。

此时，我们的代码照样先尝试打开 menu.lst 文件。这一尝试，就死机了，因为用户的服务器上是一个 menu.lst 目录。

而如果不是尝试打开 menu.lst 而是别的任何一个普通文件（例如main.lst），只要不存在相应的同名目录，就不会死机。

奥妙就在这里。

PXE 的情况很讨厌，你不太容易判断一个文件名是否是一个目录。在有些情况下，只要去碰一个目录，就死机了。这简直没辙。文件可以碰，即使是不存在的文件，都可以尝试去打开，只不过会返回失败的消息罢了。但目录不行，只要尝试打开目录，它就死给你看。

你可能说了，我这里怎么弄都没事，不存在问题。但是，这里是别人的情况，是别人报告的问题。不仅要照顾你，还得照顾别人。他的环境与你的不同。

hulongzhuo · 发表于 2010-5-23 07:52:06

这也太容易混淆了,就为了考虑不同的用户使问题变得更复杂了,但为了软件更好的操作,牺牲某一方的利益是值得的.

zhaohj · 发表于 2010-5-23 12:48:42

原帖由不点于 2010-5-23 02:16 发表
此时，我们的代码照样先尝试打开 menu.lst 文件。这一尝试，就死机了，因为用户的服务器上是一个 menu.lst 目录。

我理解了，PXE有特殊性。程序先尝试打开 menu.lst 文件，而这个文件不存在而menu.lst 目录存在就麻烦出来了。

PXE有特殊性，无法判断这个menu.lst 是文件还是目录。

谢谢不点大解释！

xianglang · 发表于 2010-5-23 20:37:09

能不能在打开之前，先判断一下这个是文件还是目录？如果可以判断，我觉得就可以避免了。如果非得舍弃的话，我觉得还是将MENU.LST作为文件比较好，毕竟作为目录用的人不多，而且也是以前的做法了。

zhaohj · 发表于 2010-5-24 07:17:13

原帖由 xianglang 于 2010-5-23 20:37 发表
能不能在打开之前，先判断一下这个是文件还是目录？如果可以判断，我觉得就可以避免了。如果非得舍弃的话，我觉得还是将MENU.LST作为文件比较好，毕竟作为目录用的人不多，而且也是以前的做法了。

PXE做不到，没属性。不象HDD/FD/CD。

chenall · 发表于 2010-5-24 11:57:13

已经更新了．
使用menu.lst+menu目录

以前如果使用menu.lst目录的记得修改成menu，否则可能会死机．

zhaohj · 发表于 2010-5-24 14:36:55

谢谢GRUB4DOS这次的重大更新。

请教C大：最近有个想法关于文件和目录的显示，FAT dir 的FAT命令这个显示方式不错，但目前不支持非FAT的类型；ls命令看看能不能改造一下，至少不像现在的紧凑方式显示，或象DOS的dir/w显示方式也可。如: ls [--w] [FILE_OR_DIR] ,--w代表宽行显示。最好有按文件字母排序的显示。

chenall · 发表于 2010-5-24 16:15:35

对GRUB4DOS的这一部份我还没有研究过，不好改．

看看有没有其它人对这个感兴趣的，帮助改一下再提交补丁。^_^

33445566 · 发表于 2010-5-24 21:04:28

原帖由 chenall 于 2010-5-24 11:57 发表
已经更新了．
使用menu.lst+menu目录

以前如果使用menu.lst目录的记得修改成menu，否则可能会死机．

网启时：grldr中的menu目录和/menu.lst可以改名吗？若可以，怎么改？

[ 本帖最后由 33445566 于 2010-5-24 21:05 编辑 ]

liuzhaoyzz · 发表于 2010-5-25 09:26:42

不点，chenall，我今天在外面，突然想起了一个问题，我提个关于PXE的合理化建议。2010.5.23日更新之后，grub4dos查找菜单的顺序是menu.lst→MAC&IP→menu\default，结合本地的menu.lst，可能有两种情况：
1、本地和PXE采用同一个menu.lst菜单，本地的(hd),(ud),(cd)放在一个title里面，网络的(pd)放在里外一个title里面，而如果精通grub4dos的高级技巧，你甚至可以把本地和网络统一在一个title里面。这种情况没有问题。
2、另外一种，本地采用放在某个目录的（比如说boot）menu.lst菜单，网络直接采用menu\default菜单，这时候菜单查找的顺序又回到了以前速度较慢的那种模式，先找MAC&IP，找不到再找menu\default，事实上，可能没有多少人用MAC或者IP作为菜单名字，只是为了保持兼容才保留。
因此，我觉得是不是可以把查找菜单的顺序改成menu.lst→menu\default→MAC&IP？我在外面，没有具体测试过，自从2010.5.2日之后我一直是采用的menu.lst,删除了menu.lst\default目录及文件了。我怕错过了“grub4dos的PXE更新月”，所以赶快来反映下，这对我没有什么影响，不过从长远来看似乎这种检测模式更加合理点。

33445566 · 发表于 2010-5-25 09:46:29

grub4dos 2010.05.23 从启动到出现菜单的时间明显较早期的长，明显没有早期的快

		自动登录	找回密码
密码			注册

grub4dos 外部命令 wenv [2010-10-17 ]

回复 #148 zhaohj 的帖子

回复 #154 sgw888 的帖子

回复 #159 zhaohj 的帖子