LLM 解释
在 1980 年代至 2000 年代初期的 DOS 环境中，实现自动化按键操作是一项成熟的技术，通常被称为“键盘宏”（Keyboard Macro）或“按键脚本”。针对原贴中提到的在 DOS 业务系统运行的同时模拟按键需求，其核心技术实现与环境限制如下：
1. 技术核心：TSR（终止并驻留）程序
在单任务的 DOS 环境下，要让一个自动化程序与业务系统同时运行，该自动化程序必须以 TSR（Terminate and Stay Resident）模式存在。其工作原理通常是拦截 INT 09H（硬件键盘中断）或 INT 16H（ BIOS 键盘服务中断）。
-
INT 16H 拦截法：这是最常见的实现方式。自动化程序通过挂钩（Hook）INT 16H，当业务系统调用该中断尝试从键盘缓冲区读取字符时，TSR 程序不等待物理按键，而是直接将预设的扫描码（Scan Code）或 ASCII 码填入返回寄存器。
-
键盘缓冲区注入法：DOS 系统在内存低位（0040:001A 至 0040:001D）维护一个循环队列作为键盘缓冲区。TSR 程序可以定时（利用 INT 08H 定时器中断）检查缓冲区状态，并在必要时直接改写缓冲区内存，实现“自动打字”的效果。
2. 历史上的解决方案与工具
在 2010 年该贴讨论时，虽然 Windows 平台已有“按键精灵”等成熟软件，但纯 DOS 下主要依赖以下几类工具：
-
专用宏工具：如 SuperKey、ProKey 或 KeyWorks。这些是 1980-90 年代流行的商业或共享软件，允许用户录制按键序列并分配给特定的热键触发，支持循环执行和简单的延时。
-
批处理增强工具：一些扩展工具如 STACKER 或 SENDKEYS（非 Windows 版），可以在启动业务系统前将特定按键压入键盘堆栈，但通常只能处理启动初期的输入，难以处理复杂的逻辑循环。
-
自定义 C/汇编程序：对于特定业务流程（如原贴提到的“上下移动+回车”），当年的开发者通常会编写简单的 C 或汇编程序，挂载 INT 08H 计数，达到特定间隔后向 INT 16H 注入按键。
3. 技术限制与兼容性风险
尽管技术上可行，但在实际的 DOS 生产环境中存在以下限制：
-
直接访问硬件冲突：如果业务系统为了追求性能，跳过了 BIOS 中断（INT 16H）直接通过 I/O 端口（60H/64H）读取键盘控制器的原始数据，那么基于中断拦截的 TSR 脚本将完全失效。
-
内存空间限制（640KB）：TSR 程序会占用常规内存。如果业务系统本身很大，加载自动化工具可能导致内存不足（Out of Memory）或系统挂起。
-
时序同步问题：DOS 是非抢占式环境。如果自动化程序发送按键的速度快于业务系统的处理速度（例如数据库查询未完成时即按下 Enter），会导致输入错乱或缓冲区溢出。
4. 现代模拟环境下的替代方案
若该 DOS 系统运行在虚拟机（如 VMware, VirtualBox）或模拟器（如 DOSBox）中，通常不再需要在 DOS 内部编写 TSR。
-
DOSBox：可以通过外部脚本工具（如 AutoHotkey）直接向 DOSBox 窗口发送指令。
-
虚拟化平台：利用宿主机的自动化 API（如 Python 的
pyautogui）可以跨越操作系统边界实现按键注入，这比在 DOS 内部实现驻留程序更稳定且易于调试。
总结而言，原贴讨论的需求在 DOS 时代是通过 TSR 挂钩 INT 16H 来实现的。在现今维护旧系统时，建议优先考虑在宿主环境进行自动化模拟，而非编写底层的 DOS 驻留代码。
