COM（Component Object Model）は古い技術だが、いまだに現役 あらためて解説する

　前回解説したプレビューハンドラなど（「エクスプローラーのプレビューウィンドウについて解説する」）、エクスプローラーの拡張機能は、COM（Component Object Model）を使って作られている。

　COMは、すでにWindowsでは主流ではなく、後継として.NET Frameworkが登場している。しかし、COMは廃止されたわけではなく、いまだにWindowsのさまざまな場所で使われ続けている。というのも、Windows XPまでは、WindowsのOSの主要オブジェクト技術であり、Windows自身がCOMで構築されていたと言っていいほど利用されていたからである。

　エクスプローラーや関連技術でいまだにCOMが使われているのは、その名残でもある。長らく続けてきた本連載だが、COMについては解説するタイミングを失っていた。ちょうどいい機会なので、今回はCOMを簡単に解説してみたい。

COMの前身となるOLEは1990年に開発された

　COMの源流は、WordにExcelのシートを入れるための「OLE（Object Linking and Embbeding)」技術にさかのぼる。

COMの基本になるVTBLは、OLE2.0やOCXで使われたが、当時は「COM」とは呼ばなかった。1997年頃になって、OLE関連の技術をまとめてCOM、Component Object Modelという名称に統一された。その後、DCOMやCOM+といった派生技術もできたが、.NET Frameworkが後継技術として2000年に登場した

　1980年台前半にXeroxのSTARなどで実現されていた「Compound Document」を、Windows上で実現するための技術としてOLEが1990年に開発された。当時は競合技術もあり、MicrosoftはOLEの開発に力を入れた。競合は結果的には姿を消したが、勝ったというよりも自滅しただけで、結果的にちゃんと動いたOLEが生き残ることになった。

　当時のWindows 3.1（1992年）では、i486やPentiumなどの32bitプロセッサが使われていたが、クロック周波数は二桁～300MHz程度。DRAMも16Mbitチップの世代。今から考えると、かなり非力なマシンで実現された技術だ。もちろん、PC性能の伸びしろは考慮されていただろうが、COMによるコンポーネントの呼び出しは比較的低コストになるように作られている。

　OLEは、その後OLE2.0となり、このときに現在のCOM技術のベースとなる仮想関数テーブル（VTBL）が採用された。しかし、当時はCOMという名称は使われていなかった。OLEは、Visual BASICの機能拡張コンポーネント技術にも使われ、このときに作られたのがOLE Control Extensions（OCX）である。OCXの登場により、Visual BASICは活況を呈した。OCXで作られたさまざまなコンポーネントが流通し、これをインストールすることで、簡単にVisual BASICでできることが増えたからである。

　OCXはその後、Internet Explorerにも実装され、ActiveXという名称になる。OCXなどCOMコンポーネントは、Visual C++のATL（Active Template Library）を使うと比較的簡単に作成することができた。C++からは、WindowsのAPIや高速な処理が可能で、その機能が簡単にVisual BASICで使えるようになった。

COMという名称は1997年頃から使われ始める

　COMという名称が使われ始めたのは、1997年頃。さまざまに変わってきた名称を整理し、オブジェクト技術の総称として使われた。

　COMが提供するのは、実行時に独立した別のプログラムコードを呼び出すための仕組みである。しかし、これはなかなか難しい。というのは、最終的に実行される機械語命令では、実行するプログラムの開始アドレスが明確に定まっている必要があるからだ。たとえば、WordからExcelの機能を呼び出すには、メモリに置かれたExcelのプログラムコード開始アドレスを知らねばならないが、実行環境や状況などでメモリの利用状態が異なるため、実行開始アドレスが変わってしまい、一定のアドレスにすることができない。

　そこで機能の実行開始アドレスを一定の順番で並べた表（リスト）を作り、機能と表内の順番を対応させた。こうしたルールを定め、表の作成や呼び出しなどの仕組みを提供するのがCOMである。

　逆に言えば、COMを使うことで呼び出し元と呼び出し先を「分離」することができる。独立して開発が可能で、実行時までお互いのアドレスを知らなくてもいいからだ。DirectX系のAPIも呼び出しの仕組みに簡略化されたCOM（Nano-COMと呼ばれることがある）を使う。これは特に呼び出し元（ゲームなどのDirectX利用アプリケーション）と呼び出し先（DirectX）を分離させるために使われる。これにより、前世代のDirectX向けに作られたゲームが、新しいDirectXの下で動作できるようになる。

　COMを使ってコンポーネントを作成すれば、プログラムは実行時にコンポーネントの機能を利用できるようになる。システムにインストールされたコンポーネントを登録しているのがレジストリだ。レジストリは、COMのためだけに作られたわけではないが、COMにおいて重要な役割を果たす。レジストリ編集が危険といわれる理由のひとつは、コンポーネントの登録が行なわれているため、登録情報を書き換えてしまうと、アプリケーションやWindowsがクラッシュしてしまう可能性があるからだ。

　前回解説したプレビューハンドラもレジストリに登録されており、エクスプローラーはこれを見て、どんなプレビューハンドラが登録されているのかを知る。そのあとで必要な情報は、コンポーネント自身にたずねることで得られるようになっている。

　コンポーネントが持つ機能（処理）に対応するメソッドは、インターフェースと呼ばれる情報に格納されている。COMコンポーネントは、メモリに置かれ、実行可能な状態であるとき、自身が持つインターフェースを外部のプログラムに教えることができる。このとき、VTBLというアドレス表を使う。

メモリにロードされたコンポーネントの中にVTBLと呼ばれるテーブル（リスト）が作られ、ここに各メソッドの実行開始アドレスが書き込まれる。COMコンポーネントを呼び出すクライアント・アプリケーションはAPIを使い、VTBLへのポインタを入手。これを使ってメソッドを呼び出す

　VTBLは、メソッドの実行開始アドレスを並べたリストになっていて、COMコンポーネントには、このVTBLの場所（アドレス）を通知する関数が必ず用意されている。アドレス表の位置が機能を表わし、そこに書き込まれたアドレスが実際のプログラムの実行開始位置となる。コンポーネットは必ず、QueryInterface／AddRef／Releaseの3つのメソッドを持っており、これが先頭の3つになる。

　これにより、呼び出し側のプログラムは、現在の実行開始アドレスを知ることができる。もっともCOMでは、C++などの言語用にCOMの機能を使う、あるいはコンポーネントを作るためのライブラリが用意されており、こうした細かい仕組みにまで立ち入ることなく、コンポーネントの利用や作成ができるようになっている。

　ただし、コンポーネントを呼び出すときに必要になる引数などの情報に関しては、呼び出し元が理解している必要がある。たとえばプレビューハンドラには、実装すべきインターフェースが4つ定義されている。プレビューハンドラを作る場合には、このインターフェース（メソッド）を実行するプログラムを書かねばならない。

　WordにExcelの表を埋め込む用途には、複合ドキュメント用のインターフェースが定義されている。複合ドキュメントを実装するアプリケーション（Word）は、これを呼び出せるように作らねばならない。埋め込まれるオブジェクトを提供する側も、そのためにコンポーネントを登録しておく必要がある。複合ドキュメントが有効なアプリケーションでは、クリップボードやドラッグ＆ドロップ経由で相手プログラム（コンポーネント）の情報を得て、オブジェクトのリンクや埋め込みを行なう。

COMの後継となるのが「.NET Framework」 ただし、今でも現役で使われている

　しかし、COMにはいくつか問題があった。たとえば、機能を追加するなどコンポーネントのバージョンアップをする場合、互換性を保たないと、旧アプリケーションやサードパーティのアプリケーションが動作しない可能性があった。同一のコンポーネントは、1つしか登録できないという制約があり、システムディレクトリにおかれていたため、古いコンポーネントを同梱したアプリケーションが新しいコンポーネントを上書きしてしまう可能性があった。

　COMを使うActiveXも一時は隆盛を極めたが、セキュリティ的な問題が多発し、結果的に制限された形でしか利用できないようになり、後継のEdgeでは廃止されている。

　ネットワークを介してCOMを呼び出せるようにしたものがDCOM（Distributed COM）である。コンポーネントを別のマシンに置き、ネットワークを介して呼び出せるようにしたものだ。このDCOMは、のちに改良されてCOM+と呼ばれるようになった。

　このCOMやCOM+の後継となるのが.NET Framework（やCLR:Common Language Runtime）である。逆に言えば、.NET FrameworkはCOMの問題を解決できるような仕組みとして作られた。しかし、前述のようにCOMを廃止することはできず、.NET Frameworkでは、COMコンポーネントを簡単に扱えるようにしてある。

　.NET Frameworkでは、COMのコンポーネントに対応するものとして「アセンブリ」を定義する。アセンブリには、リフレクションと呼ばれる仕組みがあって、アセンブリが含むクラスやそのメソッド、引数などの情報を調べることができる。アセンブリは、原則、特定のアプリケーション（他のアセンブリ）から呼び出すことが前提となるローカルなものだが、「グローバル・アセンブリキャッシュ」（GAC。Global Assembly Cache）にインストールすることで他のプログラム（アセンブリ）から利用可能になる。

　現在ではソフトウェア開発で、COMコンポーネントを作ることは少なくなったが、Windowsのコンポーネントを呼び出して使うことは結構ある。COMは古い技術だが、いまだに現役と言える。