Freigeben über

App-Manifest (ausführbare Datei)

  • Artikel

Plattformen

Clients – Windows 8
Server – Windows Server 2012

BESCHREIBUNG

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

Im Kompatibilitätsabschnitt des Manifests kann Windows neue Verhaltensweisen für neu erstellte Software bereitstellen und gleichzeitig die Kompatibilität für vorhandene Software beibehalten. Dieser Abschnitt unterstützt Windows dabei, auch in zukünftigen Versionen von Windows eine bessere Kompatibilität bereitzustellen. Eine App, die die Unterstützung nur für Windows 8 im Kompatibilitätsabschnitt deklariert, erhält beispielsweise weiterhin Windows 8 Verhalten in zukünftigen Versionen von Windows.

Manifestation

Apps ohne Kompatibilitätsabschnitt in ihrem Manifest weisen standardmäßig Windows Vista-Verhalten unter Windows 7 und Windows 8 und zukünftigen Windows-Versionen auf. Beachten Sie, dass Windows XP und Windows Vista diesen Manifestabschnitt ignorieren und keine Auswirkungen darauf haben.

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

Standardmäßiger RPC-Threadpool (Remote Procedure Call, Remoteprozeduraufruf)

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

    • Für Binärdateien, die für Windows 7 und höhere Versionen 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 höhere 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 den primären Wird zurückgegeben. Dieses Verhalten wird auch dann erzwungen, wenn die Desktopfenster-Manager-Komposition nicht aktiviert ist. Apps mit für Windows 7 und höher deklarierter Kompatibilität dürfen den primären Videopuffer zum Rendern 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. Wenn Sie die App ausführen, wird der Desktopfenster-Manager deaktiviert.

DirectDraw-Bitblockübertragung (Bitblt) an das primäre Element ohne Beschneidungsfenster

  • Windows 8 und Windows 7: Apps, die für Windows 7 und höhere Versionen von Windows manifestiert sind, werden daran gehindert, einen Bitblt für den primären Desktop-Videopuffer ohne ein Beschneidungsfenster auszuführen. Dies führt zu einem Fehler, und der Bitbltbereich wird nicht gerendert. Windows erzwingt dieses Verhalten auch dann, wenn Sie die Desktopfenster-Manager-Komposition nicht aktivieren. Apps mit für Windows 7 und höher deklarierter Kompatibilität müssen ein Bitblt für ein Beschneidungsfenster ausführen.
  • Windows Vista (Standard): Apps müssen in der Lage sein, eine Bitblt für die primäre Datei ohne ein Beschneidungsfenster auszuführen, da Legacy-Apps von diesem Verhalten abhängen. Wenn Sie diese App ausführen, wird der Desktopfenster-Manager deaktiviert.

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ückzusetzen, wodurch der nächste Aufruf dieser Funktion vorzeitig zurückgegeben wird.
  • Windows Vista (Standard): Stellt das Verhalten mit der Racebedingung bereit, von der Apps möglicherweise abhängig sind. Apps, die dieses Rennen vor dem Windows 7-Verhalten vermeiden müssen, sollten auf das überlappende Ereignis warten und getOverlappedResult mit bWait == FALSE aufrufen, wenn sie signalisiert werden.

Shelldesigns status im Modus mit hohem Kontrast

  • Windows 8: Gibt den tatsächlichen designierenden status für den Modus mit hohem Kontrast zurück.
  • Windows 7: Gibt design als nicht verfügbar zurück, wenn der Modus mit hohem Kontrast aktiviert ist, da DWM noch aktiviert ist.
  • Windows Vista (Standard): Gibt die Designart als nicht verfügbar zurück, wenn sie sich im Modus mit hohem Kontrast befindet, da DWM noch aktiviert ist.

Shell iPersistFile::Save-Methode

  • 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 Wert ist.

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

  • Windows 7 und früher (Standardeinstellung): CShellLink::Save bestimmt nicht, ob der iPersistFile-Handler eine relative Pfadüberprüfung 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 nicht die PCA-Entschärfung.
  • Windows 7: Apps mit dem Kompatibilitätsabschnitt werden auf potenzielle Kompatibilitätsprobleme bei Windows 8 Änderungen nachverfolgt (in diesem Dokument beschrieben).
  • Windows Vista (Standard): Apps, die unter bestimmten Umständen nicht ordnungsgemäß installiert werden oder während der Laufzeit 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)

UnterstütztOS: GUID des unterstützten Betriebssystems: Die GUIDs, die den unterstützten Betriebssystemen zugeordnet sind, 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 Windows 7-Verhalten.

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

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

Microsoft generiert und stellt bei Bedarf GUIDs für zukünftige Windows-Versionen bereit.

Ein XML-Beispiel für ein aktualisiertes Manifest:

Hinweis

Bei den Attribut- und Tagnamen im App-Manifest wird die Groß-/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 down-Level. 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 auf diesem Betriebssystem getestet haben oder gerade testen. Windows Vista und frühere Betriebssystemversionen beachten diese Einträge nicht. Ab 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 Abschnitt zur Kompatibilität des App-Manifests funktioniert:

  1. Testen Sie die App mit dem neuen Kompatibilitätsabschnitt und der 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 der SupportedOS-ID = {e2011457-1546-43c5-a5fe-008deee3d3f0), um sicherzustellen, dass die App ordnungsgemäß mit dem Windows Vista-Verhalten funktioniert.

Ressourcen