中国DOS联盟

LLM 解释

---

技术背景与原理分析

在 DOS 时代，软件显示中文主要有两种截然不同的技术路径。雨露提到的 DiskGenius（原名 DiskMan）以及 SPFDisk、Norton Utilities 8.0 等软件，之所以能实现“无需外挂中文平台”显示汉字，主要是基于以下技术实现：

1. 图形模式下的点阵绘图（Graphics Mode Rendering）

这是 DiskGenius 等软件最常用的方法。

• 实现原理：软件运行后，会通过 BIOS 中断（如 INT 10H, AX=0013H 或 VESA 模式）切换到图形显示模式。在这种模式下，屏幕不再由硬件字符发生器控制，而是由软件直接操控每一个像素点。
• 内建字库：软件内部集成了一套精简的字模数据（通常是 16x16 点阵）。当程序需要显示汉字时，它会根据汉字的 GB 码（内码）计算出该字在内建字库中的偏移量，然后按照点阵位图（Bitmap）的方式，将像素逐一“画”在显示缓冲区中。
• 为何“没异样”：在反汇编或十六进制编辑器中查看主程序时，你看到的中文短语是内码（编码），而显示效果靠的是字模（数据）。如果你修改了编码（如将中文改为英文），程序逻辑依然会去查找对应字符的点阵，只不过因为你改成了 ASCII 字符，它可能调用了内置的英文点阵绘制函数。

2. VGA/EGA 软字体加载技术（VGA Soft Font / Bit-Mapped Text Mode）

如帖子中提到的 VTM、VT技术 或 acios：

• 实现原理：DOS 字符模式（Text Mode）下，VGA 显卡允许用户自定义显示字符的字形（Font RAM）。这种技术通过修改显卡的字符发生器 RAM，将原本 256 个字符中的部分（通常是高 128 个字符或利用多个字符平面）替换为汉字点阵。
• 局限性：标准 VGA 文本模式只能同时显示 256 或 512 个不同的字符。对于包含数千汉字的中文环境来说不够用，但对于界面固定的工具软件（如 SPFDisk），只需要提取界面用到的几十个特定汉字，将其定义为“自定义字符”即可在文本模式下显示中文。

3. 关于“汉化”与“字符提取”的误区

雨露在帖子中提到，将 DiskGenius 中的中文改为英文后软件正常运行，这证明了软件的逻辑架构：

• 编码转换：软件内部处理的是字符串。在中文版中，字符串存储的是 GBK/GB2312 编码；在英文版中，存储的是 ASCII 编码。
• 渲染逻辑：软件的渲染引擎（Drawing Engine）会判断当前要输出的字符。如果是 ASCII 字符，则调用 BIOS 字体或内置 8x16 字体；如果是双字节字符，则调用内置的 16x16 汉字字库进行绘图。
• 汉化难点：正如雨露所述，中文短语通常比英文短语占用的字节空间更少（例如“确定”占 4 字节，而“OK”仅占 2 字节，“Confirm”则占 7 字节）。在汉化英文软件时，常因目标位置空间不足导致无法直接修改，需要进行复杂的指针重定向（Long Jump）或扩充扇区处理。

4. 关于 FreeDOS command.com 的兼容性

在帖子后期讨论中提及的 FreeDOS 与 MS-DOS 兼容性问题，源于两者的内部实现差异：

• COMSPEC 与环境块：FreeDOS 的 command.com 在内存管理和环境变量的处理上与微软版本不完全一致。
• 延迟变量处理：FreeDOS 对批处理文件的解析逻辑更接近于后期的增强型 shell，导致某些依赖于 MS-DOS 错误特性的批处理代码在 FreeDOS 下表现不同。
• 引导与初始化：DOS 启动时，内核（IO.SYS/KERNEL.SYS）会传递特定的数据结构给 command.com。如果内核版本与命令解析器版本不匹配（如 MS-DOS 7.1 内核去加载 FreeDOS 的 command.com），常会因环境变量初始化失败而导致无法定位自身路径。

总结

DiskGenius 这类软件本质上是“自带驱动与字库”的自包含程序。它们不依赖操作系统的显示服务，而是直接操作显示硬件。这种做法在当年的优点是兼容性极强（不挑中文平台），缺点是增加了主程序的体积，且无法支持第三方输入法。