4

Windows Vista 以降、Microsoft は互換性シムのクラスを追加しました。これにより、アプリケーションが管理ファイルとレジストリへのアクセス権を持っていることを前提として、引き続き機能することができます。

つまり、Windows XPで失敗したアプリケーションは、 Windows Vistaで実行されます。

これらの OS 提供のバグ修正は、アプリケーション マニフェストにセクションを追加し、アプリケーションを実行する必要があることを宣言することで無効にすることができasInvokerます。

<!-- Disable Windows Vista standard user compatability heuristics -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
   <security>
      <requestedPrivileges>
         <requestedExecutionLevel level="asInvoker"/>
      </requestedPrivileges>
   </security>
</trustInfo>

理想的には、開発者はアプリケーションをテストして、(不必要に) 管理者特権を必要としないことを確認します。これをテストするには、asInvokerとしてマニフェストする必要があります。

しかし、結局のところ、 asInvoker としてマニフェストされた顧客にアプリケーションをリリースするつもりはありません。何かを見逃したとしても、ユーザーに影響を与えたくありません。Microsoft のオペレーティング システムに間違いを修正してもらいたいです。このソリューションの問題は次のとおりです。

  • リリース前にマニフェストを変更する必要があります
  • Windows Vista で動作するだけなので、見逃したことについては決して知りません。

同様の難問が、Windows 7 のsupportedOSのマニファイスト全体で発生します。設計およびテストされた Windows のバージョンを示すマニフェストをアプリケーションに追加できます。

<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 
   <application> 
      <!--The ID below indicates application support for Windows Vista -->
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> 
      <!--The ID below indicates application support for Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
   </application> 
</compatibility>

サポートされている OS 項目の場合、オペレーティング システムは、どの OS 向けに設計されているかを事前に認識しています。これにより、Windows 7 をサポートしていない場合、アプリケーションは Windows Vista のコンテキストに配置されます。

代替テキスト
(ソース: msdn.com )

このアクションは、一部の互換モードでアプリケーションを実行するのと似ています。たとえば、次のようになります。

  • Windows Server 2008 (サービス パック 1)
  • Windows Vista (サービス パック 2)
  • Windows Vista (サービス パック 1)
  • Windows ビスタ
  • Windows Server 2003 (サービス パック 1)
  • Windows XP (サービス パック 2)
  • ウィンドウズ2000
  • Windows NT 4.0 (サービス パック 5)
  • ウィンドウズ 98 / ウィンドウズ ミー
  • Windows95

ここで、互換性シムの schmorgasboard が適用され、Windows は文書化されていない古い動作をエミュレートして、文書化されていない動作に依存しているときにアプリがクラッシュするのを防ぎます。

Windows 7 がWindows Vistaコンテキストで実行されるアプリケーションに提供する互換性シムの例:

  • RPC は、OS スレッド プールではなく、古いプライベート スレッド プールを使用します。
  • プライマリ ビデオ デスクトップ ディスプレイ バッファをロックできます。
  • クリッピング ウィンドウを指定せずに、プライマリ デスクトップ ビデオ バッファにブリットできます。
  • GetOverlappedResult 競合状態に対して脆弱になります (それに依存している場合)
  • Program Compatibilty Assistant (PCA) 緩和策を引き続き取得します。

また、 Windows 7でアプリケーションを適切にテストするには、 supportsOSマニフェスト エントリを追加する必要があります。しかし、繰り返しになりますが、これらのシム (PCA など) の利点を失いたくないので、そのフラグを付けてアプリケーションを出荷するつもりはありません。また、アプリに問題があり、それがVistaコンテキストで実行されていたために修正された場合: アプリは機能しているだけなので、顧客からそれについて知ることはありません。

考え？ガイダンス？ベストプラクティス？

4

3 に答える 3

2

asInvoker としてマニフェストされた顧客にアプリケーションをリリースするつもりはありません。何かを見逃したとしても、ユーザーに影響を与えたくありません。

これは悪いアプローチだと思います。私のアドバイスは、最初から正しくマニフェストを作成し、デプロイしたものをテストすることです。

Microsoft は、すべてのユーザーの互換性のために後ろ向きになるつもりはありません。彼らは、最大のベンダーが犯す最も一般的で影響の大きい間違いをターゲットにしようとしています。小さな問題を見逃すと、将来シムを提供する可能性は低くなります。

Microsoft が互換性シムを追加するたびに、私たちは皆、代償を払います。他の誰かのバグとの互換性を達成するために脳死の方法でいくつかのケースを処理しなければならなかったために、本来の方法で動作しない API があります。これは、長くて苦痛なデバッグ セッションを意味し、より長い (または完全ではない) ドキュメントを処理することを意味し、OS の非効率性が誰にとってもほとんどないことを意味します。これはまた、Windows 開発者が OS を改善する代わりに、他の人の間違いを修正することに時間を浪費していることを意味します。

これらの互換性の変更は、適切に対応した開発者に不利益をもたらす大きな打撃となる場合があります。多くのアプリケーションは高 DPI を正しく処理しません。したがって、Vista では、互換性の名目で、正しく処理するアプリケーションはないと想定しています (別の方法で明示的に主張しない限り)。Vista は UI スケーリングを適用します。高 DPI を処理しなかったアプリケーションでは、結果が改善されます (ただし最適ではありません)。high_DPI を処理したアプリケーションでは、結果が低下します。(そして、優れたアプリを使用していた顧客は、Vista にアップグレードして Microsoft のせいにすると、アプリが悪化するのを目の当たりにします。) 税金を払わなかった開発者は Microsoft から支援を受け、残りの私たち (Microsoft を含む) は罰せられます。これを回避する唯一の方法は、全員が税金を支払うことです。

一般に、Microsoft は、これらの互換性シムをより対象を絞ったものにすることに長けています (ただし、Vista はかなり率直でした)。とはいえ、それぞれに多少の費用がかかります。

開発中はベスト プラクティスに従います。展開する予定のものをテストします。大きく壊れた場合は、Microsoftが修正してくれるかもしれません。そうしないと、更新をリリースしなければならない場合があります。一部の開発者が正しいことをしなかったために全員がペナルティを受けるよりはましです。

于 2009-11-12T17:02:57.497 に答える
1

AsInvokerは、アプリケーションを配布する正しい方法です!!!

つまり、ユーザーの資格情報を使用して実行されます。「卑劣なことをする」または「管理者権限を使用する」とは書かれていません。

そのマニフェストがないと、アプリケーションを「UACを認識していないので、UACを備えたシステムで機能させるために必要なハックを教えてください」とブランド化しています。

ただし、アプリケーションが管理者のみの処理を実行しようとしない場合（標準ユーザーとしてログインし、アプリを実行して失敗を監視するだけで簡単にテストできます）、AsInvokerは完全に正しいです。

これはあなたがそれを理解するのに役立つかもしれません：Vistaのユーザーアカウント制御のプログラマーの調査

于 2009-12-01T21:14:07.050 に答える
0

私が理解しているように、ディストリビューションにマニフェスト ファイルを提供する代わりに、次のコマンドをアプリケーションのリソース ファイルに追加することで、EXE ファイルに直接リンクすることもできます: [1,2]。

CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "YourApp.exe.manifest"

EXE ファイルを含むディレクトリ内の別のマニフェスト ファイルは、このリンクされたマニフェストをオーバーライドできますが、それは顧客次第です。あなたはそれを供給しません。

現在、Microsoft の「RC」リソース コンパイラは、#ifdef [3] などのプリプロセッサ ディレクティブを受け入れます。つまり、TESTING と DEPLOYMENT などの異なるプリプロセッサ定義を定義する 2 つの個別のビルド ターゲットを Visual Studio に指示できます。

次に、 #ifdef ディレクティブを使用して、テスト用と展開用のビルド ターゲットに 2 つの異なるマニフェスト ファイルを使用するだけで、必要に応じてマニフェスト ファイルを編集できます。これで問題は解決しますか？

[1] http://msdn.microsoft.com/en-us/library/ms997646.aspx
[2] http://doc.ddart.net/xmlsdk/htm/sdk_dependencies_5wvi.htm
[3] http://msdn .microsoft.com/en-us/library/aa381033%28VS.85%29.aspx

于 2009-11-11T18:23:16.403 に答える