无忧启动论坛

 找回密码
 注册
搜索
最纯净的「微PE装机优盘」UEPON大师作品系统gho:最纯净好用系统下载站数据恢复、数据保护、视频编辑
Win To Go 极致利器(IXUNCIS固态U盘)无忧启动网成立20周年!广告联系 QQ:184822951 微信:wuyouceo
楼主: chenall

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

[复制链接]
发表于 2010-5-15 19:41:46 | 显示全部楼层

回复 #148 zhaohj 的帖子

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

使用道具 举报

发表于 2010-5-15 22:32:23 | 显示全部楼层
感谢不点大,这样太高兴了,以后版本可以同步了。
回复

使用道具 举报

发表于 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很感冒。
回复

使用道具 举报

发表于 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到内存就会出错的.
回复

使用道具 举报

发表于 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一下。
回复

使用道具 举报

 楼主| 发表于 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:
把输入的字符全部转成大写的
回复

使用道具 举报

发表于 2010-5-19 22:22:43 | 显示全部楼层
感谢C大,这样以后就方便了,最也不用担心输入时大小写问题了。
回复

使用道具 举报

发表于 2010-5-20 00:27:42 | 显示全部楼层

回复 #154 sgw888 的帖子

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

使用道具 举报

发表于 2010-5-20 09:59:40 | 显示全部楼层
问不点大一个题外话,G4D的HDD有grldr.mbr,为何CD没有grldrcd.bin(2KB)。
如果有grldrcd.bin引导文件与版本无关,编辑ISO就方便多了。象WIN2000的启动文件一样。
回复

使用道具 举报

发表于 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 | 显示全部楼层

回复 #159 zhaohj 的帖子

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 上吧?
回复

使用道具 举报

发表于 2010-5-20 15:56:34 | 显示全部楼层
原帖由 hulongzhuo 于 2010-5-20 13:31 发表
要是GRUB的变量,可以传递到DOS,就有质的飞跃了...


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

使用道具 举报

发表于 2010-5-20 16:17:54 | 显示全部楼层
DD用法大概知道了,WRITE是怎么用的?
回复

使用道具 举报

发表于 2010-5-21 11:36:55 | 显示全部楼层
C大,有人报告unifont问题,有空看看
http://bbs.wuyou.net/forum.php?m ... p;page=6#pid1956103
回复

使用道具 举报

发表于 2010-5-21 12:10:32 | 显示全部楼层
C大:
标题栏 title 能否改造一下。
为了美观,菜单中插入了空行及分隔行,数字就不正确了。
title --key 3 [1] WINPE
如果能这样,按3跳到第4个标题栏。
回复

使用道具 举报

发表于 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 编辑 ]
回复

使用道具 举报

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

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

使用道具 举报

发表于 2010-5-23 07:52:06 | 显示全部楼层
这也太容易混淆了,就为了考虑不同的用户使问题变得更复杂了,但为了软件更好的操作,牺牲某一方的利益是值得的.
回复

使用道具 举报

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


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

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

谢谢不点大解释!
回复

使用道具 举报

发表于 2010-5-23 20:37:09 | 显示全部楼层
能不能在打开之前,先判断一下这个是文件还是目录?如果可以判断,我觉得就可以避免了。如果非得舍弃的话,我觉得还是将MENU.LST作为文件比较好,毕竟作为目录用的人不多,而且也是以前的做法了。
回复

使用道具 举报

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


PXE做不到,没属性。不象HDD/FD/CD。
回复

使用道具 举报

 楼主| 发表于 2010-5-24 11:57:13 | 显示全部楼层
已经更新了.
使用menu.lst+menu目录

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

使用道具 举报

发表于 2010-5-24 14:36:55 | 显示全部楼层
谢谢GRUB4DOS这次的重大更新。

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

使用道具 举报

 楼主| 发表于 2010-5-24 16:15:35 | 显示全部楼层
对GRUB4DOS的这一部份我还没有研究过,不好改.

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

使用道具 举报

发表于 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 编辑 ]
回复

使用道具 举报

发表于 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更新月”,所以赶快来反映下,这对我没有什么影响,不过从长远来看似乎这种检测模式更加合理点。
回复

使用道具 举报

发表于 2010-5-25 09:46:29 | 显示全部楼层
grub4dos 2010.05.23 从启动到出现菜单的时间明显较早期的长,明显没有早期的快
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|手机版|Archiver|捐助支持|无忧启动 ( 闽ICP备05002490号-1 )

闽公网安备 35020302032614号

GMT+8, 2021-3-5 16:01

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表