经典DOS游戏64号存款问题的C语言整数溢出分析与修复

1. 项目背景与核心价值

"64号存款问题"是上世纪90年代流行于DOS系统的一款经典文字冒险游戏的隐藏Bug代号。这个用Turbo C 2.0编写的游戏因存款计算模块的整数溢出错误，导致玩家在第64次存取操作时账户余额异常。作为早期计算机教育中的经典案例，它不仅反映了早期程序员对边界条件处理的疏忽，更成为理解C语言内存管理和数值运算的活教材。

我在整理旧书时偶然发现了一张1994年的3.5英寸软盘，里面保存着这个游戏的完整源代码。通过现代IDE（如VS Code）重新编译运行时，发现除了原始的逻辑错误外，还存在字符编码兼容性、DOS API调用失效等典型跨代问题。修复这类"数字考古"项目，不仅能还原计算发展史的真实片段，对理解以下核心概念尤其有帮助：

• 16位到32位系统的整数表示差异
• 早期C编译器对未定义行为的处理方式
• 面向硬件编程时代的代码优化技巧

2. 原始代码问题诊断

2.1 64号存款问题的本质

游戏使用16位整型变量存储玩家金币，关键代码如下：

c复制unsigned int gold = 32767; // 初始资金
void deposit(int amount) {
    gold += amount;
    if(gold > 65535) gold = 65535; // 防止溢出
}

表面看有溢出保护，但存在三个致命缺陷：

1. 使用无符号整型却用有符号数比较（gold > 65535永远为假）
2. 存款次数计数器也是16位整型，在第32768次操作时会发生回绕
3. DOS环境下的Turbo C默认将int视为16位，与现代编译器的32位int产生行为差异

2.2 跨时代环境差异问题

在Windows 10+VS Code环境下运行时暴露的新问题：

1. 文本渲染乱码：原代码使用IBM PC扩展ASCII码绘制边框（如0xB3表示竖线），现代终端多采用UTF-8编码
2. 输入处理失效：依赖BIOS中断的getch()实现（int 0x16）在保护模式下无法工作
3. 延时函数崩溃：基于8253定时器端口（0x40）的精确延时在现代系统会触发保护异常

3. 系统性修复方案

3.1 数据层修复

将关键变量升级为显式长度类型：
`