中国DOS联盟

-- 联合DOS 推动DOS 发展DOS --

联盟域名：www.cn-dos.net 论坛域名：www.cn-dos.net/forum
DOS，代表着自由开放与发展，我们努力起来，学习FreeDOS和Linux的自由开放与GNU精神，共同创造和发展美好的自由与GNU GPL世界吧！

中国DOS联盟论坛 » DOS开发编程 & 发展交流（开发室） » QHIMEM V3.8 Readme翻译

Walkman
新手上路

积分 18
发帖 8
注册 2007-1-10
状态离线

『楼主』: QHIMEM V3.8 Readme翻译

译者注：尝试翻译一下。不过由于DOS很多名词没有翻译的标准词语，微软的知识库也是恶心的机器翻译，我只能随意挑一种。为免误解，以下列出几个词汇对照：
upper memory——上位内存
low memory——下位内存
shadow RAM——影子内存
handle——句柄
……
相信不用翻译，大家都明白这些是什么东西，但是这不是缩写，不翻好像有点说不过去。这些中文翻译词自己看到都觉得有点恶心，请诸位按照自己的需要自行替换。
另外这仅是翻译文稿，难免有未能道尽作者原意的地方，仅供参考，一切以原英文文本为准。由于语言功力不足，DOS专业知识底子也不厚，离“信雅达”还有很大距离，请各位多多包涵指正。
以下是翻译原文：

                     QHIMEM -- DOS XMS管理器, V3.8
                  ===================================
1. 描述
   QHIMEM是一个对应DOS的扩展（XMS）内存管理驱动程序。它是HIMEM，FDXMS及其它同类驱动程序的代替品。

   QHIMEM积极支持由Uwe Sieber所编写的版本号3.70或以上的UMBPCI驱动。很多用户喜欢使用UMBPCI，因为它所占用的内存远比EMM386少。如果首先加载UMBPCI，其后QHIMEM就可以直接加载到上位内存当中。如此一来QHIMEM就可以为DOS系统同时提供上位和XMS内存。它包含了一个类似QDBOOT的“IO捕捉器”，可以捕捉640K之上软盘和硬盘的IO请求。为免在UMBPCI的“影子内存”内引起DMA错误，此类IO是通过下位内存的DOS工作空间缓冲区完成的。在一个仅限XMS访问的小型系统中，如果UMBPCI并未加载，QHIMEM默认不包含IO捕捉器并加载到下位内存。QHIMEM一般情况下占用2496字节的UMBPCI的上位内存，处理32个XMS句柄，最高可达占用3456字节，处理128个句柄。QHIMEM自身不需要任何“启动”驱程，也不需为磁盘加载QDBOOT/QDREL，不占用任何下位内存！当QHIMEM按默认加载到下位内存时，它占用2048字节，处理32个XMS句柄，最高可达3008字节，128个句柄。
   QHIMEM同时支持4.49版和4.95版的EMM386（对应MS-DOS 6.22或7.10）和JEMM驱动。它提供10字节XMS句柄和“EMM386”类驱动所需的其它部件。JEMM386/EMM386需要XMS管理程序先行加载，因此QHIMEM首先使用/B开关以“启动”模式加载。此时它占据某一临时内存空间。在JEMM386/EMM386加载完成并开始工作后，不使用/B参数把QHIMEM自身加载到上位内存。然后它复制所有之前的临时数据，并从自己的“启动”模式部分那里接管XMS方面的操作。由于QHIMEM的正常32个XMS句柄，仅占用384字节的下位内存，JEMM386/EMM386可以在一个固定的地址访问到这些句柄。所有其它QHIMEM的逻辑代码驻留在上位内存里，使得DOS用户可以在640K以下地址的内存空间里运行更大的程序。当被自身“启动”部分加载时，QHIMEM占用1728字节上位内存，和384到1344字节的下位内存（用于它那32到128个句柄的表格）。如果XMS的安装初始化被DOS延迟至QHIMEM加载后才开始，可能需要额外的240到480字节的上位内存。同UMBPCI介绍部分一样，和“EMM386”类驱动一同工作时，QHIMEM可以单独加载进下位内存（不先行加载“启动”部分）。此时它占用2048字节，处理32个XMS句柄，最高可达3008字节，处理128个句柄。
   3.8及以上版本的QHIMEM现在设置特定的DOS驱动名字，以表示它是以何种方式加载的。如果使用了/H开关且驱动加载到UMBPCI上位内存，一个驱动名为“XMSUUU0”的32字节长的驱动头将驻留于下位内存。那么自动安装脚本可以通过“if exist XMSUUUU0”来判定UMBPCI和QHIMEM是否按先后顺序被加载。/H和“头”是必需的，因为除此之外UMBPCI和QHIMEM在下位内存并未留下任何东西。如果驱动是按默认值（没有UMBPCI）或是单独加载的，它的名字将会是XMSXXXX0，跟MS-DOS HIMEM一样。当使用/B开关，驱动以“启动”模式进入上位内存，它在下位内存的句柄表会被命名为XMSBOOT0，驱动名则是XMSXXXX0。这样，自动安装脚本就可以通过"if exist XMSBOOT0"测试是否“启动”加载，通过"if exist XMSXXXX0"测试驱动的本身情况。
   QHIMEM是按照XMS 3.0规范编写的，可以处理高达4GB的XMS内存。80386或以上的CPU及最少512K扩展内存是必须条件。任意拥有至少两兆字节RAM的系统可以使用QHIMEM。对于如何使用/N开关设置XMS句柄，以及其它开关的用法，请看下面第4部分。关于QHIMEM更多的介绍，请参阅下面第7部分。
   3.8及以上的QHIMEM增加了以上所说的驱动名支持。非常感谢Erwin Veermans提供这样一个有用的点子。4.8及以上的QCACHE和4.2及以上的QCDROM已升级至能够识别3.8及以上的QHIMEM，并能继续利用它的“快速XMS操作”逻辑代码。

***注意***
由于在FreeDOS论坛上不断出现令人不快的帖子，禁止将本驱动和FreeDOS一起使用。自此于该系统中加载本驱动，将会失败退出。在其它DOS系统（如MS-DOS, EDR-DOS等）使用本驱程并未受到任何影响,依旧能获取技术支持。

2. 无担保声明
QHIMEM以现有状况作为免费软件供您使用，请自担风险。并且不作任何担保，更未有基于任何目的的商业或适应性的暗示担保！

任何关于驱动的问题或评论可以访问Johnson Lam的网站<johnson@tmfc.net>。居住于美国的QHIMEM的作者将尽力回复，并保持驱动程序正常运行。

3. 版本更新记录

V3.8  2007年1月14日 QHIMEM现在设置特定的驱动名字，以方便自动安装脚本的使用。感谢Erwin Veermans提供的这个点子。

V3.7  2007年1月9日更正QHIMEM设置128个句柄的错误。
V3.6  2007年1月4日 QHIMEM现在成为一个多合一驱动！
V3.5  2006年12月31日如果找不到UMBPCI的存在，QXHIMEM将加载至下位内存。感谢Erwin Veermans提供的这个点子。
V3.4  2006年12月17日  QXHIMEM支持UMBPCI和JEMM386/EMM386。
V3.3  2006年12月6日  由于3.70 UMBPCI已支持QXHIMEM，删除QXUMBPCI。感谢Uwe Sieber！禁止在FreeDOS上使用本驱动！
V3.2  2006年10月30日  增加 "多合一" QXHIMEM驱动和QXUMBPCI.
V3.1  2006年8月15日  在QHMBOOT/QHIMEM中更正一个严重的句柄错误。
V3.0  2006年8月7日  为了完全的支持EMM386，增加QHIMEM2和QHMBOOT2。
V2.9  2006年7月31日  更正可能存在的QHIMEM "Int 2Fh/15h"逻辑错误。
V2.8  2006年7月11日  更快的“XMS操作”逻辑代码以供QDMA和QCDROM使用。
V2.7  2006年6月27日  修正如果/N无效，QHIMEM "132 Handles"的错误。
V2.6  2006年6月23日  QHMBOOT的内存区域可以通过/M开关来设置。
V2.5  2006年6月4日  QHIMEM对应老式CPU增加/386和/486开关。
V2.4  2006年7月1日增加/T开关和更佳的扩展内存逻辑代码。
V2.3  2006年5月7日  QHIMEM现在仅占用64字节的下位内存。
V2.2  2006年5月6日  更正QHIMEM中影响EMM386的 "VDS lock"错误。
V2.1  2006年5月1日  为支持EMM386，QHIMEM/QHMBOOT更新至V2.1。
V1.4  2006年4月29日  添加“重分配（reallocates)”以实现对XMS V3.0规范的完整支持。
V1.3  2006年4月22日  空句柄逻辑代码修正。小幅的速度提升。
V1.2  2006年4月15日  更正一大一小两个错误。
V1.1  2006年4月13日  增加4GB处理能力，实现大部分符合XMS 3.0规范的逻辑代码。
V1.0  2006年4月10日  初始版本。

4. 开关选项

QHIMEM使用以下开关选项：

/386
/486 这两个开关指出当前系统使用80386或80486的旧式CPU。486之后的CPU无需这两个选项。当使用“启动”模式的时候，这两个开关会被“启动”驱程所忽略。必须在稍后的正式驱动加载时使用。
/B 指定使用“启动”模式。/B使驱程加载到临时的内存空间，直到稍后加载的UMBPCI或EMM386允许上位内存访问为止。没有/B，驱动将加载到正常的内存，并从它的“启动”部分那里接管XMS的处理功能。请参阅下面第5部分的config.sys范例。
/H 要求QHIMEM如果在UMBPCI后加载，在下位内存中留下一个名叫“XMSUUUU0”的32字节长的DOS驱动名。当跟UMBPCI一同使用，而又没有/H开关时，驱动不会使用任何下位内存。/H开关帮助自动安装脚本测试UMBPCI和QHIMEM是否一同加载。如果UMBPCI没有加载或加载不正确，驱动将会忽略此参数。
/Mn 指定一个临时的内存空间，用于在“启动”模式中加载驱动，或用于在DOS开启工作空间缓冲区之前处理UMBPCI上位内存的IO。可选值为：
   /M1 = 00010300h (64K).    /M5 = 00050300h (320K).
   /M2 = 00020300h (128K).    /M6 = 00060300h (384K).
   /M3 = 00030300h (192K).    /M7 = 00070300h (448K).
   /M4 = 00040300h (256K).    /M8 = 00080300h (512K).
   如果没有/M开关，驱动默认选择/M5，使用320K区域。请注意某些DOS系统并不从地址0开始加载，通常它们的临时数据在内存中四处散布！/Mn开关允许调整驱动的临时内存区域，以找到一个可以安全使用的区域。如果不和UMBPCI一起使用，也不是在“启动”模式，驱动会忽略/M开关。
/Nnn 指明DOS程序可以使用多少个XMS句柄。数值可以是32，48，64，96或128。没有/N开关，缺省默认值是32。如果开关/T指明使用BIOS “E820h”请求测试，且驱动单独或与UMBPCI一同加载，将设定48为最小值。在“启动”模式中，任意/N的值，从32到128，均可接受，并且在稍后的正常驱动加载中用到该值。32个句柄在大多数DOS系统中良好运行，某些进行大量XMS操作的大系统可能需要更多的句柄数。
/Tn 指明驱动为得到扩展内存而尝试作出以下的BIOS请求：
/T1 仅进行"E820h"请求。
/T2 仅进行"E801h"请求。
/T3 先尝试"E820h"请求，然后再尝试"E801h"请求。
/T4 仅进行旧式64MB请求。
/T5 先尝试"E820h"请求，再尝试旧式64-MB请求。
/T6 先尝试"E801h"请求, 再尝试旧式64-MB请求。
/T7 先尝试"E820h"请求, 然后尝试"E801h"请求, 最后尝试旧式64-MB请求。
通常情况下可以省略/T开关，因为默认是/T6。如需关于BIOS请求的详情，以及何时使用/T开关，请参阅下面第7部分。在“启动”模式中，“启动”驱动必须使用/T开关，因为它必须先行测试上位内存。当在加载驱动主体时忽略任何的/T参数。
/W 如果和UMBPCI一同加载，指明使用DOS工作空间缓冲区处理上位内存IO。此种情况下必须使用DOS 5.0或以上或类似的DOS系统。当省略/W开关时，要么正在使用一个老式的DOS系统，要么DOS并未提供“工作空间”功能，此时QHIMEM将在下位内存中设置一个512字节的缓冲区和一个32字节的头。当不与UMBPCI一同使用时，驱动忽略/W开关。

对于所有开关，用户可以根据喜好使用“-”代替“/”，开关中的字母均非大小写敏感。

5. 安装和配置

QHIMEM在config.sys中被加载。因此你的config.sys应该有类似这样的一行：DEVICE [HIGH] = [路径] QHIMEM.SYS [/386] [/486] [/B] [/Mn] [/Nnn] [/Tn] [/W]

例子：  DEVICE=C:\BIN\QHIMEM /N48 /W

      DEVICE=C:\DOS\QHIMEM.SYS /M6 /T7 /B

      DEVICEHIGH=C:\BIN\QHIMEM.SYS /486

当3.70或以上的UMBPCI和QHIMEM一同使用时，不需要“启动”驱程。在这种情况下，UMBPCI先行加载，允许访问上位内存，然后QHIMEM为DOS和其它驱动程序提供上位内存和XMS内存。JEMM386/EMM386是可选组件。在一个仅使用XMS的系统中，可以省略UMBPCI。
以下是一个3.70或以上的UMBPCI与QHIMEM一同使用的config.sys例子：
   SHELL=C:\DOS\COMMAND.COM C:\DOS /E:512 /P
   DEVICE=C:\BIN\UMBPCI.SYS                         [可省略]
   DEVICE=C:\BIN\QHIMEM /N32 /W
   DOS=HIGH,UMB
   DEVICE=C:\BIN\EMM386.EXE I=B000-B7FF X=C400-EFFF NOEMS [可选行]
   DEVICEHIGH=C:\BIN\QCACHE.SYS /F /L
   DEVICEHIGH=C:\BIN\QCDROM.SYS /D:CDROM1 /UF /L
      ..
      ..  等等
      ..

如果单独加载QHIMEM，它必须是第一个加载的DOS驱动，且它必须在下位内存中加载，如下面的例子：
   SHELL=C:\DOS\COMMAND.COM C:\DOS /E:512 /P
   DEVICE=C:\BIN\QHIMEM.SYS /N32
   DOS=HIGH,UMB
   DEVICE=C:\DOS\EMM386.EXE I=B000-B7FF NOEMS       [或JEMM386等等]
      ..
      ..  等等
      ..

当QHIMEM和JEMM386/EMM386一同使用时，一般情况下先以“启动”模式加载QHIMEM，然后加载EMM驱动，最后QHIMEM加载到上位内存。由于EMM驱动并未把“影子内存”用作上位内存，因此QCACHE/QDMA/QCDROM无需使用/L开关。下面是一个使用QHIMEM“启动”过程的config.sys范例：
   SHELL=C:\DOS\COMMAND.COM C:\DOS /E:512 /P
   DEVICE=C:\BIN\QHIMEM.SYS /N32 /B
   DOS=HIGH,UMB
   DEVICE=C:\DOS\EMM386.EXE I=B000-B7FF NOEMS       [或JEMM386等等]
   DEVICEHIGH=C:\BIN\QHIMEM.SYS
   DEVICEHIGH=C:\BIN\QCACHE.SYS /F
   DEVICEHIGH=C:\BIN\QCDROM.SYS /D:CDROM1 /UF
      ..
      ..  等等
      ..

请注意，如果使用EMM驱动，通常无需使用QDBOOT/QDREL，QHIMEM只会在UMBPCI已加载的情况下设置它的IO捕捉器。如果一个罕见的系统需要IO捕捉器来处理上位内存IO，QHIMEM也可以如下例那样加载QDBOOT/QDREL：
   SHELL=C:\DOS\COMMAND.COM C:\DOS /E:512 /P
   DEVICE=C:\BIN\QHIMEM.SYS /N32 /B
   DOS=HIGH,UMB
   DEVICE=C:\BIN\QDBOOT.SYS /R /W
   DEVICE=C:\DOS\EMM386.EXE I=B000-B7FF NOEMS    [或JEMM386/UMBPCI]
   DEVICEHIGH=C:\BIN\QDREL.SYS                   [只对应QDBOOT /R]
   DEVICEHIGH=C:\BIN\QHIMEM.SYS
   DEVICEHIGH=C:\BIN\QDMA.SYS /F /X /L          [或如上例那样使用QCACHE]
   DEVICEHIGH=C:\BIN\QCDROM.SYS /D:CDROM1 /UF /L
   DEVICEHIGH=C:\BIN\QCACHE.SYS /N                [当和QDMA一起时指明/N开关]
      ..
      ..  等等
      ..

在本例中，带有/B的QHIMEM暂时处理XMS请求，然后QDBOOT（如果使用）把驱动安全的加载到上位内存中。接下来加载EMM386/UMBPCI以允许上位内存访问。QDREL（如果使用）可以把QDBOOT的指令放进上位内存。接下来加载QHIMEM的主体。QCACHE（或QDMA，和QCACHE一起使用时）应该在QHIMEM之后加载，这样它就可以请求它的XMS缓冲区。当使用QCDROM的时候，它必须在QCAHCE（或QDMA，如果也用上）之后，才能共享该XMS缓冲区。QCACHE驱动必须在QDMA或其它单独的磁盘驱动后加载。当没有其它磁盘驱动时，QCACHE可以直接在QHIMEM之后加载。请参阅QDMA和QCDROM的说明文件以获取更多的信息。其它所有在config.sys中加载的驱动（SETVER.exe，ANSI.SYS等）可按任意次序加载。

6. 错误返回

QHIMEM返回标准XMS规范的错误码。这些错误码在XMS 3.0规范中有详细的说明。用户可以从微软或其它网站获取XMS 3.0规范的文档。

7. 特别说明事项
在已加载UMBPCI的情况下，QHIMEM在上位内存未向DOS系统声明之前已经加载进去。QHIMEM所占用的内存并不是DOS内存列表的一部分，因而QHIMEM所占用的内存并未在内存占用列表中直接列出。请注意，内存占用显示UMBPCI的占用空间是某个内存块中偏移量009Ch（如果多于32个XMS句柄偏移量更大）开始的。QHIMEM占用的就是由于这个偏移量而被上位内存跳过的部分空间。

BIOS程序支持三种扩展内存请求。现代的BIOS系统一般可以接受全部三种，但有部分可能不行，且在94年之前生产的BIOS仅能接受旧式的请求！QHIMEM通过/T开关指明需要用到哪几种BIOS扩展内存请求。这三种是：
   A) BIOS "Int 15h, AX=E820h"请求，提供所有内存区域的列表。ROM，ACPI，映射的IO或其它在任何地址的不可使用的内存“洞”均记录在案。这是最新（1995）和最好的BIOS方法。"E820h"请求相对复杂，需要更多逻辑代码，因此必须使用/T开关才能使用该请求。
   B) BIOS "Int 15h, AX=E801h"请求，返回低于和高于16MB地址的两个内存范围。该请求可以产生一个低于16MB地址的内存“洞”。任何跨越16MB地址的内存“洞”将会限制内存的上限。当BIOS不接受"E820h"请求的时候，就会转而使用这个请求。QHIMEM把这个请求作为标准请求，因为该请求需要编写较少的逻辑代码且能在绝大多数现代系统中良好工作。找到的内存数量稍微比"E820h"请求少，因为它只返回16MB地址以上满65K的内存块而忽略剩下的零碎区域。
   C) BIOS "Int 15h, AH=88h"请求，返回一个最高可达64MB地址的内存范围。任何在64MB地址之下的内存“洞”将会限制该内存范围的边界。这是旧式（1980）方法。通常用于旧式系统，或"E820h"和"E801h"请求均遭到拒绝的场合。

用户可以首先尝试不使用/T开关的QHIMEM，因为默认的/T6值会先尝试使用"E801h"请求来查找可用内存，在有需要的情况下再使用旧式64MB请求。如果不使用/T引起错误，或没有找到所有的XMS内存，用户可以单独的尝试/T4, /T2和/T1，以确定哪一种请求为其BIOS所接受。1994年前出产的BIOS应该会忽略"E801h"请求，然后接受旧式64MB请求。如果不行，这种旧式系统需使用/T4来加载QHIMEM。

按照XMS 3.0规范，直到第一个驱动请求后内存才开始安装初始化。单独加载或与UMBPCI共用时，QHIMEM把XMS安装初始化代码临时保存到它的XMS句柄表中。因此使用"E820h"请求的逻辑代码需要48项句柄表，当不使用"E820h"请求时32项句柄表已足够。当QHIMEM以“启动”模式加载时，XMS安装初始化逻辑代码不需要使用QHIMEM在下位内存中的XMS句柄表（该逻辑代码和它的“启动”部分一同存放在某个临时内存区域），因此当与JEMM386/EMM386共用时，使用32项句柄表就可以了。

QHIMEM使用/386和/486开关来指明当前系统使用旧式CPU。在保护模式下，XMS操作是由BIOS完成的，但某些BIOS代码是在关中断的状态下处理XMS操作的！为了避免“丢失”任何中断，XMS驱动把XMS操作分为多个小数据段来处理，在每个小数据段之间开中断。奔腾, AMD K5/K6/K7/Athlon，和其它更新的CPU已经足够快允许处理16K大小的数据段。486CPU需要割成4K的数据段，而386CPU则需要割成1K的数据段，使得它们不会关中断太久！实模式操作，如和UMBPCI共用时，则不受影响。处于“启动”模式中的QHIMEM对所有CPU临时使用1K的数据段。直到“启动”模式过后加载驱动主体时才可能需要/386和/486开关。

2007-3-31 05:20