• [アーティクル]

モバイル化

Windows Embedded CE 6.0 の新機能の探索

Paul Yao
この記事は、プレリリース バージョンの Windows Embedded CE 6.0 をベースにしています。ここに記載されているすべての情報は、変更されることがあります。

この記事で取り上げる話題:

  • Windows Embedded CE 6.0
  • 組み込み開発
  • カーネルの革新
  • 共有ソースの実装

この記事で使用する技術:
Windows CE

サンプルコードのダウンロード:
PocketPC2006_12.exe (157KB)

目次

Windows Embedded CE 6.0 の概要き
API の配置スキーム
カーネル モード操作
メモリのアーキテクチャ
デバイス エミュレータ
CE 6.0 のセル テクノロジ
ロケーションベースのプログラミング
セキュリティの拡張
開発ツール
重宝なツール
レジストリ ファイル エディタ
ランタイム イメージ ビューア
共有ソースおよび Windows CE の開発
まとめ

最初のバージョンの Windows CE は 1996 年に登場しました。それ以降、半導体コンポーネントでの無数の革新技術に後押しされて、多数の新種のポータブルおよび組み込み式の製品が出現しました。米国半導体工業会 (SIA) によれば、世界の半導体の売上高は 1994 年には 1,000 億ドルに達し、2006 年にはその額は 2,500 億ドルに達する見込みです。その時流に乗って Windows CE チームは、組み込み製品に取り組んでいる開発者たちの動向に注目しながら、世代が変わるごとにその境界を押し広げてきました。

Windows Embedded CE 6.0 の概要

Windows CE のこれまでの 5 つのバージョンのいずれもが、広範囲にわたる組み込みデバイスの基盤として活躍してきました。最新バージョンである Windows Embedded CE 6.0 でもその躍進は衰えず、まったく新しい一連の機能が取り揃えられました。その中には、理解を必要とするものもあれば、その存在を意識しているだけでよいものもあります。(サイド バー「マイクロソフトの組み込み革新の内幕」を参照してください。)

マイクロソフトの組み込み革新の内幕

新バージョンの製品で成功を収めるための着想、計画、開発、および配布は壮大な作業です。その製品がたとえ小規模であっても、オペレーティング システムであるときは特にそうです。Windows CE の場合、700 名を越える人員を擁する開発チームが作業に携わっています。新機能の立案時には、マイクロソフト社ではいくつかの方法でカスタマ フィードバックが活用されています。最もよく知られたフィードバック メカニズムは、ベータ版ソフトウェア プログラムのプレリリースです。つまり、プレリリース ソフトウェアが顧客に配布されます。しかし、情報源はベータ版プログラムだけではありません。設計および計画の段階を支えるものには、顧客面談や設計の見直しがあります。それによって、顧客の意見や要望を製品開発プロセスに取り入れることができます。

Windows CE の計画チームは、製品計画プロセスを開始するに当たって、世界各国の顧客と面談し、製品開発に対するそれぞれの現実および見込まれるニーズを調査しています。このような面談は、前のバージョンの製品の発売の直後から開始されました。なぜなら、革新はとどまることのないプロセスであるからです。それらの面談に基づいて、社内でドラフトの開発計画が立てられて検討されます。

ドラフト開発計画が整ったら、次のステップでは、設計の見直しのために、その一環として計画を検証します。そこでは、マイクロソフト社外から数百人が招聘されて意見を述べ合います。筆者は、2005 年 6 月に開催された CE 6.0 計画の設計検討会に参加しました。この 1 週間にわたるイベントは、参加者が守秘同意書 (NDA) に署名したうえで開始されました。それは、双方の当事者がオープンかつ率直な議論を交わせるようにするためです。設計を検討する実際の仕組みは大変興味深いものです。まず、機能の中核となる領域が、開発チームのメンバによって説明されます。どのプレゼンテーションでも終了時点に質疑応答の時間が設けられており、参加者は、登録時に支給されたワイヤレスの投票ボックスを使用します。投票が行われるごとに、その結果はすぐに表示され、全員がそれを見て議論を戦わせます。

その 1 週間が終わるまでには、開発チームがどのように優先順位を設定すればよいかに関する数百種類の意見が各参加者から出揃います。このようなやり取りの真価を最も的確に決めるものは、開発チームに与えられるヒントです。そのようなヒントは、今後の製品バージョンへの特定の機能の組み込みを切望する顧客に対して、率直な質問を提示してはじめて得られます。

関心の対象となる具体的な機能は、各人が作業で使用するガジェットの種類によって異なります。ヘッドレスの業務用コントローラの設計者であれば、次世代のミシン アプリケーションを作成しているソフトウェア開発者に対して、多種多様な要求事項があるはずです。この両者とも、携帯電話アプリケーションの開発者にとっては理屈に合わないやり方で、関心の対象物を定義するかもしれません。ここが肝心な点です。

Windows CE は多種多様なガジェットの基盤となっていますが、多くの場合、これは、Windows Mobile で稼働するデバイスおよびカスタムの組み込みデバイス (つまり、他のものすべて) の 2 種類に大別されるという印象を与えているかもしれません。しかし、1 つのプラットフォームで、標準とカスタムの両方のデバイスをサポートできるのでしょうか。答えはイエスです。Windows Mobile デバイスおよびカスタムの組み込みデバイスは、包括的なテクノロジ ポートフォリオによって互いに結びつけられています。このポートフォリオを構成するものには、小型であっても機能性の高いマルチスレッド カーネル、充実したプログラミング API ファミリ (Win32、MFC、および .NET Compact Framework)、および強力でしかも拡張可能な一連の開発ツールなどがあります。

Windows Embedded CE 6.0 (CE 6.0) には、新規のカーネルが導入されています。それによって、従来のカーネルの制限事項に対処する一方で、小型の CPU のパフォーマンスがなお一層向上します。この記事では、新規の CE 6.0 オペレーティング システムの諸機能について解説します。それにはまず、新規の API 配置スキーム、カーネル モードの新しい使用方法、およびメモリ アーキテクチャといった、新規カーネルに付帯する機能から解説を始めます。その後、CE 6.0 の他の新機能を取り上げます。

最後に、無数の Windows CE 構成を構成し、ビルドし、そしてテストするための新しいツールを取り上げます。ツールの解説は、カスタムの Windows CE 構成を作成する組み込みアプリケーションの開発者を直接の対象としています。よって、Windows Mobile の開発者であれば、この記事の後半をスキップしたいでしょうが、Windows CE 共用ソースの解説に特に注意を払いながら、すべてに目を通すことをお勧めします。これは、このソース コードからのみ提供される Windows CE の内部情報を知る必要のある全員にとって必須のリソースであるからです。

API の配置スキーム

Windows CE の長所の 1 つは、デスクトップ バージョンの Windows の各種機能および最適化の利点を開発で活用できる点にあります。最初のバージョンの Windows CE から始まって、Windows CE 5.0 までのどのバージョンでも、初期バージョンの Windows NT にあったものに似たクライアント/サーバー アーキテクチャを使用して Win32 API は配置されていました。

たとえば、Windows NT 3.5 では、クライアント/サーバー ランタイム サブシステムである csrss.exe という、たった 1 つのプロセス内にすべての GUI 関数が配備されます。CreateWindow や TextOut などの関数を呼び出すと、ローカル プロシージャ呼び出し (LPC) と呼ばれるプロセス間通信メカニズムを通して、CSRSS プロセスが起動されます。重量級の Windows NT プロセスどうしの間で何回もコンテキストの切り替えを行うと、パフォーマンス上の犠牲を払うことになるので、このアーキテクチャは、Windows NT 4.0 (1996 年にリリースされました) では正式に中止されました。その時点で、それまでのユーザー モード API ライブラリはすべて、カーネル モードに移し変えられました。

それに類似した変更が、Windows Embedded CE 6.0 のリリースでも行われることになります。また、Windows CE のこれまでのどのバージョンでも、クライアント/サーバー メカニズムを使用して、ターゲットの Win32 関数へ呼び出し元から接続していました。Windows CE と Windows NT とでは、類似点はあっても、それぞれの実装の間に相違があることに注意することが大切です。1 つの相違点として、Windows CE のほうが Windows NT よりもはるかに軽量なプロセスを使用するので、パフォーマンス上の犠牲はあまり大きくなりません。Windows CE は、Windows NT とは違って、構成可能になるように設計されています。また、システム API を配置するプロセスの使用のおかげで、オペレーティング システム全体のどの程度を個々のデバイスが必要とするかに応じて、ROM および RAM の所要量をゲート制御できるようになりました。たとえば、システム カーネル (nk.exe) というたった 1 つの API プロセスを使用して稼働するように、デバイスを構成することができます。GUI サポートを必要とするその他のデバイスも、GUI (gwes.exe) プロセスを実行する必要があります。

新規モデルでは、確かにパフォーマンスの改善は見られますが、変更を行う本当の理由は、次世代のデバイスの開発でボトルネックを生じる可能性のある制限事項を排除することにあります。Windows CE のプログラマにはよく知られているそのような制限事項には、合計プロセス数に対する制限 (32) や、前世代の Windows CE カーネルの仮想アドレス スペースの狭小さ (32 MB) などがあります。

最初のカーネルの配置後の 10 年間くらいで、多くの変更が加えられました。最近のデバイスには、これまで以上に機能を強化されたハードウェアを備えることができます。たとえば高速化された CPU、拡大されたストレージ、カラー LCD 装備の表示画面などがその例です。昨今の設計では、従来のモデルのような小さなメモリ フットプリントは必要ありません。したがって、設計のやり直しが必要になります。CE 6.0 では、システム API は独自のユーザー モード プロセスから取り出されて、カーネル モード DLL 内に置かれます。 図 1 は、Windows CE 5.0 および CE 6.0 の間の変更点を要約しています。

オペレーティング システムのこのような再編成が進行中である一方で、別の重要な変更も行われました。すなわち、オペレーティング システム コードから OEM コードが分離されました。従来はハードウェア設計者は、OEM アダプテーション層 (OAL) と呼ばれる低レベルの一連のルーチンを作成していました。しかもそのコンポーネントは、オペレーティング システムのカーネルに静的にリンクしていました。OAL およびカーネルは、nk.exe という 1 つの実行可能モジュールと見なされていました。現在、CE 6.0 ではこの 2 つのコンポーネントは、カーネル (kernel.dll) および OEM アダプテーション層 (nk.exe) という 2 つの別々のモジュールに分けて構築されます

カーネル モード操作

Windows CE を実行するには、2 つの特権レベルが CPU でサポートされなければなりません。高いほうの特権レベルをカーネル モードと呼び、低いほうの特権レベルをユーザー モードと呼びます。コードまたはデータに割り振られるメモリはすべて、この 2 つのモードのいずれかに割り当てられます。コードをユーザー モードにすれば、環境全体がさらに強固にしかも安全に稼働するようになります。ただし、このような利点は犠牲を伴います。なぜなら、ユーザー モードとカーネル モードのコードを混合すると、一般的にはカーネル モードだけでシステムを実行するより実行速度は遅くなるからです。

これまでのバージョンの Windows CE は、すべてのカーネル モード操作用に構成するか、またはカーネル モードとユーザー モードの両方を使用した混合モード操作用に構成することができました。CE 6.0 では、混合操作モードのみがサポートされます。その際、すべてのアプリケーションをユーザー モード メモリにロードし、すべての OS コンポーネントをカーネル モード メモリにロードします。 図 2 に示されているとおり、一部のコンポーネントは、ユーザー モードとカーネル モードの両方の形態をとります。このような配置では、オペレーティング システム イメージの巨大化という犠牲と引き換えに、特権の境界を越えて呼び出しを行う手間を最小化することができます。

メモリのアーキテクチャ

新規カーネルは、まったく新規のメモリ アーキテクチャを実現します。つまり、選択可能なプロセスおよびアドレス スペース サイズに対するこれまでの制限が撤廃されます。従来のカーネルは最大 32 個のプロセスをサポートし、そのプロセスのいずれもが、それぞれ独自のプロセス スロットを占有していました。CE 6.0 では、プロセス数の限度が 32 K に引き上げられています。(これは、カーネル　ハンドルのストレージに対する制限に基づいた理論上の最大値です。CE 6.0 は最大 64 K のカーネル ハンドルを収容することができ、プロセスそのもの用に 1 つと、プロセスのスレッド用に 1 つの、最低限 2 つのハンドルが 1 つのプロセスで必要になります。実際の最大値はこれより小さくなります。それは、他のタイプのカーネル オブジェクトは、カーネル ハンドル テーブル内のスペースを占有するからです。)

CE 6.0 より前は、各 Windows CE プロセスごとに 32 MB の仮想メモリ アドレス スペースがありました。CE 6.0 では、どのプロセスにも 2 GB のアドレス スペースが設けられています。プロセスのアドレス スペースの構造は、アドレス スペースが拡大しただけでなく、様変わりしました。CE 6.0 より前は、1 つの仮想アドレス スペースが 32 個のスロットに分割されていて、プロセス アドレス スペースどうしの間にオーバーラップはありませんでした。CE 6.0 ではどのプロセスにも、それ独自の完全にプライベートなプロセス アドレス スペースが与えられます。このような変更によって、CE 6.0 プロセス アドレス スペースは、デスクトップ バージョンの Windows (Windows XP など) のプロセス アドレス スペースに非常に似たものになりました。

おそらく、この新規のメモリ アーキテクチャから既存のソフトウェアはどのような影響を受けるのかとお考えになるでしょう。一般的に言って、大半の変更は、デバイス ドライバに対するものに限定されます。プロセス アドレス スペースのサイズがかなり拡大されたとはいえ、正常に稼働しているアプリケーションがそれを感知することはありません。なぜなら、前と同じアロケーション API を使用してメモリが割り振られ、これまでどおり 32 ビットの仮想メモリ ポインタを使用してデータが保管されるからです。新規のメモリ アーキテクチャによって簡単になるものがいくつかあります。たとえば、デジタル カメラのセンサーから読み込んだ、高解像度画像を保存するために必要になるような、10 MB を越えるきわめて巨大なメモリ ブロックを割り振る必要のあるアプリケーションなどがその好例です。従来は、大きなデータ ブロックが必要になった場合、共用メモリアロケーション関数 (たとえば、MapViewOfFile) を使用した割り当てを行う必要がありました。CE 6.0 より、VirtualAlloc を呼び出しさえすれば、大規模な割り当てに簡単に対応できるようになります。

プロセス アドレス スペースのサイズの拡大以外にこのメモリ アーキテクチャに導入された他の変更点として、完全にプライベートなプロセス アドレス スペースがあります。CE 6.0 より前は、一般的に、プロセスが別のプロセスのアドレス スペースを検索するのはきわめて容易でした。もはや現存しないスロット式アドレス スキームでは、現在実行中のプロセスはスロット ゼロにマップされます。これは、0 から 32 MB の範囲のメモリを参照するように、すべてのポインタを整備することによって行われていました。MapPtrProcess などの関数を呼び出すことによって、現在実行中のプロセスは別のプロセスからポインタを取り出して、プロセス スロット内のそのメモリに直接アクセスすることができます (スロット 1 の場合は 32 MB ～ 64 MB の範囲、スロット 2 の場合は 64 MB ～ 96 MB の範囲など)。しかし、プライベート プロセス アドレス スペースが実装されたため、アプリケーション プロセスは他のアプリケーション プロセスのアドレス スペース内を検索できなくなりました。そのため、2 つのプロセスが同じメモリを対象に読み取り、および書き込みを行うには、標準の Win32 共用メモリ API を使用する必要があります。

この新規アーキテクチャから最大の影響を受けるのはデバイス ドライバであると思われる理由の 1 つは、既存の Windows CE デバイス ドライバは多くの場合、MapPtrProcess などの関数を使用して、アプリケーションのアドレス スペースで直接読み取りまたは書き込みを行うからです。CE 6.0 では、アプリケーションのアドレス スペース内のデータにやはりアクセスする必要のあるドライバは、カーネル モードで実行する必要があります。そのためには、ユーザー モードのカーネル ライブラリではなく、該当する一連のカーネル ライブラリ (k.coredll.dll) にリンクします。

場合によっては、カーネル モードではなくユーザー モードでデバイス ドライバを実行する必要があるかもしれません。たとえば、カーネル モードの完全特権の認可の対象にはしたくないドライバがある場合もあります。そのような場合、ユーザー モードのデバイス ドライバ プロセス udevice.exe を使用して、CE 6.0 でそのドライバを実行することができます。

次に、CE 6.0 で使用可能になったいくつかの新機能を見てみましょう。それには、開発者ツールの拡張機能もあれば、作成するカスタム組み込みデバイスに組み入れることのできる新機能もあります。

デバイス エミュレータ

SF 小説の作家が書く物語では、機械が人間のように行動することがよくあります。それなのに、他の機械をまねる機械の活躍を書き記した物語はめったにありません。もし、デスクトップ システムが携帯電話の動作をシミュレートできたら、驚嘆に値するのではないでしょうか。

実際、そのような物まねは目新しいことではありません。それどころか、コンピュータそのものと同じくらいの歴史があります。1960 年代には、当時の新製品 IBM 360 は、その前身である IBM 1401 をエミュレートできました。1970 年代には、DEC-10 は MITS Altair をエミュレートして、Microsoft の最初の BASIC インタープリタをデバッグしていました。最近では、当然、Microsoft の Virtual PC があります。ただしそこでは、エミュレーションは仮想化になっています。

Windows CE は、3 世代のエミュレータの歴史をたどってきました。最初のものは、ほぼ同等の Windows NT 関数を直接呼び出すことによって、Windows CE をサポートしていました。出だしとしては順調でしたが、補足すべき点はかなり残っていました。第 2 世代は、ハードウェアの仮想化を使用するカスタム組み込みプラットフォームとして登場しました。これは、実際のデバイスと同じ低レベルの命令を実行しました。これは非常に有能なエミュレータでしたが、x86 以外のプロセッサへの配置に重点を置いている開発者にとっては欠点がありました。というのは、I86 命令セットを使用してビルドされていたからです。CE 6.0 に付属している第 3 世代のエミュレータは、ARM V4I 命令セットの命令レベルのエミュレーションを実現します。このエミュレータは、デバイス エミュレータとして CE 6.0 Platform Builder に付属しています。

この最新世代は、ARM V4I 命令セットをサポートします。x86 命令セットは、デスクトップの領域では主流を占めていますが、組み込みの領域にはまだ進出していません。後者の領域を先導しているのは、英国の ARM Holdings, Ltd. によって設計されたライセンス付きの命令セットです。マシン命令セット レベルでのエミュレーションの利点は、バイナリ互換性にあります。エミュレータ用に x86 の実行可能ファイルを作成し、実際のデバイス用に別の ARM 実行可能ファイル セットを作成する手間をかけなくても、1 つのバイナリ セットを作成すれば、両方とも実行することができます。便利さが増すだけでなく、テストの信頼性を高めることも可能です。なぜなら、セットアップ スクリプト中のエラーや、コンパイラまたはリンカのバグにわずらわされずに、同じ実行可能ファイルを使用してどの箇所でもテストできるからです。

CE 6.0 のセル テクノロジ

マシンからマシンへの通信を使用可能にするために、携帯電話ネットワークへ接続するのに必要なインターフェイスが CE 6.0 に組み込まれています。従来は、電話呼び出しや SMS (テキスト) メッセージの送信のサポートは Windows CE には用意されていませんでした。CE 6.0 では、携帯電話ネットワークへの接続のための一連のコンポーネントの選択セットが使用可能になっています。

CE 6.0 には cellcore.dll が備えられています。これは、Win32 API を拡張して、データ接続の開始や SMS メッセージの送信などのさまざまな携帯電話サービスをサポートします。CE 6.0 に備えられた別のキー コンポーネントに ril.dll があります。これは、無線インターフェイス層 (RIL) 用のドライバです。このコンポーネントは、アプリケーション層を携帯電話ハードウェアに接続するための低レベル インターフェイスとして機能します。これまでは、Windows CE 上で携帯電話を構築するには、独自のインターフェイス層を開発する必要がありました。これは簡単なことではなく、決意を固めた数少ない開拓者だけが挑んだ作業でした。

CE 6.0 には、カーネル モード ドライバ (wapdrv.dll) およびユーザー モード API (wap.dll) も含め、WAP (Wireless Application Protocol: ワイヤレス アプリケーション プロトコル) 用の低レベル コンポーネントをはじめとする、その他のサポート要素もあります。CE 6.0 に備わったブラウザには、WAP ブラウズのサポートはなく、HTML 専用のブラウザのサポートがあることに注意する必要があります。Windows Mobile で稼働するデバイス (WAP をサポートします) に付属している Pocket Internet Explorer は、CE 6.0 に付属している HTML 専用バージョンとは異なります。

そのようなワイヤレス データ端末の作成を可能にするために、SMS メッセージングの充実したサポートがあります。これが重要な理由は、携帯電話ネットワークは SMS を使用して、ボイス メール、ファクシミリ、および電子メールなどのサービスに関する通知を送信するからです。したがって、SMS ブロードキャスト メッセージ、通知メッセージ、および状況メッセージの受信を可能にするための充実した一連の SMS サービス プロバイダが CE 6.0 に備えられています。

ロケーションベースのプログラミング

コンピュータがモバイル化する以前は、コンピュータのロケーションの判別に対してあまり関心は払われていませんでした。空調設備の整った機密室にメインフレーム コンピュータが搬入されてしまったら、その場所を判別する必要はなかったからです。昨今のポケット サイズのシステムや車載型自動車用コンピュータの登場によって、ロケーションの問題が突如として関心を集めています。

Microsoft は、Windows Mobile 5.0 を使用する GPS (Global Positioning System: 全地球測位システム) API のサポートを導入しました。現在、これと同じ API と、それをサポートするドライバが CE 6.0 で使用可能になっています。

セキュリティの拡張

ここ数年にわたって、すべてのコンピュータ システムのセキュリティを強化する方法の策定が、大きなテーマとなっています。セキュリティは、何といっても Windows Vista? のメイン テーマの 1 つです。しかも、CE 6.0 チームも、セキュリティをその重要課題として位置づけています。

CE 6.0 に加えられた改善点を取り上げる前に、Windows CE に既に存在するセキュリティ機能に一通り目を通しておきましょう。Windows CE セキュリティの中心要素は、Windows CE で稼働するデバイスの機能によって成り立っています。つまり、どのアプリケーションおよび DLL のロードおよび実行を許可するかが、厳格な統制下に置かれます。デバイスは、OEMCertifyModule 関数を通して、無許可のコードが実行されないようにすることができます。許可を受けたモジュールを識別するためによく使用される方法としては、デジタル証明書の使用があります。デバイスのセキュリティは、さまざまな構成を使用してセットアップすることができます。たとえば、有効な証明書の付いていない未知のモジュールにはすべて、システム アクセスを拒否できるように構成することもできます。あるいは、このメカニズムをオフにして、すべてのモジュールがすべてのシステム サービスに完全アクセスできるようにすることもできます。

別の中心的なセキュリティ機能に、暗号化 API があります。これを使用してアプリケーションは、さまざまな暗号化アルゴリズムを介してデータ ブロックの暗号化および暗号化解除を行うことができます。暗号化アルゴリズムは、CALG_DES や CALG_AES といった、プレフィックス CALG_ の付いたシンボル名で識別されます。また別のセキュリティ機能として SSL (Secure Sockets Layer: セキュア ソケット レイヤ) があります。これにより、セキュアな HTTP 接続が実現されます。それ以外に、PPTP (Point-to-Point Tunneling Protocol: ポイント ツー ポイント トンネリング プロトコル) を介して、VPN (Virtual Private Networking: 仮想プライベート ネットワーキング) がサポートされます。また、サーバー システムとのセキュアな接続を可能にするためのさまざまな認証メカニズムが Windows CE でサポートされています。それには、Windows NT LAN Manager プロトコルや、それより強じんな Kerberos 認証プロトコルなども含まれます。

前のバージョンの Windows CE に装備されていたその他の機能には、資格情報マネージャ、スマート カードのサポート、DPAPI (Data Protection API: データ保護 API)、公開鍵証明書 (PKI) のサポート、および LASS (Local Authentication Subsystem: ローカル認証サブシステム) などがあります。それでは、CE 6.0 での新規のセキュリティ機能は何でしょうか。

この記事の前半で述べたとおり、ユーザー モード コードとカーネル モード コードは明確に区別されています。CE 6.0 では、保護サーバー ライブラリ (PSL) と、ユーザー モードからカーネル モードに渡される I/O コントロール (IOCTL) パラメータの妥当性検査が強化されたため、カーネル モードのセキュリティおよび安定度が向上しました。

セキュア ローダーのサポートによって、システム周辺のセキュリティを大幅に改善することができます。セキュア ローダーを使用すれば、信頼されたコードだけがシステム上で実行されるようになります。Windows CE 5.0 では、ローダー フックがオペレーティング システムに備えられていましたが、OEM は自社独自のセキュア ローダーを作成する必要がありました。それに対して CE 6.0 には、セキュア ローダーが標準装備されています。信頼性に関するローダーの判断は、証明書に基づいて下されます。これは、システムで実行されるすべてのコードは、署名付きでなければならないことを意味します。セキュア ローダーを有効にした場合、コードのシグニチャが検査され、信頼のおける証明書によってそのシグニチャが署名されていれば、そのコードの実行が許可されます。適切に署名されていなければ、モジュールのロードは失敗します。どの証明書に信頼を置くかは、OEM の裁量に委ねられるので、システムで実行するコードもその制御下に置かれます。

セキュリティ上の改良が加えられた別の領域に、Windows CE の OS デザイン (新しいプラットフォーム) ウィザードがあります。デバイスのセキュリティを損なうような機能を使用してプラットフォームを構成すると、セキュリティ警告が出されます。たとえば、図 3 は、オブジェクト交換 (OBEX) プロトコルをプラットフォームに組み込んだときに表示される通知を示しています。発生する可能性のある被害の詳細が示されます。これは、プラットフォーム開発者が、プラットフォームの開発プロセスの初期段階で潜在的な問題点に対処するのに役立ちます。

図 3 デザイン ウィザードのセキュリティ警告 (Click the image for a larger view))

CE 6.0 セキュリティに追加された最後の機能は、セキュア ブート ローダーのサポートです。ダウンロードしたオペレーティング システム (NK.BIN) のイメージに、有効なデジタル署名が付いていることがこの機能によって確認されてはじめて、システムでの OS イメージのインストールと実行が許可されます。

開発ツール

CE 6.0 以前は、Windows CE チームは、Platform Builder という名前のスタンドアロン製品を送り出していました。CE 6.0 では、プラットフォーム開発ツールは Visual Studio 2005 に統合されています。Visual Studio はもちろん、クライアントおよび Web の両方を対象とした第一線の開発ツールですが、現在はこのツールを使用して Windows CE をサポートすることができます。IntelliSense、構文検査、構文の強調表示、アウトライン ビュー、および関数の完了などの、アプリケーション開発者にとって便利な機能を、カスタムの Windows CE プラットフォームの開発で使用することができます。

Visual Studio パラダイムへの適合性を向上するために、Platform Builder の一部の用語が変更されました。現在、Windows CE 5.0 ワークスペースは、CE 6.0 ではソリューションとなっています。現在、Windows CE 5.0 プロジェクト (IDE 定義のアプリケーションまたは DLL) は、CE 6.0 ではサブプロジェクトとなっています。

新規の CE 6.0 プラットフォームを構成して作成しようとするときに Visual Studio 2005 を開始するのは、最初は奇異な感じがしましたが、Windows CE 5.0 の設定およびコマンドがどのように Visual Studio にマップされるかを習得するまでに、あまり時間はかかりませんでした。新規の Windows CE プラットフォームを作成するコマンドは、どちらのバージョンのものも互いに似ています。Windows CE 5.0 の場合、[ファイル] | [新しいプラットフォーム...] メニュー項目を選択します。Windows CE 6.0 では、[ファイル] | [新規] | [プロジェクト...] メニューを選択します。CE 6.0 ツールがインストールされていれば、新規プロジェクト タイプが Visual Studio の [新しいプロジェクト] ウィンドウに追加されます。プロジェクト タイプは、Platform Builder という名前になります。 図 4 には、「OS デザイン」用の新規のプロジェクト テンプレートと共に、この変更が示されています。

図 4 Platform Builder プロジェクト タイプを示した [新しいプロジェクト] ウィンドウ (Click the image for a larger view))

プロジェクトのロケーションおよび名前を選択してから [OK] をクリックすれば、Windows CE の OS デザイン ウィザードが表示されます。作成したものの新しい名前 (「Platform Builder ワークスペース」ではなく「OS デザイン」) は別として、新規の CE 6.0 ウィザードは、以前の Windows CE 5.0 ウィザードと同じです。

新たに手を加えたいくつかの部分は別として、OS デザイン ウィザードの残りの部分は、Windows CE 5.0 Platform Builder の経験のある方全員にとってなじみ深いものです。前のバージョンと同様に、新規プラットフォームを定義する最初のステップでは、1 つ以上のボード サポート パッケージ (BSP) を選択します。すると、ウィザードからプロンプトで設計テンプレートをたずねられます。これは、プラットフォームの初期構成として利用するためのものです。Windows CE 5.0 の設計テンプレートのいくつかは改名されています。場合によっては、旧設計テンプレートが設計テンプレート変種として表示されることがあります。Windows CE 5.0 では「小さなカーネル」と呼ばれていたものが、CE 6.0 では「Small Footprint Device」と改名されました。ただしそれ以外では、これは Windows CE で稼働するヘッドレスのプラットフォーム用の最小限のオペレーティング システム機能セットを表します。

Windows CE の OS デザイン ウィザードは OS デザイン (.pbxml) を作成します。これは Visual Studio プロジェクトになります。OS デザインは、ソリューション (.sln) ファイルに追加されます。ウィザードを完了すると、新たに作成されたソリューション ファイルが開きます。Windows CE 設計ソリューションを開くと、Visual Studio のメニューが変更されて、[ビルド] および [デバッグ] というお馴染みの Platform Builder メニューが表示されます (図 5 および 6 を参照)。[ターゲット] メニューにも変更が加えられます。

図 5 [ビルド] メニュー

図 6 [デバッグ] メニュー

Visual Studio の初心者の場合、作業を開始するためのヒントが 2 つあります。その 1 つとして、[ソリューション エクスプローラ] が中心的役割を果たします。これが開かない場合、[表示] | [ソリューション エクスプローラ] を使用して起動してください。このウィンドウのコンテンツを掘り下げていけば、多数の構成の詳細を確かめることができます。

コンテキスト (つまりポップアップ) メニューもまた、Visual Studio での中心的役割を果たします。このメニューを起動するには、これを選択してマウスの右ボタンでクリックします。たとえば、[ソリューション エクスプローラ] ウィンドウで OS デザイン ソリューションを選択してから、[プロパティ] メニュー項目を選択することによって、OS 構成ウィンドウを開くことができます。

重宝なツール

ソフトウェア開発の世界において最も制約を受けるリソースは、人的稼働時間です。ツールが優れていればいるほど、担当者の生産性はますます高くなるので、開発ツールへの投資に終わりはありません。組み込み製品開発の中核を成す Windows CE Platform Builder が既に Visual Studio 2005 に統合されているので、Platform Builder チームは、IDE の保守に代えて、気のきいた新ツールの追加に積極的に取り組むことができます。なぜなら、Visual Studio には、それ専用の開発チームが付いているからです。

このグループによって開発された気のきいた未来のツールの感触を味わうことができます。そこには、CE 6.0 で導入された 2 つの新しい機能が備えられています。その 1 つは、グラフィカル レジストリ ファイル エディタです。これを使用すれば、新規のレジストリ キーおよびレジストリ値の編集および .reg ファイルへの追加を簡単に行うことができます。もう 1 つの気のきいたツールは、nk.bin ファイルの中身を検査するためのランタイム イメージ ビューアです。このツールを使用すると、2 つのそれぞれ異なる nk.bin ファイルどうしの比較でさえ可能になります。最後に、共用ソースがあります。技術的に言えばツールではありませんが、Windows CE 開発者にとって有用なオープン ソースの出現は、筆者に言わせればたいへん期待の持てるものです。

レジストリ ファイル エディタ

Windows CE コンポーネントを構成する際の重要な局面の一環として、システム レジストリの設定値を作成します。これまでレジストリ (.reg) ファイルは、図 7 に示されているように、生のテキスト フォームで編集する必要がありました。 図 8 に示されているとおり、新規のレジストリ ファイル エディタが Visual Studio に用意されています。これのほうが、はるかに使いやすくなっています。ただし必要時には、レジストリ編集ウィンドウの下部にある [ソース] ボタンをクリックすれば、これまでどおりプレーン テキスト バージョンのレジストリ ファイルを編集することもできます。また、既定の編集モードは、開発者が使い慣れたレジストリ編集ツールに似ています。

図 8 Visual Studio のレジストリ ファイル エディタ (Click the image for a larger view))

ランタイム イメージ ビューア

さらに別の重宝な開発機能として、ランタイム イメージ ビューアがあります。原則として、Windows CE イメージは nk.bin ファイルに書き込まれます。これまでは、ある特定の nk.bin ファイル内に何があるかを正確に知ることは困難でした。しかも、nk.bin どうしの内容を比較することはほぼ不可能でした。そのため、試行錯誤と当て推量を繰り返し、とうの昔に忘れてしまった変更の詳細の記憶を苦心してたどりながら、大量のトラブルシューティングを行うはめに陥ります。イメージ ビューアは、その種の問題に手を貸します。

図 9 は、デバイス エミュレータ BSP および Small Footprint Device 設計テンプレートを使用して構築された Windows CE イメージの内容を示しています。モジュールを選択し、その結果を Visual Studio の [プロパティ] ウィンドウに表示することによって、どの実行可能モジュール (*.exe および *.dll) ファイルに関するヘッダー情報でも表示することができます。イメージ ビューアを使用して、.bib ファイルの FILES セクションに収められているどのファイルの内容でも表示することができます。

図 9 nk.bin の表示のためのランタイム イメージ ビューアの使用 (Click the image for a larger view))

共有ソースおよび Windows CE の開発

CE 6.0 では、Windows CE 3.0 で登場したプログラム (共用ソース プログラム) がそのまま活用され続けます。オープン ソースの動きをきっかけとして、Windows CE Platform Builder の評価版をダウンロードする人全員が、Windows CE のソース コードのかなりの部分を利用できるようにするための取り組みが、マイクロソフト社によって開始されています。

Windows CE で実行するためのアプリケーションを構築する開発者は、他のオープン ソース プロジェクトから既に実質的な恩恵を被っています。おそらく、中でも最もよく知られているのは、.NET Compact Framework の拡張版である OpenNETCF プロジェクトです。OpenNETCF プロジェクトは、ここからダウンロードすることができます。

マイクロソフト社は、Bluetooth プロジェクトなどの、いくつかのソース コード プロジェクトを直接後援しています。ここには、Windows CE ベースのアプリケーションでの Bluetooth の使用を容易にするためのマネージ コード クラスが用意されています。それ以外に、利用可能なドライバが公的にはないときに、webcam を使用した設計に取り掛かるために使用される webcam ドライバも用意されています。マイクロソフト社が後援する 3 番目のプロジェクトとして、デジタル ビデオ レコーダ (DVR) プロジェクトがあります。これは、Windows CE で稼働するビデオ レコーダの製造をサポートするためのものです。

まとめ

Windows CE 開発の世界はますます活況を呈しています。アプリケーション開発および Windows Mobile で稼働するデバイス、デバイス ドライバの開発、または低レベルの BSP プログラミングのいずれに関心がある場合でも、開発業務の簡略化および効率化に結びつく革新は必ず見つかります。新規のカーネルによって、利用可能なプロセスおよびプロセス アドレス スペースに対する厄介な制限事項の一部が取り除かれました。Visual Studio との統合によって、Visual Studio 2005 に備わっているすべての生産性強化への道が通じました。

これまで Windows CE をお気に入りだった方は、今後はのめり込むことになるでしょう。Windows CE の世界への新しい参加者の方は、ここまでお読みになれば、おそらく可能性に満ちた未来に期待を寄せているに違いありません。そのような可能性について皆と語り合いたいとお考えの方は、Windows Embedded Developer Interest Group にぜひお越しください。

Paul Yao は、Data Security Company 社で、Utimaco ソフトウェアのビジネス統合担当部長の職に就いています。同氏は、MSDN マガジンの編集者として活躍するほかに、Windows プログラミングに関して発行した最初の書物を含め、8 冊の著書の共同著者でもあります。また、同氏は、Windows Embedded Developers Interest Group (WE-DIG) の創設者であり、Paul Yao Company の設立者でもあります。

この記事は、 MSDN マガジン - 2006 年 12 月号からの翻訳です。