基礎から覚える 最新OSのアーキテクチャー 第5回

Windows 8でMetro Styleアプリを動かす「WinRT」

非同期呼び出しAPIで
待たされ時間のイライラを解消？

　もうひとつの特徴は、「非同期呼び出し」のAPIを提供するという点である。従来のAPIを呼び出すと、なんらかの「結果」を持って戻ってきた。そのため処理に時間のかかるAPIでは、長い間アプリへ制御が戻らないこともある。これに対して非同期呼び出しでは、APIの呼び出しと結果の受け渡しが別になっている。API呼び出しは単なるリクエストであり、呼び出し後はすぐにアプリに制御が戻る。

非同期API呼びだしは最初に要求のみを行ない、結果は別に受け取る。そのため要求したあとは、APIが処理を終えるまでの間にほかの作業を進められる。これに対して同期呼び出しAPIでは、結果が帰るまでアプリには戻ってこない

　ユーザーの入力を待ったり、ネットワーク内のデバイスを探すなどAPIの処理に時間がかかるような場合は、CPUの処理時間からみると非常に長い時間がかかる。非同期APIでは、システムがこうした作業や入力待ちをしている間に、別の作業を先に進めておくことが可能だ。あるいは処理が終わるまで、ほかのプロセスに処理時間を譲るといったことも可能になる。

　非同期APIの結果の受け取りは、通常そのための関数などを「コールバック」としてAPI呼び出し時に登録しておき、これをシステムに呼び出してもらって結果を受け取る。JavaScriptやC＃、Visual BASICといった言語では、もっと簡易な記法が用意されており、呼び出しと結果の受け取りをまとめて記述できる。

　WinRTはMetro Style専用のAPIだ。Metro Styleアプリは、CやC＋＋で開発する機械語コードである「アンマネージコード」と、.NET FrameworkのC＃やVisual BASICで開発する「マネージコード」のどちらでも開発できる。さらに、HTML5とJavaScript(これはWinJSと呼ぶようだ)でもアプリ開発が可能だ。

　WinRTではAPIの機能をオブジェクトとして実現しており、これを各言語環境に合わせて変換して提供している。例えばアンマネージコードからは、Metro Style用の.NET Frameworkオブジェクトとして利用できる。

今回Buildで公開されたWinRTの図は、Windows 8の構造を表しているのではなく、アプリのタイプとその実行環境を表している

　上の図はBuildで公開された、Metro StyleとDesktop Styleの関係を表した図である。誤解されることが多いのだが、これは決してWindows 8の「構造」を表したものではなく、アプリと利用するAPIや開発言語システムなどの「環境」を表したものだ。

　では構造はどうなっているのだろうか？　それを推測したのが、下の図だ。これは基調講演やカンファレンスなどの内容から筆者が推測したものであり、マイクロソフトの公式見解ではないことに注意されたい。

筆者予想によるWinRTの構造図

Metro Styleアプリの仕組み

　前述のように、Metro Styleアプリはマネージコード、アンマネージコード、およびWinJSで開発が可能だ。しかしその実行環境は、従来のWindowsデスクトップ側とは隔離されており、「App Container」と呼ばれる環境の中で動作する。

　アンマネージコードからWin32 APIを呼び出すこともできるようだが、一部の機能は制限されていて、利用できないという。例えば「GDI」はMetro Style側では呼び出せない。だが「Win32 APIを呼び出せるなら、直接DLLなどを指定して呼び出せば利用できるのではないか？」と、Win32でのプログラミングについて知っている人なら思うだろう。

　これについてBuildで開発担当者に聞いてみたところ、「App Container自体がサンドボックスとなっており、例えばDLLをメモリーにロードするようなAPIを監視していて、特定のAPIのみ利用できるようにしてある」という。呼び出せない機能にはほかにも、デスクトップにウインドウを表示する「CreateWindow」APIのような機能も使えなくされている。