中国DOS联盟

或者说，还是感到很生疏。

> 我曾用它在纯DOS下将Win2003的ISO镜像文件虚拟为光驱，并进行安装。

在 DOS 下将 ISO 虚拟为光驱，并能进行安装，并不说明 ISO 文件被完全模拟成物理的 CDROM 了。
我猜想，是不是它把 ISO 文件的扇区内容解读出来，然后再用某个 MSCDEX 兼容的程序把 CDROM 变成某个 DOS 盘符，例如 H: 盘？这并不对 CDROM 硬件 IO 端口进行操作。在实模式下不可能对于 IO 端口进行仿真的。IO 端口在实模式下只能访问真实的设备。

如果是这样的话，这样的仿真不能离开 DOS 而存在。GRUB 的仿真是不依赖于 DOS 的，所以，不能用这种办法来实现。虽然 GRUB 运行在 DOS 下，但是 GRUB 不利用任何 DOS 中断以及 DOS 数据结构。GRUB 只用 BIOS 中断和 BIOS 数据结构。因为 GRUB 要启动其它操作系统，所以，GRUB 与具体的某个操作系统无关。所以，不能像 BCDL 所实现的那样用 ISO 去仿真CDROM。

> 如果修改一下并转换成真正的 SYS 驱动程序应该不会太难吧。

单纯把一个 SYS 转成 EXE，或者反之，这应当不难（我对于SYS的结构也不了解）。但是，不管是 SYS 还是 EXE，它都是 DOS 内部使用的概念，不能由 GRUB 来借用。我觉得 GRUB 去学它，这条路是走不通的。当然了，如果讨论的不是 GRUB 而是如何从 ISO 文件引导系统，则是完全可以的。但我觉得从 DOS 内部实现这个，仍然有（别的一些）少量（但并不容易解决的）困难需要面对（不讨论这个了）。

> 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光驱驱动程序来进行下一步的操作的。

由于我不熟悉，这段话还不很懂。BCDL首先加载 SYS 光驱驱动，那么，可不可以这么说：SYS 文件运行于 DOS 环境？ SHSUCDHD.EXE显然是运行于 DOS 的。如果 SYS 文件并非运行于 DOS 的，而我们想把 SHSUCDHD.EXE 转换成这样的 SYS 格式，恐怕即使转换成功，也不能使用。即使能够使用，还有问题：你说了，BCDL使用MSCDEX兼容方式处理光盘，也就等于说，是在 DOS 之下模拟 ISO 为一个盘符了。这只能用于 DOS 兼容的操作系统，不能用于 LINUX 等其它系统。LINUX 是不知道盘符的。

呵呵，我很糊涂，所以，说的可能也比较可笑了。如果你发现我有不清楚的概念，可以继续指出来并给以解释。

GRUB当然并不使用DOS中断，而且也并不提供DOS中断。GRUB for DOS所做的，仅是提供一个DOS下的运行入口，然后恢复一些DOS驱动/TSR程序所做的改动，然后调用原有的GRUB 0.93的主体部分，使之在真实的非DOS环境下运行。

但是，BCDL则正好相反。BCDL本身的运行环境跟GRUB 0.93中的stage2相同，都是不使用DOS中断的，所以可以用GRUB通过chainloader来直接加载。但是，跟GRUB不同的是，据我研究，BCDL其中的一部分本身就是一个DOS中断提供程序（相当于IO.SYS+MSDOS.SYS的一个子集），所以当它运行后它可以用来直接调用DOS程序了。具体来说，BCDL就是通过以下流程来从CD-ROM/RW光盘启动的：

1：开始加载BCDL.BIN，提供DOS中断（即类似IO.SYS+MSDOS.SYS的子集）；
2：自动运行作用相当于“DEVICE=VIDE-CDD.SYS”的命令；
3：运行VIDE-CDD.SYS这个SYS格式的纯DOS驱动程序；
4：BCDL.BIN通过上面这个DOS方式的SYS文件提供的与MSCDEX兼容的光驱接口来真正调入光驱并从光驱启动。

由此可见，BCDL.BIN是通过调用一个SYS格式的纯DOS下的光驱驱动程序来实现对光驱的加载的。这个SYS格式的文件可以是任何未压缩的DOS驱动程序，比如如果换成SCSICD.SYS，就可以从SCSI光驱启动。甚至可以换成其它非光驱的SYS文件，例如RAMDRIVE.SYS、UMBPCI.SYS、DRFAT32.SYS等。当然，虽然它们都是可以用BCDL加载的，不过由于它们不是DOS光驱驱动程序，所以BCDL无法通过它们从光驱启动。

和其它的纯DOS光驱驱动程序（如上面所提到的VIDE-CDD.SYS等）一样，SHSUCDHD.EXE正是一个真正的与MSCDEX兼容的纯DOS光驱驱动程序，只需修改成为一个SYS格式的DOS光驱驱动程序（即可用DEVICE=SHSUCDHD.SYS方式来加载的DOS光驱驱动程序），那么BCDL进行到第4步时就可以从ISO文件来启动了。

现在SHSUCDHD的源代码上面已有，所以不妨试试，将SHSUCDHD.EXE修改成一个SYS格式的DOS光驱驱动程序，如何？说明：SHSUCDHD可以用MASM 6.0编译。MASM 6.0可以在这儿下载：
http://www.bbs.motion-bg.com/dl.php?file=388

讨论得这么激烈，虽然偶看得懂的不多，但还是加精一下，以示佩服！
希望各位高手多多参与，带领我们早日脱菜。

以下是引用Wengier在2003-10-3 21:41:09的发言：
GRUB当然并不使用DOS中断，而且也并不提供DOS中断。GRUB for DOS所做的，仅是提供一个DOS下的运行入口，然后恢复一些DOS驱动/TSR程序所做的改动，然后调用原有的GRUB 0.93的主体部分，使之在真实的非DOS环境下运行。

但是，BCDL则正好相反。BCDL本身的运行环境跟GRUB 0.93中的stage2相同，都是不使用DOS中断的，所以可以用GRUB通过chainloader来直接加载。但是，跟GRUB不同的是，据我研究，BCDL其中的一部分本身就是一个DOS中断提供程序（相当于IO.SYS+MSDOS.SYS的一个子集），所以当它运行后它可以用来直接调用DOS程序了。具体来说，BCDL就是通过以下流程来从CD-ROM/RW光盘启动的：

1：开始加载BCDL.BIN，提供DOS中断（即类似IO.SYS+MSDOS.SYS的子集）；
2：自动运行作用相当于“DEVICE=VIDE-CDD.SYS”的命令；
3：运行VIDE-CDD.SYS这个SYS格式的纯DOS驱动程序；
4：BCDL.BIN通过上面这个DOS方式的SYS文件提供的与MSCDEX兼容的光驱接口来真正调入光驱并从光驱启动。

由此可见，BCDL.BIN是通过调用一个SYS格式的纯DOS下的光驱驱动程序来实现对光驱的加载的。这个SYS格式的文件可以是任何未压缩的DOS驱动程序，比如如果换成SCSICD.SYS，就可以从SCSI光驱启动。甚至可以换成其它非光驱的SYS文件，例如RAMDRIVE.SYS、UMBPCI.SYS、DRFAT32.SYS等。当然，虽然它们都是可以用BCDL加载的，不过由于它们不是DOS光驱驱动程序，所以BCDL无法通过它们从光驱启动。

和其它的纯DOS光驱驱动程序（如上面所提到的VIDE-CDD.SYS等）一样，SHSUCDHD.EXE正是一个真正的与MSCDEX兼容的纯DOS光驱驱动程序，只需修改成为一个SYS格式的DOS光驱驱动程序（即可用DEVICE=SHSUCDHD.SYS方式来加载的DOS光驱驱动程序），那么BCDL进行到第4步时就可以从ISO文件来启动了。

现在SHSUCDHD的源代码上面已有，所以不妨试试，将SHSUCDHD.EXE修改成一个SYS格式的DOS光驱驱动程序，如何？说明：SHSUCDHD可以用MASM 6.0编译。MASM 6.0可以在这儿下载：
http://www.bbs.motion-bg.com/dl.php?file=388

可是.....重點在於shsucdhd.exe是需要himem.sys的......

以下是引用Roy的发言：
可是.....重點在於shsucdhd.exe是需要himem.sys的......

其实，可以在SHSUCDHD的ASM源代码的基础上，修改成一个独立的（不需要HIMEM.SYS等）纯DOS的SYS格式的虚拟光驱驱动程序，只要它仍与MSCDEX接口兼容，那么BCDL就是可以加载它并用它来启动的。这样，从ISO文件直接启动就成功了。

谢谢以上各位兄弟。我看的似乎有点明白了。我准备进一步看看 ASM 的源码。

我在自己的脑子中总要有个清晰的认识才行。我再来猜测一下。这个 BCDL 加载了一个以 DOS 为基础的 SYS 程序，在这个 MSCDEX 兼容环境下，BCDL可以读取 CD 上的扇区数据。只要能够读取扇区数据，就可以从 CD 引导。

这样虽然能够从 CD 引导，但引导 CD 的基础，不是纯粹的 BIOS ，而是 DOS 或者叫做 类DOS 的。这种 类DOS，可以认为是对 BIOS 的扩展（从正面来看），也可以认为是对于 BIOS 的污染（这是从反面来理解的）。所有这些驱动程序，无非就是要实现 MSCDEX 这个“标准”，这个标准所真正实现的，无非就是可以读出 CD 的扇区内容罢了。这样，MS 通过推行 MSCDEX 这个标准，就强行污染了 BIOS：你们 BIOS 制造商不能给用户提供 CD 扇区读的功能，而只有我微软的 MSCDEX 才是标准。想对 CD 进行底层操作，就离不开我微软。

而各家 BIOS 厂家也太傻冒了，它们的 BIOS 实际上都已经有了 CD 的读函数（大家想想 BIOS 可以启动 CD，说明 BIOS 可以读 CD 扇区），只不过各家的读函数有差别，没有形成标准。它们被动地跟着微软屁股后面跑，而完全不能想到自己是 BIOS 的主人！微软制定个啥，啥就是标准。【如果这里碰巧有 BIOS 厂家的人，我这个观点就是给他看的】。BIOS 厂家应当自发制定 CD 的 BIOS int 标准，就像磁盘的 BIOS 标准一样。这决不能等待微软去制定了。微软一开始就不是个好东西！

标准是多么重要！微软深知此道！没有标准，即使你的功能再强大，也等于零，只能处于被动挨打的地位，最后都给微软吃掉了，还不知道。不仅 CDROM 要有 int 标准，USB 等等也都要有 int 标准，决不能让微软继续污染（事实上微软还在继续污染）。

回到正题。

BIOS 本来就有 CD 的读函数，却绕了很大的圈子，最后还要依赖一个什么 MSCDX 的 DOS 标准去读扇区，简直太可笑了。MSCDEX 所实现的，无非就是读 CD 扇区，这个功能，一点都不比 BIOS 强（只不过没有统一形成标准）。

我以前在 DOS 下搜集 CDROM 扇区读的中断。知道MSCDEX 用 int 2f 来提供 CDROM 的读函数。直到某一日我忽然发现 BIOS 本身就有 CDROM 的读方法，我才恍然大悟，同时有一种被微软愚弄的感觉。

看看那些 DOS 下的 CD 驱动程序有多少？太多了，种种色色。为什么会有这么多呢？只有一个解释：不同的 CD，需要不同的驱动。有些 CD 不能驱动。这说明，有了 MSCDEX ，仍然不能完美解决 CDROM 的问题。这个 MSCDEX 变得多么无聊。本来很简单的问题，让它一插手，就变得复杂无比，害得所有的技术人员都疲惫不堪。

很多年以前都可以从 BIOS 引导光盘了，可是，遗憾的是，就差“统一”二字，BIOS 却不能提供 CD 的 int 接口。

＝＝＝＝＝＝＝＝＝＝

刚才说过，类DOS 环境污染了 BIOS。具体说来，类 DOS 环境使用了诸如 int 2f 这样的中断，而真实的 BIOS 是不用这些中断的。这里就存在着隐患了。当 CDROM 上引导的操作系统不覆盖掉 int 2f 的中断向量表的时候，这样可能还不要紧，但是，当 CDROM 上运行的某个程序修改 int 2f 时，这就惨了，系统就要崩溃。虽然出现问题的可能性不算太大，但，确实有可能出现。只要有可能出现隐含问题，就不是一个可取的好方法。

＝＝＝＝＝＝＝＝＝＝＝

综合以上所说，我不会去按照 MSCDEX 的思路去做这个工作。我希望看看相关的源码，对于用 grub 来实现 ISO 引导，希望能有所帮助。

我并没有完全否定修改 EXE 为 SYS 这个作法。如果我确实有时间，并且也确实发现修改它不困难的话，我会试试的。如果发现有一些比较罗嗦的问题，可能就要放弃了，毕竟，我还没有了解过 SYS 文件的结构以及相关的编程规范。如果有人完成它，我当然是支持的，毕竟这可能是一条捷径。首先实现它，然后再正规地用 GRUB 本身来实现，这当然是不矛盾的。

谢谢诸位，欢迎继续讨论，发表各人的高见。

以下是引用Wengier在2003-10-3 23:17:39的发言：

以下是引用Roy的发言：
可是.....重點在於shsucdhd.exe是需要himem.sys的......

其实，可以在SHSUCDHD的ASM源代码的基础上，修改成一个独立的（不需要HIMEM.SYS等）纯DOS的SYS格式的虚拟光驱驱动程序，只要它仍与MSCDEX接口兼容，那么BCDL就是可以加载它并用它来启动的。这样，从ISO文件直接启动就成功了。

这是又一层障碍了。HIMEM 也是微软的。虽然标准本身不是微软的，但微软的 himem 是事实工业标准。

SHSUCDHD 启用扩展内存，说明问题比较复杂。我已经失去信心了。剥离它是可能的，但要花费力气的。目前缺乏的是时间。

以下是Roy的发言：

“可是.....重點在於shsucdhd.exe是需要himem.sys的......”

以下是不点的发言：

“SHSUCDHD启用扩展内存，说明问题比较复杂。我已经失去信心了。剥离它是可能的，但要花费力气的。目前缺乏的是时间。”

我刚才自己试了一下，发现SHSUCDHD.EXE并不需要HIMEM.SYS或其它XMS扩展内存驱动程序，而是本来就是可以独立使用的。所以Roy上面说的“shsucdhd.exe是需要himem.sys的”是不正确的。因此根本不需要剥离或改写。

以下是引用Wengier在2003-10-4 20:46:15的发言：

我刚才自己试了一下，发现SHSUCDHD.EXE并不需要HIMEM.SYS或其它XMS扩展内存驱动程序，而是本来就是可以独立使用的。所以Roy上面说的“shsucdhd.exe是需要himem.sys的”是不正确的。因此根本不需要剥离或改写。

そう、そう。。。(對啊,對啊...)
我確實弄錯了一些了.....
現在...我在這裡,
鄭重的說一句:
ごめんなさい！(對不起!)

Roy最近在学日语啊！还是从小看日本动漫学来的？

以下是引用cn_archer在2003-10-4 22:55:14的发言：
Roy最近在学日语啊！还是从小看日本动漫学来的？

哈......兩者都是呢.....

以下是引用不点在2003-10-4 17:02:50的发言：
刚才说过，类DOS环境污染了BIOS。具体说来，类DOS环境使用了诸如int2f这样的中断，而真实的BIOS是不用这些中断的。这里就存在着隐患了。当CDROM上引导的操作系统不覆盖掉int2f的中断向量表的时候，这样可能还不要紧，但是，当CDROM上运行的某个程序修改int2f时，这就惨了，系统就要崩溃。虽然出现问题的可能性不算太大，但，确实有可能出现。只要有可能出现隐含问题，就不是一个可取的好方法。

据我观察，这种担心似乎是不必要的，因为以下两点：

1：BCDL之所以使用DOS的MSCDEX兼容标准，只是因为它用一个DOS光驱驱动程序来走捷径，既避免了自己写光驱驱动程序，又可以适应更多的光驱（因为那个DOS光驱驱动程序是可以更换的）；但这并非说BCDL就是进行MSCDEX的操作，而是只是利用与MSCDEX兼容的各种DOS光驱驱动程序来先驱动光驱这一捷径，然后使用自己的代码（类BIOS虚拟法，而并非MSCDEX法）来完成相应的光驱的引导，而并不会提供或使用新的中断；

2：BCDL在进行第4步（即最后一步）时，当真正实现启动光驱前，会恢复和重置所有DOS中断（包括那个先加载的DOS光驱驱动程序），所以可以说不会对已成功启动的光盘上的程序的运行造成任何影响。这是我长期测试和使用后的一些发现。

综上所述，再加上SHSUCDHD.EXE本身就是可以独立使用的（而不需HIMEM.SYS等），所以如果将它转换为SYS的话，那应该能直接被BCDL加载吧。。

学到东西了！支持啊！请继续。。我们联盟太需要这样的讨论了。。

据我观察，这种担心似乎是不必要的，因为以下两点：

1：BCDL之所以使用DOS的MSCDEX兼容标准，只是因为它用一个DOS光驱驱动程序来走捷径，既避免了自己写光驱驱动程序，又可以适应更多的光驱（因为那个DOS光驱驱动程序是可以更换的）；但这并非说BCDL就是进行MSCDEX的操作，而是只是利用与MSCDEX兼容的各种DOS光驱驱动程序来先驱动光驱这一捷径，然后使用自己的代码（类BIOS虚拟法，而并非MSCDEX法）来完成相应的光驱的引导，而并不会提供或使用新的中断；

2：BCDL在进行第4步（即最后一步）时，当真正实现启动光驱前，会恢复和重置所有DOS中断（包括那个先加载的DOS光驱驱动程序），所以可以说不会对已成功启动的光盘上的程序的运行造成任何影响。这是我长期测试和使用后的一些发现。

综上所述，再加上SHSUCDHD.EXE本身就是可以独立使用的（而不需HIMEM.SYS等），所以如果将它转换为SYS的话，那应该能直接被BCDL加载吧。。

问题的关键是，真实光驱的驱动程序和 ISO 的光盘仿真程序 SHSUCDHD.EXE 之间的差别究竟有多大？如果差别不大的话，我估计 SHSUCDHD.EXE 的作者就可以很方便地把它也写成 SYS 文件了。所以，我猜测这里可能存在某种难以逾越的障碍。

根据你刚才 1 的说法，BCDL 对真实光驱的支持，可能主要是在硬件层面的，也就是说，可能是基于 ATAPI CDROM 的 IO 设备接口规范的。如果是这样的，那么基本上就可以断言 BCDL 无法启动 ISO 文件。因为这个硬件规范不适用于软件，它不是一个 int 的规范【微软故意不让推出 int 规范，因为微软不能从中得到好处，虽然推出这个规范的同时，很容易就可以顺便推出一个 int 规范，多写上几句话就行】。

表面上看，这个 SYS 和 EXE 的差别不大，这仅仅是从文件格式而言，而可能并没有从实现方法这一本质去挖掘。SYS 脱离 DOS 我是相信的，因为 SBM 也是用这种办法来实现从真实光驱引导的。

单纯用 ISO 引导，这个也是可以实现的。SHSUCDHD.EXE 就实现了。然而，我一直以来所担心的，就是把两个风马牛不相及的东西硬是凑在一起。老实说，看别人的程序，并不一定比自己编程序来得容易。以前我看了 SBM 的程序，本来想用它来写 GRUB for DOS 的光盘仿真程序，但我放弃了，原因就是，它用的 ATAPI 规范，是我所不能采用的，或者说，是我所反对的。这是个硬件规范，CDROM 以及 BIOS 厂家可以使用这样的规范，但我们不应当使用它。要把 SBM 改造得可以从 ISO 文件启动，可以说是不可能的，除非添加大量的代码，而这，无异于重新编程了。

同样的道理也适用于 BCDL，它如果严重依赖 ATAPI 等等这类硬件规范，那就很难用它来引导 ISO 文件。它驱动的是硬件，它最后要调用硬件指令来从光盘引导。当它来调用假想的 SHSUCDHD.SYS 中程序时，这些程序的响应是软的，调用者所期望的硬件反应（硬件中断），始终不会出现，这样，完全无用了。

也许 SHSUCDHD.EXE 是自成一体的。它可以处理 ISO 的仿真，使用的是另外一种规范：可引导的 CDROM 规范。这个规范确实是比较软，因为不涉及硬件。任何引导 ISO 文件的方法，都得利用这个规范，将来我用 GRUB for DOS 来实现 ISO 的引导，当然也得用这个规范。假定 SHSUCDHD.EXE 确实是用的这个规范，那么，它就很难跟 BCDL 以及 SBM 这类程序糅合在一起。一个硬，一个软，完全南辕北辄了。

我粗略看了 SHSUCDHD.EXE 的程序，里面到处充满的对于 DOS 的 HACK。他大概是要恢复 DOS 修改了的中断向量，或者别的什么。总之，读起来很费劲。没有时间去仔细研究它了。我将来在 GRUB 中编程，也不用它，我直接用上面说的“可引导的 CDROM 规范”。

我在 GRUB 中要实现的，就是这样一种糅合：把现在两种引导方式都统一处理，作出一种“终极”的完美解决。

这里的瓶颈，就是 BCDL 以及 SBM 所采用的硬件规范，这是导致硬软不能统一的根本原因。勉强把两张皮贴在一起，也不是没有可能的，但，其花费的力气不是较小的，而可能是巨大的，得不偿失。重新编程，可能是比较容易的。

不采用硬件规范，而是写一个 BIOS 的补丁程序，把光盘扇区的读出函数加入到 int 13h 中，这样一了百了，什么问题都没有了。在 ISO 文件的情形，我们甚至还可以写入 ISO 文件！！这对于从一个空的 img 文件制作出一个新的 ISO 文件是有用的。我所描绘的这个前景是美好的吧？当然实现起来，也是比较费时的了。

谢谢各位提供的背景资料，欢迎继续发表高见。

由于没有BCDL的源代码和详细的工作原理说明文件，所以至于BCDL所期望的是“软的”还是“硬的”，确实无法说明。

不过，如果GRUB针对BIOS写补丁程序的话，虽然可能实现一些非常美好的功能，但是，由于BIOS的光盘读功能本来就没有标准，GRUB的此补丁能做到通用吗？还有，如果BIOS本身就不支持光盘引导功能怎么办（比如我的那台电脑就是）？