中国DOS联盟

Gemini 解答

---

运行 UCDOS 启动脚本 UC.BAT 导致系统彻底死机（挂起），且排除 EMM386 的影响后依然出现，通常由以下几个确定性的底层技术原因导致：

1. 显卡显示驱动（DISP 模块）与硬件/模拟环境冲突

这是 UCDOS 启动挂起最常见的原因。

• 底层机制：UCDOS 在启动时，UC.BAT 会依次加载汉字字模检索、输入法以及核心的显示驱动（通常命名为 DISP*.EXE，例如 DISPVGA.EXE、DISPET.EXE、DISP64.EXE 等）。这些驱动为了提升中文点阵渲染速度，往往绕过 BIOS INT 10h 中断，直接向显示适配器的 I/O 端口（如 3C0h–3DAh 等 VGA/SVGA 寄存器）读写数据，甚至直接修改显存寻址窗口。
• 死机原因：
  • 早期多合一整合包（如 tau 或各类 3-in-1）为了适应当时某些特定显卡（如 ET4000、Trident 8900/9000、S3 系列），在批处理中可能硬编码了特定的非标驱动。若当前运行环境是现代集成显卡、独立显卡，或是 VMware、VirtualBox 等虚拟机，硬件对这些非标特定寄存器指令无法响应或模拟失真，导致总线周期挂起或直接引发硬件挂起。
• 排查方法：单步运行（在 DOS 启动时按 F8，或在批处理中加入 PAUSE），观察具体停在哪一个 DISP 驱动。如果是显卡驱动导致，应换用最基础的标准 VGA 640×480 16色驱动（如通用的 DISPVGA.EXE）或支持 VESA 标准的通用驱动（如 DISPVESA.EXE）。

2. 多合一整合包（250KB 极小体积）的精简缺陷

原帖提及的“250KB 三合一/四合一”属于高度精简版（Mini 版）。标准的完整 UCDOS 7.0 仅核心与字库就需要数兆字节。

• 共享字库与文件缺失：极小体积的整合包通常剔除了标准字库（如 16 点阵字库 HZK16、西文字库 ASC16 等），改用国标矢量轮廓或高度压缩的字库，甚至强行让 UCDOS、天汇（TW）、中国龙共用一套修改过的字模。
• 空指针与中断未捕获：UCDOS 的部分 TSR（内存常驻）程序鲁棒性较差，若初始化阶段在指定路径未读取到预期大小的字库或配置文件，未能正确退出，而是继续执行后续初始化，使用未赋值的内存指针挂接中断（如 INT 10h、INT 16h、INT 2Fh），一旦触发相关中断，CPU 执行跳转至无效地址（如 0000:0000 区域），引发死机。

3. 多系统切换造成的中断向量链断裂（TSR 冲突）

帖中提到了 QUIT.COM，这揭示了多合一汉字系统的固有隐患：

• 中断拦截链污染：天汇、UCDOS 等中文 DOS 平台启动后，均会深度劫持 INT 10h（显示服务）、INT 16h（键盘服务）、INT 2Fh（多路复用中断）、INT 09h（键盘硬件中断）等关键向量。
• 恢复失败：若用户此前在该会话中运行过天汇或其它 DOS 工具，随后直接调用 UC.BAT（或者虽然使用了 QUIT.COM 卸载，但因加载顺序交错导致中断向量未恢复到最初的系统状态），UCDOS 启动时再次挂接这些中断，就会形成中断链循环调用，最终导致堆栈溢出（Stack Overflow）死机。
• 验证前提：纯净测试必须在冷启动或干净重启（Clean Boot）后，不运行任何其他汉字系统，直接测试 UC.BAT。

4. 现代高主频 CPU 的时序竞态问题

若测试环境为真实的高主频现代 PC（如 Pentium 4 之后或千兆赫兹级 CPU）运行 MS-DOS：

• 部分 UCDOS 附带的输入法模块、辅助 TSR，其内部延时循环依赖 CPU 计数循环（类似于早年 Borland Pascal CRT 经典的“Runtime error 200”机制，但部分汇编实现中直接因为超高速除法产生溢出中断，或者因硬件 I/O 读写未插入适当的 I/O delay 而导致外设状态机紊乱）。
• 这种时序错误在纯 MS-DOS 裸机环境下体现为直接冻结（Freezing），不报任何错误代码。