10 ポイント 投稿者 GN⁺ 2026-04-27 | 1件のコメント | WhatsAppで共有
  • 90年代のBorland製テキストUIフレームワークを、クロスプラットフォーム+Unicode対応で現代化したオープンソース移植版
  • ターミナルアプリを作る際に ターミナル互換性の対応が不要 - Linux、Windows、DOSで同一コードのまま動作
  • リサイズ可能な 重なり合うウィンドウ、プルダウンメニュー、ダイアログ、ボタン、スクロールバー、入力ボックス、チェックボックス、ラジオボタン などの TUIウィジェットがすでに内蔵 されており、自前で実装せずそのまま使える
  • UTF-8 Unicodeを全面サポート — 既存の char ベースAPIを維持しつつ、CJK全角文字、結合文字、絵文字まで処理でき、moveStr() の1行だけでマルチバイト文字列のスクロール・切り詰め処理が自動化
  • Microsoft RTLのUTF-8 setlocale サポートを活用し、std::ifstream f("コンピュータ.txt") のようなコードがWindowsでもそのまま動作
  • 24ビットTrue Color対応 — 従来の16色からRGB、xterm-256、ターミナルの既定色まで拡張され、ターミナルが非対応でも自動で最も近い色に量子化
  • マウスホイール、中ボタン、トリプルクリック、最大32767行/列の画面サイズ、ウィンドウリサイズイベントなど、現代的な入出力をすべてサポート
  • システムクリップボード連携を標準搭載: Windows/macOSではそのまま動作し、SSHリモート環境でもX11フォワーディングやOSC 52エスケープコードを通じてコピー&ペースト可能
  • Borland C++時代の既存Turbo Visionソースコードを 最小限の修正でそのままビルド可能
  • CMakeビルドシステムに対応、vcpkgで ./vcpkg install tvision の1行だけでインストール完了、CMakeサブモジュールとして add_subdirectory を追加すれば依存関係も自動リンク
  • C++14以上、libncurseswが必要 / MITライセンス

1件のコメント

 
GN⁺ 2026-04-27
Hacker Newsのコメント
  • このリポジトリがフロントページに載っているのを見て本当にうれしくなったし、今はこのリポジトリ向けのwrapperを自分で作っている
    .Net上でmacOS向けにTurbo Visionを動かしているのだが、かなり魔法のような感覚がある
    より高水準のAPIを提供し、かなり古めかしいpalette APIもラップまたは改善し、layoutも追加しているところだ
    まだ非公開リポジトリで鋭意作業中で、今日はコントロールが置かれたsurface基準でpaletteを決め、明日は別の部分を整えるという感じで継続的に手を入れている
    layoutの整理や、今の基準で不足している基本コントロールの追加など、やることはまだ残っている
    以前Terminal.Guiも使ってみたが、v2への移行中だからか、バグなしで扱うのはかなり難しかったし、Claudeも実際のターミナルを考慮せずにTUIライブラリを作ると何をしてはいけないかをよく示していた
    だから現代版Turbo Visionがあればいいのにと思っていたところでこのリポジトリを見つけ、Unicode対応まで入っているのを見て本当にありがたかった

    • OxygeneはRemObjectsのElements製品群の一部なので、Pascal系のOxygeneだけでなく、複数の人気言語を混在させながらWindows、macOS、Linux、Androidなどへ展開できる
      https://www.remobjects.com/elements/oxygene/
      https://www.remobjects.com/elements/
    • 自分もこのtvisionポートで作業してみたが、新しいTUIフレームワークを触るたびに、結局Turbo Visionのほうが優れていると感じる
      私も.NET wrapperを作っていて、たぶん進捗はそこまでではないが、Windows Forms APIをできるだけ近く再現しつつ、drag-and-dropのTUIデザイナーまで入れたいと思っている
      例はこちら: https://github.com/brianluft/terminalforms/tree/main/src/TerminalFormsDemo
      C++側の厄介な統合作業の大半はこちらで処理した: https://github.com/brianluft/terminalforms/tree/main/src/tfcore
      P/Invokeで呼べるようにシンプルなC関数をexportしておき、C#側は主にクラス構造化に集中できるようにした
      最初はC++で可能なことはすべてC#でも可能であるべきだと押し通したが、あまりに複雑になり、placement newでC++オブジェクトをC#バッファ内に置いて、実質的にC#側でC++クラスを継承するようなレベルまで行ったところで設計が破綻した
      結局、より直接的で柔軟性は低いがはるかに単純なアプローチに切り替え、柔軟性はC#側に持たせることにした
      あなたのP/Invokeシステムがどう構成されているのか気になる
    • このTVライブラリを触るとノスタルジーをしっかり刺激されて楽しい
      おかげでGEOS向けアプリを作るとか、1人Hurdチームに入るとかいう無駄な試みをせずに済んでいる気がする
    • 私も同じことをやってみたかった
      Terminal.Guiも使ってみたが、TVのほうが魅力的でwrapperを考えていたので、公開されたらぜひ見てみたい
  • 私のプログラミング歴は文字どおり90年代にゴミ箱から始まった
    誰かが捨てたTurbo Visionの本を拾い、誰でも作れた青みがかったTUIにすぐ夢中になった

  • 元のバージョンはTurbo Pascal 6に含まれていて、C++ポートは後から出た
    だからこれはポートの現代的ポートと見ていい
    Borlandは他のフレームワークでも似たようなことをしていて、OWLももともとはTurbo Pascal for Windows 1.5のほうが先だったし、C++ Builderのツールのかなりの部分も実際にはDelphiで書かれていた
    Turbo Pascal 5.5のObject Pascal、そして6のTurbo Visionが私のOOP入門だったが、その道に入れたのは幸運だったと思う
    MS-DOSのような環境でも、OOPとTurbo Visionがもたらすフレームワークの利点をしっかり学べた

    • 面白いことに、Free Visionは一時パブリックドメインとして公開されたC++版を誰かが手作業で翻訳し、再びObject/Free Pascalへ移植した結果生まれたものだ
    • OWLは本当に時代を先取りしていた
  • BorlandがTurbo Pascal、Turbo C++、TurboVisionを出してきたとき、可能性の宇宙が一気に広がったように感じた
    コンパイラ性能も素晴らしく、マニュアルは芸術品のようで、あの本を今でも持っていられたらと思う
    これは単なる文化的宝物だ

    • あのマニュアルは本当にすごかった
      90年代初頭にC/C++をほぼTurbo C++付属のBorland本の山だけ読んで独学したが、今では参考書だけ読んでそうやって学ぶ場面を想像することすら難しい
    • Turbo Visionは長い間、自分にとっての黄金標準のような存在だった
      新しいTUIフレームワークはいつも何かが足りない感じがしていたし、今これをまた使ってみて、それが単なるノスタルジーだったのか確かめようと思っている
      次のツールに組み込む予定で、作った人たちには大きな拍手を送りたい
    • Borland一色だった時代があった
      GW-BASICとMS-DOSを除けば、Turbo BASIC、Turbo Pascal、Turbo C++ for MS-DOS and Windows 3.x、Turbo Vision、OWLまで全部Borlandだった
      VC++は5あたりから使ったが、MFCはBorland製品に比べるといつもあまりに味気なく感じられた
      今でもC++ BuilderのRAD能力に本当に追いつけているものは少なく、.NETもDelphiのような低レベルコーディングとAOTのストーリーを整理するのにかなり長い時間がかかった
      Go、C++、Rustの開発者にはMS-DOS向けTurbo Pascal 7と最新のDelphiを何部かずつ渡すべきだと思う
  • Turbo Vision 2.0は今でもかなり実用的で、1年前にプロトタイプ作業で実際に使ってみた
    LLDBデバッガ向けのTurbo Visionフロントエンドを作り、BorlandのTurbo Debuggerのように動かそうとしたが、大半は思いどおりにいった
    199x年で止まった場所をそのまま引き継いだようで驚かされたし、1993年のコードも大きな問題なくコンパイルして実行できた
    内蔵エディタにもScintillaベースのより良い版があって、syntax highlightingのような機能も入っているが、私が改造しようとしていた部分はうまくいかず、たぶん作者に助けを求める必要がありそうだ
    ただ、現代的な共有知としての意味でのドキュメントは不足していて、Stack OverflowやAIに尋ねるのは難しく、サンプルコードを見て学び、Turbo Visionの本を何冊も読み返す昔ながらのやり方で進めるしかなかった
    手動layoutはかなり面倒なので、Qtのような自動layoutがあるといいし、splitterも少し恋しいが、実装自体は難しくなさそうだ
    もうひとつ驚いたのは、TVが実際にはかなり小さくコンパクトだという点だ。90年代にはものすごく巨大に感じていた
    全体として現代化の作業は本当によくできていて、私はこれをとても気に入っている

  • cmakeディレクティブが山ほどあるのを見ると、つい昔に戻りたくなる
    Turbo CやPascalではF9を押せばすぐ動いたのに
    一方で、これは私たちのツールチェーンの無能さも示していると感じる
    今の時代ならオンラインコンパイラをひとつ示してすぐ実行するか、ダウンロードしてフォルダをひとつ開いて実行する程度で済むべきなのに、ツールというより儀式の手順になってしまっている

    • 現代Unixでのソフトウェアコンパイルは、かつてすでに解決済みの問題だった
      ./configure && make && make installこそ、今でもgold standardであるべきだ
  • これはTurbo Visionポート/クローンのひとつにすぎない
    C++側にはこれもある: https://github.com/kloczek/tvision
    FreePascal/Lazarusに入っている版はPascalで書かれていて、Rust版もひとつあるが、少しvibe-codedっぽく見える: https://github.com/aovestdipaperino/turbo-vision-4-rust

  • ターミナルでこれを動かすと、本来のテキストモード画面のマウスが持っていた肝心の感覚が少し失われる
    本物のテキストモード画面では、マウスポインタではなく、マウスで動く黄色いブロックのように見えた
    高解像度LinuxテキストモードでGPMを使って動かしてみた人がいるのか気になる

    • 本質的に黄色だったわけではない
      下のセルの色を反転して表示する方式で、画面の大半を埋めるメインウィンドウが濃い青だったため、結果として明るい黄色のブロックのように見えることが多かった
  • 最近のWookash podcastでChuck Jazdzewskiを扱った回を勧めたい
    もともとTurbo Visionを作ったチームの一員で、そのエコシステム全体の話もたくさん出てくる

  • 私はいまだにC++版より本物のTurbo Vision、つまりPascal版のほうを求めている
    C++版は結局、Pascal版を移したものに近く感じられる
    たとえばPascalではusesがキーワードなのに、#defineでモジュールをincludeする方式はどうしてもハックっぽく感じる
    まあ今となっては大きな違いではないかもしれないが

    • Free Pascalに含まれているFree Visionが事実上その役割を果たしている
      テキストモードIDEもFree Visionを使っている
      https://wiki.lazarus.freepascal.org/images/1/19/Userscreen.png
      ただし大きな違いは、Free VisionとTurbo VisionがDelphiのclassではなく、Turbo Pascal 5.5時代のobject型を使っている点だ
      classならRTTIのおかげで自動シリアライズのようなものを実装しやすいが、objectにはそれがないので、異なる型を実行時に区別するには、オブジェクトポインタの固定オフセットにあるVMTポインタを登録するような形で手動シリアライズを行う必要がある
      Free Pascalはobjectにprivate/protected/publicやpropertyのような便利機能を少し追加しているが、Free Visionは元のTurbo Vision APIを実装するため、そうした拡張は使っていない