特集

Linuxで動く.NET環境「Mono 1.0」の実力(前編)

―― なぜMonoは作られ、何を目指すのか? そしてその実力は? ――

株式会社ピーデー
川俣 晶
2004/10/05

Page1 Page2 Page3 Page4

UNIXという価値観を共有したWindows NTとLinux

 しばしば、筆者は「マイクロソフト信者」と呼ばれる場合がある。マイクロソフト製品利用者の多くは、熱狂的にマイクロソフトやその製品を崇拝したり心酔したりしないので、そもそもマイクロソフト「信者」なる人種はほとんど存在しないだろう、という点を差し引いてもまったくのぬれぎぬである。

 というのも、筆者は、世間のほとんどがLinuxという名前を知らないころに、Linuxを次の時代の主力OSの候補として検討していたからである。まだ、Windows 3.1が最先端のOSであった時代、通のマニアであれば後継OSとしてIBMが開発したOS/2を支持するのが当然だという風潮がまかり通っていた時代に、筆者はずばり本命はWindows NTであり、それがうまく行かなかった場合これに代わるのはフリーのPC UNIX、つまり、LinuxやFreeBSDなどであると考えていた。

 この時代、マイクロソフトは主力OSとして、Windows NTよりもWindows 95を売り込もうとしていたので、明らかにマイクロソフトの望む方向性に反する予測を立てていたことになる。マイクロソフトの特定の製品を支持したからといって、それがマイクロソフトの思惑どおりだとは限らない。マイクロソフトの営業方針に逆らう意見を平然と述べていた筆者は、さぞかしマイクロソフトから見て嫌なやつだったに違いない(笑)。

 この時代に、筆者はWindows NTとLinuxをLAN上で共存させて使うということも試みている。Windows NTの方は正確なバージョンを忘れたが、かなり初期のバージョンであった。Linuxの方は、恐らく最近のLinux愛好家が知ることもない初期のディストリビューションであるYggdrasil Linuxを使用した(申し訳ないが、正確なバージョンは失念してしまった)。

 さて、話を戻そう。このようにしてインストールしたYggdrasil Linuxマシンは、LAN上で、Windows NTと共存していた。すでに詳しいことは覚えていないが、両者の間の相互運用性はかなり良好だったと記憶している。例えば、Windows NT側からtelnetコマンドでLinuxマシンにログインして操作することは問題なかったし、ftpコマンドによるファイル転送もできた。

 もちろん、いまの視点から見れば、それらの初歩的な機能が使えることなど当たり前と思うかもしれない。しかし、当時の時代背景を考えれば画期的なことだったといえる。この時代、インターネットのブームはまだ来ておらず、Linuxのブームも来ていない。多くのパソコン・ユーザーは、TCP/IPもtelnetもftpも知らずにパソコンを使っていたのである。イーサネットも普及しておらず、ネットワークといえばモデムと電話回線を使った無手順通信で、Nifty-ServeであるとかPC-VANといった「パソコン通信」と呼ばれるサービスにダイヤルアップ接続することを意味していた。そんな時代に、Windows NTに標準で入っているtelnetを使ってLinuxに接続できたことは、ある種の感動を感じさせるのに十分であった。

 このような相互運用性が実現された理由は、決してWindows NTがLinuxとの相互運用性を意識していたからではない。この状況を理解するには、“UNIX”と呼ばれる、似てはいるが相互に互換性があるとは限らない一群のOSの存在を意識する必要がある。UNIXという名前の単一のOSが存在するわけではないが、ここではそれらをUNIXと呼ぶことにしよう。

 最初のUNIXは、巨大複雑化したMulticsというOSのアンチテーゼとして、AT&TのBell研究所で開発されたという。その後、UNIXは研究所や大学などで多く使われていた。しかし、徐々にUNIXは浸透し、商品へと変化していく。それまで大学などであればタダ同然で入手できたUNIXが、急に商品として高額の料金を求められるようになったのである。これに不満を感じたリチャード・ストールマン氏が始めたのが、無料ですべてのソース・コードを入手できることを要求するライセンスを提唱するGNUということらしい。

 また、UNIXの商業化の流れは、ワークステーションと呼ばれるUNIXを採用した高性能小型コンピュータのブームを呼んだ。現在Javaで注目されることの多いSun Microsystemsは、本来このワークステーションで一世を風靡(ふうび)した企業である。ワークステーションは、ミニコンよりも下、パソコンよりも上の領域で普及し、企業内のビジネス・システムを含めて多くの利用者を獲得した。

 さて、不正確かつ大ざっぱではあるが、Windows NTとLinuxはこのような状況下で生まれてきたことになる。その当時のパソコンよりも上の領域を切り開くことを期待されたOSであるWindows NTには、当然UNIXとの互換性が要求された。米国政府のシステム導入規約をクリアするためには、標準化されたUNIX仕様の一種であるPOSIXとの互換性を確保する必要があると同時に、すでにUNIXワークステーションが多く使われる一般企業のシステムに食い込んでいくためにも、UNIXとの互換性は必須要件だった。その結果として、POSIXのアプリケーションを実行するための「POSIXサブシステム」を装備し、UNIXで使用されるプロトコルであるTCP/IPにも標準で対応して、telnetやftpといった基本的なコマンドも備えることになったのだろう。

 一方、Linuxの方はどうか。こちらもUNIXを意識していたことは間違いないだろう。当時のUNIXワークステーションは、平均的なパソコンOSとは比較にならないほど強力なOSであり、それを知るマニアであればぜひ使いたいと思うのが当然というだけの存在感があったと思う。現実的かつ実用的にUNIXを使うには、32bit CPUが必要であったが、Intel 386が普及し始めたことで、このハードルはクリアされつつあった。しかし、ハードウェアのハードルはクリアされても、ソフトウェアのハードルは依然として残っていた。マルチユーザーOSであるUNIXは、まともに買おうとするとべらぼうに高価で、また当時すでに活動を開始していたGNUも、無料で入手できるOSを提供することはできていなかった。

 このような背景が存在する状況で生まれてきたのがLinuxである。当然、安価に個人レベルでもUNIXを使いたい、というニーズを満たすからこそ、多くの利用者から注目を浴びたのだと思う。とすれば、Linuxの目標は全く新しいアーキテクチャのOSを開発することにはない。それよりも、UNIXと互換度の高いOSを手に入れることが、当然の期待される目標となるだろう。

 この2つの経緯を見れば、Windows NTとLinuxが驚くほど良好に接続できた理由は明らかだろう。UNIXという価値観を共有すればこそ、それは可能となったものといえる。UNIXの圧倒的な存在感がある限り、この2つのOSの相互運用性は確保されたも同然と思えた。

 そして、時は流れた。

WindowsとLinuxとを結ぶ「Mono」

 2004年現在、UNIXの圧倒的な存在感は過去のものとなった。いまや、Linuxという名前は、UNIXという名前の存在感を上回る大きさを備えている。そして、WindowsとLinuxは、UNIXという価値観を介すことなく直接向かい合っている。OSとしての価値だけでなく、企業、思想、社会運動などのさまざまな思惑が絡み合い、両者の関係は極度に冷え切ってしまったといえる。

 いま、Windowsが自発的にLinuxとの相互運用性を積極的に求めていく理由は考えにくい(「Windows Services for UNIX」というソフトウェアもあり、結果的にLinuxとの相互運用性を高めることに寄与していることも事実だが、その対象はLinuxを含む“UNIX”であって、Linuxに限定されない。Linuxを含むUNIXとの相互運用性改善策は見られるものの、Linux限定の策は見られないように感じる)。逆に、Linuxが、より多くのシェアを持つWindowsを切り崩すためにWindowsとの相互運用性を高める動きはある。しかし、Windowsのファイル・サーバになるといったレベルでは成果が見られるものの、Linux上でWindowsアプリケーションを稼働させる試みについては、実用レベルでは成功しているとはいいにくい。つまり、相互運用性は限定的にしか得られていないといえる。

 それにもかかわらず、まだWindowsとLinuxの間にある程度の相互運用性が保たれている理由は、インターネットという開かれたネットワークの存在があるためだろう。インターネットを経由して通信を行う場合、通信相手のOSが何であっても、通信を成立させる必要性が発生する。それ故に、特定OS固有の技術をインターネット上に持ち出すことは受け入れられないことが多く、どうしてもインターネット標準に準拠する必要があり、それを介してWindowsとLinuxの間には最低レベルの相互運用性が確保されることになる。それによって、例えば、Windows付属のftpを用いて、Linuxマシンにファイルを転送するような作業は、依然として良好な相互運用性を保ったまま維持されている。

 しかし、インターネットに直接依存しない処理については、そのような強制力は働かず、非互換性が拡大する傾向が生じる。その典型的な例が、Webアプリケーションを開発するためのフレームワークであるASP.NETだろう。ASP.NETはWebのコンテンツを提供するためのサーバ側で動作するプログラムを実現する。送信されるコンテンツそのものは、単なるHTML文書であるため、必ずしもクライアント側を特定OSに制限するわけではない。その点で、相互運用性が維持されているように見えるが、コンテンツを生成するプログラムは特定OSに強く依存しており、OS選択の自由度は著しく制限される。例えば、ASP.NETでWebアプリケーションを開発してしまった場合、それを継続して運用していくためには、常にサーバOSとしてWindowsを使い続けねばならないという拘束が生じてしまう。

 だが、驚くなかれ、そのような拘束を打破してしまうプロジェクトが世の中には存在している。ASP.NETを、Linuxを含むUNIX上で動作させてしまうというのである。それは、「Mono」と呼ばれるプロジェクトである(ここで、Linux上でWindowsアプリケーションを稼働させることができていないのに、同じWindows上の技術であるASP.NETならできるという話はウソくさいと思った人は、次のコラムを読んでいただきたい)。

[コラム] Windowsアプリケーションは無理でもASP.NETアプリケーションならLinuxでも動く(かもしれない)理由

 Linux上でASP.NETを動作させるという表明を考えるに当たり、1つ注意しておくことがある。それは、表明するだけなら何でも表明できるということである。世の中には、明らかに達成不可能な目標を掲げて資金を集めてしまう事例もある。技術の素人を納得させるそれらしい理屈と、説得力のあるビジネス・プランがあれば、残念ながらそれは可能である。資金集めを伴わないボランティアのプロジェクトでも、同じような事例はあり得る。

 例えば、Linux上でWindowsアプリケーションを稼働させるという主張は、達成不可能な目標に当たるのではないかと思う。そのような主張は何年も前から何度も耳にしているが、実用レベルで実現されている事例を不幸にして私は知らない。検証はしていないが、OSのアーキテクチャの相違が著しいことから考えて、おそらくは完全な互換性は実現できないのではないか、と感じている。

 ちなみに、Windows NTのPOSIXサブシステムがPOSIXの要求する仕様を満たすのは、Windows NTを設計する時点でその実現を要件として含めてあったためだろう(Windows NTにはPOSIXサブシステムでのみ使われる機能があらかじめ含まれている)。しかし、Linuxを開発する時点で、Windowsアプリケーションを実行するための互換性を維持することは要件として含めていないだろうと思う。

 さて、そのような達成不可能な問題を踏まえて、あらためてASP.NETについて考えると、疑問が出てこないだろうか。もし、Linux上で、Windowsアプリケーションについての実用的な互換性を持たせることができないのであれば、Windows上で動作するアプリケーションの一種であるASP.NETアプリケーションの実用的な互換性もまた不可能ではないか。そのような疑問が当然出てくるだろう。

 だが、そうではない。1つだけ、かつてのWindowsアプリケーションに関する事例と、ASP.NETに関する事例には、決定的な相違が存在するのである。それは、かつてのWindowsアプリケーションに関する事例が想定したものがWin32 APIベースで動作するネイティブ・コードのアプリケーションであるのに対して、ASP.NETは.NET Frameworkベースで動作するマネージ・コードのアプリケーションである、という相違である。マネージ・コードのアプリケーションは、MSILと呼ばれる仮想コードによって記述されているため、ハードウェアやOSに対する依存性が従来よりも格段に低くなっている。つまり、ASP.NETアプリケーションがWindowsだけでなくLinuxでも動作する、という状況は、Win32アプリケーションをLinuxで動作させるという話よりも、格段に現実味を帯びているのである。

 なお、依存性の低下が完全な互換を約束しないことに注意が必要である。次回後編では、Visual Studio .NETで開発した簡単なASP.NETアプリケーションが、無修正でそのままLinux上で動作する例をお見せするが、すべてのプログラムが動作するわけではない。しかし、完全な互換ではないことはMonoの価値の低さを意味するわけではない。むしろ、完全な互換を目指すプロジェクトよりもはるかに価値が高いことを意味しているとすらいえる。完全な互換は途方もないコストと時間を要する割に、なかなか満足行くものが得られないことが多い。しかし、互換を取れるものだけに絞って互換を取る行為は、短時間かつ低コストで、実用に耐える技術につながる可能性が高い。つまり、完全な互換性がないことを嘆くよりも、わずかな修正でASP.NETアプリケーションがLinux上で動くことに驚くべきなのだ。

 果たして、本当にASP.NETアプリケーションが動作するのか。長い前置きになったが、実際にLinux上で動作させてみた体験記を書いてみたい。

 ここでは、Fedora Core 2とMono 1.0.1を使用してみた。Fedora Core 2は、Linuxの有名ブランドであるRed Hatの実験的な無料Linuxディストリビューションである。そしてMono 1.0.1は、Mono Projectが開発した.NET Framework互換環境であり、Linuxなどで動作するC#コンパイラ、BASICコンパイラやASP.NETの実行環境を含むオープンソース・ソフトウェアである。

 

 INDEX
  [特集]Linuxで動く.NET環境「Mono 1.0」の実力(前編)
   1.WindowsとLinuxとを結ぶ「Mono」
     2.Monoが生まれた背景
     3.Monoの機能とインストール
     4.C#コンパイラとVB.NETコンパイラ
  [特集]Linuxで動く.NET環境「Mono 1.0」の実力(後編)
     1.バイナリの互換性を検証する
     2.環境間の相違と対策/Monoと.NET Frameworkとの速度比較
     3.XSPを用いたASP.NET
     4.Apacheを用いたASP.NET

更新履歴
【2004/10/21】本記事の一部に以下のような誤りがありました。お詫びして訂正させていただきます。

Fedora Core 2は、Linuxの有名ブランドであるRed Hatの流れをくむ完全無料のLinuxディストリビューションである。
Fedora Core 2は、Linuxの有名ブランドであるRed Hatの実験的な無料Linuxディストリビューションである。

 


@IT Special

- PR -

TechTargetジャパン

Insider.NET フォーラム 新着記事
  • MacinCloud (2016/7/22)
     MacinCloudはクラウドベースのMacレンタルサービスで、Macの実機なしにMacを利用した開発が安価で行えるのが大きな特徴といえる
  • Macでビルド/iOS Simulator for Windows (2016/7/21)
     Visual StudioとMacを連携して、XamarinアプリをMac上でビルド/実行する方法と、Windowsで使えるiOS Simulatorを紹介する
  • 構文:文字列にクラス名などを間違えずに埋め込む (2016/7/20)
     C# 6で追加されたnameof演算子を使うと、クラス名/変数名/プロパティ名などを安全に文字列化できる。名前にまつわるバグを減らしてくれるうれしい機能だ
  • XAML Previewer for Xamarin.Formsを使ってみよう (2016/7/15)
     XAML Previewer for Xamarin.Formsを使うと、ページがどう表示されるかを開発環境上で簡単に確認できる。多くの人が望んでいた機能だ
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

イベントカレンダー

PickUpイベント

- PR -

アクセスランキング

もっと見る

ホワイトペーパーTechTargetジャパン

注目のテーマ

Insider.NET 記事ランキング

本日 月間
ソリューションFLASH