Visual Studio 2005 のネイティブ開発者向けの新機能
Nishan Jebanasam
Microsoft Corporation
May 2005
適用対象
Windows Mobile ベースのデバイス
Windows Mobile 2003 Second Edition ベースのデバイス
Windows CE ベースのデバイス
Visual Studio 2005
eMbedded Visual C++4.0
ActiveX
ActiveSync
要約: この記事では、Visual Studio 2005 のネイティブ デバイス開発機能セットの概要について説明します。この記事は、eMbedded Visual C++ の後継について知りたい eMbedded Visual C++ による開発者と、ネイティブ アプリケーションを使用するターゲット デバイスのプラットフォームについて知りたいデスクトップ コンピュータ対象の C++ による開発者の両者を対象としています。
目次
はじめに
前提条件
IDE
ネイティブ ライブラリ
デバッグ
エミュレータ
方法
はじめに
Visual Studio 2005 には、Windows Mobile ベースのデバイスと Windows CE ベースのデバイス向けの C/C++ 開発機能が含まれています。これは、eMbedded Visual C++4.0 の後継となる機能です。この開発機能を使用すると、開発者は Microsoft のデバイス プラットフォーム向けの C/C++ アプリケーションを作成できます。Visual Studio 2005 の機能の一部を次に示します。
- ネイティブ プロジェクト システムのデバイス プラットフォーム
- アプリケーション ウィザードとクラス ウィザード
- SDK の統合
- リソース エディタ
- デバイス向けクロスコンパイラ
- リモート配布とリモート デバッグ
- ネイティブ デバイス フレームワーク
- エミュレータ
- ヘルプ
前提条件
デバイス向けの開発に Visual Studio 2005 を使用するために必要な前提条件は、次のとおりです。
- Windows 2000 以降
- 192 MB の RAM(256 MB 以上を推奨)
- Intel Pentium III 600 MHz プロセッサまたは同等のプロセッサ
- ActiveSync 最新版(デバイス上にアプリケーションを配布してデバッグする場合)
- Windows Mobile 5.0 SDK(ソフトウェア開発キット)(Windows Mobile 5.0 デバイスをターゲットにする場合)
IDE
このセクションでは、Visual Studio 2005 によって提供されるデバイスをターゲットにするデザイン タイムの機能について説明します。
アプリケーション ウィザード
Visual Studio 2005 には、5 つのアプリケーション ウィザードが付属しています。このウィザードを使用すると、次の種類のプロジェクトを作成できます。
- Win32 スマート デバイス プロジェクト
- ATL スマート デバイス プロジェクト
- MFC スマート デバイス アプリケーション
- MFC スマート デバイス DLL
- MFC スマート デバイス ActiveX コントロール
図 1 に示すように、このアプリケーション ウィザードは、**[新しいプロジェクト]ダイアログ ボックスの[Visual C++]ノードの[スマート デバイス]**に表示されます。
図 1 Visual Studio 2005 のプロジェクトに使用できるアプリケーション ウィザード(クリックすると大きな画像を表示します)
図 2 に示すように、アプリケーションを作成するときは、プロジェクトでターゲットにするプラットフォーム SDK も選択する必要があります。Visual Studio 2005 には、Windows Mobile 2003 SDK が付属しているので、Visual Studio 2005 をインストールすると、すぐに Pocket PC 2003 SDK と Smartphone 2003 SDK を使用できます。
図 2 プロジェクトに追加するプラットフォーム SDK(クリックすると大きな画像を表示します)
Visual Studio 2005 に追加してインストールした Windows Mobile SDK や Windows CE SDK もこのページに表示されます(プロジェクトで使用するプラットフォーム SDK は 1 つまたは複数選択できます)。Visual Studio 2005 は、Windows Mobile 2003 プラットフォーム以降と Windows CE 5.0 プラットフォーム以降だけをサポートします。
プラットフォーム SDK を選択すると、アプリケーション ウィザードがプロジェクト、テンプレート ソース コード、既定のリソース、およびプロジェクト プロパティ(コンパイラ スイッチ、依存ライブラリ、およびその他のプロジェクト プロパティ)を生成します。
クラス ウィザード
Visual Studio 2005 には、コードを生成するクラス ウィザードも付属しています。これを使用すると、よく使う機能を実行できます。サンプルを利用すると、ATL(Active Template Library)COM オブジェクトや MFC(Microsoft Foundation Class)クラスを組み込めます。プロジェクトでクラス ウィザードを実行するには、プロジェクトを右クリックし、**[追加]をクリックしてから、[クラス]**をクリックします。
図 3 に示すように、Visual Studio 2005 は、次のデバイス プラットフォーム向けクラス ウィザードをサポートします。
- ATL シンプル オブジェクト
- ATL コントロール
- ATL ダイアログ
- ATL プロパティ ページ
- ATL サポートを MFC へ追加
- MFC クラス
- C++ クラス
図 3 Visual Studio 2005 でサポートされるクラス(クリックすると大きな画像を表示します)
Visual Studio がスマート デバイス プラットフォーム向けにサポートするクラス ウィザードでは、ウィザード アイコンに小さな「デバイス」アイコンが埋め込まれています。
構成とプラットフォーム
プロジェクトのほとんどすべての設定は、「構成」によって異なります。構成固有の設定は、デバッグ用ビルド情報または リリース用ビルド情報とプロジェクトのプラットフォームを組み合わせて行われます。たとえば、**[Pocket PC 2003 (ARMV4) Debug]構成に固有のコンパイラ スイッチを設定し、[Pocket PC 2003 (ARMV4) Release]**構成に異なるスイッチを設定できます。
各構成は、独自のプロジェクト出力バイナリを生成します。たとえば、プロジェクトが**[Pocket PC 2003 (ARMV4)]と[Smartphone 2003 (ARMV4)]をターゲットにする場合、[Pocket PC 2003 (ARMV4) Release]構成をビルドするときは[Smartphone 2003 (ARM V4) Release]構成をビルドするときとは異なるバイナリが生成されます。同様に、[Pocket PC 2003 (ARMV4) Debug]**構成をビルドすると、別のバイナリ出力が生成されます。図 4 では、SDK、プラットフォーム、アーキテクチャ、構成、およびプロジェクト出力の関係の要約を示します。
図 4 SDK、プラットフォーム、アーキテクチャ、構成、およびプロジェクト出力間の関係。
Visual Studio は、初期状態では、プロジェクト プロパティを特定の 1 つの構成に適用します。設定を複数の構成に適用するには、**[Project プロパティ ページ]ダイアログ ボックスで[すべての構成]や[すべてのプラットフォーム]を選択して、プロジェクト内のデバッグ構成およびリリース構成、またはすべてのプラットフォームに設定を適用する必要があります。さらに、一部のプロパティにはテキストが含まれています(たとえば、スイッチの列挙ではありません)。[すべての構成]や[すべてのプラットフォーム]**を選択すると、テキストを含むプロパティがクリアされることがあります。これは、プロジェクト システムがテキストの共通部分をとったり、テキストを結合しないためです。ユーザーによって選択された複数の構成でプロパティのテキストが正確に一致しない場合は、何も表示されません。このような場合は、構成ごとにプロパティを適用して、テキストが削除されないようにする必要があります。
図 5 では、デバッグとリリースの**[プリプロセッサの定義]が正確に一致しないので、ユーザーが[すべての** **構成]**を選択すると、図 6 に示すように、このプロパティがクリアされます。
図 5 デバッグとリリースで一致しないプリプロセッサ定義(クリックすると大きな画像を表示します)
図 6 不一致のため、[すべての構成]が選択されると、プロパティがクリアされます(クリックすると大きな画像を表示します)
このマルチプラットフォーム プロジェクト機能には多くの利点があります。この機能により、1 つのコード ベースを維持したり、#ifdef を使用することで、アプリケーションの UI、入力処理などをカスタマイズできます。さらに、プロパティをすべての構成に適用できるので(「プロジェクト プロパティ」を参照)、構成を簡単に保守できます。たとえば、プロジェクト出力を 1 つの証明書で署名して、すべてのプロジェクト出力に適用できます(したがって、Pocket PC バイナリと Smartphone バイナリは同じ証明書で署名されます)。
プロジェクト プロパティ
このセクションでは、デバイス開発者に役立つプロパティについて説明します。このセクションのプロパティはすべて、構成ごとに適用します。
配布
図 7 に示すように、[配布]構成プロパティには、デバイス開発者によく使用されるプロパティ セットのいくつかが含まれています。このプロパティを使用すると、ターゲットの配布デバイスを選択したり、プロジェクトと共に配布する追加ファイルを列挙したり、プロジェクト出力先のデバイスのリモート ディレクトリを指定したり、配布後にプロジェクト出力をデバイスに登録するかどうかを指定できます。[追加 **ファイル]**プロパティを使用するために、特別な構文を使用する必要がありますが、このプロパティ セットのほとんどは簡単に使用できます。
図 7 [配布]構成プロパティ(クリックすると大きな画像を表示します)
[追加 ファイル]プロパティを使用すると、プロジェクトを配布するときに、ターゲット デバイスにダウンロードする 1 つ以上のファイルを指定できます。指定したファイルはコンパイルされず、デバイスにコピーされるだけであることに注意してください(指定した場合は、登録されます)。[追加 **ファイル]**構文の例については、「方法」を参照してください。
Authenticode 署名
Windows Mobile ベースのデバイスでは、アプリケーションのセキュリティの重要性が増してきています。デバイス開発者は、さまざまなセキュリティ モデルを理解し、このセキュリティ モデルがアプリケーションの開発方法と再配布方法にどのように影響するかを理解する必要があります。
Authenticode 署名は、デジタル コンテンツの出所を認証する方法です。署名は、秘密鍵でバイナリをエンコードします。これは、対応する公開鍵でだけ確認できます。公開鍵は、デバイスにインストールできる証明書の形式で再配布されます。このようにして、ユーザーはデバイスからアプリケーションを起動するときに、アプリケーションの作成者を確認できます。ユーザーは証明機関を検証するために、信頼されているルート証明書まで証明書を追跡できます。たとえば、デバイスから追跡できる有効なルート証明書を持っている可能性が最も高いのは、信頼されている著名な証明機関です。一方、デバイスからたどることが可能な信頼されているルートを持っていない可能性が最も高いのは、独自に生成した証明書秘密鍵でアプリケーションに署名している個人の作成者です。
「A Practical Guide to the Smartphone Application Security and Code Signing Model for Developers」(英語) は、Authenticode 署名についての初歩的な情報を提供しています。この記事をよく理解する必要があります。
[Authenticode **署名をする]**構成プロパティ(図 8)を使用すると、プロジェクト出力の署名に使用する証明書を選択したり、デバイスに証明書を提供するかどうかを指定したり、証明書の提供先のデバイスでどの証明書ストアを使用するかを指定できます。提供(Provisioning)は、デバイスを特定の設定で構成する行為です(この例では、証明書を証明書ストアにインストールすることです)。
図 8 [Authenticode 署名をする]構成プロパティ(クリックすると大きな画像を表示します)
証明書を選択した後で、[Authenticode **署名をする]プロパティを[はい]に設定すると、Visual Studio 2005 は、プロジェクト出力がビルドされるたびに、プロジェクト出力に署名します。[デバイスのプロビジョニング]プロパティを[特権のある証明書ストア]に設定すると、次にプロジェクトを配布するときに、[証明書]プロパティで選択した証明書がターゲット デバイス上の特権証明書ストアに提供(provisioning)されます。同様に[デバイスのプロビジョニング]プロパティを[特権のない証明書ストア]に設定すると、次にプロジェクトを配布するときに、[証明書]**プロパティで選択した証明書がターゲット デバイス上の特権なし証明書ストアに提供されます。デバイス セキュリティ ポリシーが証明書の提供を許可していない場合、この手順は失敗するので、デバイスのポリシーを変更して、証明書の提供を許可する必要があります。
C/C++
図 9 に示すように、**[C/C++]**構成プロパティには、プロジェクト向けのコンパイラの設定のすべてが含まれています。デバイス プラットフォームのコンパイルは、ターゲットにしているデバイス アーキテクチャに固有のデバイス コンパイラを呼び出すので、デバイス プラットフォームで使用できるプロパティは、デスクトップ コンピュータ プラットフォームで使用できるプロパティと少し異なります。
図 9 [C/C++]構成プロパティ(クリックすると大きな画像を表示します)
デバイス開発者に影響する主なプロパティの一部を次に示します。
プリコンパイル済み ヘッダー
開発者が Visual Studio 2005 で作成したネイティブ デバイス アプリケーション プロジェクトのほとんどは、**[プリコンパイル済みヘッダー ファイルを使用する]に設定されます。既定では[stdafx]**です。独自のプリコンパイル済みヘッダーの作成と使用の詳細については、「方法」を参照してください。
詳細
アーキテクチャ用コンパイル
このプロパティは、コンパイルに使用する命令セットを設定します。各デバイス コンパイラは、多くのアーキテクチャの中の 1 つのアーキテクチャ用にコンパイルすることができます。
ARM と ARM Thumb 呼び出しの相互作用
このプロパティは、16 ビット ARM コードと 32 ビット ARM コードを相互にサンクするコードの生成を可能にします。
コマンド ライン
プロパティ ページで使用できない追加のスイッチを設定できます。
リンカ
図 10 に示すように、**[リンカ]**構成プロパティには、プロジェクトで使用できるすべてのリンカ設定が含まれています。
図 10 [リンカ]構成プロパティ(クリックすると大きな画像を表示します)
アプリケーションがデバイス プラットフォームをターゲットにする場合、**[C/C++]構成プロパティはデバイス固有のプロパティ セットを保持します。デバイス プラットフォームとデスクトップ コンピュータ プラットフォームで同じリンカが使用されるので、[リンカ]**構成プロパティはどちらのプラットフォームでも同じです。同じリンカを使用するので、一部のプロパティはデバイス プラットフォームに適用されませんが、表示はされます。表 1 にいくつかの例の説明を示します。
表 1 デバイス プラットフォームに適用されない[リンカ]プロパティ
プロパティ ページ | デバイス プラットフォームに適用されないプロパティ | メモ |
---|---|---|
全般 | 出力の登録 | [配布]ページで設定 |
入力 | 埋め込みマネージ リソース ファイル | なし |
システム | SubSystem
ターミナル サーバー CD からスワップ実行 ネットワークからスワップ実行 ドライバ |
なし |
最適化 | Optimize for Windows 98
Profile Guided Database |
なし |
詳細 | ターゲット
Profile CLR Thread Attribute CLR Image Type キー ファイル |
[リンカ]ページの[コマンド ライン]プロパティで設定。
[Authenticode 署名をする]ページで処理されるデバイス プラットフォーム向けの署名 |
リソース エディタ
Visual Studio 2005 ネイティブ リソース エディタは、eMbedded Visual C++、Visual C++ 6.0、および Visual Studio .NET 2003 が使用するネイティブ リソース エディタと同じなので、なじみのある外観です。Visual Studio 2005 のネイティブ スマート デバイス プロジェクトは、次の種類のすべてのリソースをサポートします。
- アクセラレータ
- ビットマップ
- カーソル
- ダイアログ
- アイコン
- メニュー
- レジストリ
- ストリング テーブル
- ツールバー
- バージョン
複数のリソース ファイル
プロジェクトが Pocket PC と Smartphone をターゲットにする場合は、Visual Studio 2005 を使用すると、ターゲットにするプラットフォームごとに別のリソース ファイルを生成することで、異なるデバイス フォーム ファクタ向けにアプリケーションの UI を簡単にカスタマイズできます。図 11 に示すサンプル プロジェクトには、Pocket PC リソース ファイルと Smartphone リソース ファイルの両方があります。Smartphone リソース ファイル(MyDeviceApp1sp.rc)には、**[ビルドから除外]アイコンが表示されていることに注意してください。これは、プロジェクトの現在のターゲット プラットフォームが Pocket PC であることを示します。したがって、ユーザーがプロジェクトをビルドすると、Pocket PC リソース ファイルだけがビルドに挿入されます。ユーザーがアクティブなターゲット プラットフォームを Smartphone に変更すると、MyDeviceApp1sp.rc から[ビルドから除外]**アイコンが消えて、MyDeviceApp1ppc.rc に表示されます。したがって、ユーザーがターゲットにするプラットフォームに基づいて、正しいリソース ファイルがプロジェクトにコンパイルされます。
図 11 Pocket PC および Smartphone リソース ファイルを使用するサンプル プロジェクト
RC2 ファイル
一部のアプリケーション ウィザードは、標準の RC(リソース コンパイラ)ファイルのほかに、RC2 ファイルを生成します。リソース コンパイラはこの RC2 ファイルを処理しませんが、RC ファイルには RC2 ファイルがインクルードされます。このファイルには、リソース コンパイラが処理方法を知らないリソースが含まれています。HI_RES_AWARE カスタム リソース(HI_RES_AWARE カスタム リソースの詳細については、「高解像度と画面の向きへの対応」を参照)に加え、RC ファイルに配置されているとリソース コンパイラが編集する RCDATA メニュー(スタイル データが同等の 16 進値で置き換えられ、元に戻すことができません)が含まれている例もあります。RC2 ファイルは、リソース コンパイラに編集させたくないカスタム リソースを格納する便利な場所です。
UI モデル
デバイス SDK は、独自の UI モデルを定義できます。この UI モデルを使用すると、ダイアログ エディタに表示されるコントロールのリストにフィルタを適用して、プラットフォームがサポートするコントロールだけを表示できます。図 12 に示すように、Visual Studio 2005 には、すでに Visual Studio 2005 に含まれている Windows Mobile 2003 SDK 向けの「CE」UI モデルが付属します。
図 12 Visual Studio とその Windows Mobile 2003 SDK 向けの組み込み UI モデル(クリックすると大きな画像を表示します)
高解像度と画面の向きへの対応
Windows Mobile 2003 Second Edition 以降には、高解像度機能(グラフィックスをより高い dpi で表示する機能)と、画面の向きの切り替え機能(画面を動的に回転し、「縦」モードか「横」モードで表示する機能)が備わっています。Visual Studio 2005 は、ネイティブ デバイス開発者に、高解像度と画面の向きに対応するアプリケーションを作成をサポートする機能を提供します。
DeviceResolutionAware.h
Windows Mobile 2003 Second Edition の開発者向けリソースがリリースされたとき、便利なヘッダー ファイル UIHelper.h が格納されていました。このヘッダー ファイルには、高解像度と画面の向きに対応するアプリケーションを作成する開発者を支援する複数のマクロと機能が含まれていました。この機能は、次のとおりです。
GetDisplayMode
現在の表示の構成が縦、正方形、または横のいずれかを特定します。
StretchIcon
アイコンを指定されたサイズに伸縮します(Windows Mobile 2003 Second Edition プラットフォーム以降にのみ適用)。
StretchBitmap
画像のグリッドを含むビットマップを伸縮します。
ImageList_LoadImage
プラットフォーム ImageList_LoadImage と同様に動作します。ただし、まずビットマップの dpi フィールドをチェック(GetBitmapLogPixels を使用)し、そのフィールドを画面の dpi と比較(LogPixelsX と LogPixelsY を使用)してから、値が異なる場合は拡大縮小を実行(ImageList_StretchBitmap を使用)します。
RelayoutDialog
ダイアログ テンプレートに基づいて、ダイアログを再レイアウトします。この機能は、すべての子ウィンドウ コントロールで繰り返され、それぞれで SetWindowPos を呼び出します。また、静的テキスト コントロールごとに SetWindowText を呼び出し、静的画像コントロール内の選択されたビットマップまたはアイコンを更新します。この方法は、現在のダイアログと新しいテンプレートが、同じ IDC を使用する同じコントロールのすべてを保持していると仮定しています。
Visual Studio 2005 では、この機能がヘッダー ファイル DeviceResolutionAware.h(名前空間「DRA::」)に含まれています。
画面の向きへの対応
5 つのスマート デバイス アプリケーション ウィザードと ATL ダイアログ クラス ウィザードは、ウィザードが生成するダイアログを回転させる WM_SIZE イベント ハンドラを含むテンプレート コードを生成します。さらに、ウィザードは、2 つのバージョンの既定のダイアログを生成します。たとえば、[バージョン情報]ダイアログの場合は、正方形/縦バージョンと横バージョンが生成されます。次のコードは、ネイティブ デバイス アプリケーションの UI をデザインするときに例として利用できます。
// Message handler for About box.
INT_PTR CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
// ...
// Other message handlers cut for brevity
// ...
#ifdef _DEVICE_RESOLUTION_AWARE
case WM_SIZE:
{
DRA::RelayoutDialog(
g_hInst,
hDlg,
DRA::GetDisplayMode() != DRA::Portrait ? MAKEINTRESOURCE(IDD_ABOUTBOX_WIDE) : MAKEINTRESOURCE(IDD_ABOUTBOX));
}
break;
#endif
}
return (INT_PTR)FALSE;
}
高解像度への対応
Windows Mobile 2003 用にコンパイルされたアプリケーション(つまり、Windows CE サブシステム バージョン 4.20)は、高解像度対応デバイスではピクセルが自動的に 2 倍になります。ただし、ユーザーがカスタム リソース(HI_RES_AWARE)を定義して、デバイスのオペレーティング システムにアプリケーションのピクセルを 2 倍にしないように通知した場合を除きます。ウィザードによって生成されたコードは、自動的に Visual Studio 2005 に HI_RES_AWARE リソースを定義します。このデザインにより、開発者はアプリケーションを作成するときに、高解像度への対応を考慮できるので、今日の市場に現れるデバイスのより新しい表示機能を利用できます。高解像度対応デバイス上で Windows Mobile 2003 アプリケーションのピクセルを 2 倍にする場合は、プロジェクトの RC2 ファイルから HI_RES_AWARE リソースを削除します。より新しいプラットフォーム バージョン(つまり、Windows CE 4.20 より新しいバージョン)でビルドするアプリケーションは、HI_RES_AWARE リソースが含まれていなくても、ピクセルが 2 倍になりません。また、Smartphone は、高解像度の Smartphone デバイス上でもピクセルを 2 倍にしないことに注意してください。
画面の向きと高解像度への対応の詳細については、「Step by Step: Develop Orientation-Aware and DPI-Aware Applications for Pocket PC」(英語) を参照してください。
ネイティブ ライブラリ
表 2 に示すように、Visual Studio 2005 は、デバイス向けの更新されたバージョンの MFC(Microsoft Foundation Class)、ATL(Active Template Library)、および SCL(Standard C++ Library)と、CRT(C Runtime)の小さなサブセットが含まれています。この新しいデバイス ライブラリは、デスクトップ用 MFC 8.0、ATL 8.0、SCL 8.0、および CRT 8.0 ライブラリ(サイズ、パフォーマンス、およびプラットフォーム機能に基づくサブセット)に基づいています。このライブラリは、Windows CE、Pocket PC、Smartphone の間で異なる点がないので、開発者はこの 3 つのプラットフォームで使用できるランタイムの機能を使用できます。ただし、このランタイムには、ある程度、プラットフォームによる違いがあります。たとえば、DCOM プラットフォーム上の ATL の動作は、COM プラットフォーム上の動作とは異なります。また、GUI とヘッドレス プラットフォームでも同様です。今後、MFC は UI モデル対応になり、AYGShell 上での動作が非 AYGShell プラットフォーム上での動作と異なるようになります。
ネイティブ ライブラリは、動的ライブラリと静的ライブラリの両方で使用できます(今後、静的ライブラリとしてだけ使用できるようになる SCL を除く)。
表 2 CRT、ATL、MFC、および SCL の概要
ライブラリ | リンク オプション | .dll 名([d] はデバッグ バージョン) |
---|---|---|
「ミニ」C Runtime 8.0 | 静的および動的 | Msvcr80[d].dll |
ATL 8.0 | 静的および動的 | Atl80.dll |
MFC 8.0 | 静的および動的 | Mfc80u[d].dll |
SCL 8.0 | 静的のみ | 適用なし |
ミニ C Runtime 8.0
MFC と ATL 8.0 は、デバイスに付属する CRT では使用できない特定の C API を使用しています。したがって、「ミニ」C ランタイムがこの追加の API を提供します。このランタイムは、完全な CRT にすることを目的にしているのではなく、主に MFC と ATL のサポート向けに提供されます。表 3 に、デバイス向けの msvcr80.dll に提供される API のリストを示します。
表 3 msvcr80.dll によって提供される API
_CrtDbgReportW | _wsplitpath_s |
_CrtGetReportHook | _ui64toa_s |
_CrtSetReportFile | _ui64tow_s |
_CrtSetReportHook | _ultoa_s |
_CrtSetReportMode | _ultow_s |
_gmtime64_s | _wcstoi64 |
_i64toa_s | _wcstoui64 |
_i64tow_s | calloc |
_invalid_parameter | memcpy_s |
_itoa_s | memmove_s |
_itow_s | strcat_s |
_ltoa_s | strcpy_s |
_ltow_s | strncpy_s |
_localtime64_s | wcscat_s |
_mktime64 | wcscpy_s |
_strtoi64 | wcsftime |
_strtoui64 | wcsncpy_s |
_time64 | wcsnlen |
_wmakepath_s |
Active Template Library 8.0
これまで、開発者は、COM ベースのアプリケーション向けの ATL を使用してきました。ATL には便利なクラスがあります。このクラスを使用すると、COM プログラミングがより簡単になるほか、文字列の操作と変換、配列、リスト、およびツリーの管理などが簡単になります。Visual Studio 2005 では、eMbedded Visual C++ に比較して、Web サービス クライアント サポート、拡張ソケット サポート(IPv6)、および強化されたセキュリティと信頼性が異なります。ただし、デバイス向けの ATL 8.0 には、デスクトップ ATL 機能のすべてがあるわけではありません。セキュリティ、サービス、ATL Data、および ATL Server は、デバイス バージョンに含まれていません(Web サービス消費はサポートされています)。この省略は、主にスケジュールとリソースの制約のためです。
Microsoft Foundation Classes 8.0
MFC も、デバイス空間で重要な役割を果たします。今日では MFC を使用するデバイス上のネイティブ アプリケーションが数多くあるほか、.NET Compact Framework の出現もあり、特にリソースに制約があるデバイスで、ネイティブ GUI アプリケーションのニーズが続くと思われます。
Visual Studio 2005 のデバイス向けの MFC は、簡単なダイアログ ベースのアプリケーションから、MFC ドキュメント/ビュー アーキテクチャを採用する高度なアプリケーションまで、アプリケーション向けの多機能なフレームワークを提供します。もちろん、デバイス オペレーティング システムには、基になるサポートがないクラスがあります。また、サイズ、パフォーマンス、またはスケジュールの理由で、移植されなかったクラスもあります。図 13 に、Visual Studio 2005 がデバイス向けにサポートする MFC のサブセットの概要を示します。
図 13 Visual Studio 2005 がサポートするデバイス向けの MFC のサブセット(クリックすると大きな画像を表示します)
Standard C++ Library 8.0
デバイス向けの Standard C++ Library 8.0 も、デスクトップ SCL のサブセットです。表 4 では、SCL 8.0 がデバイスに提供する機能について説明します。
表 4 SCL 8.0 のデバイス向けの機能
機能 | 説明 |
---|---|
診断 | 数種類の例外的な状況を報告するためのコンポーネントと、文書化プログラム アサート用のコンポーネントが含まれています。 |
汎用ユーティリティ | SCL のその他の要素内で使用されるコンポーネントが含まれています。また、このコンポーネントは、C++ プログラムによっても使用されます。このカテゴリには、STL(Standard Template Library)と関数オブジェクトによって使用されるコンポーネント、動的メモリ管理ユーティリティ、および日付/時刻ユーティリティも含まれています。また、C ライブラリのメモリ管理コンポーネントも含まれています。 |
文字列 | 「文字」のシーケンスを操作するコンポーネントが含まれています。ここで、文字は char 型、w_char 型、または C++ プログラム内で定義された型のいずれかです。ライブラリは、クラス テンプレート basic_string を提供します。これは、文字列の基本プロパティを定義します。string 型と wstring 型は、ライブラリが提供する定義済みのテンプレートのインスタンス化です。 |
STL | 最も広く使用されているアルゴリズムとデータ構造体にアクセスできる C++ プログラムを提供します。STL ヘッダーは、コンテナ、反復子、アルゴリズムの 3 つの主要な組織概念にグループ化できます。コンテナは、データを組織化する多機能で柔軟な方法を提供するテンプレート クラスです(vector、list、set、および map など)。反復子は、アルゴリズムとコンテナを貼り付ける役割を果たします。STL は、並べ替え、検索、その他のよく使う機能を処理するプログラム可能なアルゴリズムの大規模なセットです。 |
数値 | 半数値演算の実行に使用されるコンポーネントと、複素数型、数値配列、汎用数値アルゴリズム、および ISO C ライブラリから追加された機能用のコンポーネントが含まれています。 |
入力/出力 | 入出力ストリームの前方宣言、定義済み入出力ストリーム オブジェクト、基本入出力ストリーム クラス、ストリーム バッファ処理、ストリーム書式設定と処理子、文字列ストリーム、およびファイル ストリーム用のコンポーネントが含まれています。 |
また、SCL も Standard C LibraryStandard C Library を組み込んでいます。基になるデバイス オペレーティング システム サポートを備えている一部の Standard C Library だけが組み込まれていることに注意してください。
Windows Template Library 8.0
WTL(Windows Template Library)8.0 には、Web 上でサポートされていないサンプルが残っています。Visual Studio 2005 がリリースされるころには、WTL 8.0 のデバイス部分が公開されている可能性があります。現在のデバイス向けの WTL については、Microsoft Download Center を参照してください。
デバッグ
Visual Studio 2005 のネイティブ デバイス デバッガは、高速で信頼性が高い多機能なデバッグの体感性をデバイス開発者に提供します。リモート デバッガにおける eMbedded Visual C++ 以来の最も注目に値する改良点は、速度と信頼性です。ステッピングや式の評価のようなシナリオにおける応答が大幅に強化されました。主なデバッガ機能は、次のとおりです。
- ステッピングと「次のステートメントの設定」コマンドを通してプログラム フローを制御します。
- Windows の例外を処理します。
- ブレークポイントを設定し、ブレークポイントに条件を適用します(データ ブレークポイントはサポートされていないことに注意してください)。
- **[ウォッチ、自動変数、ローカル]**ウィンドウの式を通してアプリケーションの状態を表示します。STL の視覚化のサポートも含まれています。
- レジスタ ウィンドウと混合表示ウィンドウを通して、低レベルのアセンブリ表現を表示します。
- 実行中のプロセスにアタッチしてデバッグし、完了時にデタッチします。
- デバイス上で JIT(Just-In-Time)デバッグを可能にします。
- Watson Kdump を事後検証デバッグします。
Visual Studio 2005 のネイティブ デバイス アプリケーションをデバッグする方法は複数あります。その多くは、「方法」セクションで概要を説明しています。
自分がビルドしたのではない .dll ファイルまたは .exe ファイルをデバッグする(つまり、使用できるプロジェクトがない)場合は、シンボル検索パスにデバッグするコンポーネントの .pdb ファイルの場所を含めるように設定することをお勧めします(.pdb ファイルを使用できる場合)。
シンボル検索パスを設定する
- Visual Studio 2005 で、**[ツール]をクリックし、[オプション]**をクリックします。
- **[オプション]ダイアログ ボックスで、[デバッグ]を展開し、[シンボル]**を選択します。
- .pdb ファイルが配置されているフォルダを入力します。
(クリックすると大きな画像を表示します)
F5
最もよく使用されるデバッグ シナリオは F5 です。つまり、デバッガからアプリケーションを起動します。Visual Studio 2005 では、デバイス上のネイティブ アプリケーションのデバッグは、ローカル デスクトップ コンピュータ アプリケーションのデバッグと同様にシームレスに行うことができます。デバッガからアプリケーションを起動するには、F5(アプリケーションの新しいインスタンスを起動)、F10(ステップ オーバー)、または F11(ステップ イン)を使用できます。アプリケーションのシンボルとソースにアクセスできると、次のデバッグ情報を取得できます。
- ブレークポイント
- ウォッチ
- 自動変数
- ローカル
- イミディエイト
- 呼び出し履歴
- スレッド
- モジュール
- プロセス
- メモリ
- 混合モード
- レジスタ
エミュレータ
Visual Studio 2005 には、Microsoft Device Emulator 1.0 が付属します。このエミュレータを使用すると、開発者は、スマート デバイス アプリケーションを配布するターゲット デバイスにアクセスできます。図 13 に示すように、Device Emulator は、独自のアドレス空間内でデバイス オペレーティング システム(このドキュメントでは「イメージ」と呼ぶ)を起動し、ARM 命令セットをエミュレートして、実際のデバイスにきわめて近いエミュレーションを提供します。開発者は、エミュレータをほとんどすべての点で実際のデバイスとして扱うことができます。
図 13 Device Emulator(クリックすると大きな画像を表示します)
Device Emulator は ARM バイナリを実行できるので、開発者が Windows Mobile 向けにビルドしたプロジェクトは、再ビルドされる必要なく、エミュレータ上で実行できます。図 14 に示すように、Device Emulator は、指定されたプラットフォームの使用可能なターゲット デバイスのリストに独自のターゲット「デバイス」として表示されます。
図 14 Visual Studio にターゲット「デバイス」として表示される Device Emulator
エミュレータを選択し、アプリケーションを配布すると、エミュレータが起動します(図 14 では、イメージは Pocket PC 2003 Second Edition)。エミュレータが起動すると、ユーザーがエミュレータを実際のデバイスのように扱うことができます。また、Visual Studio 2005 がアプリケーションをダウンロードし、デバッガを起動します。さらに、いつでも複数のエミュレータを起動し、それぞれ別のイメージを起動できます。Visual Studio 2005 を使用すると、アプリケーションを配布およびデバッグする「デバイス」を任意の数だけ使用できます。
Device Emulator は、機能をホストする役割を果たすので、開発者がその機能を使用してデバイス上でさまざまな作業を行うことができます。Device Emulator の機能の詳細については、「方法」セクションを参照してください。
方法
このセクションでは、ネイティブ スマート デバイス開発者が実行する特定のタスクの詳細について説明します。
プロジェクト: 複数のプラットフォームの開発
プロジェクトを作成する前に、ターゲットにするプラットフォームが決定していると理想的です。プロジェクトを作成するときに、アプリケーション ウィザードでプラットフォームを選択できます。ただし、プロジェクトでターゲットにするプラットフォームがわからない場合、またはデスクトップ プラットフォームをターゲットとして追加する場合は、ネイティブ デバイス プロジェクトの作成後にプラットフォームを追加できます。
プロジェクトに別のプラットフォームを追加する
構成マネージャを開きます。
構成マネージャが表示されます。
(クリックすると大きな画像を表示します)
**[新しいソリューション プラットフォーム]の[New]**を選択します。
既存の Windows Mobile 2003 プロジェクトに Windows Mobile 5.0 プラットフォームを追加するには、手動で手順を実行して、Windows Mobile 5.0 構成向けに正しくビルドする必要があることに注意してください。
既存の Windows Mobile 2003 プロジェクトに Windows Mobile 5.0 プラットフォームを追加する
- プロジェクトを右クリックし、**[プロパティ]**を選択します。
- **[プロパティ]ダイアログ ボックスの[プラットフォーム]**から、Windows Mobile 5.0 プラットフォームを選択します。
- [リンカ]を展開し、[コマンド **ライン]**を選択します。
- **[/MACHINE:ARM]**を削除します。
- **[適用]**をクリックします。
- 追加した Windows Mobile 5.0 ごとに手順 2 ~ 6 を繰り返します。
上の手順を実行しない場合は、Windows Mobile 5.0 構成をビルドしたときに、次のリンク エラーを受け取ります。
Fatal error LNK1112: module machine type 'THUMB' conflicts with target machine type 'ARM'
プロジェクト: アプリケーションと共にダウンロードする追加のファイルの指定
プロジェクトと共にダウンロードするファイルを追加するには、そのファイルを次の形式で指定する必要があります。
ファイル名|ソース ディレクトリ|リモート ディレクトリ|登録
ここで、
ファイル名 は、配布するファイルの名前です。
ソース ディレクトリ は、ファイルが格納されているデスクトップ コンピュータ上の絶対パスです。
リモート ディレクトリ は、ファイルの配布先であるデバイス上の場所です。
登録 は、0 または 1 のいずれかです(0 は登録しないことを意味し、1 は登録することを意味します)。
たとえば、c:\foo\bar.dll を追加して、デバイス上の \windows ディレクトリにダウンロードし、配布時に登録するには、**[追加ファイル]**プロパティに次のエントリを入力します。 Bar.dll|c:\foo|\windows|1.
複数の追加ファイルを配布する
- そのプロパティの省略符ボタンをクリックします。
(クリックすると大きな画像を表示します)
上の形式を使用して、1 行ごとに 1 つの新しいファイルを入力します。
**[OK]**をクリックします。
プロジェクト: テスト証明書を使用した Authenticode 署名
個人証明書ストアに署名証明書がない場合、次の手順に従って、個人証明書ストアに証明書をインポートできます。この例では、Visual Studio 2005 に含まれているテスト証明書を使用します。
個人証明書ストアに証明書をインポートする
[Authenticode **署名をする]**構成プロパティを選択します。
**[証明書]エントリ内の[省略符]**ボタンをクリックします。
**[証明書の管理]をクリックし、[インポート]**をクリックします。
<VS インストール ディレクトリ>\SmartDevices\SDK\SDKTools\TestCertificates を参照します。
[フィルタ]ボックスに、*.pfx と入力します。
**メモ **これは重要な手順です。.cer ファイルには秘密鍵がないため、.cer ファイルのインポートでは、秘密鍵を使用して署名できないからです。
**[TestCert_Privileged.pfx]**を選択し、ウィザードを最後まで実行します。ウィザードにはパスワードが必要ありません。
証明書がインポートされたら、証明書マネージャを閉じます。
[証明書の選択] ダイアログ ボックスで、証明書を選択し、**[OK]**をクリックします。
**[デバイスのプロビジョニング]**リストで、証明書ストアを選択します。
手順 8 で、インポートした証明書が**[証明書の選択]**ダイアログ ボックスに表示されない場合は、非コード署名証明書または秘密鍵が付いていない証明書のいずれかをインポートした可能性があります。もう一度手順に従って、手順 5 で確実に .pfx ファイルを選択する必要があります。
プロジェクト: プリコンパイル済みヘッダーの作成と使用
Visual Studio 2005 で作成されたほとんどのネイティブ デバイス アプリケーション プロジェクトは、[プリコンパイル済みヘッダー ファイルを使用する]に設定されます。これは既定で stdafx です。別のプリコンパイル済みヘッダーを使用する場合は、次の手順を実行します。
既定以外のプリコンパイル済みヘッダーを使用する
- プリコンパイルする .cpp ファイルを右クリックし、**[プロパティ]**を選択します。
- [C/C++]を展開し、[プリコンパイル済みヘッダー] を選択します。
- [プリコンパイル済みヘッダーの作成/使用]から、[プリコンパイル済みヘッダーを作成する] を選択します。
- 同じプロパティ ページの**[ファイルを使用して PCH を作成/使用]**に、使用するヘッダー ファイルの名前を入力します。
- **[OK]**をクリックします。
- プロジェクトを右クリックし、**[プロパティ]**を選択します。
- [C/C++]を展開し、[プリコンパイル済みヘッダー] を選択します。
- [プリコンパイル済みヘッダーの作成/使用]で、[プリコンパイル済みヘッダー ファイルを使用する] が選択されていることを確認します。
- 同じプロパティ ページの**[ファイルを使用して PCH を作成/使用]**に、使用するヘッダー ファイルの名前を入力します。
リソース エディタ: Smartphone のメニュー
Smartphone のメニューを作成するには、いくつかの手動の手順が必要です。記事「How to: Create a Soft Key Bar」(英語) は、このトピックに関する優れたリファレンスです。
Visual Studio 2005 を使用すると、Smartphone のメニューを正しく作成できます。
Visual Studio 2005 で Smartphone を作成する
RCDATA セクションがあることを確認します。通常、このセクションは RC2 ファイルに格納されています。
リソース ID の値が 100 以上であることを確認します(Windows Mobile 2003 でのバグを回避するため)。ID は、リソース ヘッダー ファイル内で設定できます(Smartphone の場合は resourcesp.h)。
ボタンのインデックスに NOMENU が設定されていることを確認します。
IDR_MENU RCDATA BEGIN IDR_MENU, 2, I_IMAGENONE, IDM_OK, TBSTATE_ENABLED, TBSTYLE _BUTTON | TBSTYLE_AUTOSIZE, IDS_OK, 0, NOMENU , I_IMAGENONE, IDM_HELP, TBSTATE_ENABLED, TBSTYLE_DROPDOWN | TBSTYLE_AUTOSIZE, IDS_HELP, 0, 0, END
リソース エディタ: ActiveX コントロール開発
Visual Studio 2005 を使用して、デバイス向けの ActiveX コントロールをデザインする場合は、いくつかの追加の手順が必要です。リソース エディタは、デスクトップ コンピュータに登録されているコントロール使用して、デザイン時にコントロールを操作するため、また、開発者はデスクトップ コンピュータにデバイス コントロールを登録できないため、次の手順がデザイン時の代替の作業になります。次の手順では、ActiveX コントロール プロジェクトとホスト プロジェクトがすでにあり、ダイアログで ActiveX コントロールをホストしていると仮定します。
Visual Studio 2005 を使用して ActiveX コントロールをデザインする
リソース エディタで、ホスト プロジェクトのダイアログを開きます。
ツールボックスから、カスタム コントロールをダイアログにドラッグします。
ActiveX コントロールをどのように表示するかに合わせて、ダイアログ上のカスタム コントロールの位置とサイズを決定します。
カスタム コントロールを右クリックし、**[プロパティ]**を選択します。
**[クラス]**プロパティに、ActiveX コントロールの GUID を貼り付けます(必ず中かっこ { } で囲みます)。
ソリューション エクスプローラで、プロジェクト名.RC2 ファイルを右クリックし、**[コードの表示]**を選択します。
**[手動で編集されたリソースをここに追加します]**セクションに、次のダイアログ Init コードを追加します。カスタム コントロールを正しく表示するには、ダイアログ Init セクションが必要です。実際のダイアログ Init セクションの内容は使用されません。
<project name>
を使用するプロジェクトの名前で置き換えてください。IDD_<project name>_DIALOG DLGINIT BEGIN IDC_CUSTOM1, 0x376, 22, 0 0x0000, 0x0000, 0x0800, 0x0000, 0x094d, 0x0000, 0x043d, 0x0000, 0x0013, 0xcdcd, 0xcdcd, 0
ホスト プロジェクトをビルドして実行します(ActiveX コントロールをターゲット デバイスに配布して登録する必要があります)。
デバッグ: プロセスへのアタッチ
アプリケーションがデバイス(またはエミュレータ)上ですでに実行されている場合は、すでに実行されているインスタンスにデバッガをアタッチできます。
Visual Studio 2005 を使用して、デバイスまたはエミュレータ上で実行されているアプリケーションにデバッガをアタッチする
- [ツール]メニューで、[プロセスにアタッチ]をクリックします。[プロセス に **アタッチ]**ダイアログ ボックスが表示されます。
(クリックすると大きな画像を表示します)
[トランスポート]ボックスで、[スマート **デバイス]**を選択します。
**[参照]**をクリックして、接続できるデバイス(エミュレータを含む)のリストを表示します。
ターゲット デバイスまたはエミュレータを選択し、**[接続]**をクリックします。
ネイティブ デバッガとマネージ デバッガのどちらとアタッチするかを明示的に選択するか、[自動]を選択して、IDE に適切なデバッガを決定させることができます。選択するデバッガがわからない場合は、[自動]を選択することをお勧めします。ターゲット デバイスを選択すると、[選択可能な **プロセス]**リストにデバイス上で実行されているプロセスが列挙されます。
(クリックすると大きな画像を表示します)
[型]列は、アプリケーションがマネージとネイティブのどちらであるかを示すことに注意してください。WinCE はネイティブを示し、.NET CF はマネージを示します。すべてのマネージ プロセスの内部では、本来、ネイティブ コードが実行されているので、**[型]列に[WinCE, .NET CF]**が表示されます。
- プロセスを選択し、**[アタッチ]**をクリックします。デバッガがアタッチされ、IDE がデバッグ モードになります。
デスクトップ コンピュータ上でデバッグする .dll または .exe ファイルのコピーが Visual Studio 2005 のシンボル検索パスにある場合は、デバッガがそれを読み込み、コンポーネントへのシンボル/ソースを検索します。デバッガが検索に成功すると、開発者は完全なデバッグ情報を受け取ります(F5 を使用してプロジェクトを起動した場合と同様)。
デスクトップ コンピュータ上で .dll ファイルまたは .exe ファイルを見つけることができず、Windows Mobile 5.0 をターゲットにしている場合、デバッガはデバイスから PDATA を読み込みます。ARM、MIPS、および SH デバイス コンパイラは、PDATA 構造体を使用して、実行時にスタック ウォーキングを支援します。この構造体は、呼び出し履歴アンワインディングを支援します。Windows Mobile 2003 デバイスをデバッグする場合、デバッガはデバイスから PDATA を読み込むことができません。したがって、.dll ファイルまたは .exe ファイルへのシンボルとソースがあっても、デスクトップ コンピュータに .dll または .exe のコピーが実際にない場合は、デバッグ情報を取得できません。
デバッグ: JIT デバッグ
JIT(Just-In-Time)デバッグを使用すると、クラッシュ時にデバッガをアプリケーションにアタッチできます。これにより、クラッシュの原因に関する詳細を取得できます。このためには、JIT デバッガをデバイスにインストールして、クラッシュによって生成される例外をデバッガがキャッチできるようにします。
JIT デバッグを有効にする
- <VS インストール ディレクトリ>\SmartDevices\Debugger\target\wce400\cpu に移動します(たとえば、cpu は、Windows Mobile 2003 の場合 ARMV4、Windows Mobile 5.0 の場合 ARMV4i)。
- eDbgJit.exe をデバイス上の \windows フォルダにコピーします。
- 実行可能ファイルを起動します。
- このファイルを Smartphone で実行する場合は、実行可能ファイルを \windows にコピーしてから、実行可能ファイルへのショートカットを作成し、ショートカットを Smartphone の**[スタート メニュー]**フォルダに配置します。このショートカットを使用すると、実行可能ファイルに簡単にアクセスして実行できます。
- このファイルを Windows Mobile 2003 ベースのデバイスで実行する場合は、デバイスをソフト リセットします。
- エミュレータを使用する場合は、ソフト リセット後に[Saving State]オプションを選択することをお勧めします。
この時点で、JIT デバッガがインストールされているので、アプリケーションがデバイスでクラッシュすると、JIT デバッガが通知し、Visual Studio 2005 をアプリケーションにアタッチします(または、アプリケーションを終了します)。
JIT デバッグを無効にする
- デバイスから eDbgJit.exe を削除します。
デバッグ: 事後検証デバッグ
クラッシュ時にプロセスをデバッグできない場合は、事後検証デバッグを使用すると、デバッガをクラッシュ ダンプ ファイルにアタッチすることで、クラッシュ後にアプリケーションをデバッグできます。
最初の手順は、デバイスからダンプ ファイルを実際に取得することです。Windows Quality Online Services と呼ばれる確立されたプロセスがあります。これを使用すると、アプリケーション クラッシュからダンプ ファイルを取得できます。プライバシー問題のため、プログラムにサインアップする必要があります。詳細については、Windows Quality Online Services を参照してください。
ダンプ ファイルを取得したら、次の手順を実行します。
Visual Studio 2005 でダンプ ファイルをデバッグする
- ファイル名.kdump ファイルを、Visual Studio 2005 がインストールされているコンピュータ上のディレクトリにコピーします。
- Visual Studio 2005 で、**[ファイル]メニューの[開く]をクリックし、[プロジェクト/ソリューション]**をクリックします。
- ダンプ ファイルを開きます。
- F5 キーを押します。
メモ .kdump ファイルをプロジェクト/ソリューションとして開いていることを確認してください。代わりに**[ファイルを** **開く]**アイコンをクリックすると、.kdump ファイルがファイルとして開かれるので、そのファイルをデバッグできません。
(クリックすると大きな画像を表示します)
クラッシュした .dll ファイルまたは .exe ファイルへのシンボルがある場合は、シンボル検索パスにそのファイルを格納しているフォルダを含めるように設定します。
デバッグ: Services
Services.exe のデバッグ用のサポートは、Visual Studio 2005 向けに評価中です。評価が終わるまでは、サポートされていない回避策を使用すると、Visual Studio 2005 ベータ 2 向けの services のデバッグが可能になります。
Visual Studio 2005 ベータ 2 の services のデバッグを有効にする
- システム ドライブ\Documents and Settings\ユーザー名\Local Settings\Application Data\Microsoft\CoreCon\1.0 に移動します。
- エディタ(メモ帳など)で、conman_ds_debugger.xsl を開きます。
**メモ **続行する前に、必ずこの .xsl ファイルのバックアップを別のフォルダに作成してください。
services.exe を検索します。
ファイルからこのエントリを削除します。
保存し、ファイルを閉じます。
Visual Studio を閉じてから、再起動します。
次にプロセスにアタッチするとき、Services.exe がアタッチ可能なプロセスとして表示されます。
(クリックすると大きな画像を表示します)
Visual Studio 2005 ベータ 2 の場合、このシナリオはサポートされていません。これは、Visual Studio 2005 最終リリースの公式サポート向けに評価中です。
エミュレータ: フォルダ共有
デスクトップ コンピュータ(または、ネットワーク)上のフォルダをエミュレータに「SD カード」としてマップできます。この動作は、デスクトップ コンピュータのフォルダ内のファイルを含むデバイスへのカードの挿入をシミュレートします。これは、Device Emulator イメージとデスクトップ コンピュータ間でファイルを移動する便利な方法です。
フォルダを共有する
- エミュレータで、**[ファイル]を選択し、[構成]**を選択します。
- [全般]タブで、共有するフォルダを[共有 **フォルダ]**プロパティに入力します。
- **[OK]**をクリックします。エミュレータから共有フォルダにアクセスできます。
エミュレータ: 状態の保存
エミュレータでイメージが起動されたら、イメージを構成し、その「状態」を保存できます。したがって、エミュレータを完全にオフにできます。次にそのイメージを使用するときは、最後の状態が復元されます。この機能は、アプリケーションに特定の環境が必要な場合、または実行されるその他のアプリケーションがインストールされている場合に、大変便利です。状態の保存機能の別の利点は、次にそのイメージを使用してエミュレータを起動するときの開始時間が大幅に縮小されることです(保存されている状態のイメージがすでに起動されているため)。
保存されている状態を消去し、デバイスをコールド起動する
- エミュレータで、**[ファイル]を選択し、[保存された状態をクリア]**を選択します。
Visual Studio 2005 に付属する Pocket PC 2003 Second Edition エミュレータ イメージと Smartphone 2003 Second Edition エミュレータ イメージは、実際に事前に起動されている保存済み状態のイメージです。このため、イメージは、開発者がエミュレータを起動すると、すぐに「起動」するように見えます。
エミュレータ: ActiveSync
Visual Studio 2005 では、エミュレータへの ActiveSync 接続を確立できます。connection to the emulator. これには、エミュレータをその「クレイドル」内に仮想的に配置します。デスクトップ コンピュータに ActiveSync がインストールされている必要があります(Visual Studio 2005 は ActiveSync 4.0 以降だけをサポートします)。
エミュレータへの ActiveSync 接続を確立する
エミュレータを開始します(たとえば、IDE で**[ツール]メニューの[デバイス** に **接続]**をクリックし、イメージを選択して起動します)。
エミュレータの起動後、Visual Studio 2005 で、[ツール]メニューの[デバイス エミュレータ **マネージャ]**をクリックします。
起動したイメージを選択します(横に緑色の矢印が表示されています)。
**[操作]メニューの[クレードルに接続]**をクリックします。
ActiveSync が DMA 接続を許可するように設定されていることを確認してください。
これで、ActiveSync がデスクトップ コンピュータに接続するエミュレータとして起動します。
エミュレータへの接続が確立したら、ActiveSync ファイル エクスプローラやその他の ActiveSync 機能を使用できます。
**メモ エミュレータへの ActiveSync 接続の確立後、Visual Studio 2005 を使用して配布する場合は、エミュレータをデバイスとして扱う必要があります。たとえば、Pocket PC 2003 Second Edition エミュレータ イメージへの ActiveSync 接続を確立し、それにアプリケーションを配布する場合は、Visual Studio でターゲット デバイスとして[Pocket PC 2003 Device]**を選択する必要があります。
エミュレータ: 画面の回転
エミュレータは、画面の回転機能を備えた実際のデバイスをシミュレートする回転をサポートします(縦から横モード)。また、基になるイメージも回転をサポートする必要があることに注意してください(Pocket PC 2003 Second Edition 以降など)。
エミュレータを回転させる
- **[ファイル]**メニューの[構成]を選択します。
- **[表示]**タブを選択します。
- 方向を 0、80、180、または 270 度に設定します。
**メモ Pocket PC の場合は、[カレンダー]**ボタンが回転機能にマップされるので、このボタンを選択すると、エミュレータ(とその内部の画像)が回転します。
(クリックすると大きな画像を表示します)
エミュレータ: COM ポート マップ
また、エミュレータのシリアル ポートをデスクトップ コンピュータの物理 COM ポートにマップできます。この機能を使用すると、周辺装置を接続し、実際にエミュレータから周辺装置を使用できます。この機能の実用的な例は、シリアル Bluetooth を通して GPS デバイスと通信することです。デスクトップ コンピュータの COM1 ポートにマップすると、エミュレータのシリアル ポート 1 がデスクトップ コンピュータの COM1 ポートにマップされます。これで、エミュレータから GPS ドライバをデバッグできます。
エミュレータの COM ポートをマップする
エミュレータの**[ファイル]メニューの[構成]**を選択します。
**[エミュレータのプロパティ]ダイアログ ボックスで、[周辺機器]**タブを選択します。
**[シリアル ポート 1]で、[COM1]を選択し、[OK]**を選択します。