DOSBox-X项目中的SFT表实现问题分析与修复

背景介绍

DOSBox-X是一款开源的DOS模拟器，近期在实现系统文件表(SFT)功能时遇到了一个严重问题：当运行Windows 3.1系统并尝试退出时，系统会崩溃并抛出"无效操作码"异常。这个问题源于对SFT表实现方式的修改。

问题现象

开发人员发现，当启用新的SFT表实现代码时，Windows 3.1在386增强模式下退出时会崩溃，系统日志中会记录大量"无效操作码"异常。而恢复到旧版代码后，问题消失。

技术分析

SFT表的作用

系统文件表(SFT)是MS-DOS中用于跟踪所有打开文件的数据结构。它包含了文件句柄、文件属性、文件位置指针等关键信息。Windows 3.1在运行期间高度依赖SFT表来管理文件操作。

问题根源

经过深入分析，发现Windows 3.1对SFT表有以下特殊要求：

1. 段地址匹配：第一个SFT表必须与"信息块"(info block)位于同一内存段中
2. 特殊文件条目：SFT表中必须包含CON、AUX、PRN等特殊设备的条目
3. 字符串匹配：Windows 3.1会检查"CON"字符串在SFT表中出现三次

新版实现未能满足这些特殊要求，导致Windows 3.1在退出时无法正确处理文件资源而崩溃。

解决方案

开发团队采取了以下修复措施：

1. 分离SFT表结构：将固定部分(包含CON等特殊设备)与动态部分分开处理
2. 内存布局优化：确保SFT表不再与其他关键数据结构(如FCB SFT和CON驱动)重叠
3. 字符串匹配实现：在第一个SFT表中正确放置"CON"字符串三次

兼容性验证

修复后，不仅解决了Windows 3.1的崩溃问题，还验证了之前受影响的游戏(如Dunkle Schatten 2)也能正常运行。这表明新的SFT实现既满足了Windows的特殊需求，又保持了与DOS游戏的兼容性。

技术启示

这个案例展示了模拟器开发中的典型挑战：

1. 历史系统往往依赖未公开的实现细节
2. 看似简单的数据结构可能隐藏着复杂的兼容性要求
3. 在保持功能正确性的同时，必须注意内存布局的安全性

通过深入研究真实MS-DOS的行为并逆向分析Windows 3.1的预期，开发团队最终找到了平衡功能与兼容性的解决方案。