Windowsランタイム・コンポーネントの概要と、Windowsストア・アプリの実行環境、Windowsストア・アプリで既存のコードを再利用する際の基本方針を解説。
powered by Insider.NET
Windowsストア・アプリは、JavaScript、C#など、さまざまな言語を用いて開発できる。
しかし、Windowsストア・アプリの実行基盤であるWindowsランタイム(WinRT)は、.NET Frameworkのような共通言語基盤ではない。
具体的には、Windowsストア・アプリでは、プログラミング言語ごとに利用できるインフラストラクチャとバイナリ形式が異なる(次の図を参照)。このため、C++/CX(C++ component extensions。後述)で開発したネイティブ・コードのDLLをJavaScriptやC#のコードから呼び出したり、C#で開発したMSILのDLLをC++/CXのコードから呼び出したりはできない。
インフラストラクチャ間の相互運用性の欠如は、Windowsストア・アプリの開発に対する制約となる。また、.NET Frameworkによってもたらされた、開発者のプログラミング言語選択の自由からは大きな退却だ。
Windowsランタイムは、この問題を解決し、各インフラストラクチャ上のプログラムの相互運用を可能とするために、WindowsランタイムABI(アプリケーション・バイナリ・インターフェイス)を定めている。
WindowsランタイムABIを利用して、ほかのインフラストラクチャ上のプログラムにAPIを提供するには、Visual Studio 2012を利用してWindowsランタイム・コンポーネントを作成する。これにより、Win32 APIを呼び出すC++/CXのDLLをJavaScriptやC#のコードから利用したり、Windowsストア・アプリ用.NET(.NET for Windows Store App)を操作するC#やVBのDLLをJavaScriptやC++/CXのコードから利用したりできる。
しかし、Windowsランタイム・コンポーネントを作成するための情報はそれほど多いとは言えないのが現状である*1。このため、Windowsランタイム・コンポーネントは、それが提供する価値ほどには活用されていないと思われる。
*1 MSDNには、「Windows ランタイム コンポーネントの作成」から一連の記事がある。
本連載では、実際にC++/CXでWindowsランタイム・コンポーネントを作成することで、Windowsランタイム・コンポーネントを開発するためのポイントを紹介する。これによって、Windowsランタイム・コンポーネントという選択肢についての理解を広げたい。
1990年代初頭に16bit Windowsの開発を経験していた方であれば、「Windowsランタイム・コンポーネントは、VBXのWindowsストア・アプリ版」といえば分かりやすいだろう。
1990年代後半に32bit Windowsの開発を経験していた方であれば、「Windowsランタイム・コンポーネントは、COMコンポーネント(OCX、ActiveXコントロール)のWindowsストア・アプリ版」といえば分かりやすいだろう。
Windowsランタイム・コンポーネントは、かつてVB(Visual Basic)アプリに対してC++で開発したVBXやOCXで低レベルな機能を提供していたのと同様に、JavaScriptやC#、VBに対してC++/CXでWin32 APIやCライブラリを利用した機能を、JavaScriptやC++/CXに対してC#やVBでWindowsストア・アプリ用.NETを利用した機能を提供するためのコンポーネント技術だ。
ここでの技術のコアとなるのが、WindowsランタイムABI(=Windowsランタイム型を利用したバイナリ・インターフェイス)である。
Copyright© Digital Advantage Corp. All Rights Reserved.