LLM 解释
项目背景与技术前提
SEAL、Qube、WinTix 等 DOS 图形界面（GUI）增强程序的核心是绕过传统 DOS 文本模式（如 80×25），直接操作 VGA 等显卡的图形模式（如 320×200 256色、640×480 16色），通过软件渲染实现窗口、按钮等界面元素。这类程序对中文的“支持不好”本质是缺乏中文点阵字库、双字节字符（DBCS）处理逻辑，以及与中文输入系统的接口——这是国外开发者未考虑的本地化需求。
DOS GUI 中文支持的核心技术挑战
-
中文点阵字库嵌入
DOS GUI 程序依赖自身携带的西文字库（通常是 8×8、16×16 点阵），而中文需要至少 16×16 点阵（简体）或 24×24 点阵（繁体）的字库文件（如 .FON、.HZ 或自定义格式）。需解决：
- 字库体积：16×16 简体中文字库（含 GB2312 6763 个字符）约 16KB×2 = 32KB（单色），24×24 则需 72KB，需平衡程序体积与显示效果；
- 字库渲染：图形模式下需将点阵数据逐像素绘制到显存（如 VGA 的 0xA0000 段），需处理“字符宽高”与“窗口布局”的适配（如中文占 2 个西文字符宽度）。
-
双字节字符（DBCS）处理
西文 GUI 仅需处理单字节 ASCII 字符，而中文需识别“高字节（>0x80）+ 低字节”的双字节序列：
- 文本渲染逻辑需修改：在绘制字符串时，需判断当前字节是否为高字节，若为则合并下一字节作为完整中文字符；
- 文本布局调整：中文输入框、标签等控件需支持“双字节字符宽度”，避免字符截断或错位（如输入框光标需按 2 个像素单位移动）。
-
中文输入系统接口适配
DOS 下中文输入依赖第三方平台（如 UCDOS、天汇、超想）提供的 INT 16H 中断钩子（替代 DOS 标准键盘中断，处理拼音/五笔等输入逻辑）。需解决：
- 程序需保留对 INT 16H 的调用，而非直接读取键盘端口（否则会绕过中文输入平台）；
- 图形界面需实现“输入候选框”的渲染（如在光标处弹出候选列表），或依赖中文平台提供的“悬浮候选窗”（需平台支持图形模式下的显示）。
-
图形模式与中文平台的兼容性
部分中文平台（如早期 UCDOS）仅在特定图形模式下稳定（如 320×200 256色），若 GUI 程序使用非标准模式（如 640×480 256色），可能导致中文输入或显示异常——这是当年常见的“玄学”问题，本质是中文平台对显卡寄存器的操作与 GUI 程序冲突。
当年可行的实现路径（基于公开技术）
-
字库嵌入与渲染
- 提取 UCDOS 等合法中文平台的点阵字库（需注意版权），或使用公开的开源中文字库（如早期的
HZK16）；
- 在 GUI 程序的文本渲染函数中添加 DBCS 判断：若当前字节
>=0xA1（GB2312 高字节起始），则读取下一字节，组合为汉字内码，再从字库中索引对应的点阵数据。
-
输入接口适配
- 保留程序对
int 16h ah=00h/01h（读取键盘）的调用，而非直接访问 0x60 端口；
- 若程序支持自定义输入回调，可对接中文平台的 API（如 UCDOS 的
INT 16h ah=4Ch 获取输入字符）。
-
兼容性优化
- 优先适配 VGA 标准图形模式（如 320×200 256色），减少与中文平台的显卡冲突；
- 避免直接修改显卡的“模式控制寄存器”（如 VGA 的
0x3D8），改用 BIOS 调用 int 10h ah=00h 设置图形模式（兼容性更好）。
历史局限性与常见误解
当年开发者常遇到的“中文显示乱码”“输入无响应”问题，多源于：
-
未处理 DBCS 边界：如字符串截断在双字节中间，导致后续字符解析错误；
-
字库索引错误：GB2312 内码需转换为字库偏移量（公式：
偏移量 = ((高字节 - 0xA1) * 94 + (低字节 - 0xA1)) * 点阵大小），若公式错误会显示随机点阵；
-
直接访问硬件：部分 GUI 程序为追求效率，直接读取键盘端口或修改显卡寄存器，绕过了中文平台的中断钩子，导致输入失效。
后续讨论的补充
跟帖中提到的“DOS 游戏创意”虽与本项目直接关联度低，但 DOS 游戏的中文本地化（如《仙剑奇侠传》DOS 版）其实采用了类似逻辑：嵌入中文字库、处理 DBCS 渲染、适配中文输入——这为 DOS GUI 中文支持提供了可参考的实践案例。
若需进一步推进，可优先从 SEAL 入手（其开源版本 SEAL 2.0 提供了较清晰的文本渲染接口），通过修改 text.c 等模块添加 DBCS 支持与字库加载逻辑，再验证与 UCDOS 等中文平台的兼容性。
