wangsea：
> 能否开发一个精简的Grub版本
我目前的答复是，不能。原因前面说过，要真正大规模精简，就得转向汇编语言，有可能将 GRUB 精简至 30K 以内。不过，你可以尝鲜 gandalf 新近创作的 avldr.exe。
> 功能：Grub XXX.img 命令行功能的版本（不需要menu.lst)
此处的问题是(前面也曾经提到过)，XXX.img 要装入扩展内存的话，有可能失败。如果此时没有 himem等内存管理程序，那么这有可能实现，但是，在有 himem 等内存管理程序存在的情况下，这将变得很复杂，很困难了。也就是说，把 XXX.img拷贝到物理内存的顶端，这个目的恐怕达不到，拷贝过程有可能会失败(比如如果覆盖掉已经分配了的关键的 XMS内存的话)。如果谁能详细研究 XMS等等这些 DOS下的扩展内存规范，能够顺利实现拷贝的话，那么，他就可能制作出你所说的这种工具。我支持有人做，但我没有时间，也没有兴趣做，即使不考虑内存管理程序的影响，我也不想做(我认为其意义不是很大)。
如果你说的是脱离扩展内存，只使用磁盘介质的仿真(相当于没有 --mem 参数)，并且假定 XXX.img 是连续的。这样可以实现你的要求，但是，仍然存在下面的问题：
如果你说的是用 grub 命令实现仿真，然后退回到-------原来的------ DOS，那么，这可是在欺骗 DOS，注意 DOS 有时可以被欺骗，有时它不能被欺骗。
如果你的系统中有一个真实的软驱，你用 XXX.img 仿真(fd0)软盘，这是可以欺骗 DOS 的。如果你的系统中有 n 个硬盘，而你用XXX.img 仿真第 n + 1 个硬盘，这恐怕不行，即使你同时修改了 BIOS 数据区中的软盘和硬盘个数字节，也不行。这是因为，DOS在启动时已经确定了磁盘的总数，在启动之后新增加的磁盘，它都可能不承认的。
还有一个问题是，此时很容易死机，我能想到的死机原因，大致有以下两个方面：
1. 如果仿真程序没有处理好 DOS 常规内存的 arena 结构，则 直接就死掉。
2. 如果仿真了当前 DOS 正在使用的磁盘，则当仿真之后 DOS 可能因为找不到原来真实磁盘上的内容而出错，甚至死掉。
有鉴于以上这些复杂的原因，所以，我不主张别人去做这样的开发。当然了，如果确实有 DOS 高手愿意做，那么这些问题可能都会得到解决的，虽然很不容易。
> 能否开发一个精简的Grub版本
我目前的答复是，不能。原因前面说过，要真正大规模精简，就得转向汇编语言，有可能将 GRUB 精简至 30K 以内。不过，你可以尝鲜 gandalf 新近创作的 avldr.exe。
> 功能：Grub XXX.img 命令行功能的版本（不需要menu.lst)
此处的问题是(前面也曾经提到过)，XXX.img 要装入扩展内存的话，有可能失败。如果此时没有 himem等内存管理程序，那么这有可能实现，但是，在有 himem 等内存管理程序存在的情况下，这将变得很复杂，很困难了。也就是说，把 XXX.img拷贝到物理内存的顶端，这个目的恐怕达不到，拷贝过程有可能会失败(比如如果覆盖掉已经分配了的关键的 XMS内存的话)。如果谁能详细研究 XMS等等这些 DOS下的扩展内存规范，能够顺利实现拷贝的话，那么，他就可能制作出你所说的这种工具。我支持有人做，但我没有时间，也没有兴趣做，即使不考虑内存管理程序的影响，我也不想做(我认为其意义不是很大)。
如果你说的是脱离扩展内存，只使用磁盘介质的仿真(相当于没有 --mem 参数)，并且假定 XXX.img 是连续的。这样可以实现你的要求，但是，仍然存在下面的问题：
如果你说的是用 grub 命令实现仿真，然后退回到-------原来的------ DOS，那么，这可是在欺骗 DOS，注意 DOS 有时可以被欺骗，有时它不能被欺骗。
如果你的系统中有一个真实的软驱，你用 XXX.img 仿真(fd0)软盘，这是可以欺骗 DOS 的。如果你的系统中有 n 个硬盘，而你用XXX.img 仿真第 n + 1 个硬盘，这恐怕不行，即使你同时修改了 BIOS 数据区中的软盘和硬盘个数字节，也不行。这是因为，DOS在启动时已经确定了磁盘的总数，在启动之后新增加的磁盘，它都可能不承认的。
还有一个问题是，此时很容易死机，我能想到的死机原因，大致有以下两个方面：
1. 如果仿真程序没有处理好 DOS 常规内存的 arena 结构，则 直接就死掉。
2. 如果仿真了当前 DOS 正在使用的磁盘，则当仿真之后 DOS 可能因为找不到原来真实磁盘上的内容而出错，甚至死掉。
有鉴于以上这些复杂的原因，所以，我不主张别人去做这样的开发。当然了，如果确实有 DOS 高手愿意做，那么这些问题可能都会得到解决的，虽然很不容易。
因为我们亲手创建，这个世界更加美丽。
