标题: Q-系 驅 動 有 潛 在 的 臭 蟲 [打印本页]
作者: johnsonlam 时间: 2007-5-29 13:25 标题: Q-系 驅 動 有 潛 在 的 臭 蟲
由 於 我 不 大 懂 匯 編 的 中 文 詞 彙 ， 請 有 心 人 幫 忙 翻 譯 一 下 ， 謝 謝 !
=-=-=-=-=-=
Serious problems have been noted in the current QHIMEM, QCACHE/QDMA and
QCDROM drivers.
QHIMEM is written to return an error code of zero, meaning no error, on
all XMS requests which are successful. This error code is returned in
the BL-register. However, the V3.0 XMS Specification states that all
CPU registers are to be saved and restored by an XMS driver, when it is
called by DOS programs to do XMS requests.
It is unclear, from the V3.0 Specification, that when XMS errors do not
occur, the BL-register should NOT be modified. For most DOS programs,
this is no problem. But a few programs such as "I_CACHE" require that
the BX-register must NOT change, if XMS errors do not occur. If those
programs are run with QHIMEM, the programs may fail.
QCACHE/QDMA/QCDROM are all written to do I-O for disk and CD/DVD drives
anywhere in DOS memory, including upper-memory past 640K. QCACHE will
deal with upper-memory by converting its address "segment" and "offset"
to a 20-bit memory address. Then, it uses the 20-bit address with its
own "Fast XMS" logic in moving data to or from upper-memory.
The problem is that upper-memory may have been "mapped", with EMM386 or
an equivalent "EMS" driver, to physical addresses that are NOT the same
as its "segment" address! For example, upper-memory with a "segment"
of D000h and "offset" of 0400h will be accessed by QCACHE at a physical
32-bit address of 000D0400h. If EMM386 etc. has "mapped" this memory
to a true 32-bit address that is NOT 000D0400h, I-O requests will fail.
QDMA/QCDROM do not contain their own "Fast XMS" logic and must call the
XMS manager (QHIMEM, HIMEM, etc.) to do an XMS data "move". But, they
must tell the XMS manager the "segment" and "offset" address for upper-
memory that was given to them by the user program. XMS managers were
NOT designed for "moves" to DOS upper-memory, and most will NOT convert
the "segment" address to its true 32-bit physical address. So, again,
I-O requests will fail.
作者: wang6610 时间: 2007-5-29 14:27
按香港的繁体中文译就可以，都能看懂。
作者: johnsonlam 时间: 2007-5-29 15:32
| Quote: | |
|
問 題 是 : 在 香 港 通 常 都 不 譯 ， 看 不 懂 就 要 問 人 ， 資 訊 以 口 傳 遞 。
我 的 中 文 只 是 一 般 ， 得 坐 下 來 譯 個 多 小 時 ， 稍 等 有 空 才 能 搞 ...
作者: 本是 时间: 2007-5-29 16:58
草译如下：
目前的 QHIMEM、QCACHE/QDMA 和 QCDROM 驱动程序发现存在严重问题。
按设计，QHIMEM 返回错误代码0，表示无错，在所有的 XMS 调用上是成功的。错误代码在 BL 寄存器中返回。然而，3.0版的XMS规范中说明：一旦有DOS程序通过XMS驱动程序来实现XMS调用，所有的 CPU 寄存器由 XMS 驱动程序保存并恢复。
目前尚不清楚，从 V3.0 说明看，当 XMS 不发生错误时， BL 寄存器应该是否被修改。对大多数 DOS 程序而言，这不是问题。但是象"I_CACHE"这样的一些程序要求，如果 XMS 不发生错误，BX 寄存器不能发生变化。如果那些程序在 QHIMEM 之后运行，程序可以失败。
QCACHE/QDMA/QCDROM 全部设计为在内存中完成磁盘和CD/DVD的I-O操作，包括 640K以上的高位内存。QCACHE 处理内存的方式是，将段地址：偏移地址转换成20位的内存地址。然后，它以“自己的快速XMS”逻辑用20位地址移动数据到上位内存或从上位内存移走数据。
问题是上位内存可能是“映射”而来的，是从 EMM386 或类似的EMS驱动程序映射来的与它的段地址不同的物理地址！例如，有 D000h“段”和 0400h “偏移”的上位内存将被 QCACHE 在 000D0400h 的一个物理的 32 位的地址存取。如果 EMM386 等等“映射”了内存到不是 000D0400h 的一个真实的 32 位的地址，I-O 请求将失败。
QDMA/QCDROM 不包含“他们的自己的快速XMS”逻辑，必须调用 XMS 管理器 ( QHIMEM，HIMEM，等等。）来完成 XMS 数据“搬移”。但是，他们必须告诉 XMS 管理器由用户程序给他们的上位内存的“段”和“偏移”地址。而XMS 管理器并没为设计成“搬移”到DOS的上位内存，而且它们大多数将不变换“段”地址到真实的32 位物理地址。因此，I-O 请求将再次失败。
作者: johnsonlam 时间: 2007-5-29 17:44
感 謝 本 是 兄 ， 譯 得 真 好 !