古いDOS機やWindows NT 4.0のマシンが、いまも現役で業務を支えている。そんな話は、レガシーシステムの珍談として片づけるには重い。Hacker News のこのスレッドでは、単なる懐古ではなく、50年先までソフトウェアを保つのはどういうことかが、現場の体験談と混ざり合いながら語られていた。面白いのは、みんなが「古いものを残したい」と言っているわけではないことだ。むしろ、残ってしまう条件が何かを、かなり具体的に示している。
元記事は、Hacker News の「Ask HN」投稿だ。投稿者は、いまでもDOS機や古い業務用環境を使い続けている人、あるいはそうした現場を知っている人に経験を聞いている。挙げられていた例はかなり具体的で、dBase、Clipper、CLARION、Paradox といった DOS 時代の RAD 環境を、期間限定のような扱いではなく本番の業務処理に使っているケース、ISA カードで制御される CNC mill、spectrometer、microscope のような産業機器、そして parallel port dongle がないと動かない何か、という三つの系統だった。投稿者は「何か売りたいわけではなく、現代のハードウェア上でもこうしたものを延命するアイデアを考えている」と書いている。
この問いに対して、まず印象的な実例として出てきたのが、ある原子力発電所の話だ。そこでは、2007年時点で Windows NT 4.0 のマシンが動いていたという。役割は制御棒の状態を表示すること、つまり「棒が入っているか、何本入っているか、どれくらい深く入っているか」を示すことだった。ただし重要なのは、これは制御そのものではなく、あくまで表示専用だった点だ。元のソフトは1980年代、発電所が建設されたころに AmigaOS 向けに書かれたものだったが、Amiga はもう買えず、元機はとっくに壊れていた。そこで1990年代半ば、当時の最新だった Windows NT 4.0 上で動く AmigaOS エミュレータが導入された。そのエミュレータは英国の企業が作ったものだが、その会社も1990年代後半に消えてしまう。さらに、NT 4.0 以降の Windows では、エミュレータが物理ハードウェアへ直接アクセスできなくなり、状態信号を拾えなくなった。直せる人もいない。結果として、その発電所は新しい機器とソフトを一式で認証し直すか、今ある構成を続けるかの二択になり、後者を選んだ。投稿者は、Pentium 1 のシステムが NT 4.0 上で AmigaOS エミュレータを動かし、原子炉の制御棒の状態を表示している現場を、見学中に実際に見つけたという。予備機は eBay で買って、隣の棚に積んであったそうだ。
スレッドでは他にも、Windows NT 4 には Java に関する長い免責文があり、核施設や航空機、医療機器、兵器には使うなと警告していた、という昔話が出た。これに対し「表示専用でも安心にはならない」と返すコメントがあり、さらにチェルノブイリ事故を引き合いに出して制御棒の話をする人もいたが、別の参加者は、あの事故では制御棒だけでなく、ガイガーカウンタや冷却水の流量、温度計すら十分に監視できていなかったと指摘している。
議論はそこから、「50年動かす前提のソフトをどう作るか」に広がった。ある人は、OSや仮想化の互換性を優先し、今の64ビット環境で32ビットの Windows 95 をエミュレーションできるなら、将来の延命にもつながるのではないかと考えた。別の人は、仕様を徹底的に文書化し、ビルド手順、依存関係、バージョン管理、公開ソース、ローカル完結のビルドを重視すべきだと言った。 opaque blob を減らせ、紙にも残せ、という主張だ。さらに別の参加者は、DOS emulation や HX DOS Extender のような具体的な選択肢を挙げ、Win32 DLL をどうやって DOS 側で生かすかまで踏み込んでいる。昔からあるものは長く残る、という Lindy effect に触れたコメントもあったし、「1976年のやり方で今も通るものは何か」という問いから、C、SQL、Lisp、8080 エミュレータの組み合わせを思いつく人もいた。要するにこのスレッドは、古い機械の武勇伝ではなく、レガシーを未来へ持ち越す方法論の寄せ集めになっていた。
ここで一番おもしろいのは、レガシー維持の理由が「古いから安心」ではなく、むしろ逆に「変える方が危険で高い」からだという点だと思う。原子力発電所の例では、問題のシステムは制御ではなく表示だった。それでも置き換えが難しい。なぜなら、ソフトだけでなく、エミュレータ、OS、ハードウェアアクセス、認証の積み重ねが全部ひとつの塊になっていたからだ。ここが、単なる古いPCの延命と決定的に違う。壊れているのは部品ではなく、前提のつながりなのだと思う。
スレッドのコメントで何度も出てきたのは、エミュレーションや仮想化を入れれば安心、とは限らないという感触だった。実際には、OS更新で直接のハードウェアアクセスが塞がれる、サードパーティの会社が消える、ドライバや周辺APIの前提がずれる、といった理由で、せっかくの延命策がある日突然役に立たなくなる。これが怖いのは、壊れ方が静かなことだ。いきなり全損ではなく、ある日「もう動かない」に変わる。しかもその時点では、古い機械を動かす人も、もうその仕組みを理解していないことが多い。だから互換性は機能ではなく、維持され続ける体制そのものだと考えた方がいいのだろう。
ninalanyon のコメントは、かなり本質を突いていたと思う。50年持たせたいなら、ソースコードだけでなく、何を実現するシステムなのかを細かく書け、依存関係を記録しろ、ビルドをローカル完結にしろ、という話だ。地味だが、これが効くのは、長寿命システムの敵が「複雑さ」より「記憶の喪失」だからだ。現場の人は仕様を頭の中で補ってしまうし、今の便利なツールは勝手に外部から何かを取ってきたりする。そういう“当然”が数十年後には全部地雷になる。紙に残す、版数を記す、原図と部品表を残す。古い業界では今でも当たり前だというコメントがあったが、ソフトウェア業界はそこを軽く見すぎてきたのではないかと思う。
スレッド全体を読むと、C を選ぶべきか、Rust が将来の定番になるのか、DOS エミュレータに寄せるのがよいのか、といった技術論はもちろんある。ただ、もっと大きいのは「誰がそれを50年持たせるのか」という問いだ。人気のある言語を選べばいい、という意見もあれば、普遍的で時代を選ばないものに寄せるべきだという意見もあった。でも現実には、言語やOSが何であれ、維持する人がいなくなれば終わる。原子力発電所の話が妙に生々しいのは、そこに予備機まで用意されていたからだ。つまり、技術的な解決に見えて、実際は「壊れたときに代替を確保し続ける」運用の話でもある。レガシーは、コードより先に組織の都合で生き延びるのだと思う。
参考: Ask HN: Who's still keeping a DOS machine up because the business depends on it? | Hacker News
