WinCE6.0R2以降のQFEについて

ご存知の通り、WinCEの開発環境では不具合に対するパッチとしてQFE（Quick Fix Engineering）が提供されています。このQFEを順番に当てる事でPlatform Builderの環境が正しく保たれる訳ですが、この当て方が結構難しいのです。

実際にWinCE6.0が発表されてから、Windows Vistaの発売やWinCE6.0SP1、WinCE6.0R2の発表というようにその組み合わせが複雑怪奇となっていて、どういう順番でQFEを当てたら良いのかよくわからないという状態に陥っている方もいらっしゃるかもしれません。実際に最新のQFEではWinCE6.0R2以降でないと適用できないという条件もあり、このあたり迷ってしまう場合もあるでしょう。

そこでインストールとQFEの正しい適用方法についての記述がありますので転記します。

1. Visual Studio 2005
2. Visual Studio 2005 SP1
3. Visual Studio 2005 SP1 Update for Vista（Vistaで使用している場合）
4. Windows Embedded CE 6.0 Platform Builder
5. Windows Embedded CE 6.0 SP1
6. Windows Embedded CE 6.0 R2
7. Windows Embedded CE 6.0 Cumulative Product Update Rollup 12/31/2007
8. QFE Monthly Update（2008年1月以降）

すでに2006年と2007年に発行されたQFEはWinCE6.0SP1、WinCE6.0R2および2007年のCumulative Product Update Rollupに含まれているようなので、これだけで良いのです。2008年からは今日時点（5/1）では1月〜3月までの3回分を適用してください。

これでだいぶ楽になりました。

なおここまで最新のQFEを適用しても、CETKのところで述べたtux.hが壊れている問題は直っていませんでした。日本語版だけの問題ですが、日本語版PB6.0を利用されている方で、CETKにユーザーテストを追加する場合は、このtux.hを別途入手してください。

VistaでのQFE適用ではUACを切ろう

Windows Vistaが発売されてからしばらく経ち、開発用のPCにもWindows Vistaを搭載したマシンを導入する場合も出てきたと思います。もともとのPlatform Builder 6.0はVisual Studio 2005と共に、Windows XP Professional上での動作が保障されていましたが、VS2005にSP1を適用し、PB6.0もSP1を適用することでVista上で動作させることができるようになります。なお対象はVista BusinessとVista Ultimateです。私もVista Businessでの動作は検証しました。Vista Ultimateはインストールしたものの、動作検証は実はまだです。

ところでPB6.0のSP1を適用するためにQFEを順に適用していくと、2007年1月のQFEを当てる段階で以下のようなダイアログが表示されてしまいます。

「There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor.」、すなわち問題が発生してインストールができないからサポート担当者から販売メーカーにコンタクトしてくれということです。どういう問題が発生したかはさっぱりわからないわけです。私も普段はWinXPしか使っていないため、Vistaに関してはよくわからず、対処の方法で困ってしまいました。

であちこち聞いて回ってわかった事は、Vistaから導入されたUAC（User Account Control）という機能が処理をブロックしているということでした。「コントロールパネル」－「ユーザーアカウント」を開き、「ユーザーアカウント」を選択し「ユーザーアカウント制御の有効化または無効化」を選択してください。すると以下のような設定画面が表示されます。

ここで「ユーザーアカウント制御（UAC）を使ってコンピュータの保護に役立たせる」のチェックボックスをオフにします。

これで問題となったQFEのインストールもサクサクとできるようになります。こんな簡単なことなのに、私はしばらく悩みました。いまさらですが、Vista恐るべし。

WinCE用QFEについて

よくいろいろなセミナーでQFEを当ててくださいという話を耳にすることがあると思います。QFEはQuick Fix Engineeringの略で、Platform Builderに含まれるモジュールやソースコードに不具合や改善点があった場合に提供されるパッチです。非常に簡単に言うと、最新のQFEまでをインストールすることで、開発環境は最新のものになっているということになります。

ただ気をつけなくていけない事は、このQFE、最新のものだけを適用すればいいというわけではありません。面倒ではありますが、過去のものから順に適用しておく必要があります。たとえばWinCE6.0では、現在のところ2006までのまとめQFEと2007/1～2007/4までの各月のQFEが提供されています。これらを古い順に適用することが必要なのです。

それからQFEですが、マイクロソフトのダウンロードセンターからダウンロードできます。ところがどうやって検索を掛けたら良いのか、正直なところ探すのが大変というのも事実です。このQFEのURLをクリックするとWinCE関連のQFEが新しい順に表示されます。ご利用ください。

Nk.binの構成は？（Platform Builder 6.0）

Windows CEでOSイメージを作成すると、一般にNk.binというファイルが生成されます。このNk.binですが、その中に入れたはずのモジュールがちゃんと含まれているのだろうか？という素朴な疑問がわいてくることがよくあります。それからWinCEのライセンスの問題で、生成したOSイメージを使用するためには、どのライセンスを購入したらいいのか？という悩みもあります。

PB6.0ではこのような疑問を解決するための、いくつか便利な機能が入っています。

1. Nk.binの構成を確認する方法

これはいたって簡単に確認ができます。生成したファイルをPB6.0でオープンするだけです。“File：Open：File...”を選択し、生成したNk.binをオープンしてください。例えば前の記事で作成した“C:\WINCE600\OSDesigns\MyOSDesign\MyOSDesign\RelDir\TrainingBSP_ARMV4I_Debug\Nk.bin”を開くとPB6.0では以下の様に見ることができます。

2. WinCEライセンスの確認

“Tools：Platform Builder for CE 6.0：Run-Time Lisence Assessment Tool”を選択してください。対象となるNk.binを選択すると、以下のようにターゲットのOSイメージの構成と対象ライセンスを確認することができます。この例ではライセンスとしてProfessionalが必要だということがわかります。

Clone BSPの作成（Platform Builder 6.0）

WinCEの開発で、新しいBSPを作る際、フォルダをコピーしてあれこれ直して作るという方法があります。それでも構わないのですが、ファイル名を変更したりするのは結構面倒という話があります。そこでClone BSPを作成し、基となるBSPの構成をそっくりコピーしてしまうのがお勧めです。

Clone BSPを作るのは簡単ですが落とし穴がありますので、そこを含めて説明します。

まず“Tools：Platform Builder for CE 6.0：Clone BSP」を選択しClone BSP作成のためのWizardを起動します。

Clone BSPウィンドウが開きますので、必要な名前を入力して“Clone”ボタンをクリックしてください。以下の例ではオリジナルのBSPとして「Device Emulator: ARMV4I」を指定しています。そしてこの時の“Name”と“Platform directory”が新しいBSPの名前となります。ここで変な名前を付けると後悔しますから注意ですね。

するといとも簡単に新しいBSPのディレクトリが“C:\WinCE600\Platform”以下にできているのを見ることができます。

落とし穴

さあここでいつものように新しいOSデザインを作成すればビルドができるはずです。いつものように“File：New：Project...”を選択し新しいOSデザインを作ります。OS Design Wizardの途中で出てくるBSPの選択画面で、先ほどクローンとして作成した新しいBSPが有効になっていることがわかります。今回はこのTrainingBSP01を選択してMobile Handheldをデフォルトで作成してみます。そしてビルドです。

すべてデフォルトのままやっていますので、本来はそのままビルドが通るはずと思います。ところがなぜか以下のようなエラーが出てしまうのです。

Error: Could not find file 'C:\WINCE600\OSDesigns\MyOSDesign01\MyOSDesign01\RelDir\TrainingBSP01_ARMV4I_Debug\kitl.dll' on disk
kitl.dll C:\WINCE600\OSDesigns\MyOSDesign01\MyOSDesign01\RelDir\TrainingBSP01_ARMV4I_Debug\kitl.dll NK SHZ

Error: failed setting line
makeimg: FATAL ERROR: Command returned non-zero exit code 1 (dec).
makeimg: FATAL ERROR: Command returned non-zero exit code 1 (dec).

簡単に言うとkitl.dllが見つからないというエラーです。なんでデフォルトのままビルドしてkitl.dllが見つからないのか？これは結構困ります。オリジナルのBSPではkitl.dllはそのままリンクできますので、この原因がどこにあるか調査するのは難しそうです。もしかするとオリジナルのフォルダから、このkitl.dllをコピーして持ってくれば良いのでは？という不埒な考えも浮かびますが、正しい解決方法がもちろんあるのです。

解決編

ということで、このエラーの解決編です。本当は問題が出る前にClone BSP作成の手順としてきちんとやっておけば最初からエラーは出ません。

1. Clone BSPを作成します。
2. “C:\WINCE600\PLATFORM\TrainingBSP01\FILES”に移動します。
3. deviceemulator-preri.batを確認し、TrainingBSP01-preri.batとリネームします。すなわち“deviceemulator”の部分をディレクトリの名前にすることになります。
4. ビルドします。
5. 出来上がり。

このBATファイル名のリネームですが、PB6.0 SP1のインストールで対策されているようです。（5/29追記）

このような手順でClone BSPを作ることが出来ます。Clone BSPはオリジナルのBSPと異なるディレクトリに存在します。オリジナルを間違って修正してしまうこと無しに、ターゲットデバイスに合わせたソースの修正が可能になるわけです。

Platform Builder 6.0の小ネタ（その3） - 追試編

小ネタ3でビルドメニューについてPB6.0のビルドメニューにおいてソリューションのビルドとプロジェクトのビルドは同じと書きました。そうしたところナカタさんからソリューションのビルドはソリューションに含まれるプロジェクトをすべてビルドするもので、プロジェクトのビルドは対象のプロジェクトだけをビルドするという点で違いがあるというご指摘をいただきました。この事について確認をしましたので報告します。まず結論を言うとナカタさんのご指摘の通りでした。どうもありがとうございます。

さてこのビルドメニューに関する詳細はMSDN Libraryの当該ページをよくごらんいただきたいと思います。ここでは“Build Solution”と“Build <OS desgin>”はどちらも“blddemo -q”を実行することが記載されています。確かにBuild Solutionでは現在選択されているソリューションに含まれるプロジェクトをビルドしますと書いてあります。そこでVS2005のソリューションに以下のように複数のプロジェクトを作成してみました。

OSイメージのプロジェクトが2つ（TEST01、TEST02）とスマートデバイスのプロジェクトが1つ（APP01）です。この状態で“Build Solution”を実行すると見事にすべてのプロジェクトがビルドされました。

なるほどこういう違いがあったのですね。

Platform Builder 6.0の小ネタ（その3）

Windows Embedded CE 6.0の開発環境 Platform Builder 6.0（PB6.0）は、これまでのPlatform Builderのように単独で動作するツールでは無くなりました。PB6.0はVisual Studio 2005 Professional（VS2005）のプラグインとして動作します。なのでそのメニュー構造は結構変わっていて、これまでPBを使ってきた開発者にとって、戸惑う事が多いと思います。

今日は最初にちょっと悩んでしまいがちなビルドメニューについて書いてみます。。まずPB6.0のビルドメニューを開いた図を下に示します。以降の話はこの図をベースにします。

5. ソリューション or プロジェクト

最初に困るのはソリューションとプロジェクト名（上の例ではTEST01）にそれぞれ同じようなビルドメニューがあるという事です。

• ソリューションのビルド
• ソリューションのリビルド
• ソリューションのクリーン
• TEST01のビルド
• TEST01のリビルド
• TEST01のクリーン

ここで“ソリューション”とはVS2005の用語で、今開いているプロジェクトの事を指しています。PC用のアプリケーションを作るときは、PB6.0とは異なりOSイメージを作る事はありません。ですからこのソリューションはアプリケーションのプロジェクトを指すだけです。しかしPB6.0はOSイメージを構築するものですから、ここで“ソリューション”と“TEST01”どちらのビルドをすべきかその違いを把握しておく必要があります。

それで結論なんですが、どちらも同じという事です。好きなほうを選んで大丈夫です。じゃあ何で同じメニューが並んでいるのかというと、その理由は私にもわかりません。思うに、PB6.0がVS2005のプラグインであるため、単にオリジナルのVS2005のメニューが残っているだけではないかなと．．．

それから注意事項をひとつ。“ソリューションのビルド”メニューを良く見ると、ショートカットキーとして“F7”が割り当てられています。これはVS2005のオリジナルの機能で、アプリケーションを作られる方は多用するようです。この操作をPB6.0でついやってしまうと、長い長いSysgenからMakeimgまでの一連の操作が始まってしまいます。間違ってもPB6.0ではF7を押さないでください。

6. Advanced Build Command

ビルドメニューにはAdvanced Build Commandということで従来の“Build OS”メニューの一部に相当するコマンドが入っています。実際にはこちらを使用したほうがいいでしょう。なお下の一覧で青字はBuild Demo Toolsのコマンド、具体的にはコマンドプロンプトでのコマンドです。

• Sysgen　→　blddemo -q
• Clean Sysgen　→　blddemo clean -q
• Build and Sysgen　→　blddemo
• Rebuild and Clean Sysgen　→　blddemo clean cleanplat -c
• Build Current BSP and Subproject　→　blddemo -qbsp
• Rebuild Current BSP and Sub project　→　blddemo -qbsp -c

これはPB5.0と同じようなコマンドが入っています。“ビルド：ソリューションのビルド”メニューはこの中で“Sysgen”と同じものです。ですから一番最初にSysgenを実行してカタログイメージの構築をしたら、あとは“Build Current BSP and Subproject”メニューを選択するのが効果的です。この“Build Current BSP and Subproject”はビルド時のSysgen → Build → Buildrel → Makeimgというプロセスにおいて、Build以降だけを行います。従って最も時間のかかるSysgenフェイズが省略されますので、大幅なビルド時間の短縮となります。以前iMac＋Parallels上でビルド時間を測定した時のデータでは、Sysgenはビルド全体の78%を占めていました。先の環境では90分が20分に短縮されるという事になります。ビルド時間を短縮できるのはすごく良いことです。

なお某所では“Sysgen”すなわちblddemo -qは夜中にやっとけと言われていました。確かにビルドの時間を考えると、それはその通りですね。

Platform Builder 6.0の小ネタ（その2）

昨日の続きというか、おまけの内容を書きたいと思います。最初の話はPB6.0の話ではなく、WinCE1.0の頃から続いている話ですが、内容の理解を深めるためにあえて書きます。

3. ビルド時の制御ファイル

WinCEでOSイメージを構築するとき、OEMベンダー固有のドライバ等をビルドするために、dirsとsourcesという二つのファイルがそのフォルダ構造を示しています。

• dirs：ビルド対象のフォルダを記述します。
• sources：ビルドするソースファイルの指定や、リンクするライブラリ、出力ファイル名などのビルド情報を記述します。

たとえば以下のようなデバイスドライバがあったとします。「C:\WINCE600\PLATFORM\DEVICEEMULATOR\src\drivers」以下にはbacklight, battdrvr, ceddk, display, dmaといったようにドライバが並んでいるのが見えます。これらはそれぞれ別々のフォルダに格納されているのです。

そこでPBはどのフォルダをビルドするかという事を知るために、先のフォルダにあるdirsというファイルを参照します。そこでdirsには以下のようにビルドするフォルダが記述されているのです。

DIRS=ceddk     \
     ethernet  \
     rilpdd    \
     display   \
　　　・・・

このdirsに記述されているフォルダを順番にたどりながら、フォルダの先頭にsourcesファイルを見つけるとそのフォルダをビルドする仕組みになっています。この仕組みは非常に簡単なもので、ドライバ類を追加したときは単にdirsファイルにそのフォルダ名を追記するだけでビルドの対象になるのです。

4. dirsファイルのオープン

このdirsファイルを編集する場合、ファイルエクスプローラー等で対象のファイルをオープンして変更する事で目的は達せられます。また先日の記事と同様にVS2005＋PB6.0ではIDE上で開く事もできます。

その方法はsourcesと同様で、VS2005のソリューションエクスプローラーでdirsファイルのあるフォルダをダブルクリックするとdirsをオープンする事ができます。たとえば上記のスクリーンショットの場合には、driversフォルダをダブルクリックするだけでdriversフォルダのdirsを開く事ができます。またdirsはsourcesと異なり、ビルドするフォルダ構造をたどるための記述なので、変更がそのままビルドに影響を与えます。

なおこのVS2005＋PB6.0のソリューションエクスプローラーでは、フォルダ名をダブルクリックされるとdirsかsourcesファイルをオープンするような仕組みになっているようです。

Platform Builder 6.0の小ネタ（その1）

遊んでいる話ばかりだと、このブログのテーマとちょっとずれますので、WinCE6.0の開発環境であるPlatform Builder 6.0（PB6.0）の小ネタについて書いてみます。一応タイトルには“その1”と付いていますが、“その2”があるかどうかは気力しだいです．．．

1. sourcesファイルのオープン

PB6.0のBuildフェイズでは、そのビルドの制御をsourcesファイルで行います。たとえば%_WINCEROOT%\PLATFORM\DEVICEEMULATOR\SRC\DRIVERS\BACKLIGHTで記述されているバックライトのドライバは、このディレクトリ以下にsourcesファイルがあります。わかっていればこのsourcesファイルを直接テキストエディタでオープンして編集する事ができます。でもせっかくVS2005＋PB6.0のIDEがあるので、そこをうまく利用するとフォルダをあまり意識する必要が無くなります。

VS2005のソリューションエクスプローラーでPlatformディレクトリの下にあるドライバのフォルダ、上図では反転している“backlight”の部分をダブルクリックするとsourcesファイルがオープンできます。ちょっと便利です。

2. sourcesファイルのタイムスタンプ

1項でsourcesファイルを簡単に開く事ができました。そしてsourcesファイルを修正してファイルを保存する事でsourcesファイルの更新ができます。ファイルを保存した後に対象のモジュールをビルドすると、IDE上の作業なのでタイムスタンプを見て再ビルドしてくれるように思ってしまいがちです。しかしPB6.0ではsourcesファイルのタイムスタンプは見ないので、単にbuildとすると、sourcesファイルが更新されていても再ビルドしてくれません。

そこでこのように、対象のモジュール上で右クリックをしてサブメニューを出し、そこから“Rebuild”を選択する事で明示的に再ビルドをする必要があります。せっかくのIDEなのですが、souseceファイルのタイムスタンプを見てくれないという仕様は以前から変わりが無いようですね。残念！

システムのプロファイリング

尿管結石からなんとなく復活していますが、まだ違和感が残っています。明日は月曜日なので、地元の総合病院で検査を受けるつもりです。ということで、久しぶりにWinCEネタを書きます。

システムを構築した際、思ったような性能が出ないということはよくあります。その原因として、CPU性能が足りないとか、処理方式が悪いとか、バスが詰まっているとか、まぁとにかく色々あるわけです。でもどこが悪いのかを見つけ出すのは大変な場合も多く、あてずっぽうで処理を見直したりすることになります。特に後から追加となったアプリケーションやデバイスドライバが、その犯人に仕立て上げられたりすることもあるわけです。「お前が入ったら遅くなった」と言われて．．．

大体はエンジニアの経験に基づく勘で検討をするので、それほど大きくはずすことも無いとは思いますが、やはり定量的な指標でその原因を追究することも大切です。WinCEの開発環境であるPlatform Builder（PB）では実はそのための手段も準備されています。しかし残念ながらあまりわかりやすい方法とは言えないようです。

以前も書いたTipsに、「Target Control」でのスレッドプライオリティの変更に関する記事がありました。このTarget Cotrolは結構使えるコマンドが多く、今回の動作時のプロファイリングを行う「Monte Carlo Profile」を使うことで、モジュールがどのくらい動作しているのかを把握することができます。プロファイリングを始めるためには「prof on」、終了するためには「prof off」とTarget Control上で入力するだけで以下のような結果を得ることができるのです。

1924830 PID:a3fa510a TID:a3fa50da 0x83fa6800: Module               Hits     Percent

1924830 PID:a3fa510a TID:a3fa50da 0x83fa6800: ------------ ---------- -------

1924830 PID:a3fa510a TID:a3fa50da 0x83fa6800: IDLE                83212     96.5

1924830 PID:a3fa510a TID:a3fa50da 0x83fa6800: nk.exe               2607      3.0

1924830 PID:a3fa510a TID:a3fa50da 0x83fa6800: kbdmouse.dll        107      0.1

1924830 PID:a3fa510a TID:a3fa50da 0x83fa6800: coredll.dll              72      0.0

1924830 PID:a3fa510a TID:a3fa50da 0x83fa6800: gwes.exe               67      0.0

1924830 PID:a3fa510a TID:a3fa50da 0x83fa6800: shell.exe               26      0.0

1924840 PID:a3fa510a TID:a3fa50da 0x83fa6800: relfsd.dll                10      0.0

1924840 PID:a3fa510a TID:a3fa50da 0x83fa6800: ddi.dll                    10      0.0

1924840 PID:a3fa510a TID:a3fa50da 0x83fa6800: fsdmgr.dll                7      0.0

1924840 PID:a3fa510a TID:a3fa50da 0x83fa6800: ceshell.dll               6      0.0

1924840 PID:a3fa510a TID:a3fa50da 0x83fa6800: dc21x4.dll               6      0.0

1924840 PID:a3fa510a TID:a3fa50da 0x83fa6800: filesys.exe              5      0.0

1924840 PID:a3fa510a TID:a3fa50da 0x83fa6800: Phillo.exe               3      0.0

1924840 PID:a3fa510a TID:a3fa50da 0x83fa6800: pm.dll                     2      0.0

1924840 PID:a3fa510a TID:a3fa50da 0x83fa6800: cxport.dll                2      0.0

1924840 PID:a3fa510a TID:a3fa50da 0x83fa6800: toolhelp.dll              1      0.0

1924840 PID:a3fa510a TID:a3fa50da 0x83fa6800: commctrl.dll            1      0.0

1924840 PID:a3fa510a TID:a3fa50da 0x83fa6800: UNKNOWN              5      0.0

このように、それぞれのモジュールがどのくらいヒットしているのかが一目瞭然です。このMonte Carlo Profilerを使用すると「何で」遅くなったのかまではわからないのですが、「どこが」遅いのかはわかります。もちろんここでより多くの時間を必要としているモジュールだけが悪いわけではありませんが、ひとつの指標として捕らえることができます。

このMote Carlo Profilerを使用するためには以下の手順でOSイメージを構築することが要求されます。

1. OEMProfileTimerDisable関数とOEMProfileTimerEnable関数をOALに実装します。
2. ProfilerHit関数の呼び出しのためのISRをカーネルに実装します。
3. bProfileTimerRunningをセットするための正しいハンドルをOEMIdleに実装します。
4. IMGPROFILER環境変数がセットされている場合、Config.bibファイルのMEMORYセクションにPROFILE=ONと記述されていることを確認します。
5. OSイメージを生成します。

なお使用するカーネルは「Kernkitlprof.exe」となります。詳細はPBのヘルプをご覧いただきたいのですが、このMonte Carlo Profilerを活用することはシステムの問題点を解決する上で、非常に有効な手段の一つと言えるでしょう。