中国DOS联盟

今天我在真实模式（非虚拟机中）下对GRUB for DOS 0.14进行了一些测试，结果发现了以下BUG（以前的版本中好像也有）：

如果用GRUB（不管是MBR中的GRUB还是GRUB for DOS）来chainloader操作系统后，再试图通过运行GRUB.EXE进入GRUB for DOS时会死机。比如说，在GRUB for DOS的shell下输入：
root (hd0,0)
chainloader +1
boot
这时会自动从硬盘重启并重新进入DOS，但再次输入GRUB.EXE就死机了。但VMWare中反而可能不死机。

关于FreeDOS Kernel 2032，我刚才也试着在真实模式下用GRUB for DOS 0.14调用它，结果跟2030/2031一样，仍然是出现"FreeDOS”字样后就死机了。

GRUB for DOS 对于 MS DOS 支持得最好。如果运行 MS DOS 出现失常，那才是严重的问题。

如果你的 FreeDOS 的 CONFIG.SYS 中有很多驱动程序（device drivers），例如内存管理程序，这可能会引起失败。

在 FreeDOS下确实容易出现故障，这个我也发现了。但是，如果 config.sys 中不加载程序，在内存中也不运行 TSR 程序，那么，应当是很稳定的（我的机器上，所有测试都是通过的）。

第一次用 grub.exe 当然可以。但是，当你第二次再用 grub.exe 时，因为你没有保证此时系统处于“干净”状态，所以，会出现异常。如果保证运行 grub.exe 时，DOS 的 int table 不被修改过。这样肯定不会有故障的。

死机，是因为 grub for dos 对于 freeDOS 支持不太好，以后有待改进。改进的话，也无非就是，当发现 int table 不适合运行 grub.exe 时，自动退出，出现一条错误提示罢了。在这种状态下，是不允许运行 grub 的。

非常希望GRUB for DOS能在EMM386/VCPI等环境下运行。像Win3.x/9x、BasicLinux等就可以在EMM386/VCPI下运行呢，毕竟我们一般都是通过用EMM386来提供UMB高端内存的。

另外，建议将下面这段话更新一下，因为新的DOS（如MS-DOS 7.10+DOSLFN或者ROM-DOS 7.10等）下是支持长文件名的：

“0.1.2 修正了一个读取软盘扇区的 BUG；增加了从 menu.lst 菜单安装 GRUB 到 MBR 的菜单项。使用方法是，将解包后的 boot 目录拷贝到 C:\ 也就是根目录下（于是就有了这个文件 C:\boot\grub\menu.lst）。这需要在 Windows 下操作，因为在 C:\boot\grub 目录下有很多长文件名，而 DOS 不能建立长文件名。”

有 EMM386 的情况，并非属于“保护模式”。EMM386 仅仅“使用”了保护模式，而它提供给程序的服务接口，是不用保护模式的。比如说吧，在使用 MS DOS 时，你可以在 CONFIG.SYS 中包括 HIMEM.SYS，这时，GRUB 仍然可以工作。它之所以能够工作，是因为 GRUB FOR DOS 对于 HIMEM 进行了汇编语言的 HACK，能够自动恢复 HIMEM 所修改的 INT 向量。同样，对于 EMM386 以及其它任何一款 TSR 程序，也都可以做类似的 HACK，但这需要时间。

可惜，在 FREEDOS 上，我目前还没有时间对其内存管理程序进行 HACK。以后有时间的话，会完成这个工作的。

至于说从真正的保护模式内部运行 GRUB，似乎没有这个必要。即使有人需要这个，也很难实现。假如有人知道如何从 WIN98 的保护模式切换到实模式的方法，那么，这（从保护模式运行GRUB）将是非常容易的事情了。但这似乎是微软未公开的秘密，恐怕没有人能够掌握了吧。

关于那段话，大家都明白是对于微软原始的系统而言的，并不假定用户已经安装了长文件名工具，所以，我觉得这样写也不算太坏，尤其是对于纯粹的 WINDOWS 用户而言。

EMM386是“使用”了保护模式后就使系统进入V86虚拟模式使得实模式的DOS程序可以运行，并且通过提供VCPI内存使保护模式的DOS程序也可以运行，对吧？据我所知，一些DOS扩展器（如CWSDPMI等），以及Win3.x 386 enhanced mode/9x中的“DOS窗口”，都使用了V86虚拟模式使得实模式DOS程序可以运行，且通过提供DPMI服务器，使得保护模式的DOS程序也可以运行的。实模式、32位保护模式、V86模式在386或以上电脑中可以轻易切换（只是从V86虚拟模式下有时切换到实/保护模式有些困难），但在286电脑中呢，除根本没有V86模式外，从实模式切换到保护模式（286只有16位保护模式，而没有32位保护模式）容易，但反之则不行，除非硬RESET（即重启整个系统）或软RESET（即OS/2 1.x中从保护模式切换到实模式以运行DOS程序所使用的办法）。

以下是引用不点在2003-9-26 23:27:51的发言：
比如说吧，在使用MSDOS时，你可以在CONFIG.SYS中包括HIMEM.SYS，这时，GRUB仍然可以工作。它之所以能够工作，是因为GRUB FOR DOS对于HIMEM进行了汇编语言的HACK，能够自动恢复HIMEM所修改的INT向量。同样，对于EMM386以及其它任何一款TSR程序，也都可以做类似的HACK，但这需要时间。

我觉得如果对每个驱动程序或TSR程序进行类似的hack的话，必定是非常复杂而且永远也不可能做到最完美（因为各种驱动/TSR程序太多了）。不知能不能给GRUB加入一个自动寻找和恢复被修改过的INT向量的代码来自动完成这些功能？

哎, 这就对了.

我昨天把你的那个 PC ＤＯＳ 装上了, 准备对它进行 HACK, 虽然 HACK 进展还算顺利, 但是, 我停止进行下去了.原因是, 我开始感到罗嗦了. 正如你所说的一样(我们不谋而合了).

得了, 以后就不再对某个 DOS 进行 HACK 了. 要设计一个程序自动恢复中断向量.

以下是引用Wengier在2003-9-26 5:23:15的发言：
非常希望GRUB for DOS能在EMM386/VCPI等环境下运行。像Win3.x/9x、BasicLinux等就可以在EMM386/VCPI下运行呢，毕竟我们一般都是通过用EMM386来提供UMB高端内存的。

另外，建议将下面这段话更新一下，因为新的DOS（如MS-DOS 7.10+DOSLFN或者ROM-DOS 7.10等）下是支持长文件名的：

“0.1.2 修正了一个读取软盘扇区的 BUG；增加了从 menu.lst 菜单安装 GRUB 到 MBR 的菜单项。使用方法是，将解包后的 boot 目录拷贝到 C:\ 也就是根目录下（于是就有了这个文件 C:\boot\grub\menu.lst）。这需要在 Windows 下操作，因为在 C:\boot\grub 目录下有很多长文件名，而 DOS 不能建立长文件名。”

我小时候看的书上写UMB称上位内存，HMA称高端内存
不知现在书上怎么写？

没错，应该是：

UMB: Upper Memory Block：上位内存块
HMA：High Memory Area：高位内存区

不点：

关于下面一段话，似乎有修改的必要：

“正如上面所说，GRUB 对于磁盘的仿真是基于 BIOS 的 int 0x13。那些使用 BIOS 的操作系统，在 GRUB 仿真之下能够很好地运转。这些系统有：各种各样的 DOS；Windows Me 以前的系统（不包括 Windows Me）。我不知道 Windows Me 是否使用 BIOS，但 Windows 2000 之后的 Windows 系列似乎都不使用 BIOS 了。已知 LINUX 也不使用 BIOS。”

Windows 3.x/9x/ME都是基于DOS的（不管是MS-DOS 6.x，还是MS-DOS 7.x或8.0），所以它们都是通过DOS/BIOS功能来存取的。但Win2K/XP则完全不一样，因为它们是OS/2、WinNT的更新版本。所谓Windows 2000，即Windows NT 5.0（具体版本号：NT 5.00.2195），而Windows XP即Windows NT 5.1（具体版本号：NT 5.10.2600）。WinNT是在OS/2的基础上修改而来的，而OS/2、WinNT/2K/XP作为同一系列系统，是使用完全不同于BIOS的方法来存取磁盘的。相比之下，Win3.x/9x/ME都是DOS下运行的程序，Win95即Windows 4.0 GUI（具体版本号：4.00.950），Win98即Windows 4.1 GUI（具体版本号：4.10.1998/2222），WinME即Windows 4.9 GUI（具体版本号：4.90.3000），它们都是一回事。所以如果Win95/98是通过DOS/BIOS功能来存取磁盘的话，那么WinME也同样是这样的了。

以下是引用Wengier在2003-9-25 5:28:58的发言：
今天我在真实模式（非虚拟机中）下对GRUB for DOS 0.14进行了一些测试，结果发现了以下BUG（以前的版本中好像也有）：

如果用GRUB（不管是MBR中的GRUB还是GRUB for DOS）来chainloader操作系统后，再试图通过运行GRUB.EXE进入GRUB for DOS时会死机。比如说，在GRUB for DOS的shell下输入：
root (hd0,0)
chainloader +1
boot
这时会自动从硬盘重启并重新进入DOS，但再次输入GRUB.EXE就死机了。但VMWare中反而可能不死机。

关于FreeDOS Kernel 2032，我刚才也试着在真实模式下用GRUB for DOS 0.14调用它，结果跟2030/2031一样，仍然是出现"FreeDOS”字样后就死机了。

斑竹，如果我用光盘引导来启动系统,虚拟出软驱后,
用可以用虚拟软盘上的grub
来重新引导系统吗?
即可否虚拟软盘来重新引导系统？

TO Wengier:

好！证据很充足，这说服了我，虽然我对于 ME 并不了解。

TO hanshen：

没问题的。我用光盘启动到 DOS，可以运行 GRUB.exe，至于说 GRUB 在软盘的第一扇区（这个软盘是光盘上的一个软盘映象文件），自然也是可以的，这没有本质的差别。

你如果不太放心，可以用 VMWARE 或者 Virtual PC ，用 ISO 文件来测试，以免浪费你刻录光盘。

以下是引用不点在2003-10-1 11:44:03的发言：
你如果不太放心，可以用VMWARE或者VirtualPC，用ISO文件来测试，以免浪费你刻录光盘。

非常希望GRUB for DOS能通过Bootable CD Loader来支持从ISO镜像文件启动，相信需要的人非常多的，不管是DOS/WIN用户，或者是Unix/Linux用户。不知最近有什么进展吗？

俄国人写的那个光盘引导程序，似乎本质上和 SBM 的方法一样，都是对于光盘的物理地址进行操作，躲过了 BIOS。所以，这个办法只能引导真实的光驱，不能引导 ISO 文件。

VMWARE 之类的软件之所以可以引导 ISO 文件，是因为它们在操作系统和硬件这一级别而对物理的 IO 端口读写进行了仿真。这在真实的情况是不可能的。我们的仿真是修改 BIOS，而其它都完全是真实的机器，所以，无法用端口读写来实现 ISO 的引导。

基于 BIOS 的 ISO 引导，这本身实现起来也不是很困难。但是，我想首先实现基于 BIOS int 的真实 CDROM 引导（而不是基于 IO 端口的 CDROM 引导）。这个工作完成之后，可能对于基于 BIOS int 的 ISO 引导有着基本的帮助。这个工作的完成，不会很快，需要一两年甚至更长。

实现 BIOS int CDROM 引导，可能提供有用的信息，帮助实现基于 BIOS int 的 ISO 引导。所以我不想首先实现后者。

以下是引用不点在2003-10-1 21:41:15的发言：
俄国人写的那个光盘引导程序，似乎本质上和 SBM 的方法一样，都是对于光盘的物理地址进行操作，躲过了 BIOS。所以，这个办法只能引导真实的光驱，不能引导 ISO 文件。

VMWARE 之类的软件之所以可以引导 ISO 文件，是因为它们在操作系统和硬件这一级别而对物理的 IO 端口读写进行了仿真。这在真实的情况是不可能的。我们的仿真是修改 BIOS，而其它都完全是真实的机器，所以，无法用端口读写来实现 ISO 的引导。

基于 BIOS 的 ISO 引导，这本身实现起来也不是很困难。但是，我想首先实现基于 BIOS int 的真实 CDROM 引导（而不是基于  IO 端口的 CDROM 引导）。这个工作完成之后，可能对于基于 BIOS int 的 ISO 引导有着基本的帮助。这个工作的完成，不会很快，需要一两年甚至更长。

实现 BIOS int CDROM 引导，可能提供有用的信息，帮助实现基于 BIOS int 的 ISO 引导。所以我不想首先实现后者。

其實只要bcdl.bin能載入shsucdhd.exe就可以做到了...
可是......
shsucdhd.exe要修改一下才可以...

Roy上面说到“SHSUCDHD需做一些小修改”是指将它从EXE格式修改成SYS格式的，以用BCDL进行加载。SHSUCDHD就是那个用ISO镜像光驱驱动程序，即将ISO文件虚拟为物理光驱。我曾用它在纯DOS下将Win2003的ISO镜像文件虚拟为光驱，并进行安装。下面上传它的EXE可执行文件以及ASM源代码：
打开附件

其中的源代码SHSUCDHD.ASM从结构上来看里面似乎已包含了SYS设备驱动程序的一些必要内容（例如SYS设备驱动程序中所独有且必备的strategy、interrupt部分等），所以我想，如果修改一下并转换成真正的SYS驱动程序应该不会太难吧（只可惜我的ASM水平还很有限，所以还不太清楚具体该怎么修改它的源代码以真正实现）。

BCDL.BIN本身应该并非直接对光盘的物理地址进行操作，而是BCDL.BIN在真正加载前，首先调用一个DOS光驱驱动程序（如VIDE-CDD.SYS、OAKCDROM.SYS之类的），由这个光驱驱动程序来对物理光盘进行操作和驱动，然后由BCDL.BIN使用MSCDEX的INT兼容方式对光盘进行真正加载并启动。如果用SHSUCDHD.SYS（即SHSUCDHD.EXE的SYS版本）来做为中间的那个光驱驱动程序来虚拟ISO镜像文件的话，那展现在BCDL.BIN面前的就是一个真正的物理光驱了，因为BCDL.BIN并不直接存取光驱的物理地址，而只是根据已加载的DOS光驱驱动程序来进行下一步的操作的。