デニス・リッチー：CがUnixを移植可能にした仕組み
2026年9月9日はデニス・リッチー生誕85年です。CとUnixの仕事は、ソフトウェアを機械間で移動する方法を変えました。しかし、移植可能なコードとは、すべてのコンピューターで同じファイルを実行できるという意味ではありませんでした。
自作プログラムの入ったディスクを友人に渡す場面を想像してください。相手のコンピューターはプロセッサーもOSも、ファイルの扱い方も異なります。渡したのは、実行できるもの、再ビルドできるもの、それとも高くつく書き直しの仕事でしょうか。この問いは、何らかの形でリッチーに恩恵を受けた有名製品を並べるより、よい入門になります。
Heidelberg Laureate Forumは、彼の誕生日を1941年9月9日としています。今日で85年です。Nerd Calendarにも記載されています。誕生日に考えるのは、元のコンピューターがなくなっても残る仕事です。
CとUnixは問題の別々の部分を解決した
Cはプログラミング言語、つまりコンパイラーが翻訳できる操作の記述方法です。UnixはOSであり、資源を管理し、プログラムにサービスを提供します。両者を混同すると、その関係が生産的だった理由が見えなくなります。言語はディスク装置の型番を知らずに計算を表せます。OSは内部の機構の多くを隠しながら、ファイルアクセスを提供できます。
Computer History Museumは、リッチーをCの作者、ケン・トンプソンと共にUnixを作った人物としています。同館の説明では、両者は1970年代初頭のベル研究所で生まれました。これは協働によるシステム開発であり、ひとりの発明家が計算機の全層を作った話ではありません。
プログラムを、つながった3つの判断と考えてみましょう。何を計算するか、サービスをどう要求するか、どの機械命令で実行するかです。これらは強く絡み合うこともあれば、ひとつを変えても残り2つを捨てずに済むほど分離することもできます。移植性は、その分離を役立つものにするところから始まります。
1973年の書き換えは始まりであり、魔法のスイッチではない
リッチーとトンプソンのUnixシステムの論文は、Cへの書き換えを1973年夏としています。保存された本文は、1974年の論文を1978年に改訂した版です。規模が大きくなっても、理解しやすく変更しやすいシステムになったと説明しています。
カーネルを高水準言語で書き直すと、プログラマーが時間をかけて記述する内容が変わります。アセンブリ言語はプロセッサーの命令に密着しています。Cでは関数、データ、制御の流れを記述し、多くの命令レベルの選択をコンパイラーに任せられます。機械はなお重要ですが、主要なソースで直接記す定型的な細部は減ります。
また、移植性が当初からの大構想だったわけでもありません。Cの歴史で、リッチーは移植性への関心は後から生まれたと述べています。CはBから発展し、1972年が最も創造的な年でした。仕事環境を改善し、その後、どれほど遠くへ持っていけるかを発見した物語なのです。
移植可能なソースは万能の実行ファイルではない
ディスクに戻りましょう。入っているのは、Cで書かれた読める指示であるソースコードかもしれません。あるいは、特定の対象向けにすでに翻訳された実行ファイルかもしれません。両者は異なる贈り物です。別の対象向けコンパイラーは、適したソースから別の機械語を生成できます。古い実行ファイルをコピーしても、その翻訳は起こりません。
気温を読み、最小値を報告する小さなプログラムを想像してください。比較の論理はグラフィックカードを知る必要がありません。入出力が両システムにある機能を使うなら、同じソースをそれぞれで再ビルドできるかもしれません。しかし、特定の環境専用のグラフィックライブラリーでウィンドウを追加すると、その部分に別の依存関係が生まれます。
コンパイルの成功は、ひとつの確認地点にすぎません。プログラムには想定するライブラリー、入力の慣習、動作も必要です。開けたファイルに、予想外の形式の数値が入っていることもあります。両方起動するプログラムでも、データの意味について一致しないことがあります。したがって移植性には、コンパイラーの承認だけでなく、動作の検証が必要です。
ハードウェアが変わると、何を変える必要があるか
プログラムを読む有用な方法は、周囲の環境についてどこで前提を置いているか尋ねることです。特に3か所に注意が必要です。
- データ表現。特定の整数サイズを仮定したり、生のメモリーをコピーして構造体を保存したりしていませんか。定義された交換形式と、メモリー内の配置は別物です。
- OSのサービス。ファイル、時刻、入力などの資源をどう取得しますか。限定されたインターフェースのほうが、全関数に散らばった環境固有の呼び出しより適応させやすくなります。
- ハードウェアへのアクセス。機器を直接操作するコードには、その機器の理解が必要です。明確な境界の後ろに置けば作業を集中できますが、作業そのものが消えるわけではありません。
これは私たちが提案する実用的な読み方であり、昔のCプログラムがすべて従っていたという主張ではありません。言語は分離の機会を提供しますが、使うのはプログラマーです。見事に短いプログラムが隠れた前提だらけで、少し長いものが期待を明示していることもあります。
本当の成果：人間の仕事を作り直す量を減らす
1978年のCとUnixの移植性の論文で、Stephen C. JohnsonとリッチーはInterdata 8/32への移行を記録しています。実用上の尺度は、書き直しと比べてどれだけ労力を節約したかです。ソースの多くは環境を越えて共通のままでしたが、その周辺の技術作業はなお重要でした。
保ちたいのはこの視点です。得られるものは、あらゆる適応作業がなくなることではありません。アルゴリズム、判断、蓄積された理解など、すでに思考が組み込まれた部分を保存することです。新しい機械だからといって、同じ問題を最初から解き直す必要はないはずです。
スティーブ・ウォズニアックのパソコン設計の記事は、よい併読相手になります。機械をどう親しみやすくするか、役立つソフトウェアをどうひとつの機械に閉じ込めないようにするか、という異なる設計の問いとして読んでみてください。
この記事の他言語版： ドイツ語 · スペイン語 · フランス語。
誕生日の演習：隠れた前提をひとつ見つける
この考えを試すためにOSを移植する必要はありません。理解している小さなプログラムを選び、期待する入出力を書き出し、環境についての前提をひとつ特定します。ディレクトリーのパス、文字コード、特定の画面ライブラリーかもしれません。
その前提を、明確な名前の付いた境界に移しましょう。別の環境があれば、そこで再ビルドし、同じ例で結果を比較します。なければ、何を確認すべきか記録します。普遍的な移植性の証明にはなりませんが、曖昧な願望を、他の人が調べられる具体的な問いに変えられます。
リッチー生誕85年にふさわしい敬意の示し方です。知識のひとつを、先へ持ち運びやすくしましょう。CとUnixはコンピューターの違いをなくしませんでした。その歴史は、違いが存在しないふりをするより、違いに伴う費用を減らすことが重要でありうる理由を示しています。