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

不点

module 和 modulenounzip

当 kernel 加载了一个内核后，内核也可能需要某些模块，这时候就可以用上述两条命令了。很少用到。

outline 是图形模式下显示字符笔画的边框。在图形模式下，如果 splashimage 的颜色与字符颜色很接近，则字符就不能看清。有了 outline，给字符加上轮廓，就可以看清字符了。outline 对文本模式不起作用。

不点

@zhaohj:

0x300 是扇区序号。物理地址就是 0x300 * 0x200 = 0x60000 了。

@all

back.xpm.gz 文件有个对应的 8.3 格式的短文件名 backxp~1.gz，这个打开却是正常的。估计问题出在 NTFS 驱动程序内部。chenall 看看能否解决，实在不行，请 bean 来解决。

注意，在 grub 命令行之下，可以比较 FAT32 之下的和 NTFS 之下的内容相同的文件：

cmp (hd0,0)/back.xpm.gz (hd0,7)/back.xpm.gz

还可以用

cat --length=120 (hd0,0)/back.xpm.gz
cat --length=120 (hd0,7)/back.xpm.gz

来比较两个文件开头的差别。

不点

hhh333 因为做出了重大发现，而被授予国家重大诺贝尔科学发现金质奖章。

chenall 你得把这个 bug 解决了。实在解决不了，再求助于 bean。

这次难度系数，向上翻腾8周半，向下翻腾5周半，转体960度。

－－－－－－－－－－－－－－－

根据大家的研究，初步感觉，问题与 gz 无关。那么可能是 ntfs 下小文件访问时容易出现的问题。

因此就要注意， NTFS 支持模块代码中，究竟什么地方与此有关？读小文件的过程，与读大文件的过程有何区别？

只要找到差别，就缩小了范围，再加上一些调试代码，也就比较容易找到问题的根源了。

不点

map /menu (rd) 与 map --mem /menu (rd) 有区别吗??

正如你猜测的那样，没区别。你后来的说法是错的。

(rd) 就在内存了。map /menu (rd) 就是把 /menu 拷贝到内存，并让 (rd) 指向那段内存区域（的开头）。

至于说 menu 的内容采用什么编码，则与 (rd) 和 map 都无关了，menu 只是一个文件罢了。

不点

g4d_off 是个外置的 halt 命令，用来关机的。这是 zw2312914 写的。

如果 grub4dos 内建的 halt 失败了，可以试试 g4d_off 命令。我倒是觉得应该把 g4d_off 改名为 HALT。

不点

应该是 hiddenmenu ，你拼写错了，少了一个 d。

hiddenmenu 只能用于菜单初始化命令中，出现在所有的 title 之前。命令行下不能使用这个命令。

不点

你理解得正确。

菜单初始化命令中不带参数的 configfile 命令，就是用来启动当前根设备下的 /menu.lst 文件的。这是为了兼容以前的处理方式。

如果你不想这样，当然就可以去掉这条命令了，或者也可以添加一个你希望的参数，启动你所指定的 menu 文件。

不点

我也上载了一个叫做 test 的版本。我已经测试过了。经过 chenall 改造后的 NTFS 驱动，好像正常了。

大家再多测试几日，如果没问题，就把 test 版更名为正常发布版。

没想到 chenall 动作如此快速。定位 bug 很精准。我不知道，chenall 是如何想到用 fstest 来试验的。

不点

我也看不太懂 ntfs 的驱动。不过感觉 chenall 的改动是没错的。chenall 就是注释掉了一行代码。仔细想想，这行代码似乎应该注释掉，如果不注释掉，反而觉得有些不自然。

所以，我现在就准备把 test 改成正常的发布版，而对于今天早先发布的那个正常版，就把它加上 old 字样，暂时保留一段时间。

不点

不是，应该是 hiddenmenu --off

我们的参数大多都以两个减号开头，也有一部分参数不带减号。比如，今天新增的 pxe 的参数 nokeep　就不带减号。以前的 dd　命令的参数也不带减号，debug 的参数也不带减号。

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

不点

一个小于 512 字节的文件，是不可以作为 img 来仿真的。

但是，对于 (rd) 的情况，应该放宽限制，因为 (rd) 不是一个虚拟磁盘。

请 chenall 把这个问题也解决吧。这个容易，因为这是我们在 map 命令中施加的限制，只要针对 (rd) 不再限制就行了。

更新：我来解决吧。这个问题应该在 14 日的版本中解决了。请试试看有无问题。

[ 本帖最后由 不点 于 2010-5-14 00:54 编辑 ]

不点

pxe nokeep 是 pxe keep 的反操作。仅仅是把内存中的一个变量的值改变了而已。

pxe unload 则不仅执行 nokeep 的动作，而且执行 unload 的动作。unload 就是卸载 pxe 的环境。

执行 pxe unload 之后，pxe 设备就无法访问了。

pxe nokeep 之后，影响 boot 命令的执行。boot 会顺便执行 pxe unload 的动作。
同样，pxe keep 之后，也影响 boot 命令的执行。此时 boot 当然就不再顺便执行 pxe unload 的动作了。

一旦 pxe unload 被执行，除非重启电脑，否则由 BIOS 所建立的 PXE 环境将不复存在。这就意味着（即使）在进入 DOS 后也无法访问 PXE 服务器上的文件了。

不点

回复 #136 hhh333 的帖子

带不带减号，有规律，也没有规律。设计者愿意怎么设计就怎么设计。比如说，dd 命令的参数，历史以来，就不带减号。如果我们在 grub4dos 中加上减号，反而很另类。Linux 的 tar 命令，其选项可以带一个减号，也可以不带减号，都能承认的。pxe 的操作用很多子命令来实现，如果加上减号，看起来就像是选项了。命令和选项，在人的理解的层面上是有差别的。至于说这个 hiddenmenu --off 为何要加上减号，那是因为 hiddenmenu 原来有一个参数叫做 --silent，我们现在添加一个参数，如果不带减号，那也不符合惯性定律。如果原来没有参数，我们肯定不会为 off 带上减号，因为这看起来很别扭。

有些命令的用法很复杂，命令行中的项目很多，不容易区分选项和文件名等其他对象，这就需要加上减号来区别，例如 map 就是这样一个命令。

也有这种情况，设计为带减号和不带减号都可以。甚至在设计时因为匆忙，来不及仔细考虑，于是就有可能弄错了，把不该带减号的，带了减号，或者反之，把该带减号的，丢掉了减号。这没办法，那就将错就错了。

比如说，root 和 rootnoverify 命令，就不该是两条命令，合为一条更为合理。但这是历史，也只能认可，犯不着为这点小事就重新设计。毕竟兼容性是重要的，大家已经习惯了的，要尊重。

另一个例子。findroot 和 find 的合并，就另当别论了。合并后，findroot 的功能变成 find --set-root 选项的功能了。这是因为，gnu grub 中原来没有 findroot 命令，大家没有形成使用 findroot 的习惯，所以，尽早合并到 find 中，是有好处的，让程序代码的重用率增加了，因此节约了代码空间。

不点

pxe keep 导致死机的问题，看来最终与 grub4dos 启动之初的 BIOS 硬盘和光盘查找过程有关。在 boot land 上有人报告 bug，我们解决了。没想到 pxe 的死机也是由此引起的。谢谢 zhaohj 的及时反馈。这真是一个意外的收获。程序的 “健康” （robust） 是很重要的。看来，0.4.5 在健壮性、兼容性、启动的成功率方面，又要有所提升了。

很抱歉，关于 ud 设备，我还不能做很多事情。坦白地说，我还没有研究过 ud。bean 所开发的几个方面的软件，例如 NTFS 的支持，PXE 的支持，fbinst 以及 ud 设备，我还都不怎么熟悉。这有待今后随着时间的增长，逐步增进了解。我觉得 chenall 在这方面很不错，多加研究，甚至还可以更进一步地改进完善。

每个人都有自己的长处、优势。我的优势是在传统 BIOS 的兼容处理方面。我在编写功能软件方面不强。

不点

问题出来以后，问题的性质、本质，一定要弄清楚，否则就可能发生误读。

虽然我们说，新版本解决了 grub4dos 启动死机的问题，但是，这解决的问题，却不是 grub4dos 的，而是 BIOS 的。本质上讲，并没有发现 grub4dos 在这方面有任何 bug。所做的工作，无非就是减少了对 BIOS 的调用而已。也就是说，注释掉那些 BIOS 调用代码，就不死机了。添加上就又要死机了。而 grub4dos 对于 BIOS 本身的调用格式，那是没问题的，因为这就经过了很多年的检验。

pxe 这个东西，虽然勉强能用，但也不能依靠它来实现载人航天。CDROM这种规范，是微软DOS时代的产物，但微软很快就放弃DOS了。PXE是更晚的规范，与DOS的共存，谁来保障？大家知道，CDROM规范尽管也有毛病，但还不算严重。PXE的BIOS，竟然占用100K数量级的常规内存，可以说是非常成问题的。虽然规范本身不一定要求占用100K，但是，实现PXE的厂家，却这么做了。显然，与CDROM的情况相比，PXE的现实情况是很垃圾的。相同的 PXE 软件环境（例如GRUB4DOS和DOS），在不同的主板下，其结果就可能不同。正如同样一个U盘，插在不同的机器，其结果也不同。

CDROM的软肋是它的规范本身存在固有问题，与硬盘、软盘的兼容存在壁垒。同时，CDROM 设备由于体积的问题而避免不了被淘汰的命运。

PXE 的软肋是它占用了太多的内存，实在只能用“垃圾”来形容了。假如将来有别的技术，一定可以轻松取代 PXE 这种技术的。不过也许等不到那一天，PXE 和整个 BIOS 环境，都已经被彻底淘汰了。

我们不少人都了解 syslinux。syslinux 似乎能够支持访问 http web 服务器的文件。用 syslinux 自己的网络模块，不需要占用 100K 内存，就能实现更加丰富的功能。如果此时再回头看看 BIOS 厂商的 PXE，那“垃圾”二字应该在脑子里立刻出现。我们用 syslinux，应该用它的精华，应该把其精华发扬光大，甚至如果有能力的话，把它的精华移植到 grub4dos 中。

要调和两个、三个不同的软件产品（DOS，GRUB4DOS、PXEBIOS），那可不是一件轻松的事。两个还勉强可以调和（DOS和GRUB4DOS），都属于软件。而PXE则属于硬件层面，而它的设计又不好。很难保证它与另外两个不发生冲突。我们可以在 DOS 和 GRUB4DOS 之间来回切换。但是，如果 PXE 也来搅局，想一帆风顺，恐怕不现实。即使在你的机器上调试通过了，你也不能保证在其他的机器都能通过。

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

不点

哈哈，竟然有人把“成功”说成是“失败”。你成功了居然不知道是成功了。

GRUB4DOS 本来就是依赖 BIOS 来访问移动硬盘以及其他各种设备的。如果 BIOS 有 bug（这种情况比较常见），那么，就无法访问移动硬盘的后部，只能访问，比如说，137G 的空间。

如果不出所料，你的问题就是这样的，因而也根本不是问题。谁还把这当成问题呢？

甚至在某些主板之下，你只有 8G 可以被 BIOS 访问到。那时你一定更加莫名其妙了。还有更糟糕的情况，只有 500M，或者 250M，或者 100M，或者1.44M 能被访问。估计最后这个情况你就要破口骂它了。

不点

对不起，我刚刚查看了 grub.exe 的源代码，发现当通过 grub.exe 启动的时候，PXE 自动屏蔽了。代码如下：

        orb     $0x01, %al                      /* bit0=disable pxe */

因此，无法通过 grub.exe 而再次启动 PXE。

之所以屏蔽掉，是出于安全考虑。有些机器会在这种情况下（在重新激活PXE的时候）死机。

我准备编译一个版本你试试。也只能给你用。

已经上载到 nufans 了，文件名是 grubpxe.exe。

这个版本不再禁止 pxe。

不点

你还不明白什么是 BIOS。

BIOS 是机器主板上的程序。不同的机器，其 BIOS 也不同。

你没听说过？同一个 U 盘，在不同的机器上效果也不同。有的正常启动，有的则死机。这都是机器主板 BIOS 的差别造成的。这与你的机器新旧没关系。即使再过十年、二十年、一百年，BIOS 照样会有 BUG。为什么呢？因为有些 BUG 甚至是故意安排的。最近甚至有报告说，在一些新型机器上，微软的 DOS7+ 无法运行，死机。而 FreeDOS 和 DOS6.22 竟然能够运行，grub4dos 和 syslinux 也能运行。这都属于 BIOS bug 的范畴。

不点

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

不点

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

不点

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 编辑 ]

不点

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 上吧？

不点

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

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

前不久，我们更改了 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 编辑 ]

不点

所以，这也确实是个隐患。毕竟很多人已经认为，查找 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 的情况很讨厌，你不太容易判断一个文件名是否是一个目录。在有些情况下，只要去碰一个目录，就死机了。这简直没辙。文件可以碰，即使是不存在的文件，都可以尝试去打开，只不过会返回失败的消息罢了。但目录不行，只要尝试打开目录，它就死给你看。

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

不点

目前只能运行一条外部命令，只有它退出以后，才能运行另外的外部命令。

WENV 运行 configfile 之后，由于没有返回，所以，认为这条命令没有执行完。

想想有没有办法。

能不能把 wenv 运行的 configfile 命令转化成内部的 configfile 命令？

也就是说，WENV（或者其他外部命令）先退出，退出前做好某些必要的设置工作，然后，由内核检测某个设置，如果发现需要运行某个命令，就在 WENV（或者其他外部命令）退出之后立即运行。这样就解决问题了。

不点

2010DOS622 发表于 2017-1-20 07:49
chenall 你所提供下载地址已经失效

wenv 已经过时，不再使用了。目前的外部命令都不需要 wenv 了。