将旧的 DOS TUI 移植到 ncurses答案

【问题标题】：Porting an old DOS TUI to ncurses将旧的 DOS TUI 移植到 ncurses
【发布时间】：2017-03-28 17:30:59
【问题描述】：

我想就如何移植 90 年代初为 MS-DOS 编写的旧 C++ 程序提供一些建议。

这个程序实现了一个相当复杂的文本用户界面。接口代码和逻辑分离得很好，我觉得用ncurses做起来也不会太难。

作为一个新手，我有几个问题：

DOS 程序拦截中断 0x33 来处理鼠标事件。中断处理程序将事件存储在 FIFO 中，主程序会定期汇集这些事件。（FIFO 中的每个元素都是一个 C 结构，包含有关事件性质、鼠标位置和按钮状态的信息。）为了保持代码逻辑不变，我正在考虑触发一个线程，该线程调用getch() 在无限循环中异步执行，并以与旧程序相同的方式填充 FIFO。我的想法是这个线程，只有这个线程，应该访问标准输入，而主线程只负责访问标准输出（通过 add_wch() 和类似的方法）。以这种方式使用 ncurses 是否安全，或者 stdin/stdout 访问是否需要始终在同一个线程中完成？
这个应用程序的颜色设置方式非常拜占庭式，因为它使用了“继承调色板”的概念。基本上，一个窗口通常指定背景色和前景色，并且该窗口中的每个小部件仅设置前景（但一些小部件重新定义了 fg/bg）。我知道 ncurses 的 attr() 总是希望使用对指定颜色，必须使用 initp() 对其进行初始化，这与该程序的逻辑不符。因此，当程序想要分别更改 fg/bg 颜色时，我正在考虑使用tiparm() 直接发送 setaf/setbf 序列。（我会失去在不支持 setaf/setbf 的终端上运行代码的能力，但这不会是一个巨大的损失。）发送 setaf/setbf 控制序列然后调用像 add_wch() 这样的函数是否安全，或者后者应该只与 attr() 一起使用吗？

我可以编写一些测试脚本来检查我的想法是否有效，但我不确定这种方法是否应该始终有效。

感谢您的帮助！

【问题讨论】：

标签： terminal cross-platform ncurses

【解决方案1】：

有很多可能性 - 但除了提到 add_wch 之外，所描述的方法听起来像 terminfo（低级）而不是 curses。除了tiparm，curses 应用程序将使用wattr_set、init_pair、start_color 等。

ncurses I/O 必须在一个线程中；虽然可以编译 ncurses 以提供帮助（通过在某些地方使用互斥锁），但打包人员通常会忽略这一点（即使使用这种配置，应用程序开发人员仍然需要做一些工作）。

进一步阅读：

【讨论】：

你对terminfo的评论是对的，其实我主要对ncurses的getch函数感兴趣。它的实现似乎远非微不足道。如果我理解您的评论，在主线程中使用低级 terminfo 函数和 printf 并在事件线程中使用 getch 就可以了，因为所有 ncurses 函数（实际上只是这个函数）都将被调用线。这是正确的吗？
getch 不是低级函数（它是 curses 库的一部分，必须使用 initscr 或 newterm 初始化，并且将使用其他 curses 更新屏幕 -库函数）。即使使用帮助线程化的 ncurses 配置，tparm、tputs 等使用的低级数据仍然需要互斥锁。
非常感谢 Thomas，这正是我需要的信息（尽管这不是我所希望的……）。