BSD-annexの日記： UNIXプログラミングはこの20年間で変わっただろうか

●情報源
　 informIT
　 OSnews
　 daemon news

Advanced UNIX Programming 第2版の出版にあたり、 著者である Marc Rochkind が第1版を書いて以来、 この20年間に何が変わったかを概説している。

----------

私が1984年に Advanced UNIX Programming の第1版を 書いた時、UNIX は既に満15歳を迎えていた。 私は今第2版を書き終えたところであり、あれから20年が経過した。 1984年以来、UNIX プログラミングがどのように変わったかを 尋ねることは興味深いことだと思う。 そう、いくつかのことはほとんど変わっていないし、 もちろん、変わってしまったものも多くある。

基本構造はほとんど変わらないままである

変わらないと言えば、UNIX は本質的に今でも以前と同じ仕組みで 動いているということである。 fork によってプロセスが作成され、プロセスが実行するプログラム は exec 呼び出しによって決定され、open によってファイル を開いて、その次はというぐあいである。最近の UNIX プログラム のほとんどはインターネットをアクセスしている。 それに必要なシステムコール(socketやconnect等)は、 1980年代に BSD UNIX に導入されて以来ほとんど変更されていない。 さらに、システム記述言語である C も機能追加はされたけれども、 基本的には何も変わっていない。言語仕様は何度か更新されて、 今のプログラマは関数プロトタイプも使えるし、 整数やポインタのサイズの条件に制約されることもない。

実際、第2版の準備をしていて、1984年当時の例題のコードが 今でも動くことを確認している。当然、GCC コンパイラは それらのプログラムが書かれた時の C のプリミティブに関する 多くの警告を出力している。

非常に変わったことがいくつかある

基本的部分がほとんど同じというなら、何が変わったのだろうか。 それは、システムコール、使用言語、作成されたサブシステム、 移植性の必要、関連する UNIX の標準規定、というこの5項目である。

システムコールの増加

システムコールの定義にもよるが、4倍に増えている。Advanced UNIX Programming 第1版では、純正のカーネルシステムコール として、70個ほどについてのみ言及した。それらは例えば、open、read、write等であり、fopen、fread、fwriteのような ライブラリコールは含んでいない。第2版ではこれらが300あまりになった。 (全部で約1100個の標準関数コールがあるが、その多くは標準Cライブラリであるか、明らかにカーネル用途ではないものである。) 最近の UNIX はスレッドや実時間対応シグナル、非同期入出力、新しいプロセス間通信機構(POSIX IPC)等の20年前には 存在していなかったものを持っている。これらは、教育研究用システムから汎用オペレーティングシステムへの UNIX の進化 によって引き起こされたものである。組込み用システム(駐車場メータ、ディジタルビデオレコーダ等)、マッキントッシュ内部、 何百万のウェブサーバ、一般用途のデスクトップシステムにまでこれらは使われている。 このように利用されることは、1984年当時には予想もできなかったことである。

言語の増加

1984年当時、UNIX のアプリケーションは C で記述されるのが普通であった。たまに、シェルスクリプトや Awk、Fortran が 混ざることもあった。C++ は出来たばかりであり、最初は C コンパイラのフロントエンドとして実現された。 今では C は UNIX のアプリケーションを書くための主要言語ではなくなった。しかし、低レベルのプログラミングや 参照言語として重要であることは変わりない。(第1版、第2版の全ての例題は C で記述されている。) C++ は C を置きかえるためには十分に効率的であったが、多くのプロジェクトは Java を採用した。 Java より C++ を好むプログラマに私は会ったことがないほどである。 コンピュータは高速になり、Perl や Python のような翻訳型スクリプト言語がますます重要になってきている。 また、HTML、JavaScript、XSLT のような様々な XML 言語等のウェブ記述言語も加わった。

これらの現代的な言語を使って仕事をしていたとしても、その下で何が実行されているか知っておく必要性が依然として存在する。 それは、UNIX が上位言語に出来ることを定義しているというか、ある意味で制限しているからである。 これは UNIX は学びたいが、C は学びたくないという多くの学生に対する難問である。 メモリの問題をデバグしたり、宣言と定義の相違点を説明するのに疲れた彼らの教師にとっても同様である。

(閑話休題)

学生に最初から C を教えずに UNIX を学ばせることができるように、私は Jtux という Java用UNIXシステムコール インタフェースを開発した。これによって、C 言語により公式コールと同じような引数とデータ型を用いたまま、 ほとんど全てのシステムコールが Java から実行することができるようになった。 Jtux についてもっと知りたいとか、ソースをダウンロードした場合は、 http://basepath.com/aup/から可能である。

サブシステムの増加

変更点の3番目は、UNIX が今までになく目立つようになったこと(Wal-Mart にさえ売っている)と、隠れてしまったこと (J2EE やウェブサーバ、Apache、Oracle、KDE や GNOME のようなデスクトップ、それらのサブシステムの下に)である。 多くのアプリケーションプログラマは、直接 UNIX 上でプログラムを書かず、これらのサブシステムを使ってプログラムを書いている。 更に、これらのサブシステム自身が、移植性を確保するための薄いレイア(異なる OS に対して異なる作りになっている)で UNIX から 隔離されている。 このように最近では多くの UNIX システムプログラマはミドルウェアの上で仕事をしているのである。

移植性の増加

変更点の4番目は、Linux や BSD系OS、マッキントッシュの OS X カーネル(Darwin)をも含む UNIX システム間 の移植性についての要求である。1984年当時も移植性への関心はいくぶんあったが、今ではこれは必須である。 開発者は商用版 UNIX に縛られて、Linux や BSD に移植できないということは望まないし、 Linux 開発者は特定の1つのディストリビューションに縛られることを望まない。 これに対して Java のようなプラットフォームはかなりの助けとなってくれる。しかし、カーネルAPIを十分調査し、 注意深く試験をすることが、本当にコードが移植可能であるあることを保証してくれる。 実際、開発者が、私は特定の XYZ の UNIX のためにプログラムしているなどということは聞いたことがないだろうと思う。 UNIX や Linux なら何でも大丈夫、ベンダーの選択は後でいいというのが普通であろう。 (三大商用 UNIX ハードウェア製造会社である、Sun、HP、IBMは全て強力な Linux のサポータである。)

完全な標準規定の増加

移植性の要求に関連するが、変更点の5番目は標準規定である。1984年当時、UNIX の標準規定の作成は始まったばかり であった。IEEE の POSIX グループはまだ組織されていなかった。最初の標準は1988年に作成され、途方もない労力を 費やした素晴らしい品質と厳密性を持っていたが、実世界の開発者には全く役に立たないものであった。それは、 プロセス間通信やネットワーク関係の多くの API について何も記述しなかったためである。 出来るところだけやるという方針が劇的に変わったのは1996年に X/Open と OSF が統合されて Open Group が出来た 時であった。その目標は、重要なアプリケーションが使用している全ての API を包含すること、時間が許す限りそれらに ついて記述することであった。彼らは、その標準規定のひとつを Spec 1170 と名付け、926個の API、70個のヘッダ、 174個のコマンドを記述した。たぶん質より量ということだったろうが、結果としてプログラマが本当に必要としていた API の仕様を 見付けることが初めて出来るようになったわけである。今日では、移植性を目標とするプログラマにとって最良の 参考書は Open Group の Single UNIX Specification となっている。

結論

確かに、UNIX プログラミングは変化した。それは UNIX とその 上で走行するサブシステムが非常に複雑化し、言語技術が進化 したためである。 しかし、同じ UNIX であると認識できる。もはや我々の大部分は C でプログラムを書くことはないけれども、C が UNIX の公式 参照及び記述言語であることは今までと変わらずに認めている。 例え、UNIX が実は Linux であろうとも、言語が Python であ ろうと、アプリケーションが Apache や MySQL を走らせている ウェブサイトであろうと、これは変わらない。