Windows CE 6で刷新されたアーキテクチャ

Windows CE 6の強化点

　「Yamazaki」ことWindows CE 6の強化点としては、

• カーネルの変更（メモリ管理、アーキテクチャの変更）
  
• 開発環境の変更

の2点が挙げられます。

　実際の製品リリース時には、本稿で紹介する内容に加えていくつかの強化が行われると思います。

仮想メモリ管理方法の変更

　Windows CEは仮想メモリ上で動作します。そして、アプリケーションやデバイスドライバもまた、Windows CEのカーネルが管理している仮想メモリ上で動作します。より正確には、実際に仮想メモリをコミットして利用する際に、仮想メモリ領域を物理メモリ領域にマップして動作します。

　Windows CE 5.0は、4Gbytesの仮想メモリ空間を管理しています。4Gbytesのうち上位2Gbytesは「システム領域」と呼ばれ、カーネルが利用します。下位2Gbytesは「ユーザー領域」と呼ばれ、アプリケーションやデバイスドライバ、ファイルシステムが利用します。

　ユーザー領域は32Mbytesごとの領域に区切られており、この32Mbytesの領域を「スロット」（Slot）と呼びます。ユーザー領域には、このスロットが62個（32Mbytes×62＝2Gbytes）配置されています。スロットは、ユーザー領域の下位アドレスからSlot0、Slot1、……というように配置され、アプリケーション（プロセス）はSlot0〜Slot31にそれぞれ配置されます。特にSlot0は実行中プロセスのためのスロットであり、アクティブになったプロセスがSlot0に配置されます。アクティブなプロセスが入れ替わり、プロセスのスイッチが発生した場合、Slot0に新しくアクティブになったプロセス領域が格納されます。

　このように、Windows CE 5.0は仮想メモリ管理の仕様により、1つのプロセスが利用できる仮想メモリ容量は32Mbytesに限られています。アプリケーションでコミットしたヒープメモリやスタック領域もこの32Mbytesの領域に配置されます。また、ロードしたDLLもこの領域に配置されます。よって、アプリケーションはこの32Mbytesの制限を超えないように、細心の注意を払いながら設計・実装を行う必要があります。

　また、メモリ管理の仕様により、OS上で同時に起動できるプロセスの数は32個に制限されています。

　Windows CE 6では、2Gbytesのユーザー領域に1つのプロセスが配置されるという仕様に変更されています。そのため32Mbytesの制限が解除され、1プロセス当たり2Gbytesまで利用可能です。

　OS上で起動されているプロセスは、アクティブになったタイミングでこのユーザー領域の2Gbytesを共有して利用します。そのため、OS上で同時に起動できるプロセス数も3万2000個に拡張されました。ただし、この数は仮想メモリの論理上の仕様です。コミットされた仮想メモリが物理メモリにマップされ、物理メモリをすべて使い切ってしまうと、その時点で物理メモリへのマップができなくなるため、新たなプロセスの起動も不可能となります。

図2　Windows CE 5.0とCE 6の仮想メモリ機構

OSアーキテクチャとドライバ管理方式の変更

　Windows CE 6では、OSの構造にも変更が加えられています。この変更がどのような意味を持つのか理解していただくため、まずはWindows CEの内部仕様について簡単に説明します。

　Windows CEでは、OSの基本サービスを提供するモジュールである、

• GWES（Graphics Windowing and Events Subsystem）
  描画、ウィンドウ制御、イベントなどのUI入出力に関する部分をつかさどる
  
  
• Filesys（ファイルシステム）
  OS上のメモリファイルシステム（ObjectStore）や外部ストレージ（フラッシュ、ハードディスク、外部メモリデバイス）を管理
  
  
• Device（デバイスマネージャ）
  デバイスに接続されている周辺機器を制御するデバイスドライバのロードやアンロードおよびドライバI/Fの呼び出しを管理
  
  
• 通信システム

で構成されています。

　各種デバイスドライバは、デバイスマネージャやGWESにロードされて各種デバイスの制御を行います。具体的には、USB、シリアル、PCカードホストといったデバイスドライバは、デバイスマネージャにロードされます。ディスプレイドライバ、キーボード、タッチパネルといったUIの入出力系デバイスドライバは、GWESにロードされます。

　Windows CE 5.0では、GWES（GWES.exe）、Filesys（Filesys.exe）、Device（Device.exe）がそれぞれプロセスとして32Mbytesのスロットに配置されます。各種デバイスドライバは、これらのスロット内にロードされます。そのため、アプリケーションだけでなくデバイスドライバも32Mbytesの領域に細心の注意を払いながら実装することになります。また、前述の同時起動可能プロセスにはGWES.exe、Filesys.exe、Device.exeも含まれるため、アプリケーションは32−3＝29個起動できることになります。

図3　Windows CE 5.0のOSアーキテクチャ

　それに対してWindows CE 6では、GWES、Filesys、Deviceはカーネルの一部として動作します。つまり、仮想メモリ領域（4Gbytes）の上位2Gbytesのシステム領域で動作します。

　デバイスドライバには、「カーネルモードドライバ」と「ユーザーモードドライバ」という種別があります。前者はカーネル内にロードされ、GWESとDeviceで利用されます。後者はUDEVICE.exeプロセスにロードされ、仮想メモリの下位2Gbytesのユーザー領域で動作します。

図4　Windows CE 6のOSアーキテクチャ

システムコール時のパフォーマンス改善

　アプリケーションからWin32 APIを呼び出した場合、PSLコール（Protected server library Calls）によるプロセスのスイッチングが行われます。APIを呼び出したアプリは、APIをエクスポートしているCOREDLL.dllを経由してカーネルに遷移します。カーネルはAPIを実行するために必要なサービスに処理を遷移します。例えば、グラフィック出力やウィンドウ制御であればGWES、ファイルアクセスであればFilesysに遷移します。そしてサービスでの実行結果をカーネルに通知し、カーネルがアプリケーションに実行結果を通知します。

　Windows CE 5.0ではGWES、Filesys、Deviceがユーザー領域のプロセスとして動作しているため、API呼び出し時にはプロセスのスイッチング（Slot0へ移動）が発生します。

	1 　 アプリケーションがAPIをコール 2 　 呼び出すサービスをカーネルが検証し、サービスを呼び出す（サービスをSlot0にマッピング） 3 　 サービスが処理を実行し、結果をカーネルに戻す 4 　 実行結果をアプリケーションに戻す（Slot0にアプリケーションをマッピング）
図5　Windows CE 5.0の場合

　Windows CE 6ではGWES、Filesys、Deviceがカーネルの一部となったため、この遷移（アプリケーション→カーネル→サービス→カーネル→アプリケーション）によるオーバーヘッドの軽減が期待できます。

	1 　 アプリケーションがAPIをコール 2 　 カーネルがサービスを呼び出し、処理を実行 3 　 実行結果をアプリケーションに戻す
図6　Windows CE 6の場合