标题: 不点请进，GRUB for DOS的bug [打印本页]
作者: Wengier 时间: 2003-9-25 00:00 标题: 不点请进，GRUB for DOS的bug
今天我在真实模式（非虚拟机中）下对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”字样后就死机了。
作者: 不点 时间: 2003-9-25 00:00
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 的。
作者: Wengier 时间: 2003-9-26 00:00
非常希望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 不能建立长文件名。”
[此贴子已经被作者于2003-9-27 2:30:31编辑过]
作者: 不点 时间: 2003-9-26 00:00
有 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 用户而言。
作者: Wengier 时间: 2003-9-27 00:00
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-27 7:29:09编辑过]
作者: Wengier 时间: 2003-9-28 00:00
| Quote: | |
|
我觉得如果对每个驱动程序或TSR程序进行类似的hack的话，必定是非常复杂而且永远也不可能做到最完美（因为各种驱动/TSR程序太多了）。不知能不能给GRUB加入一个自动寻找和恢复被修改过的INT向量的代码来自动完成这些功能？
作者: 不点 时间: 2003-9-28 00:00
哎, 这就对了.
我昨天把你的那个 PC ＤＯＳ 装上了, 准备对它进行 HACK, 虽然 HACK 进展还算顺利, 但是, 我停止进行下去了.原因是, 我开始感到罗嗦了. 正如你所说的一样(我们不谋而合了).
得了, 以后就不再对某个 DOS 进行 HACK 了. 要设计一个程序自动恢复中断向量.
作者: llm 时间: 2003-9-29 00:00 标题: UMB中文是叫高端内存吗？
| Quote: | |
|
我小时候看的书上写UMB称上位内存，HMA称高端内存
不知现在书上怎么写？
作者: Wengier 时间: 2003-9-30 00:00
没错，应该是：
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也同样是这样的了。
[此贴子已经被作者于2003-9-30 4:27:49编辑过]
作者: hanshen 时间: 2003-9-30 00:00
| Quote: | |
|
斑竹，如果我用光盘引导来启动系统,虚拟出软驱后,
用可以用虚拟软盘上的grub
来重新引导系统吗?
即可否虚拟软盘来重新引导系统？
作者: 不点 时间: 2003-10-1 00:00
TO Wengier:
好！证据很充足，这说服了我，虽然我对于 ME 并不了解。
TO hanshen：
没问题的。我用光盘启动到 DOS，可以运行 GRUB.exe，至于说 GRUB 在软盘的第一扇区（这个软盘是光盘上的一个软盘映象文件），自然也是可以的，这没有本质的差别。
你如果不太放心，可以用 VMWARE 或者 Virtual PC ，用 ISO 文件来测试，以免浪费你刻录光盘。
作者: Wengier 时间: 2003-10-1 00:00
| Quote: | |
|
非常希望GRUB for DOS能通过Bootable CD Loader来支持从ISO镜像文件启动，相信需要的人非常多的，不管是DOS/WIN用户，或者是Unix/Linux用户。不知最近有什么进展吗？
作者: 不点 时间: 2003-10-1 00:00 标题: 用 GRUB FOR DOS 引导 ISO 映像的问题
俄国人写的那个光盘引导程序，似乎本质上和 SBM 的方法一样，都是对于光盘的物理地址进行操作，躲过了 BIOS。所以，这个办法只能引导真实的光驱，不能引导 ISO 文件。
VMWARE 之类的软件之所以可以引导 ISO 文件，是因为它们在操作系统和硬件这一级别而对物理的 IO 端口读写进行了仿真。这在真实的情况是不可能的。我们的仿真是修改 BIOS，而其它都完全是真实的机器，所以，无法用端口读写来实现 ISO 的引导。
基于 BIOS 的 ISO 引导，这本身实现起来也不是很困难。但是，我想首先实现基于 BIOS int 的真实 CDROM 引导（而不是基于 IO 端口的 CDROM 引导）。这个工作完成之后，可能对于基于 BIOS int 的 ISO 引导有着基本的帮助。这个工作的完成，不会很快，需要一两年甚至更长。
实现 BIOS int CDROM 引导，可能提供有用的信息，帮助实现基于 BIOS int 的 ISO 引导。所以我不想首先实现后者。
作者: Roy 时间: 2003-10-1 00:00
| Quote: | |
|
其實只要bcdl.bin能載入shsucdhd.exe就可以做到了...
可是......
shsucdhd.exe要修改一下才可以...
作者: Wengier 时间: 2003-10-1 00:00
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光驱驱动程序来进行下一步的操作的。
[此贴子已经被作者于2003-10-2 7:23:50编辑过]
作者: 不点 时间: 2003-10-3 00:00 标题: 我对于这里讨论的内容，仍然感到不是很了解。
或者说，还是感到很生疏。
> 我曾用它在纯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 是不知道盘符的。
呵呵，我很糊涂，所以，说的可能也比较可笑了。如果你发现我有不清楚的概念，可以继续指出来并给以解释。
作者: Wengier 时间: 2003-10-3 00:00
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
[此贴子已经被作者于2003-10-3 22:11:13编辑过]
作者: cn_archer 时间: 2003-10-3 00:00
讨论得这么激烈，虽然偶看得懂的不多，但还是加精一下，以示佩服！
希望各位高手多多参与，带领我们早日脱菜。
作者: Roy 时间: 2003-10-3 00:00
| Quote: | |
|
可是.....重點在於shsucdhd.exe是需要himem.sys的......
[此贴子已经被Wengier于2003-10-3 23:18:43编辑过]
作者: Wengier 时间: 2003-10-3 00:00
| Quote: | |
|
其实，可以在SHSUCDHD的ASM源代码的基础上，修改成一个独立的（不需要HIMEM.SYS等）纯DOS的SYS格式的虚拟光驱驱动程序，只要它仍与MSCDEX接口兼容，那么BCDL就是可以加载它并用它来启动的。这样，从ISO文件直接启动就成功了。
[此贴子已经被作者于2003-10-3 23:20:48编辑过]
作者: 不点 时间: 2003-10-4 00:00
谢谢以上各位兄弟。我看的似乎有点明白了。我准备进一步看看 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 本身来实现，这当然是不矛盾的。
谢谢诸位，欢迎继续讨论，发表各人的高见。
作者: 不点 时间: 2003-10-4 00:00
| Quote: | ||||
|
这是又一层障碍了。HIMEM 也是微软的。虽然标准本身不是微软的，但微软的 himem 是事实工业标准。
SHSUCDHD 启用扩展内存，说明问题比较复杂。我已经失去信心了。剥离它是可能的，但要花费力气的。目前缺乏的是时间。
作者: Wengier 时间: 2003-10-4 00:00
| Quote: | |
|
我刚才自己试了一下，发现SHSUCDHD.EXE并不需要HIMEM.SYS或其它XMS扩展内存驱动程序，而是本来就是可以独立使用的。所以Roy上面说的“shsucdhd.exe是需要himem.sys的”是不正确的。因此根本不需要剥离或改写。
[此贴子已经被作者于2003-10-4 20:48:55编辑过]
作者: Roy 时间: 2003-10-4 00:00
| Quote: | |
|
そう、そう。。。(對啊,對啊...)
我確實弄錯了一些了.....
現在...我在這裡,
鄭重的說一句:
ごめんなさい！(對不起!)
作者: cn_archer 时间: 2003-10-4 00:00
Roy最近在学日语啊！还是从小看日本动漫学来的？
作者: Roy 时间: 2003-10-4 00:00
| Quote: | |
|
哈......兩者都是呢.....
作者: Wengier 时间: 2003-10-5 00:00
| Quote: | |
|
据我观察，这种担心似乎是不必要的，因为以下两点：
1：BCDL之所以使用DOS的MSCDEX兼容标准，只是因为它用一个DOS光驱驱动程序来走捷径，既避免了自己写光驱驱动程序，又可以适应更多的光驱（因为那个DOS光驱驱动程序是可以更换的）；但这并非说BCDL就是进行MSCDEX的操作，而是只是利用与MSCDEX兼容的各种DOS光驱驱动程序来先驱动光驱这一捷径，然后使用自己的代码（类BIOS虚拟法，而并非MSCDEX法）来完成相应的光驱的引导，而并不会提供或使用新的中断；
2：BCDL在进行第4步（即最后一步）时，当真正实现启动光驱前，会恢复和重置所有DOS中断（包括那个先加载的DOS光驱驱动程序），所以可以说不会对已成功启动的光盘上的程序的运行造成任何影响。这是我长期测试和使用后的一些发现。
综上所述，再加上SHSUCDHD.EXE本身就是可以独立使用的（而不需HIMEM.SYS等），所以如果将它转换为SYS的话，那应该能直接被BCDL加载吧。。
[此贴子已经被作者于2003-10-5 3:56:51编辑过]
作者: 如是大师 时间: 2003-10-5 00:00
学到东西了！支持啊！请继续。。我们联盟太需要这样的讨论了。。
作者: 不点 时间: 2003-10-5 00:00
| Quote: | |
|
问题的关键是，真实光驱的驱动程序和 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 文件是有用的。我所描绘的这个前景是美好的吧？当然实现起来，也是比较费时的了。
谢谢各位提供的背景资料，欢迎继续发表高见。
作者: Wengier 时间: 2003-10-7 00:00
由于没有BCDL的源代码和详细的工作原理说明文件，所以至于BCDL所期望的是“软的”还是“硬的”，确实无法说明。
不过，如果GRUB针对BIOS写补丁程序的话，虽然可能实现一些非常美好的功能，但是，由于BIOS的光盘读功能本来就没有标准，GRUB的此补丁能做到通用吗？还有，如果BIOS本身就不支持光盘引导功能怎么办（比如我的那台电脑就是）？
作者: 不点 时间: 2003-10-7 00:00
> 由于没有BCDL的源代码和详细的工作原理说明文件，所以至于BCDL所期望的是“软的”还是“硬的”，确实无法说明。
它要引导真实光驱，又假定它无法使用 BIOS 本身的光驱引导程序，那么，它大概也只有这一个办法了，用硬件 IO 标准 ATAPI 来实现。不排除它也同时实现软的方法，但，那可能性太小了，它如果实现了软的方法，那么它应当顺便就实现了 ISO 文件的引导。或者说，实现软的方法，其目的就是实现 ISO 文件的引导。
> 不过，如果GRUB针对BIOS写补丁程序的话，虽然可能实现一些非常美好的功能，但是，由于BIOS的光盘读功能本来就没有标准，GRUB的此补丁能做到通用吗？还有，如果BIOS本身就不支持光盘引导功能怎么办（比如我的那台电脑就是）？
GRUB 做出补丁的话，当然是 GRUB 自己的调用方法了（放在 int 13h 中），跟谁的都不一样；也没有谁的曾经出现过，所以，想跟它一样都不可能了。既然是 GRUB 自己的，当然就统一了。只要使用 GRUB，就会有这个统一的补丁。不使用 GRUB 的话，当然没有了。
GRUB 的补丁，就是要把 BIOS 里面的光盘扇区函数找出来，这些函数，可能不是以 int 的形式出现的，GRUB 补丁的意图，就是把这些函数封装到 int 13h 之中。如果某个主板对此进行加密（不太可能这么做），那我们就可能无法找到这个函数，这样，我们当然就放弃对这类主板的支持。我的机器是华硕的主板，看来这个函数比较容易找到，现在已经有点眉目了，只是没有时间去做。
如果 BIOS 本身都不支持，那么，当然没有这样的函数了。放弃对这个主板的支持。
在 GNU GRUB 的 TODO 列表中也有这样明确的暗示，要求 BIOS 本身必须支持光盘引导。看来 GNU GRUB 的开发者也是这么考虑的，其思路可能和我们的是一样的。
当如上所说无法支持某个主板的时候，我们是指不支持从真实光驱引导。从 ISO 文件引导完全是支持的，这个与 BIOS 是否支持光驱引导无关。ISO 文件是软的，使用“可引导的 CDROM 标准”。
要想在那些主板之下支持真实光驱引导，可以选择 SBM 或者 BCDL。两个都是漂亮的软件。GRUB 不可能代替它们。
作者: Wengier 时间: 2003-10-7 00:00
我这几天发现BCDL最新的3.0版也推出了，它显然扩充了自身的灵活性。具体情况是，它自动在C:\下查找以下文件：
VIDE-CDD.SYS （IDE/ATAPI光驱驱动）
USB_CD.SYS （USB光驱驱动）
USBASPI.SYS + ASPICD.SYS （USB光驱驱动）
ASPI2/4/7/8DOS.SYS + ASPICD.SYS （SCSI/ASPI光驱驱动）
等等。。。
可见，BCDL.BIN并非通过硬件方法将驱动定死在IDE/ATAPI光驱上，而是通过从网上到处拼凑一些各种类型（如SCSI、USB等）的光驱驱动程序来实现其相应光驱的引导的。说不定哪天BCDL真会通过SHSUCDHD来实现ISO文件的引导呢？
作者: 不点 时间: 2003-10-7 00:00
那些光驱的驱动程序，应当都是用 ATAPI 硬件标准的。实现 ISO 文件的引导是不难的，别说有了 BCDL 以及 SBM 等，即便是没有它们，那么白手起家－－用可引导的 CDROM 标准－－也可以编写 ISO 的引导程序。引导 CDROM 同时需要上述两个标准。
GRUB 当然也可以加入对 ATAPI 标准的支持从而引导 CDROM。但是，那样的代价是，代码增大到不可接受的程度。这还是小事，更重要的，可能没有人去写了。即使把 SBM 的程序移植过来，都是相当不容易的。
我们现在的 GRUB 仿真程序，代码只有 1K，将来加入 CDROM、ISO 的支持，估计要增大到 2K 甚至 3K 了（仅就 int13的处理程序而言）。
如果用 ATAPI 标准把光驱的引导给以实现，那么，BIOS 中的CDROM 引导程序就不能得到有效的利用，这也是一种损失。
如果把 CDROM 的 int13 接口予以实现，那么，我们在 DOS 下不需要任何驱动程序，仅仅像对硬盘那样使用 int13 就可以任意访问光盘上的扇区了。这是用 ATAPI 硬件方法所不可能得到的、一个非常革命性的优点。
ATAPI 的方法，本质上只对老的 BIOS 才有价值【这些 BIOS 不能引导 CDROM】。我认为，支持老的 BIOS 以及老的 CPU 如 286，是意义不大的。
－－－－－－－－－－－
补充一下。似乎看到有人说某些 SCSI 光驱的主板，本身就可以把光驱当作硬盘来使用，是把光驱当作 BIOS 的硬盘号如 0x83 来实现。在 BIOS 设置程序中可以设置是否把光驱当作硬盘。
也许，不久之后，IDE 的光驱也会这么做的。果真如此，那就太方便了，也就不用我们再去 HACK 了。现在刷新 BIOS 是很方便的。也许我们应该等待，而不是急于去编写什么。我最害怕作无用功了。
有个人写了 BIOS 优化程序，是用来刷新 BIOS 的。也许我们可以等待他写出新的程序，将 CDROM 的补丁加入其中，这不就省事儿了？果真如此，我们也就只剩下编写从 ISO 文件来引导的程序了。所以，也许，应当只干这 ISO 文件的工作，这样，就不会白干了。
[此贴子已经被作者于2003-10-7 22:26:02编辑过]
作者: hunome 时间: 2003-10-9 00:00
有没有可能和bcdl的作者联系一下呢？
作者: 不点 时间: 2003-10-10 00:00
> 有没有可能和bcdl的作者联系一下呢？
应当是可能的. 这个我不擅长, 不知道 wengier 能否.
有硬件的驱动, 再加入软件的驱动, 比较容易. 而从软件的驱动, 再去做硬件的驱动, 比较难.
我的意思是说, BCDL 或 SBM 的作者, 可以比较容易地加入 ISO 的仿真支持, 而别人不容易加入对 CDROM 硬件的支持. 硬件规范理解起来难, 而软件标准要容易理解一些.
作者: xiaojun 时间: 2003-10-10 00:00
[em04][em04][em04]
[em04][em04][em04]
[此贴子已经被作者于2003-10-14 0:41:41编辑过]
作者: Gandalf 时间: 2004-8-11 00:00
其实，我个人猜测，BCDL 没有驻留于内存。他首先从当一个 dos 系统功能的提供者，然后把光驱的驱动载入；此刻，这个 sys 业已提供了一个 atapi 的微驱动;那么, 那些系统服务也就用不上了; 此刻,就可以像由 BIOS 的从光驱启动一样使用一个驱动器号对光盘进行访问啦.
作者: fujianabc 时间: 2004-8-11 00:00
其实个人觉得，就算支持iso文件模拟光驱，意义也不大，原因如下：
光盘启动有三种模式：模拟软盘启动、模拟硬盘启动、无模拟启动
对于前两种模拟启动，grub已能支持，所以只需要把光盘内的镜像提取出来即可，
而至于无模拟启动模式的iso文件，现在所见到的其实只有2k/xp/pe系列的光盘，就算能够模拟光驱启动，也只是基于bios的模拟，而2k/xp/pe不是基于bios的系统，就算能够模拟成功，也只能完成启动过程，无法完成进入操作系统。这就如同2k/xp/pe下不能访问grub所模拟的软驱一样，同理grub所模拟硬盘和光盘也无法进入winpe。 而从bcdl的引导原理来看，却可以从中得到借鉴，有可能(?)用类似的原理实现从不支持u盘启动的主板上启动u盘。
作者: dato 时间: 2004-8-11 00:00
那现在的版本能不能将iso镜像模拟，然后直接在DOS安装。而不需要将镜像解包才能安装。
作者: fujianabc 时间: 2004-8-11 00:00
现在不能模拟iso，但可以这样，提取出iso的启动镜像，先用虚拟软驱启动，然后加载dos下的虚拟光驱程序，再从iso开始安装。或许可以建议版主做成一个 img+iso 更方便，其中在img内完成虚拟光驱加载iso文件的步骤。
作者: newjordan2004 时间: 2004-8-12 00:00
请问版主怎么样才能使用虚拟机?因为本人装不了MS-DOS7.10,所以想用虚拟机玩,版主帮帮忙~~~
作者: 不点 时间: 2004-8-14 00:00
修改别人写的程序是痛苦的, 我最近在看 edd30, myint13h 等模块, 发现其中有不少错误, 同时也感觉到很难全面把握其编程思想, DOC很不详细.
我现在重又想起我以前的观点了, 就是 HACK BIOS, 直接找出 CDROM 的扇区函数. 这样虽然也难, 但至少是我自己编写的, 我自己可以读懂, 这是肯定的了.
我先HACK我自己机器上的 BIOS, 成功之后积累经验, 再 HACK 办公室机器上的 BIOS. 并且把 HACK 的方法公开出来, 然后别人也可以用类似的方法进行 HACK 了. 在理想的情况下, 所有的 BIOS 都可以支持了.
有源代码不见得就比没有源代码容易. 我的华硕主板的 BIOS, 即便用 DEBUG, 都非常清楚, 可是 edd30 以及 myint13 等程序, 看起来太乱了, 也很臃肿.
作者: bush 时间: 2004-8-25 00:00
有用~~~