アプリケーション用 "Designed for Windows XP"
"Designed for Microsoft Windows XP" アプリケーション仕様書 には、アプリケーションが "Designed for Microsoft Windows XP" ロゴを取得するための技術的な要件が定義されています。
以下に、"Designed for Windows XP" ソフトウェア ロゴ プログラムの基本的な技術要件を記述します。
目次 :
1.0 Windows の基本事項 : 要件の要約
2.0 インストールと削除 : 要件の要約
3.0 データの設定と管理 : 要件の要約
関連項目 :
推奨事項と将来の要件の補足ガイドライン
ダウンロード : "Designed for Microsoft Windows XP" アプリケーション仕様書
1.0 Windows の基本事項 : 要件の要約
「Windows の基本」要件を満たしているアプリケーションは、Microsoft® Windows® XP 上で正しく動作し、オペレーティング システムの信頼性に悪影響を及ぼすことはないでしょう。
1.1 主要な機能が実行可能で、安定性が保持されること
アプリケーションは、オペレーティング システムやアプリケーションの安定性を低下させることなく、主要機能を実行できなければなりません。
1.2 アプリケーションでインストールされるカーネルモード ドライバは、Windows XP での検証テストに合格していること
正しく記述されていないカーネルモード ドライバが原因で、システム クラッシュが発生することがあります。したがって、たとえば、バックアップ ツール、コピー保護プログラム、CD 書き込みプログラムなど、カーネルモード ドライバを含んでいるアプリケーションについては、テストを十分に行って、このようなリスクを最小限にすることが極めて重要です。
アプリケーションにカーネルモード ドライバがある場合、該当するドライバすべてが Windows XP Driver Verifier Manager ツール (Verifier.exe) による検証テストに合格する必要があります。すなわち、ドライバ検査プログラムの実行によって、ストップ エラー メッセージが表示されたり、システムが不安定になったりしないようにする必要があります。
アプリケーションによって提供されるすべての構成要素がこの要件を満たすようにしなければなりません。
1.3 アプリケーションに含まれているすべてのデバイス ドライバとフィルタ ドライバが Windows HCT テストに合格していること
製品にハードウェア デバイスのドライバまたはフィルタ ドライバが含まれている場合は、これらのドライバが Windows ハードウェア互換性テスト (Hardware Compatibility Test : HCT) 10.0 以降によって提供される関連テストに合格しなければなりません。
特定のカテゴリのドライバについては、マイクロソフトからのデジタル署名のないドライバをアプリケーションがインストールしようとすると、Windows XP がエンドユーザーに警告します。デジタル署名が必要なカテゴリのドライバは、コンポーネントにマイクロソフトのデジタル署名が付加されていなければなりません。
アプリケーションによって提供されるすべての構成要素がこの要件を満たすようにしなければなりません。
1.4 Windows のバージョン チェックを正しく実行すること
アプリケーションは、アプリケーションが定めている最低のバージョン要件をオペレーティング システムが満たしているかどうかを確認する必要があります。また、同じオペレーティング システムの将来のすべてのバージョンにアプリケーションをインストールし、実行できなければなりません。
場合によっては、より新しいバージョンの Windows へのアプリケーションのインストールを許可しないようにすることもできます。その場合、インストールや実行をブロックするときには、対象のアプリケーションがそれ以降の Windows のバージョンで動作するように設計されていないことを示す明確なメッセージを表示しなければなりません。
1.5 ユーザーの簡易切り替え機能およびリモート デスクトップをサポートすること
Windows XP では、ユーザーの簡易切り替え機能によって同じコンピュータを共有する複数のユーザーがそれぞれのプロファイルを持ち、ログオフすることなく現在のワーク スペースを切り替えることができます。ユーザーがユーザーの簡易切り替え機能を使った時に、アプリケーションがクラッシュしたり、データや設定内容を失ったりすることがないようにしなければなりません。
たとえば、最初のユーザーがエディタのアプリケーションを開き、そして次のユーザーが同じエディタのアプリケーションを起動した場合に、アプリケーションの最初のインスタンスが停止しないようにする必要があり、また最初のユーザーの編集内容が失われないようにする必要があります。
データと設定内容の管理に関する要件に適合させることにより、CD ドライブ、プリンタ、モデム、サウンドカードなどのリソースの共有上の問題を除き、ユーザーの簡易切り替え機能で問題が起ることはほとんどありません。
別のユーザーが実行しているアプリケーションの追加インスタンスによって主要機能に問題が発生するおそれがある場合は、障害が発生しないようにアプリケーションを再設計する必要があります。ユーザーの簡易切り替え機能で問題が起らないようにするために各機能をブロックした場合は、ブロックした理由をユーザーに通知しなければなりません。
1.6 新しい表示スタイルをサポートすること
ユーザーが新しい表示スタイルの 1 つを選択したときにアプリケーションが機能しなくなったり、使えなくなったりする場合は、アプリケーションでその機能を使えないようにしなければなりません。全画面グラフィックスのアプリケーションは、通常、この要件を満たす何かを行う必要はありません。Windows の表示スタイルを変更しても、アプリケーションが機能しなくなったり使えなくなったりすることはほとんど考えられないからです。
1.7 タスク間の切り替えをサポートすること
アプリケーションは、Alt+Tab、Ctrl+Alt+Del など、タスク切り替えのためのキーシーケンスに対応していなければなりません。アプリケーションはいかなる方法でもこれらの機能を無効にしてはいけません。
^ 先頭
2.0 インストールと削除 : 要件の要約
「インストールと削除」要件を満たしているアプリケーションは、オペレーティング システムまたはその他のアプリケーションの性能を低下させることなく Windows XP 上にインストールされます。
2.1 Windows ファイル保護機能で保護されているファイルの置き換えは行わないようにすること
Windows ファイル保護機能 (Windows File Protection : 以下、WFPと略します) で保護されているファイルを、アプリケーションで置き換えてしまうことのないようにします。アプリケーションが WFP を呼び出さないようにするには、アプリケーションが作成したものでないファイルをインストールするときに SfcIsFileProtected を呼び出します。Windows Installer サービスは、この操作を自動的に行います。
Windows ファイル保護機能 (WFP) は、Windows XP の機能の 1 つで、重要なシステムファイルの不正な置き換えを防ぎます。WFP は、Windows XP のバックグラウンドで実行され、保護対象ファイルを監視します。そして、保護対象ファイルが変更されたことを検出すると、オリジナルのファイルを復元します。
保護されているファイルには、Windows XP の製品 CD に収録されている次のファイルが含まれます。
- ほとんどの .SYS、.DLL、.EXE、および .OCX ファイル
- Micross.ttf、Tahoma.ttf、Tahomabd.ttf、Dosapp.fon、Fixedsys.fon、Modern.fon、Script.fon、Vgaoem.fon の各フォント
アプリケーションが新しいバージョンのコンポーネントを必要とする場合は、必要なバージョンを含む Microsoft サービスパックを使って、コンポーネントを更新しなければなりません。
2.2 Windows の以前のバージョンからの移行
オペレーティング システムを Windows 98、Windows ME、Windows NT®、または Windows 2000から Windows XP にアップグレードしたとき、アプリケーションは引き続き正常に機能しなければなりません。オペレーティングシステムのアップグレード時にユーザーがアプリケーションをいったん削除し、インストールし直さなければならない状況はできるだけ避けてください。
アプリケーションが Windows のバージョンごとに独自のコード (カーネル モード ドライバ、VxDs、その他) を必要とする場合は、ユーザーが Windows のアップグレード時にその解決方法をダウンロードしたり検索したりできるようにしなければなりません。
- システムを新しいバージョンにアップグレードした後、アプリケーションがクラッシュしたり、データが失われたりしてはいけません。
- その解決方法は無償で入手できなければなりません。
- その解決方法には技術的な操作が必要になってはいけません。その解決方法はエンドユーザーを対象としたもので、エンドユーザーにとって使いやすくなければなりません。たとえば、ユーザーがレジストリ エントリを変更したり、INI ファイルの設定を変更したりする必要があってはなりません。
これらの要件を満たすには、アプリケーションがオペレーティング システムの変化に動的に反応できるようにする必要があるでしょう。多くのアプリケーションは、インストール中に Windows のバージョンを検出し、検出結果に基づいて何をインストールするかを決めます。通常、このことは、インストールされているアプリケーションがオペレーティング システム専用のもので、Windows を新しいバージョンにアップグレードすると適切に機能しなくなることを意味します。
アプリケーションは、サポート対象の Windows のバージョン間でのみ移行できる必要があります。たとえば、Windows 98 および Windows ME にインストールされないようになっているアプリケーションは、これらのバージョンから移行する必要はありません。
2.3 製造元固有ファイル以外のファイルを古いバージョンで上書きしないようにすること
アプリケーションのインストールプログラムは、ファイルの最新バージョンがインストールされているかどうかを適切に確認しなければなりません。他社製ファイルまたは他社製アプリケーションによって共有されているファイルが、アプリケーションをインストールすることによって古いバージョンに置き換えられることがないようにします。
バージョンの更新が実際に必要でない限り、コンポーネントの更新をユーザーに指示してはいけません。正しいファイルバージョン情報には、古いバージョンのファイルによって新しいファイルが上書きされないようにするという要件を満たしやすくなるなど、いくつかの利点があります。したがって、配布するすべての実行可能イメージに有効なファイルバージョン情報を含まなければなりません。実行可能ファイル (EXE、DLL、OCX、CPL、その他) のプロパティを表示または取得するときは、プロパティの中に正確な Product Name、Company Name、File Version が含まれていなければなりません。
2.4 不適切な再起動を行わないようにすること
Windows XP では、インストール時にシステムの再起動 (リブート) が必要になることはほとんどありません。リブートはユーザーにとってありがたいものではなく、アプリケーションの導入を困難にする可能性があります。アプリケーションのインストール時やインストール後に、不必要なリブートを行わないようにしなければなりません。
リブートが必要な状況:
- Windows のサービス パックまたは再配布可能な認証システムファイルをインストールするときに、リブートが必要になる可能性があります。
- GINA (Graphical Identification and Authentication) ダイナミック リンク ライブラリ のインストールではリブートが必要です。GINA は、Winlogon でロードされる置き換え可能な DLL コンポーネントです。GINA はインタラクティブ ログオン モデルの認証ポリシーを実装し、またユーザーの識別と認証のためのすべての対話を行うことが期待されます。たとえば、置き換え GINA DLL により、ユーザー名とパスワードを使った Windows XP の標準の認証の代わりに、スマートカード、レチナルスキャン、その他の認証機構を実装できます。
リブートの必要がない状況:
- DLL の登録。
- サービス コンポーネントのアップグレード。サービスの更新によってそのサービスが停止する場合は、そのことをユーザーに警告しなければなりません。
- アプリケーションが使用中の既存ファイルを置き換える場合。実行中のアプリケーションの中に、更新しようとしているリソース ファイルをロードしているアプリケーションがある場合は、そのアプリケーションに関する情報をユーザーに通知し、ユーザーがそのアプリケーション (リソース ファイル) を終了できるようにしなければなりません。その結果、システムをリブートすることなく、ファイルを置き換えることができます。
また、多くの場合、この状況を避けるために、コンポーネントはサイド バイ サイドでインストールするか、delay until reboot オプションを指定して MoveFileEx を使用する必要があります。
リブートの必要がある場合、リブート要求のメッセージをユーザーに出力し、ユーザーがすぐに再起動するか、または後で行うか選べるように選択肢を用意しなければなりません。
2.5 デフォルトで Program Files フォルダにインストールすること
デフォルトでは、アプリケーションはカレント ユーザーのプログラム ファイルが保存されているサブディレクトリに正しくインストールされなければなりません。
- Windows Installer を使用する場合、このフォルダは Windows Installer ベースのパッケージの ProgramFilesFolder プロパティによって表されます。(ProgramFilesFolder プロパティは、Program Files フォルダへのパスを示す変数です。Windows Installer はすべての Windows プラットフォーム上でこの変数を適切に設定します) 。
- Windows Installer を使わない場合は、SHGetFolderPath の API を使って、CSIDL_PROGRAM_FILES の値で表される文字列を取り出す方法を推奨します。英語版のシステムでは、フォルダは通常 "C:\Program Files" となっています。しかし、このパスは世界共通でないため、英語版システム向けのアプリケーションでも、ハードコーディングしないでください。
以前にインストールしたアプリケーションをアップグレードする場合は、以前のバージョンがインストールされていたディレクトリをデフォルトにすることができます。アプリケーションがインストールを必要としない (ファイルをシステムにインストールしなくても実行できる) 場合は、この要件は適用されません。
2.6 サイド バイ サイド以外の共有ファイルは決められた場所にインストールすること
Windows ベースのアプリケーション同士は、コード、アプリケーション、レジストリにおけるコンポーネントの状態、ファイルシステム上のアプリケーション固有データ、グローバル ネーム スペースを公開する Windows API を共有することができます。共有することで、限られたハードウェア リソースを効率よく利用できるほか、品質管理部門のテストを必要とする箇所を減らすことができます。
しかし、共有を行うことに伴うコストもあります。共有によってアプリケーション同士の相互依存性が高くなり、不安定な要素が増えることになります。極端な場合には、以前は動いていたアプリケーションが、不可解にも不正な動作をするようになったり、動かなくなったりすることもあります。一般に、アプリケーションはある共有コンポーネントの特定のバージョンや実装に依存します。別のアプリケーションをインストールしたことで共有コンポーネントがアップグレード (またはダウングレード) されると、いままでのアプリケーションが使えなくなることがあります。Windows XP、Windows 2000、Windows 98 Second Edition、および Windows ME では、アプリケーションの不安定さを最小限に抑えるために、サイド バイ サイドの共有が使用できるようになっています。サイド バイ サイドの共有では、同一の Win32® コンポーネントの複数のバージョンを、メモリ上で同時に実行させることができます。
つまり、アプリケーションは、別のアプリケーションが同一コンポーネントの別のバージョンを必要としている場合にも、このアプリケーション用に設計され、このアプリケーションでのテストが済んでいる特定のコンポーネントを使用することができます。そのため開発者は、システムの別のアプリケーションに依存せずに、自分のアプリケーションに、開発者自身が選んだバージョンのコンポーネントを使用することができ、より信頼性の高いアプリケーションを作成することができます。
サイド バイ サイド共有ではないコンポーネントを置くのにふさわしい場所は、これらのコンポーネントを複数のソフトウェア製造元が使用するのか、1 社の製造元だけが使用するのかによって変わってきます :
- ソフトウェア製造元 1 社の専用の共有コンポーネントは、共有ファイルのディレクトリ、または Program Files フォルダの下のパブリッシャ (ソフトウェアの発行元) のディレクトリのどちらかにインストールします。これらのファイルは、System ディレクトリに保存してはいけません。
- 新しいコントロール パネル アプレットは、かならず Windows XP のアプリケーション ディレクトリにインストールします。
- サービスとデバイス ドライバは、System ディレクトリに置かれなければなりません。
- 複数のソフトウェア製造元によって共有される、サイド バイ サイドでない OCX と DLL は、System ディレクトリに置き、これらのアプリケーションの前バージョンとの互換性が確保できるようにします。
2.7 [プログラムの追加と削除] を正しくサポートすること
アプリケーションは、製品の名前、アプリケーションのアンインストーラの場所などを提供し、コントロールパネルの [プログラムの追加と削除] が必要なアプリケーションの情報を入手できるようにしなければなりません。インストール時にこの情報をレジストリに直接書き込むか、Windows Installer サービスをベースにしたインストール システムを使用する場合は、Windows Installer ベースのパッケージのプロパティを使用してこれらの値を設定することができます。
この要件は、インストールを行わないアプリケーション (コンポーネントをインストールしたり、レジストリにデータを書き込んだり、システムを変更したり、ユーザーが作成したファイル以外のファイルをシステム上に残したりすることなく実行できるアプリケーション) には適用されません。
アプリケーションのアンインストーラは、正しく、完全にアプリケーションを削除できなければなりません。
2.8 "All Users" のインストールをサポートすること
アプリケーションは、1 台のマシン上で複数のユーザーによって使われることがよくあります。インストーラはデフォルトで "all users" を選択するか、または "all users" のインストールをオプションで用意しなければなりません。たとえば、インストーラのデフォルト設定では、カレント ユーザー用だけのアプリケーションをインストールするオプションが選択される場合も、アプリケーションとしてはすべてのユーザーに対応してインストールするオプションも用意しておく必要があります。
権限のないユーザーがアプリケーションのインストールを試みる場合があります。制限ユーザーがアプリケーションのインストールまたは "all users" 向けインストールをできないようにする場合は、インストールの機能を適切に制限しなければなりません。
2.9 CD と DVD の自動再生をサポートすること
アプリケーションが CD、DVD など、自動再生機能をサポートするリムーバブル メディアで配布される場合は、初めてメディアが挿入されたときにアプリケーションが自動再生を使ってアプリケーションを実行するか、ユーザーにインストールを指示するメッセージを表示しなければなりません。アプリケーションが複数のディスクで配布される場合は、2 枚目以降のディスクが挿入されたとき、自動再生機能を使うか、ユーザーがキーを押すなどの操作をしなくてもインストールが続行されるようにしなければなりません。
CD または DVD からインストールを始めるときには、ユーザーが [スタート] メニューの [ファイル名を指定して実行] を使わないですむようにしなければなりません。
アプリケーションを正常にインストールした後は、CD または DVD をドライブにもう一度挿入しても、インストールが自動的に開始しないようにしなければなりません。インストールしたアプリケーションの更新または変更を希望するかどうかをユーザーに確認するのはかまいません。
^ 先頭
3.0 データの設定と管理 : 要件の要約
Microsoft® Windows XP は、ユーザー データ、ユーザー設定、およびコンピュータ設定の状態を分離させるための、基礎的なインフラストラクチャを備えています。アプリケーションでこのインフラストラクチャを正しく使用すると、次のような利点を得ることができます :
- 制限ユーザー (管理者以外) でアプリケーションを実行した時は、停止することがなく、家族や友人が 1 台のコンピュータを安全に、そして簡単に共有できます。
- 管理者の権限を与えると、コンピュータにアクセスして何でも変更できるようになりますが、両親はこの権限を子供たちに与えずに、コンピュータを使わせることができます。
- ユーザーは、アプリケーションやオペレーティング システムのファイルをバックアップすることなく、各自のドキュメントや設定を簡単にバックアップできます。
- 複数のユーザーが 1 台のコンピュータを共有できます。その際に各自で環境設定や設定を行うことができます。
- アプリケーションが、ユーザーの簡易切り替え機能が正常かつ効率的に動作することを、妨げることはほとんどありません。
3.1 ユーザーが作成したデータの保存先は、デフォルトで [マイ ドキュメント] に設定すること
ユーザーが作成したファイルは、ユーザーの [マイ ドキュメント] フォルダ (またはその下位のフォルダ) に保存されなければなりません。イメージファイルの場合は、[マイ ドキュメント] の代わりに [マイ ピクチャ] を使うことをお勧めします。同様に、オーディオ ファイルの場合は [マイ ミュージック] を使用します。
ユーザーがアプリケーションを初めて実行し、アプリケーションの [ファイルを開く] ダイアログ ボックスと [保存] ダイアログ ボックスを最初に呼び出すときのデフォルトのフォルダは、そのユーザーの [マイ ドキュメント] フォルダ (またはその下位フォルダ) でなければなりません。その後でこれらのダイアログ ボックスを呼び出したときには、直前に使用されたパスをデフォルトのパスとすることをお勧めします。ユーザー設定、アプリケーションの状態、一時ファイルなどのアプリケーション データは、[マイ ドキュメント] に保存してはいけません。
データの既定の保存場所として [マイ ドキュメント] フォルダを使用する利点は、以下のとおりです :
- すべてのユーザー (アカウントが制限されているユーザーも含む) がこの保存場所にアクセスして書き込みを行うことができます。
- ユーザーは、すべてのデータの整理や保存のために、決まった唯一の場所を持つことができます。
- 共通の [ファイルを開く] ダイアログ ボックスを使用するすべてのアプリケーションは、簡単に [マイ ドキュメント] フォルダにアクセスできるため、データを共有しやすくなります。
- [マイ ドキュメント] は仮想的な場所を示すので、管理者はその実際の場所をネットワーク上で透過的にリダイレクトすることができます。
- [マイ ドキュメント] は [スタート] メニューから選択できます。
3.2 アプリケーション データを正しく分類し、保存すること
アプリケーション データの分類と保存をこの要件のガイドラインに従って行うと、次のようなメリットがあります :
- 家族の複数メンバーが 1 台のマシンを共有して、ユーザーの簡易切り替え機能を使うことができるようになります。
- ローミング (オフライン ストレージ) などビジネス関連の操作を行うこともでき、オペレーティング システムとそのアプリケーションをセキュリティで保護することができます。
- ユーザー データがユーザーごとに一定した場所に保存され、アプリケーション データがユーザーごとに分けられます。
- これは、アプリケーションをリモート コンピュータから使えるようにするための主要な要因の 1 つです
3.3 アクセスが拒否されたときは適切に対処すること
Windows XP のデフォルトでは、制限のあるユーザー アカウント (Home Edition の制限ユーザーなど) は HKLM や Windows ディレクトリなどの、マシン固有の場所に書き込むことができません。前述したように、正しくデータを分類して保存するアプリケーションのみが、アクセス拒否エラーを避け、セキュリティが確保された環境で正常に実行できます。
しかし、正しくデータを分類し、保存しているアプリケーションでもアクセス拒否エラーが発生することがありえます。
3.4 制限ユーザーとしての実行をサポートすること
アプリケーションは、システムや他のファイルおよび設定内容の変更を行える無制限のアクセス (管理者権限など) を、どのユーザーも持つよう要求することはできません。つまり、アプリケーションは、セキュリティが確保された Windows 環境でも正しく機能しなければなりません。このセクションですでに説明した要件を満たすことにより、アプリケーションはこの要件も満たすようになります。
インストールを行わない (コンポーネントをインストールすることなく実行される) アプリケーションでも、制限ユーザーによる使用をサポートしなければなりません。
セキュリティが確保された Windows 環境とは、制限ユーザー (管理者ではないユーザー) にデフォルトで提供されるクリーン インストールされたNTFSシステムのことを意味します。この環境では、ユーザーはローカル マシンの以下の場所にのみ書き込みができます：
- レジストリの各ユーザーの部分 (HKEY_CURRENT_USER)
- 自身のユーザー プロファイル ディレクトリ (CSIDL_PROFILE)
- 共有ドキュメントの場所 (CSIDL_COMMON_DOCUMENTS)
- ユーザーがシステム ドライブのルートから作成したフォルダ
しかし、これらのフォルダを既定で使用するアプリケーションは、この項で示したほかの要件に準拠していません。
ユーザーは上記の場所のサブ キーやサブ ディレクトリにも書き込むことができます。たとえば、CSIDL_PERSONAL (マイ ドキュメント) は CSIDL_PROFILE のサブ ディレクトリであるため、そこに書き込むことができます。システムのその他の部分に対しては、ユーザーは読み取り専用アクセス権を持ちます。
アプリケーションの重要な機能が特権を持たないユーザーによって正常に実行できるとき、重要でない機能は動作しなくさせることができます。重要でない機能は、完全インストール以外の既定のインストール方法 (たとえば、最小インストールまたは標準インストール) によってインストールされてはならず、またプログラムが動作する上で重要であってはいけません。そのような重要でない機能の例としては、過去のバージョンのファイル形式をサポートするのに必要なコンポーネントなどがあります。
制限ユーザーは、ディスクのデフラグ、バックアップと復元、システム時刻の変更など、いくつかのシステム管理機能を実行できません。あるアプリケーションの主要機能の大部分がシステム管理の場合でも、制限ユーザーのアカウントからそのアプリケーションを起動できるようにし、機能を利用できない理由をユーザーに知らせなければなりません。
^ 先頭
最終更新日: 2002 年 4 月 4 日
