ターボビジョン 2.0 – 現代的なポート

15日前原文(github.com)

概要

Turbo Vision は、クラシックなテキストベースUIフレームワークの モダン移植版
クロスプラットフォーム 対応と Unicodeサポート が特徴
Linux/Windows/DOS で動作、 ソース互換性 を重視
サンプルやビルド手順、 API変更点 も詳細に解説
GitHub で公開、開発者・レトロ開発者双方に有用

Turbo Vision 2.0 モダン移植版の概要

Turbo Vision は、1990年代初頭Borlandが開発した テキストUIフレームワーク の現代版
クロスプラットフォーム （Linux/Windows/DOS）で動作、 Unicode対応
2018年末から個人プロジェクトとして開始、 2020年5月 にオープン化
レガシーコード を最小限の変更でLinux対応、 Borland C++ RTL関数 も一部実装
既存アプリの 高いソース互換性 維持、 API拡張や大規模書き換え は慎重に検討

Turbo Visionの特徴とメリット

端末依存のI/Oやワークアラウンド 不要、 一貫した動作と外観 を全環境で実現
ウィジェット（ビュー） 多数搭載：ウィンドウ、メニュー、ダイアログ、ボタン、スクロールバー等
イベントディスパッチ や 全角Unicode表示 も標準サポート
クロスプラットフォーム対応 ：#ifdef等の条件分岐なしでLinux/Windows両対応
char配列 で文字列管理、 wchar_t/TCHAR 非依存
UTF-8対応setlocale により、Windowsでも日本語ファイル名等が自然に扱える

Turbo Visionの始め方

Turbo Vision For C++ User's Guide で基本操作を習得
サンプルアプリ（hello, tvdemo, tvedit）で実践
Turbo Vision 2.0 Programming Guide （Pascalだが直感的）も推奨
パレット例 で配色の仕組みを理解
features, API changes セクションも必読

リリース・ダウンロードガイド

安定版リリースなし、最新コミット推奨
Unix系 ：自力ビルドが必要、手順は後述
Windows ：GitHub ActionsのArtifactsからバイナリ取得可能
- examples-dos32.zip：Borland C++ビルド（Unicode非対応）
- examples-x86.zip：MSVC 32bit（Vista以降）
- examples-x64.zip：MSVC 64bit（Vista以降）

ビルド環境ごとの手順

Linux
- CMake＋GCC/Clangで 静的ライブラリ 生成
- cmakeコマンドでビルド、libtvision.aと各種サンプル生成
- 必要要件：C++14対応コンパイラ、libncursesw、libgpm（任意）
- クリップボード対応：xsel/xclip（X11）、wl-clipboard（Wayland）
- アプリビルド例： g++ -std=c++14 -o hello hello.cpp ./build/libtvision.a -Iinclude -lncursesw -lgpm
- 互換ヘッダ でBorland C++ RTLをエミュレート、旧アプリ移植も容易
Windows（MSVC）
- CMakeでビルド、アーキテクチャごとにディレクトリ分け
- /MTや/MDなど RTLリンク方式 の統一が必要
- 必須フラグ：/permissive- /Zc:__cplusplus
- setlocaleで UTF-8モード、Vista以降で動作安定
Windows（MinGW）
- Linuxと同様の手順、CMake＋MinGW Makefiles
- libtvision.aとサンプルが./buildに生成
- Windows XP以降で動作可能
Windows/DOS（Borland C++）
- DOS/Windows用ライブラリとしてビルド可能（Unicode非対応）
- Borland C++ 4.52＋PowerPack、Turbo Assembler 4.0で動作確認
- 環境依存の問題あり（MAKEのバージョン、16bitインストーラ等）
Vcpkg
- vcpkg経由でのインストール対応
- Microsoftとコミュニティがメンテナンス、更新要望はIssue/PRで

Turbo VisionをCMake依存として利用

CMakeベースのアプリケーションでTurbo Visionをリンクする主な方法
- Turbo Visionインストール後にfind_packageでインポート
- 詳細は公式README参照

Turbo Visionの用途と現代的意義

GUIツールとの差別化 ：外観と動作の分離や安全性・非同期性は弱いが、 端末アプリの課題解消 に強み
既存資産の再利用 ：ウィジェットやイベント処理を活用し、 開発効率化
クロスプラットフォームのテキストUI ：Linux/Windows間の移植性確保

Unicode・クリップボード・カラー拡張

Unicodeサポート ：既存アーキテクチャに統合、Windowsでも利用可能
クリップボード連携 ：X11/Wayland/Windowsで対応
カラー拡張 ：端末環境に応じた自動調整

まとめ

Turbo Vision はレトロとモダンの橋渡しをする クロスプラットフォーム・テキストUIフレームワーク
Unicode・クリップボード・カラー 等、現代的ニーズに対応
GitHub で積極的に開発・公開、C++開発者・レトロ資産活用者に最適

Hackerたちの意見

スーパークールだね。ボーランドがTurbo Pascalコンパイラ、Turbo C++、TurboVisionを出したとき、可能性の宇宙が本当に爆発した感じがする。コンパイラのパフォーマンスは素晴らしかったし、マニュアルも芸術作品みたいだった。あの頃のマニュアルを全部取っておけばよかったな。これは文化的な宝物だよ。

└

Turbo Visionは長い間、僕にとってのゴールデンスタンダードみたいな存在だった。新しいTUIフレームワークは何かが足りない気がするんだよね。これがただのノスタルジーだったのか確かめてみるつもり。次のツールで使ってみるよ。著者たちに大きな感謝を！<3

└

マニュアルは素晴らしかった。90年代初頭に、Turbo C++に付いてきたボーランドの本の大きな山から自分でC/C++を学んだんだ。今の時代に、リファレンスマニュアルをただ読んで学ぶなんて想像できないよね。

└

確かに、GW-BASICとMS-DOSを除けば、僕にとってはボーランド一択だった。MS-DOSとWindows 3.x用のTurbo BASIC、Turbo Pascal、Turbo C++、Turbo Vision、OWL。VC+のバージョン5に入ったけど、MFCはボーランドの提供と比べるといつもダサく感じた。今でも、C++ BuilderのRAD機能に匹敵するものはないし、歴史的背景があっても、.NETが低レベルのコーディングとAOTの話を整理するのに数年かかった。Go、C++、Rustの人たちにMS-DOS用のTurbo Pascal 7と現在のDelphiを数冊渡すべきだね。

まだまだ使えるよ。1年前にTV 2.0を使ってプロトタイプを作ったんだ。LLDBデバッガーのためのTurboVisionフロントエンドを作ろうとして（ほぼ成功したけど）、ボーランドのTurbo Debuggerみたいに動くものを目指してたんだ。ちょっとメモを残しておくね： - 199x年に置いてきたところに戻ったみたいだったよ :) 1993年のコードも大きな問題なくコンパイル・実行できる。 - シンタックスハイライト付きのScintillaベースの内部TVエディタもあって、そっちの方がいい。改造しようとしたけど上手くいかなかったから、著者に助けを求める必要がありそう。 - ドキュメントがない（一般的な知恵の意味でね）から、Stack OverflowやAIに聞けない。昔みたいに例から学ぶしかないよ（バグもあるけど ;) ）。Turbo Visionに関する本を何度も読み返さないといけない。 - 手動のレイアウトはちょっと面倒だな。QTみたいな自動レイアウトがあれば便利だし、スプリッターが恋しいけど、実装するのはそんなに難しくないはず。 - 正直言って、TVがこんなに小さくてコンパクトだとは驚きだ。90年代には巨大に感じたのに :) 全体的に、著者はライブラリを現代化するのにすごく良い仕事をしたと思うし、僕はそれが大好きだ。

└

ドキュメントがない（一般的な知識の意味で）、だからStack OverflowやAIに聞けないんだよね。昔みたいにやらなきゃいけない：バグのある例から学んで（；）Turbo Visionに関する数少ない本を何度も読み返すしかない。ここで言ってることがよくわからないけど、Turbo Visionには質の高いドキュメントが豊富にあったよ。今はむしろそういうドキュメントが不足してるんじゃないかな。 https://archive.org/details/bitsavers_borlandTurrogrammingGu...

僕のプログラミングキャリアは、90年代に誰かが捨てたTurbo Visionの本を見つけたところから始まったんだ。それを拾って、すぐに誰でも作れる青っぽいTUIに恋に落ちた。

まだ「本物」のTurbo Vision、Pascal版を望んでるんだ。C++版はPascal版のポートみたいなもんだから。例えば、Pascalでは「Uses」がキーワードだから、モジュールを「#define」で「インクルード」するのは「ハック」みたいに感じる。でも、今の時代には関係ないかもね。

└

Free Visionは、Free Pascalに含まれているもので、基本的にそれだよ。テキストモードのIDEはFree Visionを使ってる。主な問題は、Free Vision（とTurbo Vision）がTurbo Pascal 5.5で導入された元の「オブジェクト」タイプを使っていて、Delphiで導入された「クラス」タイプを使ってないことなんだ。クラスのRTTIはオブジェクトの自動シリアル化を実装するのに十分なリフレクションを可能にするけど、「オブジェクト」タイプにはそれがなくて、Free/Turbo Visionは手動でシリアル化する必要があるんだ。VMTポインタを登録して、オブジェクトポインタの固定オフセットを通じてアクセスすることで、異なるタイプをランタイムで区別する手段が必要なんだ。Free Pascalは「クラス」タイプのいくつかの便利な機能を「オブジェクト」タイプに追加しているけど（プライベート/プロテクテッド/パブリックセクションとか -TPオブジェクトは全部パブリック- やプロパティ）、Free Visionは元のTurbo Vision APIを実装しているからそれを使ってないんだ。[0] https://wiki.lazarus.freepascal.org/images/1/19/Userscreen.p...

元々のバージョンはTurbo Pascal 6に付いてきたもので、C++ポートは後から出たんだ。だから、これはそのポートの現代版ってわけだね。:) ボーランドは他のフレームワークでも同じことをしていて、OWLはTurbo Pascal for Windows 1.5に最初に登場したし、C++ Builderのツールの多くは実際にはDelphiで書かれている。とにかく、Turbo Pascal 5.5がObject Pascalを採用して、Turbo Visionが6で登場したのが僕のOOPへの入り口だった。運良くその道を進むことができたんだ。OOPを学べて、MS-DOSみたいな環境でTurbo Visionが提供するすべての素晴らしい機能を体験できた。

└

面白いことに、Free Vision（Turbo VisionのFree Pascal版）は、C++版の手動翻訳に基づいているんだよね。C++版がある時点でパブリックドメインとしてリリースされたから、それをC++からObject/Free Pascalに移植した人がいるってわけ。

└

OWLは本当に時代を先取りしてたね。

ターミナルでこれを実行するときに少し失われてしまう重要な部分は、実際のテキストモード画面でのマウスの動作なんだよね。マウスポインタじゃなくて、マウスで動かす黄色いブロックだったんだ。誰か、高解像度のLinuxテキストモードでGPMを使って試した人いる？

└

本来は黄色じゃなくて、上にあるものの反転だったんだけど、画面の大部分を占めるメインウィンドウが濃い青だったから、ほとんどの時間明るい黄色に見えたんだよね。

cmakeの指示を見るとめっちゃ面白いね。なんかタイムスリップしたくなるよ。Turbo CとかPascalの時代、F9押せばすぐに動き出せたのに。今の時代、オンラインコンパイラを指さして実行できるはずなのに。ダウンロードしてフォルダで動かすだけでいいはずなのに。ツールとの関わりはそれくらいで十分なはずなのに、どうやらそれはツールじゃなくて、私たちがこだわる儀式みたいなものなんだね。

└

現代のUnixシステムでソフトウェアをコンパイルするのは、昔は解決済みの問題だったんだ。「./configure && make && make install」が常にゴールドスタンダードだった。

これはたくさんあるTurbo Visionのポートやクローンの一つだよ。C++で書かれたこれもあるよ: https://github.com/kloczek/tvision FreePascal/Lazarusに付属しているのはPascalで書かれてる。Rustでもあるけど、もしかしたらvibeコードかも: https://github.com/aovestdipaperino/turbo-vision-4-rust

これがトップページにあるなんてすごいね！このリポジトリのラッパーを書いてるところなんだ。今はTurbo Vision、つまりこのリポジトリをmacOSの.NETで動かしてる。魔法みたいな感じだよ。ラッパーは高レベルのAPIを提供して、古臭いパレットAPIを解決したり（ラップしたり）、レイアウトを追加したりしてる。var lMenuBar := new MenuBar; lMenuBar .Add(lDocumentMenu) .Add(lViewMenu) .Add(lDialogsMenu) .Add(new Menu('~A~pp').AddItem('E~x~it', Commands.Quit)); fApplication.SetMenuBar(lMenuBar); （これはOxygeneで、現在は.NETにコンパイル中。もちろん、私たちのツールチェーンを使えばGoやSwiftからも使えるし、アセンブリとしてどんなものでも消費できる。ネイティブTVバイナリにはPInvokeを使ってる。）まだまだ進行中 :D リポジトリはプライベートで、今日と明日にはコントロールが置かれるサーフェスに基づいたパレットを作ることに取り組んでる。やることリストにはレイアウトの整理や、今の時代に足りない基本的なコントロールをいくつか追加することがある。Terminal.GUIみたいなライブラリも試してみたけど、（今も？）v2への移行中で、バグなしで動かすのが本当に難しかった。Claudeは、実際のターミナルを考慮せずに作られたTUIやライブラリについての素晴らしい教訓だね。何をしないべきかがよくわかる。Turbo Visionが恋しくなって、なんで現代版を作らないんだろうって思ったら、このリポジトリを見つけて、Unicode対応になってるのを見て…作者には本当に感謝してるよ。

└

これはOxygeneだよ。知らない人のために言うと、RemObjectsのElementsスイートの一部で、PascalベースのOxygeneを使って、Windows、MacOS、Linux、Androidなどでいろんな人気のある言語を使ったり混ぜたりできるんだ。[1]: https://www.remobjects.com/elements/oxygene/ [2]: https://www.remobjects.com/elements/

└

私も同じことをやりたかった。Terminal.Guiを使ったことがあるけど、TVの方が好みだからラッパーを考えてたんだ。あなたのラッパーを見るのがすごく楽しみだよ。

└

それは魔法のような感覚だよ。へへ、このTVライブラリで作業するのは懐かしさをくすぐる:D おそらく、GEOS用のアプリを書くような無駄な努力から私を救ってくれたんだ。

└

私もこのtvisionポートで少し作業したことがあるよ。新しいTUIフレームワークを使うたびにがっかりするんだ。やっぱりTurbo Visionが一番だよ。実は自分でも.NETのラッパーを作ってるんだけど、あなたほど進んでないと思う。Windows Forms APIにできるだけ近づけて模倣してるし、ドラッグ＆ドロップのTUIデザイナーを作りたいんだ。私のラッパーのいくつかの例： https://github.com/brianluft/terminalforms/tree/main/src/Ter... C++側で大部分のハードな統合作業をしたよ： https://github.com/brianluft/terminalforms/tree/main/src/tfc... -- P/Invokeで呼び出せるシンプルなC関数をエクスポートして、C#側は主にクラスに整理するだけにしたんだ。もっと複雑なことに入ると壊れないデザインを見つけるのに何度も試行錯誤したよ。最初は「C++でできることはC#でもできるはず」と思い込んでたから、すごく複雑になってしまった。C++オブジェクトをC#バッファに配置するためにplacement newを使ったり、C#側からC++クラスを効果的にサブクラス化したりして、かなり込み入ってきちゃった。もっと直接的で柔軟性の少ないアプローチに切り替えたんだ。柔軟性はC#側に持たせることにしたよ。あなたのP/Invokeシステムがどう機能するのか、ちょっと興味あるな。

最近のWookashポッドキャスト、Chuck Jazdzewskiとのやつをおすすめするよ。彼は元々のTVを作ったチームの一員だったんだ。

ハクソク