本誌で筆者をご存じの方は，「Win32屋が，ナニ，Linuxとかに言っちゃってるの？」と感じられたことでしょう．
　そのとおりです．筆者はCP/M-80(8ビットCPU用に設計されたOS)から始まり，現在のWindows 2000に至るパソコンOSとともにコンピュータ生活を送ってきた人間です．もちろん数ヶ月前まではUNIXの仕事なんて微々たるもので，実装するなら「とにかくWin32！」ということだったわけです．
　しかし，その光景はMFCの悪夢と戦い，COMという怪物をなだめながら，なんとかやってきたという言葉で形容できるでしょう．気が付くといつも生傷が絶えません．
　ところが，筆者の勤務先のフロアーでは技術者しかいないせいなのか，最近フッと周りを見るとFreeのIntel UNIXマシンが雨後のタケノコのように立ち上がり，実験的に運用され始めていたのです．しばらくだまって見ていると，それらは快調に動作しているらしく，これまでSunやHPのマシンなどが担ってきたフロアー内の基幹サーバーにも使われる始末です．
　特にその中でもLinuxの存在が大きく，続々と台数が増加し始めています(基幹にはFreeBSDが使われていますが…)．そして気が付くとNT Serverだったマシンが続々とLinuxマシンとして稼動し始めていたのです．「そんなものには目もくれない」と黙々と無視し続けていました．
　ところがあるきっかけで，筆者もFreeUNIXの洗礼を受ける日がやってきてしまいました．Linuxの仕事が増えてきたのです．手始めに振られてきたのが，Cobalt Cube(以下CobaQ)への移植です．CobaQは，Internet用に設計された非常に小さなLinux Serverです．筆者にとってUNIXは，たまにInternetの仕事で…でも，しょうがないから触る程度…で，「Emacsの上で生活するなんてもってのほか！Developer Studio以下の原始的な環境で仕事するなんてとても耐えられん！」という信念のようなものがありました．
　ところが，そんな信念などどこへ行ってしまったのか，CobaQが来てしまったために，どんどんLinuxにはまり込んでいくことになってしまうのです．

おもしろい！Linux

　「おもしろい！Linux」と筆者が書くのも変ですが，久々に面白いと思うデバイスに会った気がします．CobaQにはディスプレイやキーボードなどの物理的ユーザーインターフェースは一切搭載されていません．ですから，TelnetもしくはWebベースですべての設定をしなければなりません．しかもCobaQは(Linuxなのに)CPUにMIPSを採用しています．あまりに筐体が小さいので，初めはLinuxの超サブセット版でもインストールされているのかと，そのスペックに懐疑的な見方をしていました．
　ところが，いろいろいじっているうちに驚いたのは，GCCなどの開発環境は入っているし，Samba，Sendmail，Apache，BINDなどのサーバーデーモンは動いているわで，ほとんど完璧なUNIXマシンなのです．その気になれば，xdmさえ動きます．アプリケーションを走らせると，すぐ近くにあるSGIのO2とそれほど変わらないのも凄いことです(図1)．

　今回の仕事は，これまでWinSockベースで作成していたサーバーアプリケーションを各種UNIXに移植する作業でした．初めは「なんで俺がUNIXやんなくちゃいけないんだ？TermでEmacs開いて喜んでるヤツらが使うOSなんて触りたくもない！」などとMac屋がDOS屋を罵るような愚痴をこぼしていましたが，慣れるにしたがい居心地が良くなってきました．
　環境のことはさておき，もうひとつの驚きは，意外なほどにC/C++言語レベルで互換性が高いことです．このことに気が付いたため，徐々にUNIXへはまり込む原因になったのです．お恥ずかしながら，この仕事は筆者が初めて携わる，そこそこの規模をもったUNIXの開発作業になったわけですが，地獄のポーティング工数を覚悟していたにもかかわらず，サーバーアプリケーションであるためにGUIが無かったことと，MIPS CPUのLinuxでありながらリトルエンディアンであったことも幸いして，あっさりと数日でポーティングできてしまいました．

GCCとMS‐C/C++って…

　GCCとMS-C/C++との互換性が高いことには驚きです．警告レベルや最適化レベルを最高にした場合には少し挙動が変わりますが，実用的な警告レベル3や最適化レベル4あたりではMS-C/C++で完璧にErrorやWarningを除去しておけば，GCCから文句を言われることはないようです．ほとんど同じコードが動作します．「どっちが卵でどっちが鶏なのか？」は知りませんが，どちらかがどちらかの実装を意識しているとしか考えられません．
　筆者はいっとき，DOS上のさまざまなCコンパイラをコレクションしていたことがありました．その経験上言えることは，これまでこのくらいコンパイラの互換性があるということを経験したことがありません(このころのCコンパイラはANSI仕様の過渡期だったので筆者は浦島太郎なのかもしれませんが…)．確かに読者の方が書かれる高度なコードによっては，コンパイラの挙動が違うことがあるのかもしれませんが，筆者の「描く」コードレベルでは必要十分です．しかも，このGCCはタダというから驚きです．

シンプルなUNIX

　筆者はUNIXをよく知りもしないで，ドライバの作成にチャレンジしようとしています．しかし実際のコードを見ると，Linuxのドライバは非常に懐かしい匂
いがします．それはなぜかというと，DOS時代に何度かデバイスドライバを作成した経験上，その概念がLinuxとよく似ていたためです．IOCTLやキャラクタ/ブロックデバイスという概念など，もうはるか昔に習得したノウハウが使えることが魅力的に感じられます．当然，MS-DOSはUNIXの影響を受けているのだから当たり前なのですが…．まあ，あのころの記述言語は基本的にアセンブラでしたけど，考え方は同じです．
　しかもこのLinuxのドライバは簡単なハードであれば，新人の研修に提出されるような，平易なC言語で記述できます．このことが，筆者にもう一度Linuxで使えるハードウェアを設計してみたいという意欲をかき立ててくれます．いかに，これまで高度に煩雑化した概念を押しつけられて我慢してきたかを再認識させられました．

オープンソースと分散オブジェクト…

　「分散オブジェクト」…筆者はDCOMによる分散オブジェクトという概念に積極的に賛同するコンピュータ屋です．しかし，現在のCOM/DCOMはもっと概念的にシンプルな方法で提供されなかったことが悔やまれてなりません．今ごろCOM+とかいって仕切り直したとしても，消化不良を起こしてただれてしまった胃壁は，そう簡単に直りそうもありません．COMは，なぜもっと簡単に使えるように提供されなかったのかを考えると残念でなりません(stdioに近いレベルの概念になっていればよかったのに)．おかげで，NTには大量のバグを抱え込むことになり，気が付けば，だれもがDCOMオブジェクトを実装する気力を失っているという状況が作り出されてしまったように思います(この文章で読んで怒ってる人いるんだろうなぁ…そんなことない！って…でも，VCDCに行ったとき米国のMSの社員もそんなこと言ってました…)．
　この業界に分散オブジェクトの普及する兆しの見えない現在，DCOMもCORBAもJavaのclassファイルも，どれだって似たようなものです．ちょっと乱暴な言い方ですが，どのオブジェクトも相手にソースコードを見せずにサブルーチンとして使ってもらう手段にすぎないからです．LinuxやGNUなどのオープンソースという「無敵の多重継承機能」の前には，どのオブジェクトテクノロジも色褪せて見えてくるから不思議です．これまで，商用アプリケーションという世界で何をしてきたんだろう，という自問自答の世界を体験させてくれます．
　GUIもやっと洗練され始め，やっと使えるかなぁ…という気がしています．Gnomeには非常に期待しており，やっとMacやWindowsのデスクトップに対抗できるかな，という感じです．まだ，かなり重いですけど…そうなった時，初めて分散オブジェクト環境が問われるのかもしれません．いずれにしても，Linuxでワクワクしていることだけは確かです．

copyright 1999 片岡 宏仁