アーカイブ: Windows Desktop Apps v1.1 の認定要件

ドキュメントのバージョン: 1.1

ドキュメントの日付: 2012 年 1 月 26 日

このドキュメントには、Windows 8 デスクトップ アプリ認定プログラムに参加するためにデスクトップ アプリが満たす必要がある技術的要件と資格要件が含まれています。 Windows 7では、このプログラムはWindowsソフトウェアロゴプログラムとして知られていました。

ようこそ。

Windows プラットフォームは、製品とパートナーの広範なエコシステムをサポートします。 製品にWindowsロゴを表示することは、Microsoft と会社の間の品質に対する関係と共有のコミットメントを表します。 お客様は、互換性基準を満たし、Windowsプラットフォームで良好に動作することを保証するため、製品のWindowsブランドを信頼しています。 アプリ認定Windows正常に合格すると、アプリをWindows互換センターで紹介できます。また、Windows Microsoft Storeにデスクトップ アプリ参照を一覧表示するために必要な手順でもあります。

Windowsアプリ認定プログラムは、Windowsブランドを持つサードパーティ製アプリが、Windowsを実行している PC に簡単にインストールでき、信頼性を確保するために役立つプログラムと技術要件で構成されています。 お客様は、購入したシステムの安定性、互換性、信頼性、パフォーマンス、品質を大切にしています。 Microsoft は、PC 用のWindows プラットフォームで実行するように設計されたソフトウェア アプリに対するこれらの要件を満たすために投資に注力しています。 これらの取り組みには、エクスペリエンスの一貫性に関する互換性テスト、パフォーマンスの向上、Windowsソフトウェアを実行している PC のセキュリティ強化が含まれます。 Microsoft 互換性テストは、業界パートナーと協力して設計されており、業界の発展と消費者の需要に応じて継続的に改善されています。

Windows アプリ認定キットは、これらの要件への準拠を検証するために使用され、Windows 7 ソフトウェア ロゴ プログラムで検証に使用される WSLK に置き換えられます。 Windows アプリ認定キットは、Windows ソフトウェア開発キット (SDK) に含まれるコンポーネントの 1 つです。

アプリの資格

アプリがデスクトップ アプリ認定Windows 8資格を得るには、次の条件と、このドキュメントに記載されているすべての技術要件を満たす必要があります。

  • スタンドアロン アプリである必要があります
  • ローカル Windows 8.1 コンピューターで実行する必要があります
  • 認定された Windows Server アプリのクライアント コンポーネントにすることができます
  • コードと機能が完了している必要があります

1.アプリは互換性があり、回復力があります

アプリがクラッシュしたり、応答が停止したりすると、ユーザーが多くの不満を引き起こします。 アプリは回復性と安定性が期待されており、このような障害を排除することで、ソフトウェアの予測性、保守性、パフォーマンス、信頼性を高めるのに役立ちます。

1.1 アプリは、Windows互換性モード、AppHelp メッセージ、およびその他の互換性修正プログラムに依存してはなりません
1.2 アプリが VB6 ランタイムに依存してはなりません
1.3 アプリは、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 アプリで重大なシャットダウンを適切に処理する必要がある
重大なシャットダウンでは、FALSE をWM_QUERYENDSESSIONに返すアプリはWM_ENDSESSION送信されて閉じられ、WM_QUERYENDSESSIONに応答してタイムアウトしたアプリは終了します。

4.2 再起動の準備として、GUI アプリが直ちに TRUE を返す必要がある
WM\_QUERYENDSESSION with LPARAM = ENDSESSION\_CLOSEAPP(0x1)。 コンソール アプリでは、SetConsoleCtrlHandler を呼び出して、シャットダウン通知を処理する関数を指定できます。 サービス アプリは RegisterServiceCtrlHandlerEx を呼び出して、シャットダウン通知を受け取る関数を指定できます。
4.3 アプリは 30 秒以内に 0 を返し、シャットダウンする必要があります
WM\_ENDSESSION と LPARAM = ENDSESSION\_CLOSEAPP(0x1)。 少なくとも、アプリはユーザー データを保存して準備し、再起動後に必要な情報を示す必要があります。
4.4 Ctrl\_C\_EVENT 通知を受け取るコンソール アプリは、直ちにシャットダウンする必要があります 4.5 ドライバーはシステムシャットダウンイベントを拒否してはなりません
**注: 中断できない操作のためにシャットダウンをブロックする必要があるアプリは、ユーザーに理由を説明する必要があります。** ShutdownBlockReasonCreate を使用して、ユーザーに理由を説明する文字列を登録します。 操作が完了したら、アプリは ShutdownBlockReasonDestroy を呼び出して、システムをシャットダウンできることを示す必要があります。

5. アプリは、クリーンで元に戻せるインストールをサポートする必要があります

クリーンで元に戻せるインストールにより、ユーザーはシステム上のアプリを正常に管理 (展開および削除) できます。

5.1 アプリは、クリーンで元に戻せるインストールを適切に実装する必要があります
インストールが失敗した場合、アプリはそれをロールバックし、マシンを以前の状態に復元できる必要があります。

5.2 アプリがユーザーにコンピュータを直ちに再起動させてはならない
コンピューターの再起動は、インストールまたは更新の最後に唯一のオプションにしないでください。 ユーザーには、後で再起動する機会が必要です。
5.3 アプリが 8.3 短いファイル名 (SFN) に依存してはいけません 5.4 アプリでサイレント インストール/アンインストールをブロックしてはならない 5.5 アプリインストーラーは、検出とアンインストールを成功させるために適切なレジストリ エントリを作成する必要があります
Windowsインベントリ ツールとテレメトリ ツールには、インストールされているアプリに関する完全な情報が必要です。 MSI ベースのインストーラーを使用している場合は、MSI によって以下のレジストリ エントリが自動的に作成されます。 MSI インストーラーを使用していない場合、インストール モジュールはインストール時に次のレジストリ エントリを作成する必要があります。
  • DisplayName
  • InstallLocation
  • Publisher
  • UninstallString
  • VersionMajor または MajorVersion
  • VersionMinor または MinorVersion

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 アプリでバージョンチェックを実行して等価性を確認することはできません
特定の機能が必要な場合は、機能自体が使用可能かどうかを確認します。 XP Windows必要な場合は、Windows XP 以降 (>= 5.1) を確認します。 これにより、検出コードは今後のバージョンのWindowsで引き続き機能します。 ドライバーのインストーラーとアンインストール モジュールでは、オペレーティング システムのバージョンを確認しないでください。

7.2 例外および権利放棄は、以下の条件を満たすアプリに対して考慮されます。
  • Windows XP、Windows Vista、Windows 7 でも実行される 1 つのパッケージとして配信され、オペレーティング システムのバージョンを確認して、特定のオペレーティング システムにインストールするコンポーネントを決定する必要があるアプリ。
  • 承認された API 呼び出しのみを使用してオペレーティング システムの最小バージョン (インストール時のみ、実行時にはチェックしない) のみを確認し、アプリ マニフェストの最小バージョン要件を適切に一覧表示するアプリ。
  • 承認された API 呼び出しのみを使用してオペレーティング システムのバージョンを確認するセキュリティ アプリ (ウイルス対策、ファイアウォールなど)、システム ユーティリティ (デフラグ、バックアップ、診断ツールなど)。

8. アプリがセーフ モードでサービスまたはドライバーを読み込まない

セーフ モードを使用すると、ユーザーはWindowsの診断とトラブルシューティングを行うことができます。 ドライバーとサービスは、ストレージ デバイス ドライバーなどの基本的なシステム操作や、ウイルス対策スキャナーなどの診断と回復の目的で必要な場合を除き、セーフ モードで読み込まれるように設定しないでください。 既定では、Windowsがセーフ モードの場合、Windowsでプレインストールされたドライバーとサービスのみが開始されます。

  • 例外と権利放棄
    セーフ モードで開始する必要があるドライバーとサービスには、権利放棄が必要です。 権利放棄要求には、該当するドライバーまたはサービスごとに SafeBoot レジストリ キーへの書き込みが含まれている必要があり、アプリまたはサービスをセーフ モードで実行する必要がある技術的な理由について説明する必要があります。 アプリ インストーラーは、次のレジストリ キーを使用して、このようなすべてのドライバーとサービスを登録する必要があります。
    - HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal - HKLM/System/CurrentControlSet/Control/SafeBoot/Network

メモ: これらのドライバーとサービスをテストして、エラーなしでセーフ モードで動作することを確認する必要があります。

9. アプリは、ユーザー アカウント制御ガイドラインに従う必要があります

一部のWindows アプリは管理者アカウントのセキュリティ コンテキストで実行され、アプリは多くの場合、過剰なユーザー権限とWindows特権を要求します。 リソースへのアクセスを制御することで、ユーザーはシステムを制御し、望ましくない変更から保護することができます。 望ましくない変更は、コンピューターを制御するルートキットなど、悪意のある場合や、特権が制限されているユーザーが行ったアクションの結果である可能性があります。 リソースへのアクセスを制御するための最も重要なルールは、ユーザーが必要なタスクを実行するために必要なアクセス標準ユーザー コンテキストの最小量を提供することです。 次のユーザー アカウント制御 (UAC) ガイドラインに従うと、アプリで必要なときに必要なアクセス許可がアプリに提供され、システムは常にセキュリティ リスクにさらされることはありません。 ほとんどのアプリは実行時に管理者特権を必要とせず、標準ユーザーとして正常に実行する必要があります。

9.1 アプリには、実行レベルを定義し、実行するためにアプリに必要な特権をオペレーティング システムに通知するマニフェストが必要です
アプリ マニフェストのマーキングは、DLL ではなく EXEs にのみ適用されます。 これは、UAC がプロセスの作成時に DLL を検査しないためです。 また、UAC ルールがWindows サービスに適用されないことにも注目してください。 マニフェストは、埋め込みでも外部でもかまいません。
マニフェストを作成するには、.exe.manifest app_name>という名前<のファイルを作成し、EXE と同じディレクトリに格納します。 アプリに内部マニフェストがある場合、外部マニフェストはすべて無視されることに注意してください。 次に例を示します。
<requestedExecutionLevel=""asInvoker |highestAvailable |requireAdministrator"" uiAccess=""true|false""/>

9.2 アプリのメイン プロセスは、標準ユーザー (asInvoker) として実行する必要があります。
管理機能は、管理特権で実行される別のプロセスに移動する必要があります。 スタート メニューのプログラム グループからアクセスできるアプリなど、ユーザー向けのアプリで、昇格を要求するには Authenticode に署名する必要があります。
例外と権利放棄
昇格された特権 (requireAdministrator または highestAvailable) を使用してメイン プロセスを実行するアプリでは、権利放棄が必要です。 メイン プロセスは、アプリへのユーザーのエントリ ポイントとして識別されます。 免除は、次のシナリオで考慮されます。
  • 実行レベルが highestAvailable に設定されている管理ツールまたはシステム ツール、および/または requireAdministrator
  • ユーザー インターフェイス特権の分離 (UIPI) をバイパスするには、アクセシビリティまたは UI オートメーション フレームワーク アプリのみが uiAccess フラグを true に設定します。 アプリの使用率を適切に開始するには、このフラグは Authenticode に署名されている必要があり、ファイル システム内の保護された場所 (Program Files) に存在する必要があります。

10. アプリは、既定で正しいフォルダーにインストールする必要があります

ユーザーは、ファイルの既定のインストール場所と一貫性のある安全なエクスペリエンスを持つ必要があります。一方で、アプリを選択した場所にインストールするオプションを維持する必要があります。 また、複数のユーザーが互いのデータと設定を破損または上書きすることなく、同じコンピューターを使用できるように、アプリ データを正しい場所に格納する必要があります。 Windowsは、プログラムとソフトウェア コンポーネント、共有アプリ データ、およびユーザー固有のアプリ データを格納するためのファイル システム内の特定の場所を提供します

10.1 アプリは、既定で Program Files フォルダーにインストールする必要があります
%ProgramFiles%のネイティブ 32 ビット アプリと 64 ビット アプリの場合、x64 で実行されている 32 ビット アプリの場合は %ProgramFiles(x86)% です。 このフォルダーに対して構成されているセキュリティアクセス許可のため、ユーザー データまたはアプリ データをこの場所に保存しないでください。

10.2 アプリの起動時に自動的に開始されないようにする必要がある
たとえば、アプリでは次のいずれかを設定しないでください。
  • レジストリ実行キー HKLM、またはソフトウェア\Microsoft\Windows\CurrentVersion の HKCU
  • レジストリ実行キー HKLM、またはソフトウェア\Wow6432Node\Microsoft\windows\CurrentVersion の HKCU
  • スタート メニュー AllPrograms > STARTUP
10.3 コンピューター上のユーザー間で共有する必要があるアプリ データは、ProgramData 10.4 内に格納する必要があります。特定のユーザーに限定され、コンピューターの他のユーザーと共有されないアプリのデータは、Users\\<username>\\AppData 10.5 に格納する必要があります。アプリは、"Windows" ディレクトリやサブディレクトリに直接書き込む必要はありません
フォントやドライバーなどのファイルをインストールするには、正しい方法を使用します。
10.6 アプリは、マシンごとのインストール時ではなく、最初の実行時にユーザー データを書き込む必要があります
アプリがインストールされると、データを格納する適切なユーザーの場所がありません。 インストール後にコンピューター レベルで既定の関連付け動作を変更しようとすると、アプリが失敗します。 代わりに、ユーザー単位レベルで既定値を要求する必要があります。これにより、複数のユーザーが互いの既定値を上書きできなくなります。
10.7 例外および権利放棄
グローバル アセンブリ キャッシュ (GAC) .NET アプリに書き込むアプリでは、アセンブリの依存関係を非公開にし、アセンブリの共有が明示的に必要でない限り、アプリ ディレクトリに格納する必要があります。

11. アプリはマルチユーザー セッションをサポートする必要がある

Windowsユーザーは、競合や中断なしで同時セッションを実行できる必要があります。

11.1 アプリは、ローカルまたはリモートで複数のセッションで実行する場合、アプリの通常の機能が悪影響を受けないようにする必要があります
11.2 アプリの設定とデータ ファイルは、ユーザー間で保持しないでください
11.3 ユーザーのプライバシーと設定をユーザーのセッションに分離する必要がある
11.4 アプリのインスタンスを互いに分離する必要がある
これは、あるインスタンスのユーザー データがアプリの別のインスタンスに表示されないことを意味します。 アクティブでないユーザー セッションのサウンドは、アクティブなユーザー セッションでは聞こえないはずです。 複数のアプリ インスタンスが共有リソースを使用する場合、アプリは競合がないことを確認する必要があります。

11.5 複数のユーザーにインストールされているアプリは、正しいフォルダーとレジストリの場所にデータを格納する必要があります
UAC の要件を参照してください。
11.6 ユーザー アプリは、ローカル アクセスとリモート アクセスの両方に対して複数のユーザー セッション (高速ユーザー 切り替え) で実行できる必要があります 11.7 アプリは、アプリの既存のインスタンスの他のターミナル サービス (TS) セッションを確認する必要があります
**注:** アプリが複数のユーザー セッションまたはリモート アクセスをサポートしていない場合は、この種のセッションから起動したときにこれを明確に示す必要があります。

12.アプリはx64バージョンのWindowsをサポートする必要があります

64 ビット ハードウェアがより一般的になるにつれて、ユーザーはアプリ開発者がアプリを 64 ビットに移行することで 64 ビット アーキテクチャの利点を活用することを期待しています。または、アプリの 32 ビット バージョンは 64 ビット バージョンのWindowsで十分に実行されます。

12.1 アプリは、64 ビット版をネイティブにサポートする必要があります。または、少なくとも 32 ビット Windows ベースのアプリは、64 ビット バージョンのWindowsとの互換性を維持するために、64 ビット システムでシームレスに実行する必要があります。
12.2 アプリとそのインストーラーは、16 ビット コードを含めたり、16 ビット コンポーネントに依存したりしてはなりません
12.3 アプリのセットアップでは、64 ビット アーキテクチャの適切なドライバーとコンポーネントを検出してインストールする必要があります
12.4 シェル プラグインは、64 ビット バージョンのWindowsで実行する必要があります
12.5 WoW64 エミュレーターで実行されているアプリは、Wow64 仮想化メカニズムを転覆またはバイパスしないでください
アプリが WoW64 エミュレーターで実行されているかどうかを検出する必要がある特定のシナリオがある場合は、IsWow64Process を呼び出して実行する必要があります。

まとめ

これらの要件が進化するにつれて、以下のリビジョン履歴の変更に注目します。 最善の作業を行うには安定した要件が不可欠であるため、Microsoft は、行う変更が持続可能であることを保証し、アプリの保護と強化を継続することを目指します。

素晴らしいカスタマー エクスペリエンスの提供に取り組んでいただき、ありがとうございます。

改定履歴

Date バージョン リビジョンの説明 ドキュメントへのリンク
2011 年 12 月 20 日 1.0 プレビュー用のドキュメントの最初の下書き。
2012 年 1 月 26 日 1.1 セクション 2 に更新します。 1.1

デスクトップ アプリ認定の詳細を確認する

要件 説明 詳細
互換性と回復性 クラッシュハング & は、ユーザーにとって大きな中断であり、フラストレーションを引き起こします。 アプリは回復性と安定性が期待されており、このような障害を排除することで、ソフトウェアの予測性、保守性、パフォーマンス、信頼性を高めるのに役立ちます。 Windows Vista、Windows 7、Windows 8 オペレーティング システム
アプリケーション検証ツール
AppInit DLL
Windows セキュリティのベスト プラクティスに従う Windowsセキュリティのベスト プラクティスを使用すると、Windows攻撃対象領域への露出を回避できます。 攻撃対象のサーフェスは、悪意のある攻撃者がターゲット ソフトウェアの脆弱性を利用してオペレーティング システムを悪用するために使用できるエントリ ポイントです。 最悪のセキュリティ脆弱性の 1 つは、特権の昇格です。 Attack Surface Analyzer
アクセス制御リスト
Windows セキュリティ機能のサポート Windowsオペレーティング システムでは、システムのセキュリティとプライバシーをサポートするための多くの手段が実装されています。 アプリケーションは、OS の整合性を維持するために、これらのメジャーをサポートする必要があります。 不適切にコンパイルされたアプリケーションでは、バッファー オーバーランが発生し、サービス拒否が発生したり、悪意のあるコードが実行されたりする可能性があります。 BinScope ツールリファレンス
System Restart Manager メッセージに準拠する ユーザーがシャットダウンを開始すると、ほとんどの場合、シャットダウンが成功することを強く望みます。彼らは急いでオフィスを出て、自分のコンピュータの電源をオフにしたいだけかもしれません。 アプリでは、シャットダウンをブロックしないことで、この要求を尊重する必要があります。 ほとんどの場合、シャットダウンは重要ではない場合があります。重要なシャットダウンの可能性に備えてアプリを準備する必要があります。 Windows Vista でのアプリケーションシャットダウンの変更
Restart Manager Development
クリーンリバーシブルインストール クリーンで元に戻せるインストールにより、ユーザーはシステム上のアプリを正常に管理 (展開および削除) できます。 方法: 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 ビット

関連項目