App-Manifest (ausführbare Datei)

Plattformen

Clients – Windows 8
Server – Windows Server 2012

BESCHREIBUNG

Der in Windows eingeführte Kompatibilitätsabschnitt des App-Manifests (ausführbare Datei) hilft dem Betriebssystem dabei, die Versionen von zu bestimmen Windows für die eine App entwickelt wurde. Darüber hinaus ermöglicht das App-Manifest Windows, das Verhalten zu bieten, das die App basierend auf der Version des Windows der App erwartet.

Der Kompatibilitätsabschnitt des Manifests ermöglicht es Windows, für neu erstellte Software neues Verhalten zu bieten und gleichzeitig die Kompatibilität für vorhandene Software zu gewährleisten. In diesem Abschnitt Windows die Kompatibilität in zukünftigen Versionen von Windows unterstützt. Beispielsweise wird eine App, die die Unterstützung nur für Windows 8 im Kompatibilitätsabschnitt deklarieren, auch in zukünftigen Versionen von Windows 8 verhalten Windows.

Manifestation

Apps ohne Kompatibilitätsabschnitt in ihrem Manifest verfügen standardmäßig über Windows Vista-Verhalten Windows 7 und Windows 8 und zukünftigen Windows Versionen. Beachten Sie, Windows XP und Windows Vista diesen Manifestabschnitt ignorieren und sich nicht darauf auswirken.

Diese Windows-Komponenten bieten abweichendes Verhalten basierend auf dem Kompatibilitätsabschnitt:

RPC-Standardthreadpool (Remote Procedure Call)

  • Windows 8 und Windows 7: Um die Skalierbarkeit zu verbessern und die Threadanzahl zu reduzieren, wurde RPC zum NT-Threadpool (Standardpool) umgeschaltet. Für Windows Vista hat RPC einen privaten Threadpool verwendet:

    • Für Binärdateien, die für Windows 7 und höher von Windows kompiliert wurden, wird der Standardpool verwendet.
    • Wenn I _ RpcMgmtEnableDedicatedThreadPool aufgerufen wird, bevor eine RPC-API aufgerufen wird, wird der private Threadpool verwendet (Vista-Verhalten).
    • Wenn _ I RpcMgmtEnableDedicatedThreadPool nach einem RPC-Aufruf aufgerufen wird, wird der Standardpool verwendet, I RpcMgmtEnableDedicatedThreadPool gibt den Fehler 1764 zurück, und der angeforderte Vorgang wird nicht _ unterstützt.
  • Windows Vista (Standard): Für Binärdateien, die für Windows Vista und frühere Versionen von Windows kompiliert wurden, wird der private Pool verwendet.

DirectDraw-Sperre

  • Windows 8 und Windows 7: Apps, die für Windows 7 und neuere Versionen des Betriebssystems manifestiert sind, können die Sperr-API in DDRAW nicht aufrufen, um den primären Desktopvideopuffer zu sperren. Dies führt zu einem Fehler, und ein NULL-Zeiger für die primäre wird zurückgegeben. Dieses Verhalten wird auch erzwungen, wenn Desktopfenster-Manager Composition nicht aktiviert ist. Apps mit Kompatibilität, die für Windows 7 und höher deklariert sind, dürfen das Rendern des primären Videopuffers nicht sperren.
  • Windows Vista (Standard): Apps können eine Sperre für den primären Videopuffer erhalten, da ältere Apps von diesem Verhalten abhängen. Das Ausführen der App deaktiviert Desktopfenster-Manager.

DirectDraw bit-block transfer (bitblt) to primary without clipping window (DirectDraw bit-block transfer (bitblt) to primary without clipping window

  • Windows 8 und Windows 7: Apps, die für Windows 7 und neuere Versionen von Windows manifestiert sind, können ohne Clippingfenster keine Bitblt zum primären Desktopvideopuffer ausführen. Dies führt zu einem Fehler, und der bitblt-Bereich wird nicht gerendert. Windows erzwingt dieses Verhalten auch dann, wenn Sie die Desktopfenster-Manager nicht aktivieren. Apps mit Kompatibilität, die für Windows 7 und höher deklariert sind, müssen ein Bitblt für ein Clippingfenster ausführen.
  • Windows Vista (Standardeinstellung): Apps müssen in der Lage sein, eine Bitblt für die primäre App ohne Clippingfenster durchzuführen, da ältere Apps von diesem Verhalten abhängen. Wenn Sie diese App ausführen, wird die Desktopfenster-Manager.

GetOverlappedResult-API

  • Windows 8 und Windows 7: Löst eine Racebedingung auf, bei der eine Multithread-App mit GetOverlappedResult zurückgeben kann, ohne das Ereignis in der überlappenden Struktur zurücksetzungen zu müssen, wodurch der nächste Aufruf dieser Funktion vorzeitig zurückgegeben wird.
  • Windows Vista (Standard): Stellt das Verhalten mit der Racebedingung zur Verfügung, von der Apps möglicherweise abhängig sind. Apps, die dieses Race vor dem Verhalten Windows 7 vermeiden müssen, sollten auf das überlappende Ereignis warten und getOverlappedResult bei Signalisierung mit bWait == FALSE aufrufen.

Status von Shell-Designs im Modus mit hohem Kontrast

  • Windows 8: Gibt den tatsächlichen Themingstatus für im Modus mit hohem Kontrast zurück.
  • Windows 7: Gibt das Thema im Modus mit hohem Kontrast als nicht verfügbar zurück, da DWM noch aktiviert ist.
  • Windows Vista (Standard): Gibt das Thema als nicht verfügbar zurück, wenn es sich im Modus mit hohem Kontrast befindet, da DWM noch aktiviert ist.

Shell-Methode "iPersistFile::Save"

  • Windows 8: CShellLink::Save bestimmt jetzt, ob der IPersistFile-Handler mit einem relativen Path-Argument aufgerufen wird, und schlägt den Aufruf fehl, wenn dies der Ist.

    Die öffentliche Dokumentation, die dieses Verhalten beschreibt, gibt an, dass das Path-Argument ein absoluter Pfad sein muss:

  • Windows 7 und früher (Standardeinstellung): CShellLink::Save bestimmt nicht, ob der iPersistFile-Handler eine Überprüfung des relativen Pfads sendet und apps ermöglicht, weiterhin mit absoluten oder relativen Pfaden zu arbeiten.

Programmkompatibilitäts-Assistent (PCA)

  • Windows 8: Apps mit dem Kompatibilitätsabschnitt erhalten keine PCA-Entschärfung.
  • Windows 7: Apps mit dem Kompatibilitätsabschnitt werden auf mögliche Kompatibilitätsprobleme bei Windows 8 (in diesem Dokument beschrieben) nachverfolgt.
  • Windows Vista (Standard): Apps, die nicht ordnungsgemäß installiert werden können oder während der Laufzeit unter bestimmten Umständen abstürzen, erhalten die PCA-Entschärfung. Weitere Informationen finden Sie im Abschnitt Ressourcen.

Nutzen von Featurefunktionen

Aktualisieren Sie das App-Manifest mit den neuesten Kompatibilitätsinformationen für die Betriebssystemunterstützung. In diesem Abschnitt werden die Ergänzungen zum Manifest beschrieben:

Namespace: Compatibility.v1 (xmlns="urn:schemas-microsoft-com:compatibility.v1">)

Abschnittsname: Kompatibilität (neuer Abschnitt)

SupportedOS: GUID des unterstützten Betriebssystems: Die GUIDs, die den unterstützten Betriebssystemen zuordnen, sind:

  • {e2011457-1546-43c5-a5fe-008deee3d3f0}

    für Windows Vista: Dies ist der Standardwert für den Switchbackkontext.

  • {35138b9a-5d96-4fbd-8e2d-a2440225f93a}

    für Windows 7: Apps, die diesen Wert im App-Manifest festlegen, erhalten das verhalten Windows 7.

  • {4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}

    für Windows 8: Apps, die diesen Wert im Anwendungsmanifest festlegen, erhalten das Windows 8 Verhalten.

Microsoft generiert und veröffentlicht BEI Bedarf GUIDs für Windows Versionen.

Ein XML-Beispiel für ein aktualisiertes Manifest:

Hinweis

Bei den Attribut- und Tagnamen im App-Manifest wird die Kleinschreibung beachtet.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 
    <application> 
        <!--The ID below indicates app support for Windows Vista -->
        <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> 
        <!--The ID below indicates app support for Windows 7 -->
        <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
        <!--The ID below indicates app support for Windows 8 -->
        <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
    </application> 
</compatibility>
</assembly>

Die GUIDs für alle Betriebssysteme im vorherigen Beispiel bieten Unterstützung auf downlevelr Ebene. Apps, die mehrere Plattformen unterstützen, benötigen keine separaten Manifeste für jede Plattform.

Tests

Eine App kann mehrere unterstützte Betriebssystem-IDs angeben. Sie sollten eine unterstützte Betriebssystem-ID hinzufügen, wenn Sie die App unter diesem Betriebssystem getestet haben oder testen. Windows Vista und frühere Betriebssystemversionen achten nicht auf diese Einträge. Ab version Windows 7 wählt Windows die GUID mit der höchsten Version im Manifest bis zur ausgeführten Windows-Version aus und bietet der App Unterstützung auf dieser Ebene. So überprüfen Sie, ob die App mit dem neuen App-Manifestkompatibilitätsabschnitt funktioniert:

  1. Testen Sie die App mit dem neuen Kompatibilitätsabschnitt und supportedOS ID = { 4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}, um sicherzustellen, dass die App mit dem neuesten Windows 8-Verhalten ordnungsgemäß funktioniert.
  2. Testen Sie die App mit dem neuen Kompatibilitätsabschnitt und der SupportedOS-ID = {35138b9a-5d96-4fbd-8e2d-a2440225f93a}, um sicherzustellen, dass die App mit dem Windows 7-Verhalten ordnungsgemäß funktioniert.
  3. Testen Sie die App mit dem neuen Kompatibilitätsabschnitt und supportedOS ID = {e2011457-1546-43c5-a5fe-008deee3d3f0}, um sicherzustellen, dass die App mit dem Verhalten von Windows Vista ordnungsgemäß funktioniert.

Ressourcen