アーカイブ: Windows Desktop Apps v3.1 の認定要件
ドキュメントのバージョン: 3.1
ドキュメントの日付: 2013 年 6 月 18 日
このドキュメントには、Windows 8.1 デスクトップ アプリ認定プログラムに参加するためにデスクトップ アプリが満たす必要がある技術的要件と資格条件が含まれています。 Windows 7 の場合、このプログラムは Windows ソフトウェア ロゴ プログラムと呼ばれます。
ようこそ！
Windows プラットフォームは、製品とパートナーの広範なエコシステムをサポートします。 製品に Windows ロゴを表示することは、Microsoft と会社の間の品質に対する関係と共有のコミットメントを表します。 お客様は、互換性基準を満たし、Windows プラットフォームで良好なパフォーマンスを発揮するため、製品の Windows ブランドを信頼しています。 Windows アプリ認定を正常に渡すと、アプリを Windows 互換センターで紹介できます。また、Windows ストアにデスクトップ アプリ参照を一覧表示するために必要な手順でもあります。
Windows アプリ認定プログラムは、Windows ブランドを搭載したサード パーティ製アプリが Windows を実行している PC に簡単にインストールでき、信頼性を確保するために役立つプログラムと技術要件で構成されています。 お客様は、購入したシステムの安定性、互換性、信頼性、パフォーマンス、品質を評価します。 Microsoft は、PC 用 Windows プラットフォーム上で実行するように設計されたソフトウェア アプリに対するこれらの要件を満たすために、投資に重点を置いています。 これらの取り組みには、エクスペリエンスの一貫性のための互換性テスト、パフォーマンスの向上、Windows ソフトウェアを実行している PC でのセキュリティの強化が含まれます。 Microsoft 互換性テストは、業界パートナーと共同で設計されており、業界の発展と消費者の需要に応じて継続的に改善されています。
Windows アプリ認定キットは、これらの要件への準拠を検証するために使用され、Windows 7 ソフトウェア ロゴ プログラムの検証に使用される WSLK に置き換えられます。 Windows アプリ認定キットは、Windows 8.1 用 Windows ソフトウェア開発キット (SDK) に含まれるコンポーネントの 1 つです。
アプリの適格性
アプリが Windows 8.1 デスクトップ アプリ認定資格を取得するには、次の条件と、このドキュメントに記載されているすべての技術要件を満たす必要があります。
- スタンドアロン アプリである必要があります
- ローカルの Windows 8.1 コンピューターで実行する必要があります
- 認定された Windows Server アプリのクライアント コンポーネントにすることができます。
- コードと機能が完了している必要があります
- ファイルやレジストリ キーなど、ローカル メカニズムを介して Windows ストア アプリと通信することはできません
- Windows システムのセキュリティや機能を危険にさらしたり、侵害したりしてはなりません
- 一意の名前を持つ必要があり、他のユーザーが商標化してはなりません
デスクトップ アプリがウイルス対策またはスパイウェア対策 (マルウェア対策) 製品カテゴリに提出される場合は、マルウェア対策プラットフォームガイドラインに準拠している必要があります。 WINDOWS 8 マルウェア対策 API ライセンス契約は、提出前に署名され、有効になっている必要があります。 パートナーは、契約に記載されている組織のメンバーであり、良好な立場にある研究者である必要があります。 この機能は、契約に記載されている組織によって Windows 8 で認定されている必要があります。 アプリは、過去 12 か月間に少なくとも 1 回テストされ、検出とクリーニングの認定を受けている必要があります。
1.アプリは互換性があり、回復力があります
アプリがクラッシュしたり、応答を停止したりすると、ユーザーの不満が大きく発生します。 アプリは回復性と安定性が期待され、このような障害を排除することで、ソフトウェアがより予測可能で保守可能で、パフォーマンスが高く、信頼性が高くなります。
- 1.1 アプリは、Windows 互換性モード、AppHelp メッセージ、およびその他の互換性修正プログラムに依存してはなりません
1.2 アプリには互換性マニフェストが必要であり、サポートされているバージョンの Windows に適した GUID を使用する必要があります
1.3 SetProcessDPIAware を呼び出すのではなく、アプリケーションのアセンブリ マニフェストを使用してアプリを DPI 対応にする必要がある
1.4 アプリが VB6 ランタイムに依存しないようにする
1.5 アプリは、HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dllsを使用して Win32 API 呼び出しをインターセプトするために任意の DLL を読み込まてはなりません。
2. アプリは Windows セキュリティのベスト プラクティスに従う必要がある
Windows セキュリティのベスト プラクティスを使用すると、Windows 攻撃表面への露出を回避できます。 攻撃対象のサーフェスは、悪意のある攻撃者がターゲット ソフトウェアの脆弱性を利用してオペレーティング システムを悪用するために使用できるエントリ ポイントです。 最悪のセキュリティの脆弱性の 1 つは、特権の昇格です。
- 2.1 アプリは、実行可能ファイルをセキュリティで保護するために 強力で適切な ACL を使用する必要があります 2.2 アプリは、ディレクトリをセキュリティで保護するために 強力で適切な ACL を使用する必要があります 2.3 アプリは強力で適切な を使用する必要があります レジストリ キーをセキュリティで保護するために ACL 2.4 アプリは、強力で適切な ACL を使用して、オブジェクトを含むディレクトリをセキュリティで保護する必要があります 2.5 アプリは、改ざんに対して脆弱なサービスへの管理者以外のアクセスを減らす必要があります2.6 アプリでは、高速再起動のサービスが 24 時間ごとに 2 回以上再起動されないようにする必要があります
Windows アプリ認定プログラムは、WINDOWS システムを危険にさらさない方法で ACL とサービスが実装されていることを確認することで、Windows 攻撃表面が公開されていないことを確認します。
3. アプリで Windows セキュリティ機能がサポートされる
Windows オペレーティング システムには、システムのセキュリティとプライバシーをサポートする多くの機能があります。 オペレーティング システムの整合性を維持するには、アプリでこれらの機能をサポートする必要があります。 不適切にコンパイルされたアプリは、バッファー オーバーランを引き起こす可能性があります。これにより、サービス拒否が発生したり、悪意のあるコードが実行されたりする可能性があります。
- 3.1 アプリは、厳密な名前のアセンブリへの安全なアクセスを確保するために AllowPartiallyTrustedCallersAttribute (APTCA) を使用してはなりません
3.2 安全な例外処理を保証するには、/SafeSEH フラグを使用してアプリをコンパイルする必要があります
3.3 データの実行を防ぐために、/NXCOMPAT フラグを使用してアプリをコンパイルする必要がある
3.4 アドレス空間レイアウトのランダム化 (ASLR) に /DYNAMICBASE フラグを使用してアプリをコンパイルする必要がある
3.5 アプリで共有 PE セクションの読み取り/書き込みを行わない
4. アプリは、システム再起動マネージャーのメッセージに準拠する必要があります
ユーザーがシャットダウンを開始すると、通常、シャットダウンが成功することを強く望みます。彼らは急いでオフィスを出て、自分のコンピュータをオフにしたいかもしれません。 アプリは、シャットダウンをブロックしないことで、この要望を尊重する必要があります。 ほとんどの場合、シャットダウンは重要ではない可能性があります。アプリは、重大なシャットダウンの可能性に備える必要があります。
- 4.1 アプリで重大なシャットダウンを適切に処理する必要がある
- 重大なシャットダウンでは、WM_QUERYENDSESSIONに FALSE を返すアプリはWM_ENDSESSION送信されて閉じられ、WM_QUERYENDSESSIONに応答してタイムアウトしたアプリは終了します。
- WM\_QUERYENDSESSION と LPARAM = ENDSESSION\_CLOSEAPP(0x1)。
コンソール アプリでは、SetConsoleCtrlHandler を呼び出して、シャットダウン通知を処理する関数を指定できます。 サービス アプリは RegisterServiceCtrlHandlerEx を呼び出して、シャットダウン通知を受信する関数を指定できます。
- WM\_ENDSESSION と LPARAM = ENDSESSION\_CLOSEAPP(0x1)。
少なくとも、アプリはユーザー データを保存して準備し、再起動後に必要な情報を示す必要があります。
注: 中断できない操作のためにシャットダウンをブロックする必要があるアプリは、ユーザーに理由を説明する必要があります。 ShutdownBlockReasonCreate を使用して、ユーザーに理由を説明する文字列を登録します。 操作が完了したら、アプリは ShutdownBlockReasonDestroy を呼び出して、システムをシャットダウンできることを示す必要があります。
5. アプリは、クリーンで元に戻せるインストールをサポートする必要があります
クリーンで元に戻せるインストールにより、ユーザーはシステム上のアプリを正常に管理 (展開および削除) できます。
- 5.1 アプリでクリーンで元に戻せるインストールを適切に実装する必要がある
- DisplayName
- InstallLocation
- 発行者
- UninstallString
- VersionMajor または MajorVersion
- VersionMinor または MinorVersion
- インストールが失敗した場合、アプリはそれをロールバックし、マシンを以前の状態に復元できる必要があります。
- インストール、アンインストール、または更新の最後に、コンピューターの再起動が唯一のオプションになることはありません。 ユーザーには、後で再起動する機会が必要です。
- Windows インベントリ ツールとテレメトリ ツールには、インストールされているアプリに関する完全な情報が必要です。 MSI ベースのインストーラーを使用している場合、MSI によって以下のレジストリ エントリが自動的に作成されます。 MSI インストーラーを使用していない場合、インストール モジュールはインストール時に次のレジストリ エントリを作成する必要があります。
6. アプリは、ファイルとドライバーにデジタル署名する必要があります
Authenticode デジタル署名を使用すると、ユーザーはソフトウェアが本物であることを確認できます。 また、ファイルがウイルスに感染したかどうかなど、改ざんされたかどうかを検出することもできます。 カーネル モードのコード署名の適用は、コード整合性 (CI) と呼ばれる Windows 機能です。これは、ファイルのイメージがメモリに読み込まれるたびにファイルの整合性を検証することで、オペレーティング システムのセキュリティを向上させます。 CI は、悪意のあるコードがシステム バイナリ ファイルを変更したかどうかを検出します。 カーネル モジュールのシグネチャが正しく検証されない場合にも、診断およびシステム監査ログ イベントが生成されます。
- 6.1 すべての実行可能ファイル (.exe、.dll、.ocx、.sys、.cpl、.drv、.scr) は Authenticode 証明書で署名する必要があります
6.2 アプリによってインストールされるすべてのカーネル モード ドライバーには、Windows ハードウェア認定プログラムを通じて取得した Microsoft 署名が必要です。 すべてのファイル システム フィルター ドライバーは、Microsoft によって署名されている必要があります。
6.3 例外および免除
- 権利放棄は、署名されていないサードパーティの再頒布可能パッケージ (ドライバーを除く) に対してのみ考慮されます。 再頒布可能パッケージの署名付きバージョンを要求する通信の証明は、この放棄が付与されるために必要です。
7. オペレーティング システムのバージョン チェックに基づいて、アプリがインストールまたはアプリの起動をブロックしない
技術的な制限がない場合、ユーザーがアプリのインストールや実行を人為的にブロックしないことが重要です。 一般に、Windows Vista 以降のバージョンの Windows 用にアプリが記述されている場合は、オペレーティング システムのバージョンを確認する必要はありません。
- 7.1 アプリがバージョンチェックを実行して等価性を確認してはならない
- Windows XP、Windows Vista、および Windows 7 でも実行される 1 つのパッケージとして提供され、オペレーティング システムのバージョンを確認して、特定のオペレーティング システムにインストールするコンポーネントを決定する必要があるアプリ。
- 承認された API 呼び出しのみを使用してオペレーティング システムの最小バージョンのみをチェックし (実行時ではなくインストール時のみ)、アプリ マニフェストに最小バージョン要件を適切に一覧表示するアプリ。
- 承認された API 呼び出しのみを使用してオペレーティング システムのバージョンを確認するセキュリティ アプリ (ウイルス対策、ファイアウォールなど)、システム ユーティリティ (デフラグ、バックアップ、診断ツールなど)。
- 特定の機能が必要な場合は、その機能自体が使用可能かどうかを確認します。 Windows XP が必要な場合は、Windows XP 以降 (>= 5.1) を確認します。 これにより、検出コードは今後のバージョンの Windows で引き続き動作します。 ドライバー インストーラーとアンインストール モジュールでは、オペレーティング システムのバージョンを確認しないでください。
8. アプリがセーフ モードでサービスまたはドライバーを読み込まない
セーフ モードを使用すると、ユーザーは Windows の診断とトラブルシューティングを行うことができます。 ドライバーとサービスは、ストレージ デバイス ドライバーなどの基本的なシステム操作や、ウイルス対策スキャナーなどの診断と回復の目的で必要な場合を除き、セーフ モードで読み込まれるように設定しないでください。 既定では、Windows がセーフ モードの場合、Windows にプレインストールされたドライバーとサービスのみが起動します。
- 8.1 例外と免除
- セーフ モードで起動する必要があるドライバーとサービスには免除が必要です。 権利放棄要求には、SafeBoot レジストリ キーへの該当するドライバーまたはサービスの書き込みが含まれている必要があります。また、アプリまたはサービスをセーフ モードで実行する必要がある技術的な理由について説明する必要があります。 アプリ インストーラーは、次のレジストリ キーを使用して、このようなすべてのドライバーとサービスを登録する必要があります。
注: これらのドライバーとサービスをテストして、エラーなしでセーフ モードで機能することを確認する必要があります。
9. アプリは、ユーザー アカウント制御のガイドラインに従う必要があります
一部の Windows アプリは管理者アカウントのセキュリティ コンテキストで実行され、アプリは多くの場合、過剰なユーザー権限と Windows 特権を要求します。 リソースへのアクセスを制御することで、ユーザーはシステムを制御し、不要な変更から保護することができます。 望ましくない変更は、コンピューターを制御するルートキットなど、悪意のあるものになる場合や、特権が制限されているユーザーによるアクションの結果である可能性があります。 リソースへのアクセスを制御するための最も重要なルールは、ユーザーが必要なタスクを実行するために必要なアクセス標準ユーザー コンテキストの量を最小限にすることです。 次のユーザー アカウント制御 (UAC) ガイドラインに従うと、アプリで必要なときに必要なアクセス許可がアプリに提供されます。システムは常にセキュリティ リスクにさらされることはありません。 ほとんどのアプリは実行時に管理者特権を必要とせず、標準ユーザーとして正常に実行する必要があります。
- 9.1 アプリには、実行レベルを定義し、実行するためにアプリに必要な特権をオペレーティング システムに通知するマニフェストが必要です
- 実行レベルが highestAvailable に設定されている管理ツールまたはシステム ツール、および/または requireAdministrator
- ユーザー インターフェイス特権分離 (UIPI) をバイパスするには、アクセシビリティまたは UI オートメーション フレームワーク アプリのみが uiAccess フラグを true に設定します。 アプリの使用率を適切に開始するには、このフラグは Authenticode 署名済みであり、ファイル システム内の保護された場所 (Program Files) に存在する必要があります。
- アプリ マニフェストのマーキングは、DLL ではなく EXEs にのみ適用されます。 これは、UAC がプロセスの作成時に DLL を検査しないためです。 UAC ルールは Microsoft サービスには適用されないことにも注目してください。 マニフェストは埋め込みでも外部でもかまいません。
マニフェストを作成するには、.manifest <app_name>.exe名前のファイルを作成し、EXE と同じディレクトリに格納します。 アプリに内部マニフェストがある場合、外部マニフェストは無視されることに注意してください。 例えば：
<requestedExecutionLevel level=""asInvoker |highestAvailable |requireAdministrator"" uiAccess=""true|false""/>
- 管理機能は、管理特権で実行される別のプロセスに移動する必要があります。 スタート メニューのプログラム グループからアクセスできるアプリなど、ユーザー向けのアプリで、昇格を要求するには Authenticode 署名が必要です。
- 昇格された特権 (requireAdministrator または highestAvailable) でメイン プロセスを実行するアプリには免除が必要です。 メイン プロセスは、アプリへのユーザーのエントリ ポイントとして識別されます。 免除は、次のシナリオのために考慮されます:
10. アプリは、既定で正しいフォルダーにインストールする必要があります
ユーザーは、選択した場所にアプリをインストールするオプションを維持しながら、ファイルの既定のインストール場所と一貫性のある安全なエクスペリエンスを持つ必要があります。 また、複数のユーザーが互いのデータと設定を破損または上書きすることなく、同じコンピューターを使用できるように、アプリ データを正しい場所に格納する必要があります。 Windows には、プログラムとソフトウェア コンポーネント、共有アプリ データ、およびユーザー固有のアプリ データを格納するためのファイル システム内の特定の場所が用意されています
- 10.1 アプリは、既定で Program Files フォルダーにインストールする必要があります
- レジストリ実行キー HKLM、またはソフトウェア\Microsoft\Windows\CurrentVersion の HKCU
- レジストリ実行キー HKLM、またはソフトウェア\Wow6432Node\Microsoft\windows\CurrentVersion の HKCU
- Start Menu AllPrograms > STARTUP
- %ProgramFiles%のネイティブ 32 ビットおよび 64 ビット アプリの場合、および x64 で実行されている 32 ビット アプリの %ProgramFiles(x86)%。 ユーザー データまたはアプリ データは、このフォルダーに対して構成されたセキュリティアクセス許可のために、この場所に保存しないでください。
- たとえば、アプリで次の設定を行うべきではありません。
- フォントやドライバーなどのファイルをインストールする正しい方法を使用します。
- アプリがインストールされると、データを格納する適切なユーザーの場所がありません。 インストール後にコンピューター レベルで既定の関連付け動作を変更しようとすると、アプリが失敗します。 代わりに、ユーザー単位レベルで既定値を要求する必要があります。これにより、複数のユーザーが互いの既定値を上書きできなくなります。
- グローバル アセンブリ キャッシュ (GAC) に書き込むアプリでは、アセンブリの依存関係をプライベートに保ち、アセンブリの共有が明示的に必要でない限り、アプリ ディレクトリに格納する必要があります。
11. アプリはマルチユーザー セッションをサポートする必要がある
Windows ユーザーは、競合や中断なしに同時セッションを実行できる必要があります。
- 11.1 アプリがローカルまたはリモートで複数のセッションで実行されている場合、アプリの通常の機能が悪影響を受けないようにする必要がある
11.2 ユーザー間でアプリの設定とデータ ファイルを保持してはならない
11.3 ユーザーのプライバシーと設定をユーザーのセッションに分離する必要がある
11.4 アプリのインスタンスを互いに分離する必要がある
- これは、あるインスタンスのユーザー データがアプリの別のインスタンスに表示されないことを意味します。 アクティブでないユーザー セッションのサウンドは、アクティブなユーザー セッションでは聞こえないはずです。 複数のアプリ インスタンスが共有リソースを使用する場合、アプリは競合がないことを確認する必要があります。
- UAC の要件を参照してください。
12. アプリは、Windows の x64 バージョンをサポートする必要があります
64 ビット ハードウェアがより一般的になると、ユーザーは、アプリを 64 ビットに移行することで、アプリ開発者が 64 ビット アーキテクチャの利点を活用することを期待しています。または、アプリの 32 ビット バージョンが 64 ビット バージョンの Windows で十分に実行されることを期待しています。
- 12.1 アプリで 64 ビットをネイティブにサポートする必要があります。または、64 ビット バージョンの Windows との互換性を維持するために、少なくとも 32 ビットの Windows ベースのアプリを 64 ビット システムでシームレスに実行する必要があります
12.2 アプリとそのインストーラーに 16 ビット コードを含めたり、16 ビット コンポーネントに依存したりしてはなりません
12.3 アプリのセットアップでは、64 ビット アーキテクチャ用の適切なドライバーとコンポーネントを検出してインストールする必要があります
12.4 シェル プラグインは、64 ビット バージョンの Windows で実行する必要があります
12.5 WoW64 エミュレーターで実行されているアプリは、Wow64 仮想化メカニズムを転覆またはバイパスしようとしないでください
- アプリが WoW64 エミュレーターで実行されているかどうかを検出する必要がある特定のシナリオがある場合は、IsWow64Process を呼び出して実行する必要があります。
結論
これらの要件が進化するにつれて、以下のリビジョン履歴の変更に注意してください。 最適な作業を行うには安定した要件が不可欠であるため、Microsoft は、行う変更が持続可能であることを確認し、アプリの保護と強化を継続することを目指します。
素晴らしいカスタマー エクスペリエンスの提供に取り組んでいただき、ありがとうございます。
リビジョン履歴
| 日付 | バージョン | リビジョンの説明 | ドキュメントへのリンク |
|---|---|---|---|
| 2011 年 12 月 20 日 | 1.0 | プレビューのドキュメントの最初の下書き。 | |
| 2012 年 1 月 26 日 | 1.1 | セクション 2 に更新します。 | 1.1 |
| 2012 年 5 月 31 日 | 1.2 | テスト結果の概要を追加しました | 1.2 |
| 2012 年 6 月 29 日 | 3.0 | Windows 8 の最終ドキュメント | 3.0 |
| 2013 年 6 月 18 日 | 3.1 | Windows 8.1 ドキュメント | 3.1 |
デスクトップ アプリ認定の詳細
| 要件 | 形容 | 詳細 |
|---|---|---|
| 互換性と回復性 | クラッシュ & ハングは、ユーザーにとって大きな中断であり、フラストレーションを引き起こします。 アプリは回復性と安定性が期待されており、このような障害を排除することで、ソフトウェアの予測性、保守性、パフォーマンス、信頼性を確保できます。 互換性を保つだけでなく、適切な GUID を宣言するために、ユーザー向けのアプリ エントリ ポイントをマニフェストする必要があります。 ユーザー向けアプリのエントリ ポイントは、HIGH-DPI 認識のためにマニフェストする必要があり、高 DPI をサポートするために適切な API が呼び出されていること。 |
Windows Vista、Windows 7、Windows 8 オペレーティング システム アプリケーション検証ツールの AppInit DLL アプリ (実行可能) マニフェスト Win32 アプリケーション High-DPI 書き込み |
| Windows セキュリティのベスト プラクティスに準拠する | Windows セキュリティのベスト プラクティスを使用すると、Windows 攻撃表面への露出を回避できます。 攻撃対象のサーフェスは、悪意のある攻撃者がターゲット ソフトウェアの脆弱性を利用してオペレーティング システムを悪用するために使用できるエントリ ポイントです。 最悪のセキュリティの脆弱性の 1 つは、特権の昇格です。 |
Attack Surface Analyzer アクセス制御リストの |
| Windows セキュリティ機能のサポート | Windows オペレーティング システムでは、システムのセキュリティとプライバシーをサポートするための多くの手段が実装されています。 アプリケーションは、OS の整合性を維持するために、これらのメジャーをサポートする必要があります。 不適切にコンパイルされたアプリケーションにより、バッファー オーバーランが発生し、サービス拒否が発生したり、悪意のあるコードが実行されたりする可能性があります。 |
BinScope ツールリファレンス |
| System Restart Manager メッセージに準拠する | ユーザーがシャットダウンを開始すると、ほとんどの場合、シャットダウンが成功することを強く望みます。彼らは急いでオフィスを出て、自分のコンピュータの電源をオフにしたいだけかもしれません。 アプリは、シャットダウンをブロックしないことで、この要望を尊重する必要があります。 ほとんどの場合、シャットダウンは重要ではない可能性があります。アプリは、重大なシャットダウンの可能性に備える必要があります。 | Windows Vista でのアプリケーションシャットダウンの変更の Restart Manager 開発 |
| クリーンリバーシブルインストール | クリーンで元に戻せるインストールにより、ユーザーはシステム上のアプリを正常に管理 (展開および削除) できます。 |
方法: ClickOnce アプリケーション を使用して前提条件をインストールする 64 ビット システムでのアプリケーションのインストール |
| ファイルとドライバーにデジタル署名する | Authenticode デジタル署名を使用すると、ユーザーはソフトウェアが本物であることを確認できます。 また、ファイルがウイルスに感染した場合など、ファイルが改ざんされたかどうかを検出することもできます。 カーネル モードのコード署名の適用は、コード整合性 (CI) と呼ばれる Windows 機能です。これは、ファイルのイメージがメモリに読み込まれるたびにファイルの整合性を検証することで、オペレーティング システムのセキュリティを向上させます。 CI は、悪意のあるコードがシステム バイナリ ファイルを変更したかどうかを検出します。 カーネル モジュールのシグネチャが正しく検証されない場合にも、診断およびシステム監査ログ イベントが生成されます。 | Windows でのカーネル モジュールのデジタル署名の |
| オペレーティング システムのバージョン チェックに基づいてインストールまたはアプリの起動をブロックしない | 技術的な制限がない場合、ユーザーがアプリのインストールや実行を人為的にブロックしないことが重要です。 一般に、アプリが Windows Vista 以降のリリース用に作成された場合、オペレーティング システムのバージョンを確認する理由はありません。 | オペレーティング システムのバージョン管理 の |
| セーフ モードでサービスとドライバーを読み込まない | セーフ モードを使用すると、ユーザーは Windows の診断とトラブルシューティングを行うことができます。 システムの基本的な操作 (ストレージ デバイス ドライバーなど) または診断と回復の目的 (ウイルス対策スキャナーなど) に必要な場合を除き、ドライバーとサービスをセーフ モードで読み込むには設定しないでください。 既定では、セーフ モードは、Windows にプレインストールされていないほとんどのドライバーとサービスを起動しません。 基本的な操作または診断と回復の目的でシステムで必要な場合を除き、これらは無効のままにする必要があります。 | オペレーティング システムがセーフ モードで実行されているかどうかを判断する |
| ユーザー アカウント制御 (UAC) ガイドラインに従う | 一部の Windows アプリは管理者アカウントのセキュリティ コンテキストで実行され、多くは過剰なユーザー権限と Windows 特権を必要とします。 リソースへのアクセスを制御することで、ユーザーは不要な変更に対してシステムを制御できます (望ましくない変更は、マシンを密に引き継ぐルートキットや、従業員が職場のコンピューターに禁止されたソフトウェアをインストールするなど、特権が制限されているユーザーからのアクションなど、悪意のある可能性があります)。 リソースへのアクセスを制御するための最も重要なルールは、ユーザーが必要なタスクを実行するために必要なアクセス標準ユーザー コンテキストの量を最小限にすることです。 UAC ガイドラインに従うと、必要に応じてアプリに必要なアクセス許可が提供され、システムがセキュリティ リスクにさらされ続けることなく実行されます。 | ユーザー アカウント制御 の UAC: アプリケーション更新ガイドライン |
| 既定で正しいフォルダーにインストールする | ユーザーは、選択した場所にアプリをインストールするオプションを維持しながら、ファイルの既定のインストール場所と一貫した安全なエクスペリエンスを持つ必要があります。 また、複数のユーザーが互いのデータと設定を破損または上書きすることなく、同じコンピューターを使用できるように、アプリ データを正しい場所に格納する必要があります。 |
インストール/アンインストール要件の概要 |
| マルチユーザー セッションのサポート | Windows ユーザーは、競合や中断なしに同時セッションを実行できる必要があります。 |
リモート デスクトップ サービス プログラミング ガイドライン |
| x64 バージョンの Windows をサポートする | 64 ビット ハードウェアの普及に伴い、ユーザーは、アプリを 64 ビットに移行することで、アプリ開発者が 64 ビット アーキテクチャの利点を活用することを期待しています。または、32 ビット バージョンのアプリが 64 ビット バージョンの Windows で十分に実行されることを期待しています。 |
アプリケーションの互換性: Windows Vista 64 ビット |