古いDOS TUIをncursesに移植する

Question

90年代前半にMS-DOS用に書かれた古いC++プログラムを移植する方法についてアドバイスをしたいと思います。

このプログラムは、非常に複雑なテキストユーザーインターフェイスを実装しています。インタフェースコードはロジックとは完全に分離されているので、ncursesを使用するのは難しくありません。

1. は、DOSプログラムをインターセプトがマウスイベントを処理するために、0x33のを中断：

   は完全な初心者なので、私はいくつかの質問を持っています。割り込みハンドラは、メインプログラムが定期的に格納するFIFOにイベントを格納します。 （FIFO内のすべての要素は、イベントの性質、マウスの位置、ボタンの状態に関する情報を含むC構造体です）コードのロジックを変更しないために、無限ループ内で非同期的にgetch（）を呼び出し、古いプログラムと同じ方法でFIFOを埋めます。私の考えは、このスレッドとこのスレッドだけがstdinにアクセスするべきですが、メインスレッドはstdout（add_wch（）などを介して）にアクセスする必要があります。 ncursesはこの方法で安全に使用できますか、またはstdin/stdoutアクセスは常に同じスレッド内で行う必要がありますか？

2. このアプリでの色の設定方法は、「継承されたパレット」という概念を使用しているため、非常にビザンチンです。基本的に、ウィンドウは通常背景色と前景色を指定し、そのウィンドウ内のすべてのウィジェットは前景のみを設定します（しかし、いくつかのウィジェットはfg/bgの両方を再定義します）。 ncursesのattr（）は常に、initp（）を使って初期化しなければならないペアを使って色を指定したいと考えています。これはこのプログラムのロジックではうまくいきません。したがって、プログラムがfg/bgの色をそれぞれ変更したいときに、tiparm（）を使ってsetaf/setbfシーケンスを直接送信することを考えています。 （setaf/setbfをサポートしていない端末でコードを実行する能力がなくなりますが、これは大きな損失ではありません）setaf/setbf制御シーケンスを送信してからadd_wch（）や後者はattr（）に関連してのみ使用されるべきですか？

   私のアイデアが機能しているかどうかを確認するためのテストスクリプトをいくつか書くことができますが、このアプローチが常に動作するはずです。

ありがとうございました！

Answer 1

あり多くの可能性があります - しかし、アプローチがadd_wchの言及を除いて、むしろ呪いより（低レベル）のterminfo のような音を説明。むしろtiparmより、呪いアプリケーションは、I/Oが1つのスレッドでなければならないwattr_set、init_pair、start_colorなど

のncursesを使用します。 ncursesは（mutexをいくつかの場所で使用することによって）助けるためにコンパイルすることができますが、パッケージャはそれを無視していました（そして、その設定でさえ、アプリケーション開発者は依然として作業するでしょう）。

さらに読書：

• curses color manipulation routines
• curses character and window attribute control routines
• curses thread support