中国DOS联盟

Gemini 解答

---

技术背景与实现分析

该编辑器是1995年基于Turbo C 3.0开发的DOS/Windows两用繁体中文文书工具，核心实现与当时的技术环境强相关：

1. 跨环境运行的本质

• DOS下：依赖ET3中文系统提供的VGA文字模式扩展（如16×16点阵繁体汉字显示），需通过中断调用（如int 10h显示、int 21h键盘输入）与硬件交互。
• Windows下：实际运行在**Windows 3.x/9x的DOS虚拟机（VDM）**中，而非原生Windows图形程序。Windows仅提供内存管理与硬件抽象，编辑器仍通过DOS中断模拟完成输入输出——这是90年代“DOS/Windows两用”程序的典型妥协方案（当时Windows图形API尚未普及，且Turbo C 3.0对Win32支持有限）。

2. 编译与构建逻辑

• 使用we.bat批处理编译，符合Turbo C 3.0的项目管理习惯（通过.prj或直接调用tcc.exe链接多个模块）。2-3万行代码分为十余个模块，可能包括：
  • 核心编辑引擎（缓冲区管理、光标移动、文本操作）；
  • 中文输入输出层（对接ET3的中断调用）；
  • 菜单与帮助系统（读取.HLP/.M2D等文本资源）；
  • 跨环境适配层（判断当前运行环境，切换中断调用方式）。

3. 中文支持的局限性

• 依赖ET3中文系统是当时的常见选择（ET3是台湾流行的DOS中文平台，提供点阵字库与输入法），但不兼容其他中文系统（如UCDOS、天汇）——这源于DOS中文系统的封闭性：不同厂商通过修改硬件中断、占用内存区域实现汉字显示，缺乏统一标准。
• 简繁转换需手动修改.HLP/.M2D，因为程序未内置字库或编码转换逻辑，仅读取纯文本资源。

4. 历史语境下的“奇怪副档名”

.1ST/.HLP等“奇怪副档名”是当时节省磁盘空间的习惯（避免与系统工具冲突，或通过自定义副档名标识资源类型），本质为ASCII文本文件，可直接用记事本打开——这在DOS时代（文件名仅8+3字符）非常普遍。

后续建议的技术合理性

跟帖用户提到的XMS内存支持与分割窗口功能，是DOS编辑器的典型增强方向：

• XMS支持：DOS传统使用640KB以下的常规内存（Conventional Memory），大文件编辑易受限制。通过HIMEM.SYS调用XMS（扩展内存），可将文本缓冲区移至1MB以上，解决大文件卡顿问题——这需要修改内存管理模块，调用int 2fh（XMS管理器中断）分配扩展内存。
• 分割窗口：需在VGA文字模式下划分多个显示区域（如上下分屏），独立管理每个区域的光标与缓冲区同步。Turbo C 3.0的conio.h库支持基本的窗口操作（如window()函数），但中文点阵（16×16）需调整窗口坐标计算（避免字符显示错位）。

历史误解与补充说明

• 所谓“Windows下直接打开”并非原生支持，而是依赖VDM的兼容性——Windows NT/2000后VDM逐渐弱化，该程序在现代Windows中可能无法运行（需通过DOSBox模拟）。
• 当年“DOS/Windows两用”的宣传易让用户误解为“原生跨平台”，实际是利用Windows对DOS的向后兼容，并非真正的图形化程序。

现代使用建议

若需复现或修改该程序，需：

1. 在DOSBox中模拟环境（加载ET3中文系统）；
2. 使用Turbo C 3.0（或兼容编译器如Open Watcom）编译；
3. 简体化需替换.HLP/.M2D中的繁体字符，并确保DOS中文系统支持简体字库（如替换ET3为UCDOS）。

该程序是90年代台湾DOS中文软件生态的典型样本，反映了当时开发者在硬件限制、中文支持与跨环境兼容之间的权衡。