第3回 CライブラリのWindowsランタイム・コンポーネント化戦略：連載：Windowsランタイム・コンポーネントによるコードの再利用（1/5 ページ）

既存のC／C++プログラムをWindowsランタイム・コンポーネント化する際に取れる戦略と、それぞれの特徴や、メリット／デメリットを考察する。

[arton，著]

powered by Insider.NET

連載目次

　前回は、Windowsランタイム・コンポーネントを作成するうえで注意すべき点について考えた後、C#で簡単なWindowsランタイム・コンポーネントを作成し、それを実際に利用してみた。その後、本連載でWindowsランタイム・コンポーネント化するmrubyをコンパイルしてみた。今回は、既存のC／C++プログラムをWindowsランタイム・コンポーネント化する際に取れる戦略と、それぞれの特徴、メリット、デメリットなどを検討してみよう。

既存のC／C++プログラムをWindowsランタイム・コンポーネント化する方法

　mrubyのようなオープンソース・ソフトウェアや、COMコンポーネントなどの既存のC／C++プログラムをWindowsランタイム・コンポーネントとして利用するには3種類の方法が考えられる。

　1つは、当然であるが、ソース・ファイルを直接作成するプログラムへコピー＆ペーストしたり、あるいはクラスのソースファイルをプロジェクトへ組み込むなどして利用する方法だ。この場合は、Windowsランタイム・コンポーネント化の対象が自作のソフトウェアでない限りは、ソース・ファイルが公開されていることが前提となる。したがって、再利用の対象はフリー・ソフトウェアか、またはオープンソース・ソフトウェアでなければならない。この場合に考えなければならない点は、ライセンスだけだ。GPLやLGPLであれば、利用した結果、修正されたソース・ファイルとそれを組み込んでいるソフトウェア自身のソース・ファイルをGPLまたはLGPLとして公開する必要がある。BSD、MITやAPLなどのオープンソース・ライセンスであれば、特許不行使条項などが定められているものはあるが、ソース・ファイルを非公開とすることは許諾されている。ソースコードを直接利用する方法は、もっとも柔軟性が高く、自作ソースとのインターフェイスもシームレスとなる。これは組み込みに当たってのインピーダンスミスマッチの考慮がほとんど不要だということを意味する。逆に問題点としては、元のソフトウェアからソースコードが分断されてしまうため、元のソフトウェアのバグフィックスなどの改変に追随するのが困難となることが挙げられる。これらの長所、短所のいずれについても、ソースコードを直接流用する方法については、Windowsランタイムコンポーネントを開発する場合に特別な設計が必要となるわけではない。そのため以降では元のソフトウェアをライブラリとして“as is”で利用する方法についてのみ考えることにする。

　残りの2つの方法は、いずれもライブラリを“as is”で利用する。なお、GPLで許諾されているソフトウェアについてはライブラリとして利用する場合でも、利用したソフトウェアはGPLでライセンスしなければならない点は留意すべきである。

　これら2つの方法を以下に示す。1つ目の方法はWindowsランタイム・コンポーネントを既存のライブラリに対するプロキシとして作成するもので、2つ目の方法はこれをファサード（Facade）として作成する。前述したとおり、ライブラリ自体はas isで利用し、Windowsランタイム・コンポーネントはこれを利用するアプリとライブラリのブリッジとして機能する。ただし、ライブラリのAPIをアプリにどのように公開するかが異なってくる。

既存のC／C++ライブラリをWindowsランタイム・コンポーネント経由でアプリが利用できるようにする方法

　以下では、これらの2つの方法について詳しく検討してみよう。