将旧的DOS TUI移植到ncurses [英] Porting an old DOS TUI to ncurses
问题描述
我想对如何移植90年代初为MS-DOS编写的旧C ++程序提供一些建议.
I would like to have some advice about how to port an old C++ program written for MS-DOS in the early 90s.
该程序实现了一个非常复杂的文本用户界面.接口代码与逻辑完全分开，我认为使用ncurses不会太困难.
This program implements a quite complex text-user interface. The interface code is well separated from the logic, and I don't think it would be too difficult to make it use ncurses.
作为一个完整的新手，我有几个问题:
Being a complete novice, I have a few questions:
-
DOS程序拦截中断0x33来处理鼠标事件.中断处理程序将事件存储在FIFO中，主程序会定期对其进行缓冲. (FIFO中的每个元素都是一个C结构，其中包含有关事件的性质，鼠标的位置及其按钮的状态的信息.)为了保持代码的逻辑不变，我正在考虑触发一个线程，该线程调用getch()在无限循环内异步进行，并以与旧程序相同的方式填充FIFO.我的想法是，该线程(仅该线程)应该访问stdin，而主线程仅负责访问stdout(通过add_wch()和类似方法). ncurses是否以这种方式安全使用，还是需要始终在同一线程内完成stdin/stdout访问?
The DOS program intercepts interrupt 0x33 to handle mouse events. The interrupt handler store events in a FIFO, which the main program pools periodically. (Every element in the FIFO is a C structure containing information about the nature of the event, the position of the mouse and the state of its buttons.) To keep the logic of the code unchanged, I was thinking of firing a thread which calls getch() asynchronously within an infinite loop and fills the FIFO in the same way the old program did. My idea is that this thread, and only this thread, should access stdin, while the main thread would only have the responsibility to access stdout (through add_wch() and similar). Is ncurses safe to use in this way, or do stdin/stdout accesses need to be always done within the same thread?
在此应用中设置颜色的方式非常简单，因为它使用了继承的调色板"的概念.基本上，一个窗口通常指定背景色和前景颜色，并且该窗口中的每个小部件都仅设置前景(但是一些小部件重新定义了fg/bg).我知道ncurses的attr()总是要使用成对指定颜色，必须使用initp()进行初始化，这与该程序的逻辑不能很好地配合.因此，我考虑在程序要分别更改fg/bg颜色时，使用tiparm()直接发送setaf/setbf序列. (我将失去在不支持setaf/setbf的终端上运行代码的能力，但这不会造成很大的损失.)发送setaf/setbf控制序列然后调用诸如add_wch()之类的函数是否安全?后者应该仅与attr()一起使用吗?
The way colors are set in this app is quite byzantine, as it uses the concept of "inherited palettes". Basically, a window usually specifies the background and foreground colors, and every widget within that window sets the foreground only (but a few widgets redefine both fg/bg). I understand that ncurses' attr() always wants to specify colors using pairs, which must be initialized using initp(), and this doesn't play nicely with the logic of this program. I am therefore thinking of using tiparm() to directly send setaf/setbf sequences when the program wants to change the fg/bg color, respectively. (I would lose the ability to run the code on terminals which do not support setaf/setbf, but this would not be a huge loss.) Is it safe to send setaf/setbf control sequences and then call functions like add_wch(), or should the latter be used only in association with attr()?
我可以编写一些测试脚本来检查我的想法是否有效，但是我不确定这种方法是否应该一直有效.
I could write a few test scripts to check that my ideas work, but I would not be sure that this approach is supposed to work always.
感谢您的帮助！
推荐答案
有很多可能性-但所描述的方法听起来像 terminfo (低级)，而不是 curses ，除了提及add_wch. curses应用程序将使用wattr_set，init_pair，start_color等，而不是tiparm.
There's a lot of possibilities - but the approach described sounds like terminfo (low-level) rather than curses, except for the mention of add_wch. Rather than tiparm, a curses application would use wattr_set, init_pair, start_color, etc.
ncurses I/O必须在一个线程中；尽管可以编译ncurses来提供帮助(通过在某些地方使用互斥锁)，但打包程序通常忽略了这一点(即使使用该配置，应用程序开发人员仍然有工作要做).
ncurses I/O has to be in one thread; while ncurses can be compiled to help (by using mutexes in some places), packagers have generally ignored that (and even with that configuration, application developers still would have work to do).
进一步阅读:
cursescolor manipulation routinescursescharacter and window attribute control routinescursesthread support
这篇关于将旧的DOS TUI移植到ncurses的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
