お気に入りのオープンソースアプリケーションの機能満載のアップデートをダウンロードしたところです。すべて正常に動作し、他のデバイスでも使用できるようになったので、今度はそれらのデバイスにも展開します。

ただ、新しいLinuxのノートパソコンがWindowsのインストールパッケージと互換性がないだけです。Androidタブレットはいかがでしょうか？そのソフトを持って、好きなところで使えばいいじゃないですか。ここで、「Buy Once, Run Once」の夢を実現するためのさまざまな障壁を探ってみましょう。

ソフトウェア開発、オペレーティングシステム構築

なぜソフトウェアがオペレーティングシステム間で動作しないのかを理解するには、ソフトウェアがどのように動作するのかを少し（ほんの少しです、約束します）知る必要があります。

ソフトウェア開発プロセス

デスクトップ、サーバー、モバイルデバイス（つまり非ウェブ）向けのごく基本的なソフトウェア開発プロセスにおいて、プログラマーは次のようなことを行います。

1. 1つまたは複数のファイルに何らかのコードを入力する。
2. コードをコンピュータが実行できるものにコンパイルする。
3. プログラムが期待通りに動作していることを確認するためのテスト。
4. ソフトウェアのパッケージングと配布・展開。

ここで気になるのは、第1ステップと第2ステップの組み合わせです。ソフトウェアをコンパイルする、つまりコードからコンピュータが理解できる1と0に変換する（機械語）作業は複雑です。詳細な説明は省くが、何が起きているのかを高いレベルで理解することは有用である。

オペレーティングシステム・アーキテクチャ

ここで重要なのは、オペレーティングシステムは単一ではなく、ソフトウェア層で構成されているという点です。

オペレーティングシステムカーネル

OSのカーネルは、コンピュータのハードウェアと通信する役割を担っています。ソフトウェアはカーネルにコマンドを渡し、カーネルはハードウェア（例えば、ハードディスクからファイルを読み込む、画面にウィンドウを描くなど）にコマンドを発行する。基本的には、ハードウェアと各種ソフトウェアの間で、すべての情報（蓄積データ、計算、ユーザー入力など）を調整するものです。カーネルは、これらの機能をすべてシステムコールでソフトウェアに提供する。

各オペレーティングシステムのカーネルは、どのシステムコールが利用できるか、何を呼び出すか、何を選択するかなど、異なるシステムコールを実装しています。そのため、ソフトウェアは、対象となる各OSのカーネルがサポートするシステムコールを考慮する必要がある。Linux で GPU にデータを送信するために使用されるシステムコールは、Windows では別の名前、提供する情報のリスト、またはその両方を持つことがあります。この正確な呼称は存在しないかもしれません。

システムライブラリ

多くの場合、ソフトウェアはカーネルを直接呼び出すことはない。その代わり、システムライブラリや基本的な関数の集合体を呼び出す。ライブラリーがあることで、例えば、ハードディスクにファイルを保存するプログラムは、すべて関数を書く必要がないのです。その代わりに、単にシステムライブラリにリンクして既存の機能を利用します。LinuxのGLibCライブラリはこの良い例で、win32apiの.DLLファイルやMacの/System/libraryディレクトリのコンテンツがこれにあたります。

システムライブラリは、アプリケーションとカーネルの間の一種の変換器として機能し、定型的なタスクを実行するために使用されます。アプリケーションは、これらのライブラリに関数を呼び出し、多くの低レベルの詳細を処理する。また、便宜上、カーネルに対してシステムコールを行うこともできる。ご想像の通り、これらのライブラリは特定のカーネル向けに書かれているため、異なるカーネルを持つOS間では使用できないことを意味します。

オペレーティングシステム実行ヘッダ

汎用ソフトの最後の障壁は、OSの実行形式である。オペレーティングシステムは、実行するファイルが特定のバイナリファイル形式に従っていることを期待します。例えば、LinuxやFreeBSDなどのOS上で動作するELF（Executable and Linkable Format）ファイルは、以下のようにファイルの属性を特定のバイトで指定する必要があります。

特に表示されるアプリケーションバイナリインターフェース（ABI）は重要です。ABIはプロセッサ、カーネル、システムライブラリで利用できるコールの組み合わせで、2つのプログラムが互いにどのように通信すべきかを定義している点で、アプリケーションプログラミングインターフェース（API）と類似しています。しかし、APIはプログラマー（人間）がソースコードの中で、2つのソフトウェアが互いに通信すべきことを示すために使うものであり、実際にはソフトウェアがコンパイルされて実行された後に、ABIによってそれが可能になるのです。各オペレーティングシステムは、特定のABIを実装しており、同じオペレーティングシステムのバージョン間で変更されることもあれば、されないこともある。

一般に、オペレーティングシステムは、プロセッサの種類、カーネル、標準システムライブラリの組み合わせによって決定される独自のABIを実装しています。ただし、オペレーティングシステムが複数実装している場合もある。例えば、FreeBSDはLinuxのバイナリをサポートしていますが、これは（Linuxカーネルではなく）FreeBSDカーネルにアドオンとしてLinuxのABIを提供しているためです。これは、VMWareやVirtualBoxのような仮想化プログラムとは異なり、ソフトウェアでマシン全体（ハードウェアとすべて）をエミュレートするものです。その結果、このタイプのABI互換性は高速になりますが、メンテナンスに手間がかかるようになります。そのため、最近ではマイクロソフト社もその価値を認めていますが、希少な存在です。

例外： 解釈ソフト

以上のことから、開発者は1種類のターゲットシステムに対してしかソフトウェアを書かないということがわかります。ダウンロードしてMacで実行し、コピーしてWindowsで実行、あるいは再度コピーしてLinuxで実行しても問題ないアプリケーションはたくさんあります。なぜ、そんなことが可能なのか？

私は嘘をついていたのだろうか？

結論から言うと、表面上は「どこにでもある」ように見えるソフトのカテゴリーがあるのです。ダウンロードすれば、サポートされているあらゆるプラットフォームで実行することができます（キーワードは「サポートされている」こと）。実際には、アプリケーションのソースコードをダウンロードし、別のアプリケーション（インタプリタ）がそのソースコードを直接リアルタイムで実行します。これは少し単純化しすぎなので、両方の言語でどのように動作するかを見てみましょう。

ジャワ

Javaがリリースされた当初、その約束は（文字通り）「write once, run anywhere」であり、ファイルの保存や計算、アプリケーションウィンドウの作成などに使用するJava関数を用いてアプリケーションを作成することだった。そして、各対応プラットフォームのJava Runtime Environment（JRE）がコードを実行し、そのコードをOSのネイティブ関数に変換する。Javaは、OS上で「直接」動作しないのがミソです。JREのうち、OS上で動作するJava Virtual Machineと呼ばれる部分で動作しています。

アプリケーションとオペレーティング・システム**の間にこの追加のソフトウェア層を置くことで、Javaは、オペレーティング・システム間で同一の一連の機能に集中することができます。何をしたいかをJavaに伝え、それを実際にどう実行するかはシステムのJVMに任せればいいのです。下の図は、JIDE Software社のJavaデスクトップアプリケーションのフレームワークで、同じアプリケーションをMac（上）、Windows（左中央）、ピュアJava（右中央）、Linux（下）で表示したものです。

Javaプログラムは、リアルタイムで正確に「コンパイル」するわけではありません。その代わり、Javaコンパイラが「バイトコード」に変換してくれますが、これは中途半端なプログラムだと考えてもらって結構です。開発者は、アプリケーションを配布する際、どのOSで動くかわからないまま、可能な限りコンパイルします。実際に起動すると、JVMはホストOS固有の機能に合わせて「残りを焼き上げる」。

パイソン

インタプリタ型言語の代表格はPythonで、Pythonスクリプトを実行すると、Pythonインタプリタがコードをオペレーティングシステムの命令に変換する。また、Javaと同様の機能を持たせることも可能で、アプリケーションの外部からコードを「インポート」すると、初回実行時にバイトコードにコンパイルされます。インタープリタは、その後の実行で元のコードが変更されたかどうかを知ることができ、その時点で新しいバイトコードに再コンパイルされます。

この「オンデマンド」操作のクールな副産物は、インタプリタを使って対話的にスクリプトを開発できることです。コマンドラインで "python "と入力するだけでインタプリタが起動し、コードを実行すればすぐに結果を見ることができます。

つまり、開発者は「リアルタイム」で操作や微調整を行い、コード行が思い通りになったら、それをコピーしてスクリプトファイルに貼り付けることができる（非インタープリタ型言語のプログラマーが行う「コードコンパイレーションテスト」のループよりずっと効率的だ）。(非インタプリタ言語のプログラマがやらなければならない「コードのコンパイルテスト」ループよりずっと効率的です)。

ソフトウェアが同じであっても

ユーザーにとって残念なことに、テクノロジー業界はまだ真に「ユニバーサル」なフォーマットを開発していない。決してそうではないかもしれません。この種の規格の導入は、通常、「最小公倍数」の解決策となり、全員の承認を得るために譲歩することになる。

いかがでしょうか？たとえ性能が劣っていても、ユニバーサル対応のソフトが欲しいですか？それとも、まだ使っているOSに満足しており、他のプラットフォーム向けのアプリには興味がないのでしょうか？下のコメント欄で教えてください

画像出典：Chief Production Officer/Shutterstock