デスクトップ・アプリケーションのポータビリティー
企業で使われているデスクトップ・アプリケーションには、ワープロ、表計算、プレゼンテーションなどのオフィス・ソフトウェア、チャット、インスタントメッセージング、開発ツール、業務用のグラフィカル・アプリケーションなどがあります。
デスクトップ・アプリケーションには、「ポータビリティー」という課題が長きにわたって議論されてきました。ポータビリティーとは、日本語で「可搬性」、または「移植性」。簡単に言うと「他のシステムへ持って行けるか？」という議論です。デスクトップ・アプリケーションの場合、Windows、X-Window（Linuxなど）、Mac OS、モバイル画面などのシステム間で共通のソフトウェアを使うことができるか、という議論です。
ソフトウェアのポータビリティーを実現するには、いくつかの選択肢があります。ソースコードを共通化する方法、共通レイヤー（層）を作る方法、シミュレーション、スクリプト言語、仮想マシンや仮想ランタイムを利用する方法などです。
ソースコードを共通化する方法は、非常に多くの技術で試されてきました。ソースコードを共通化する方法の代表的な例は標準APIです。標準APIは、オープンなテクノロジーであり、標準化団体などで規定され、ベンダー各社が自由に使えるものです。The Open Group、POSIX、OpenGL、X.Orgなどがあります。しかし、多くのデスクトップ・アプリケーションでは、標準APIは事実上の標準とはなりませんでした。X.Orgが策定しているX Window SystemなどのAPIが、ウィンドウシステムの標準APIとならなかったからです。多くのウィンドウシステムは、専用APIを使ってアプリケーションを作るのが標準であり、標準APIで記述されたアプリケーションはコンパイルできません。
共通レイヤーを使う方法は、そこそこ成功を収めており、今でも使われている方式です。それは、ウィンドウシステムの仮想APIを定義して、複数のシステムに準備することでした。たとえば、あるメーカーのソフトウェアを共通レイヤーの上に構築して作ることにし、その共通レイヤーを対象となるすべてのウィンドウシステムに準備します。これによって、結果的にソフトウェアが複数のプラットフォームに対応できたことになります。IBM Open Class Libraryや、IBM Open32-APIなどは、Windows、X-Window、OS/2などに準備されたAPIライブラリーで、共通のソースコードをOSごとにコンパイルしなおすことができました。
この方法は、広くは普及しませんでした。大きな原因はオープン・テクノロジーが登場しなかったことです。また、C言語などではプリコンパイラー言語（#ifdef）などを大量に記述する必要があり、よけいなコード管理コストがかかる原因ともなりました。また、ウィンドウシステム固有のライブラリーを呼び出すコードは移植できませんでした。固有のライブラリーは、ソースコードが手に入らないので再コンパイルができないからです。このため、新APIを使うアプリケーションの移植のほとんどはこの方法で解決できませんでした。
OSをシミュレーションする方法もよく使われています。有名なのはオープンソースのWINEでしょう。WINEでは、Linux上でWindowsのバイナリーを動作させることができます。ソフトウェアのソースコードは必要ありません。しかし、実行速度などの面で限界もあります。
スクリプト言語で書かれたソフトウェアはとてもポータビリティーの高いものとなります。スクリプトの実行環境（インタープリター）の互換性を高めることで、ソフトウェアは簡単にポータブルになります。欠点は速度が遅いことが多いこと、APIのサポート範囲が狭いこと、などです。
特別なアーキテクチャーを定義して、そのためにコンパイルしたソフトウェアを仮想マシンによって実行するソフトウェア環境が登場しています。Javaや.NETのCLR（Common Language Runtime）などです。これらの環境では、ソフトウェアをあらかじめコンパイルするため速度的に有利です。JITコンパイラーやオプティマイザーの性能が向上したりしたことにより、ネイティブコンパイルしたアプリケーションと同等の性能が出る他、幅広いAPIをサポートしており、ネイティブ・アプリケーションと同等のものが作れます。特にJavaは、マルチプラットフォームに最も強い環境となっています。
