无忧启动论坛

标题: 有没有必要让 uppermem 命令复活？ [打印本页]

作者: blank007 时间: 2021-9-6 15:13
标题: 有没有必要让 uppermem 命令复活？
在 GNU Grub 0.97 时代，基本上也就是MSDOS时代，如果系统内存超过一定的大小，比如，超过2G时，使用 SYSLinux 的 memdisk ，按命令：

kernel /grub/memdisk c=256 h=4  s=36 floppy
initrd  /grub/msdos.zip
那么，这个操作会失败。

如果按命令：

uppermem 65536 (大致数字。因为年代久远，记不清了)
kernel /grub/memdisk c=256 h=4  s=36 floppy
initrd  /grub/msdos.zip

这样操作就正常了。

现在，到了 grub4dso 0.4.6a 时代，大部分计算机的内存都超过了2G，如果按照:

  kernel /grub/memdisk c=256 h=4  s=36 floppy
initrd  /grub/msdos.zip

操作，可以顺利进入DOS系统，但也会出现一些问题。比如，容易死机、鼠标失灵。总之会有一些问题。

那么，如果 uppermem 命令复活，会不会解决这些问题？虽然现在连基于 NT5.X的 WinPE 都不一定在新机器上运行了，但对一些老机器，DOS也有一些用途。

请各位大神开示！

作者: scq330 时间: 2021-9-6 15:53
我这个dos用大于3g的内存，好多软件就不能正常运行了，用1g就可以

作者: plusv 时间: 2021-9-6 19:44

scq330 发表于 2021-9-6 15:53
我这个dos用大于3g的内存，好多软件就不能正常运行了，用1g就可以

PC 即将进入拥有 TB RAM 的时代(DDR 5 512GB 单条),
在那 DOS 恐龙年代,
打死都没想过会有这种可能.

作者: scq330 时间: 2021-9-6 21:09

plusv 发表于 2021-9-6 19:44
PC 即将进入拥有 TB RAM 的时代(DDR 5 512GB 单条),
在那 DOS 恐龙年代,
打死都没想过会有这种可能.

用d5内存的机器，我这些软件无法使用了。。。只能用二手机了。

作者: 不点 时间: 2021-9-7 00:23
非常古老的问题了，现在还有这闲情雅致？

要想让内存变大，这不可能。但要变小，则毫无困难。

用一条map 命令把一个大的 img 文件映射到内存盘上，比如，--mem 映射到 (fd17) 上，意思是不用这个盘符，随便选个数字当盘符，只要不影响正常盘符就行。它占用的内存，就相当于消耗掉了。

比如说，你有 3G 内存，想让它减少到 1G 内存。你就用一个 2G 的 img 加载到内存盘上，这样，可用的内存就只剩下 1G 了。

当然了，map 命令有个参数，使得你不必真的加载一个文件，而只需加载一个内存中的扇区，用参数控制预留的扇区数，让它预留 2G 那么多，就可以了。这样，瞬间就完成了。

作者: junyee 时间: 2021-9-7 07:49

plusv 发表于 2021-9-6 19:44
PC 即将进入拥有 TB RAM 的时代(DDR 5 512GB 单条),
在那 DOS 恐龙年代,
打死都没想过会有这种可能.

资本家不会让普通消费者轻松拥有大内存的.

一般来看,内存每提升一代,主流内存大小是上一代的1-4倍.

硬盘也有近20TB的, 但应该不会是主流.

作者: 不点 时间: 2021-9-7 16:06
标题: I
本帖最后由不点于 2021-9-7 20:21 编辑

补充一下，印象中，这个命令好像是我删除的。有的命令或功能是因为用处不大而删除，有的命令或功能是因为存在问题无法解决而删除。精简了以后，grub4dos 才可能增加新功能。否则，早就出现内存冲突，无法使用了。

再有一点要说明。bios 是处于淘汰的状态，不要指望 bios 能够正常运转。dos 严重依赖 bios，所以，dos 的失败，那是意料之中的。昨天的 dos 可能好好的，今天就可能会失败。因为 bios 可能偷偷更新了。你要是想猜测问题出在哪里，通常在没人帮忙的情况下，估计会累死，很难猜得到。不一定是内存方面的问题。大量的问题出在 int xx 的调用上。你很难知道究竟是哪个中断调用不被支持了（或者被故意破坏掉了）。

dos、bios，以及 grub4dos for bios，这都要进入博物馆了，谁还去调试它？

DOS 出了问题，难以确定问题在什么地方。不要想当然地判定，问题一定在你认为的那个地方。出问题的地方太多，可能性太多，所以，难以定位。

这是生产厂家、垄断控制者共同决定了的。你作为用户，你是没有决定权的，或者说是没有发言权也一样。

他们不想让你继续使用，你偏要继续使用。你这本质上是在跟他们作对，与他们的目的和要求相冲突。

那么，出了问题，那是你的不对咯！是你错误在先，然后才有问题的咯！你不犯错在先，那就不会有问题咯。应该这样理解吧？

所以我说，看问题，要看本质。这就是本质，一下子就说到根本点了。

好了，有人说了：“我知道本质上是我的错误，我知道我不该与厂家怼着干，但我还是想让某某方案能够变通，能够顺利运行。”——嗯，这是可以的。

也就是说，你首先得承认是你自己有问题，然后，你想寻求一种 workaround，一种妥协的方案。你应该明白，成功了值得庆贺，失败了也在情理之中，因此，你就不会要求太高，你就不会有过分的要求，你就不会有非分的要求了。

尽量不要给 yaya 增加工作量，尽量不要给 yaya 找事，尽量不要给 yaya 制造麻烦，尽量不要突然蹦出来一个问题让 yaya 必须去面对，尽量不要分散 yaya 的精力。让 yaya 自由地去做他自己愿意做的事。

尽量不要在那些 “意义不大” 或 “完全没有价值” 的方面，给 yaya 增加工作量。

作者: 不点 时间: 2021-11-28 07:32
昨天 liuzhaoyzz 版主提出让 grub4dos 支持 grub2 的 loopback 命令。

今天，我想到了这个帖子，就找到这里了。

当然，liuzhaoyzz 版主所提的问题，没有限定在 legacy bios。但我的回答，都是限于 legacy bios 层面的，不涉及 UEFI，因为我目前不怎么接触 UEFI 的电脑。

楼主所说的 uppermem 命令，是通过 int15 接口，让内存减小。有些操作系统，只能在低内存运行，不支持大内存，win98 就只能支持 1G 或 2G 内存（具体数字记不清楚了），而在更大的内存下无法启动进入桌面。前面说了，用 map 的办法可以达到同样的目的。

今天想说的是，一个多年以前被删除的命令，在当时最可能有人反对的时候，都没人反对，而如今却有人对此产生疑问了。知道这条命令的人不多，楼主是高手。能来到此处提问，也是缘分吧。

楼主仍然可以找到很老的 gnu grub 0.97，可以试试 uppermem 命令究竟能否解决楼主所遇到的问题。我猜根本解决不了，因为所描述的故障就不是这个方向。如果担心 gnu grub 0.97 难以启动成功，那可以找早期的 grub4dos，那时候还没删掉这条命令。果真能证明 uppermem 有效，而前面提到的 map 方法无效，那就可以让 yaya 把这条命令恢复出来。虽然这么多年过去了，也没人使用这条命令，不等于说这条命令完全可以被删除。你只要能证明它不可取代，我想，那就有理由让 yaya 把它恢复出来，或者以某种新的方式再实现一条具有同样功能的命令，或者考虑到要节约内存，可以在现有的某个命令中增加参数来实现。

作者: blank007 时间: 2021-11-28 18:32
GNU Grub 0.97 再也找不到了。

看了历史记录，grub4dos 0.4.4 2007-12-14 及之前的版本才有 uppermem 命令，也找不到了。

作者: 不点 时间: 2021-11-28 19:20

blank007 发表于 2021-11-28 18:32
GNU Grub 0.97 再也找不到了。

看了历史记录，grub4dos 0.4.4 2007-12-14 及之前的版本才有 upperme ...

为您找到 grub 0.97 的镜像项目：

https://github.com/jezze/grub-legacy

作者: 不点 时间: 2021-11-28 19:29
为您找到一个早期 grub4dos 的站点，是维护者 bean 建立的。

https://sourceforge.net/projects/grub4dos/files/GRUB4DOS/

作者: wintoflash 时间: 2021-11-28 19:58

blank007 发表于 2021-11-28 18:32
GNU Grub 0.97 再也找不到了。

看了历史记录，grub4dos 0.4.4 2007-12-14 及之前的版本才有 upperme ...

http://git.savannah.gnu.org/cgit/grub.git/log/?h=grub-legacy

作者: blank007 时间: 2021-11-28 21:36
先谢过各位大侠的热忱指导！

楼上两位大侠说的地方都是源码。

我在这里找到了一个有成品的。看日期还是今年 8月的。

经过初步测试，里面有 uppermem 命令。但无论是否执行 uppermem 65536 命令，效果似乎和 grub4dos 0.4.6 对 Msdos 的一些程序都差不多，尤其是对保护模式的程序：死机、或者退出。

下面是下载地址：

Debian -- 在 sid 中的 grub-legacy 软件包详细信息
https://packages.debian.org/sid/grub-legacy
.deb 文件解包后，所有需要的文件在 \usr\lib\grub\i386-pc下.

我是在 grub4dos 0.4.6a 下使用如下命令调用它的：
chainloader --force --load-segment=0 --load-offset=0x8000 --boot-cs=0 --boot-ip=0x8200 /boot/grub/stage2.bin

这里。把 grub 的 stage2 改名为 stage2.bin 了。不然grub4dos 不认它。
-
另外，在它里面执行 root (hd0,3)，它把我优盘上的fat32认成了fat。如果不使用 root (hd0,3) ，它就不能 configfile 其它菜单文件，说是不能mount设备。我的优盘只有一个分区，使用 ultraiso 写成 usb-zip+ v2 模式。

硬盘上的 ntfs 分区也说是未知的分区。

作者: blank007 时间: 2021-11-28 21:39

不点发表于 2021-11-28 19:29
为您找到一个早期 grub4dos 的站点，是维护者 bean 建立的。

https://sourceforge.net/projects/grub4do ...

我再看看这里。

作者: 不点 时间: 2021-11-28 21:53

无论是否执行 uppermem 65536 命令，效果...... ：死机、或者退出。

这不就有结论了吗？等于说 uppermem 命令是无效的。

说明问题不在这里。

感谢您辛苦测试，给我们带来了结果，和认识。

作者: blank007 时间: 2021-11-28 22:04
本帖最后由 blank007 于 2021-11-28 22:07 编辑

不点发表于 2021-11-28 19:29
为您找到一个早期 grub4dos 的站点，是维护者 bean 建立的。

https://sourceforge.net/projects/grub4do ...

用这个版本试了，结果很相似：

uppermem 65536

之后，启动dos,用mem查看，内存都是8位数的字节。

但也有差别：
,
使用 0.97 后，diskgenius 4.3 dos 版直接死机。用 grub4dos 9.4.3 , diskgen 4.3 dos 版正常运行。

pqdi2002 的 dos版， 0.97 环境下，直接死机。grub4dos 0.4.3 下卡死。
补充：还没有直接使用 grub4dos 0.4.3 启动 dos 镜像。是用 grub4dos 0.4.6a 启动 grub4dos 0.4.3 后，再启动dos镜像的。

作者: blank007 时间: 2021-11-28 22:19
再补充一小点，实际过程更复杂：启动过程，xorboot(BIOS版)→grub4dos 0.4.6a→grub4dos 0.4.3→uppermem 65536→msdos

作者: 不点 时间: 2021-11-29 05:42
谢谢 blank007 的测试。早都遗忘了的命令，您还能记得，应该是 grub4dos 的早期支持者。向您表示深深敬意！

首先，我多年来一直对 bug 高度重视，从未有丝毫懈怠。所以，首要的问题是确定，是否不该删除 uppermem 命令。如果不该删除而删除了，那就是 bug，必须修复 bug。根据您的描述，uppermem 未能起到作用，说明这个问题有了答案，不用恢复 uppermem 命令了。

其次，是要尽力帮您解决在启动 dos 的 img 方面遇到的问题，尤其是，当我发现您是早期支持者时，更感到不可懈怠！

接下来，我们不再讨论 uppermem 问题了，而是着力解决您的具体问题。我们也不要使用 uppermem 命令了，这是尽量避免它可能带来的不确定因素，导致新问题的产生。

首先，启动 DOS 的 img，有两种方式：

1、用 memdisk，就是您提到的方式。这个方式完全不采用 grub4dos 的仿真代码，仿真是由 memdisk 来完成的。

2、用 grub4dos 内置的仿真代码。grub4dos 有很多版本，您首先使用最新的 0.4.6a 系列来测试，如果失败，再用 0.4.5c 的最后一次发布来测试。如果仍然失败，而您还不死心，可以选几个更早期的 grub4dos 来试验。

测试的命令序列大致是这样的：

map --mem /grub/msdos.img (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
boot

注意 map 命令可能不支持 zip 格式的压缩文件。您需要先解压 zip，生成原始的 img 文件。

另外，map 支持 gz 格式的压缩文件，新版还支持 lzma 等格式的压缩文件。如果您实在想用压缩的 img 文件，建议用 gz 格式，这样旧版也能支持。

好的，您就先用上述两种方式分别进行测试，看看会不会有什么差别。

作者: 不点 时间: 2021-11-29 06:07

可以顺利进入DOS系统，但也会出现一些问题。比如，容易死机、鼠标失灵。总之会有一些问题。

死机、鼠标失灵。

看到鼠标，我想说，鼠标不仅是失灵的问题，而是还可能会导致死机的问题。

鼠标驱动难以做好。尤其是，新的硬件不一定支持 DOS 的鼠标驱动。

建议您去掉鼠标驱动，轻装上阵，卸载包袱，才能成功。

如果实在想用鼠标驱动的话，那我建议您试试 dosbox，这是个非常强大的 DOS 仿真工具，能够运行在 Windows 的各个系列，包括 64 位架构，也能运行在各种不同架构的 Linux 下。dosbox 使用虚拟的硬件，这有个好处就是，不受真实硬件升级换代所带来的不兼容性的影响，因此，大大提高了成功率。

我猜，也许，这正是您这个问题的症结所在。

如果您是想玩 DOS 游戏，那么 dosbox 就是最好的方案了。

作者: 不点 时间: 2021-11-29 06:21

blank007 发表于 2021-11-28 22:19
再补充一小点，实际过程更复杂：启动过程，xorboot(BIOS版)→grub4dos 0.4.6a→grub4dos 0.4.3→uppermem ...

这不行。xorboot 有可能带来影响。测试过程中，请尽量直接使用 grub4dos，不要在前面插入未知步骤。测试完了之后，您随便，爱用啥用啥。

grub4dos 的开发过程中，在 grub4dos 之前插入 ntldr 和 bootmgr 是测试过的，也是 grub4dos 官方文档明确支持的。也就是说，您可以放心地用 ntldr 和 bootmgr 来启动 grub4dos。但是，grub4dos 的开发者从未测试过 xorboot 下的情况。那么，由此带来的变数，grub4dos 的开发者是回答不了的，一般都是拒绝回答。

万一 xorboot 带来了影响，而您很晚才发现这一点，那您辛苦的测试，都白做了。

作者: blank007 时间: 2021-11-29 06:43
昨晚是匆忙之间做的有限测试。还没有更改优盘格式。首先，优盘用ultraiso 做成 udb-zip+ v2 模式，分区引导记录是 xotboot BIOS 版。先调用 grub4dos 0.4.6,。再用 0.46a 调用 0.43 或0.97。dos是约 5M 的镜像，用winimage制作。

作者: 不点 时间: 2021-11-29 07:07

diskgenius 4.3 dos 版，直接死机。pqdi2002 的 dos版，直接死机。

img 里面的 DOS，是 MSDOS，还是 FreeDOS？这是有差别的。FreeDOS 不太稳定，在扩展内存处理方面有 bug。很多程序都会使用扩展内存，这就可能出问题了。

其次，MSDOS 的版本，也有差异。请尽量使用 Win98se 里面的 DOS。

config.sys 里面，去掉那些导致死机的驻留程序，那就彻底无忧了。

比如，鼠标驱动，它不稳定，就去掉它。虽然没有鼠标很难受，但与死机比起来，还是去掉它更划算。

去掉中文模块，如果它导致其他软件死机的话。

可以试试保持 config.sys 是空的，不使用扩展内存。

可以找找别人的 config.sys，或查阅资料，看看如何填写与扩展内存相关的命令。

作者: 不点 时间: 2021-11-29 07:42
在 chenall 的站点上，保存了我的一个根据 cute mouse 改编的鼠标驱动。当初的目的，是作为 grub4dos 的外部命令来运行。您可以把它当作 DOS 的命令来运行，取代 DOS 下的其他鼠标驱动。如果您觉得原始的 cute mouse 更可靠，您也可以找原始的 cute mouse，说不定它可能还有新版提供呢。

不一定能成功，但试试也无妨。

https://github.com/chenall/grubutils/blob/master/grubutils/wee/utils/weemouse.asm

这是源代码，您需要编译它。注释里面含有编译的说明。

作者: 不点 时间: 2021-11-29 07:47

blank007 发表于 2021-11-29 06:43
昨晚是匆忙之间做的有限测试。还没有更改优盘格式。首先，优盘用ultraiso 做成 udb-zip+ v2 模式，分区引导 ...

不要用 WinImage，以前就有报告，它制作出来的 img 文件（DOS盘镜像文件）是含有扇区错误的，也就是说，不可用。

请用 imdisk 重新制作您的 img，或者，用 Linux 下的工具也行，如果有的话。

作者: blank007 时间: 2021-11-29 21:28
最终测试结果

经过各位大侠的指点和帮助，以及自己的一些努力，终于得到了确实的结果。下面就做个汇报。

一、测试环境：

2009年左右的上网本，内存2G，CPU都是ATOM，硬盘 160G/256G。一为神舟小本、一为联想小本（固态硬盘）。分区格式：ext2/ext3/ntfs/fat/fat32。
去年出的神舟优雅x4，内存8G，固态硬盘512G，分区GPT ,安装 win 10 x64。

几个优盘。

软件：Qemu x86 /x64 ，GNU Grub 0.95 /0.97 ，grub4dos 0.4.6a (2021-11-19)。memdisk 6.03。
      ultraiso 、WinImage （制作软盘镜像）、grubinst 1.4 (安装 grub4dos)

二、测试过程

在上网本的环境下(内存2G)，安装 GNU GRUB 0.95 /0.97 到优盘（fat/fat32格式，主引导记录  usb-zip + v2，分区引导记录 gnu grub 0.95/0.97 ），无论是否加    uppermem 65536 命令,

   执行：

      kernel /boot/grub/memdisk c=173 h=4 s=36 floppy
      initrd /boot/msdos/msdos.gz

      都能进入DOS环境。

   grub4dos 0.46a 下没有 uppermem 命令，但上述命令也正常执行，正常进入DOS环境。

   神舟优雅x4环境下，启用 qemu x86 (最多只能分配1G内存) 测试优盘，结果与上网本中相同。

   ——————————————————————————

   神舟优雅x4环境下，启用 qemu x64 (最多分配3G内存，所以分了3G) 测试优盘，情况有所不同。

   gnu grub 0.95 /0.97 执行：

      kernel /boot/grub/memdisk c=173 h=4 s=36 floppy
      initrd /boot/msdos/msdos.gz

   提示错误，不能加载 msdos.gz 。

      执行：

      uppermem 65536

      kernel /boot/grub/memdisk c=173 h=4 s=36 floppy
      initrd /boot/msdos/msdos.gz

      正常进入DOS。

   grub4dos 0.4.6a 执行：

      kernel /boot/grub/memdisk c=173 h=4 s=36 floppy
            initrd /boot/msdos/msdos.gz

      正常进入dos。

      执行：

                  map --mem /msdos/msdos.gz (fd0)
                  map --hook
                  rootnoverify (fd0)
                  chainloader (fd0)+1
      正常进入DOS。

三、结论与说明：

   我在话题的一次发言，言及 grub4dos 0.4.6a 下加载DOS镜像，出现的死机等现象，这与 gnu grub /grub4dos 及 uppermem 无关。有些程序不能运行或死机，是其自身问题。

   grub4dos 0.4.6a 的 map 命令，在3G以内的内存环境下，没有问题。memdisk 也是如此。 3G以上内存的情况，暂时没有办法测试。

   内存<=2G时，gnu grub 0.95/0.97/grub4dos，memdisk、uppermem 命令都能正常工作。

   内存>2G时，gnu grub 0.95/0.97 先执行 uppermem 65536 后，再调用 memdisk ，可以正常工作。grub4dos 0.4.6a 正常工作。3G以上内存的情况，暂时没有办法测试。

四、其它

   1.意外找到自己多年前用过的 gnu grub 0.97 。支持制作成光盘启动、支持ext2/fat/ntfs/iso9660文件系统。内存超过2G时，需先执行uppermem 65536 等限制可用内存大小，才能用memdisk加载镜像。
   2.意外找到另外一个版本的 gnu grub 0.97 ，发行日期：2021.08.27。支持ext2/fat/jfs/minix/xfs 文件系统。内存超过2G时，无需执行 uppermem 65536 等限制可用内存大小，即可直接使用 memdisk 加载镜像。
   下载地址：
      https://packages.debian.org/sid/grub-legacy

   3.grub4dos 0.4.6a 中，暂时没有必要复活 uppermem 命令。
   4. 2G内存可能是某些软件的分水岭。



   再次感谢各位大侠的热忱指导和帮助！！！

作者: 不点 时间: 2021-11-30 10:48
好的，这个帖子中的测试，是个很好的资料。那么我就根据实验数据，说说相关的问题，并给出自己的分析。

GNU GRUB 官方网站上关于 uppermem 的描述是这样的：

https://www.gnu.org/software/grub/manual/legacy/uppermem.html

13.3.37 uppermem— Command: uppermem kbytes

Force GRUB to assume that only kbytes kilobytes of upper memoryare installed. Any system address range maps are discarded.
Caution: This should be used with great caution, and shouldonly be necessary on some old machines. GRUB's BIOS probe can pick upall ram on all new machines the author has ever heard of. It canalso be used for debugging purposes to lie to an OS.

uppermem 65536 就是欺骗操作系统，即，告诉操作系统说，只有 64M 的可用内存。

blank007 在测试中，再现了 gnu grub 0.97 需要 uppermem 命令这个事实。如下：

神舟优雅x4环境下，启用 qemu x64 (最多分配3G内存，所以分了3G) 测试优盘，情况有所不同。gnu grub 0.95 /0.97

执行：

      kernel /boot/grub/memdisk c=173 h=4 s=36 floppy
      initrd /boot/msdos/msdos.gz

提示错误，不能加载 msdos.gz 。
执行：

      uppermem 65536
      kernel /boot/grub/memdisk c=173 h=4 s=36 floppy
      initrd /boot/msdos/msdos.gz

正常进入DOS。

而 grub4dos 没有 uppermem 命令，但在同样的条件下执行同样的命令

      kernel /boot/grub/memdisk c=173 h=4 s=36 floppy
      initrd /boot/msdos/msdos.gz

却不是失败，而是成功。

失败的原因在哪里？ blank007 没有详说，但应该是 initrd 命令失败了。

也就是说，这不是 DOS 不能处理大内存的问题，因为 grub4dos 给它 3G 内存，DOS 也认了，没有死机。

也不是 memdisk 不支持大内存的问题，因为 grub4dos 加载 memdisk，而 memdisk 又把 msdos.gz 加载在 3G 内存顶部，也成功了，没死机。

因此，只可能是 grub0.97 的 initrd 在加载 msdos.gz 到内存时失败了。这是 grub 0.97 的 bug，而 grub4dos 早已修复此 bug，所以 grub4dos 的 initrd 命令不存在问题。

以上测试又是在 qemu 中进行的，因此，与具体硬件无关。也就是说，是旧版 grub 0.97 中的 initrd 命令的局限性造成的，很可能是这条命令本身不支持大于 2G 的内存。

在测试所涉及到的范围内，无论 memdisk 还是 DOS，都没出现不适应大内存的问题。

也就是说，所测试的 DOS 映像文件，根本不需要 uppermem 命令。

作者: blank007 时间: 2021-11-30 11:20

不点发表于 2021-11-30 10:48
好的，这个帖子中的测试，是个很好的资料。那么我就根据实验数据，说说相关的问题，并给出自己的分析。

...

这是测试时的截图和错误信息。

另外，上述测试的语句都是手动输入，逐条执行。引导程序也是独立安装，直接用 GNU GRUB 0.97 或者 GRUB4DOS 引导，没有链式引导。

Snap00000.jpg (49.64 KB, 下载次数: 134)

作者: blank007 时间: 2021-11-30 11:21

不点发表于 2021-11-30 10:48
好的，这个帖子中的测试，是个很好的资料。那么我就根据实验数据，说说相关的问题，并给出自己的分析。

...

多谢大侠！！！

作者: 不点 时间: 2021-11-30 11:55
最后，关于命令序列的顺序，作一说明。我看到 blank007 使用如下序列：

map --mem /msdos/msdos.gz (fd0)
map --hook
rootnoverify (fd0)
chainloader (fd0)+1

最后两条命令的顺序，在本例中无关紧要。但在别的情况下，可能就不一样了。注意，最后，有一条被省略的 boot 命令。

在菜单中，boot 命令是可以省略的。但菜单会自动增加了一条 boot 命令。所以，无论是否省略， boot 命令都是存在的。

好的，为了明确起见，我就这么写（命令顺序已经有意颠倒过来了，这才是正确无误的）：

map  --mem  /msdos/msdos.gz (fd0)
map  --hook
chainloader  (fd0)+1
rootnoverify  (fd0)
boot

解释一下。rootnoverify 有什么用呢？它是确定当前驱动器的号码，在 assembly 层面上，它的最终目的是想要改变 DL 寄存器的值，但它自己改变不了，是让 boot 命令来做这个工作的。

注意，这条 rootnoverify 命令的服务对象是谁？它是为 boot 命令做准备的，是服务于 boot 命令的。

正是 boot 命令，才抓取当前驱动器的号码，把它赋值给 CPU 的 DL 寄存器，然后把控制权交给操作系统的引导代码。

所以说，rootnoverify 之后，就应该立即执行 boot 命令，而不是插入别的命令后，再执行 boot 命令。

如果插入的命令修改了 rootnoverify 的结果，那 boot 命令就会抓取 boot 本身执行时刻的当前驱动器号码，把它赋给 DL，而不是 rootnoverify 命令指定的驱动器号码。

而上述 chainloader 命令碰巧不改变当前驱动器号码，所以，插入了 chainloader 命令，也没有影响。

但并非所有的 chainloader 命令都不改变当前驱动器号码。

有些 chainloader 命令是会改变当前驱动器号码的。chainloader 命令的参数 --edx=.... 就可以改变驱动器号码。

当 chainloader 一个光盘的时候：chainloader (0xff) 或 chainloader (hd32) 之类的命令，不需要 rootnoverify (0xff) 或 rootnoverify (hd32) 之类的命令，因为 chainloader (...) 本身就能改变当前驱动器号码为虚拟光盘的号码。

然而，如果 chainlaoder (...) 之后，不是立即执行 boot，而是又插入了别的什么命令，则在后续执行 boot 之前，需要用一条 rootnoverify (...) 命令来确保当前驱动器是虚拟光盘，而不是别的盘号。

作者: blank007 时间: 2021-11-30 12:11
一直当成 “不校验”。

欢迎光临无忧启动论坛 (http://bbs.c3.wuyou.net/)