Freigeben über

App-Manifest (ausführbare Datei)

  • Artikel

Plattformen

Clients – Windows 8
Server – Windows Server 2012

Beschreibung

Der kompatibilitätsabschnitt des in Windows eingeführten App-Manifests (ausführbare Datei) hilft dem Betriebssystem, die Versionen von Windows zu ermitteln, auf die eine App ausgerichtet wurde. Darüber hinaus kann das App-Manifest Windows das Verhalten bereitstellen, das die App basierend auf der Von der App vorgesehenen Windows-Version erwartet.

Im Kompatibilitätsbereich des Manifests kann Windows neue Verhaltensweisen für neu erstellte Software bereitstellen und gleichzeitig die Kompatibilität für vorhandene Software beibehalten. Dieser Abschnitt hilft Windows dabei, auch in zukünftigen Versionen von Windows eine höhere Kompatibilität zu erzielen. Beispielsweise erhält eine App, die die Unterstützung nur für Windows 8 im Kompatibilitätsbereich deklariert, 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 ein abweichendes Verhalten basierend auf dem Kompatibilitätsabschnitt:

Remoteprozeduraufruf (RPC)

  • Windows 8 und Windows 7: Um die Skalierbarkeit zu verbessern und die Threadanzahl zu reduzieren, wechselt RPC zum NT-Threadpool (Standardpool). 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 die primäre Wird zurückgegeben. Dieses Verhalten wird auch dann erzwungen, wenn die Desktopfenster-Manager-Komposition nicht aktiviert ist. Apps mit Kompatibilität, die für Windows 7 und höher deklariert sind, dürfen den primären Videopuffer nicht sperren, um gerendert zu werden.
  • Windows Vista (Standard): Apps können eine Sperre für den primären Videopuffer erwerben, da ältere Apps von diesem Verhalten abhängen. Wenn die App ausgeführt wird, wird der Desktopfenster-Manager deaktiviert.

DirectDraw-Bitblockübertragung (Bitblt) in das primäre Element ohne Beschnittfenster

  • Windows 8 und Windows 7: Apps, die für Windows 7 und höhere Versionen von Windows manifestiert sind, werden daran gehindert, einen Bitblättchen für den primären Desktopvideopuffer ohne Einschneidefenster 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 Kompatibilität, die für Windows 7 und höher deklariert sind, müssen ein Bitblätten für ein Beschneidungsfenster ausführen.
  • Windows Vista (Standard): Apps müssen in der Lage sein, eine Bitblätte ohne Beschneidungsfenster auszuführen, da legacy-Apps von diesem Verhalten abhängig sind. 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 bei Signalen GetOverlappedResult mit bWait == FALSE aufrufen.

Shelldesignstatus im Modus mit hohem Kontrast

  • Windows 8: Gibt den tatsächlichen Designstatus für den Modus mit hohem Kontrast zurück.
  • Windows 7: Gibt Design als nicht verfügbar zurück, wenn der Modus für hohen Kontrast aktiviert ist, da DWM noch aktiviert ist.
  • Windows Vista (Standard): Gibt Design als nicht verfügbar zurück, wenn im Modus mit hohem Kontrast weiterhin DWM aktiviert ist.

Shell iPersistFile::Save-Methode

  • Windows 8: CShellLink::Save now determines if the IPersistFile handler is called with a relative path argument and fails the call if it is.

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

  • Windows 7 und früher (Standard): CShellLink::Save bestimmt nicht, ob der iPersistFile-Handler eine relative Pfadüberprüfung sendet und apps die Arbeit mit absoluten oder relativen Pfaden ermöglicht.

Programmkompatibilitäts-Assistent (PCA)

  • Windows 8: Apps mit dem Kompatibilitätsabschnitt erhalten nicht die PCA-Entschärfung.
  • Windows 7: Apps mit dem Kompatibilitätsbereich werden auf mögliche Kompatibilitätsprobleme für Windows 8-Änderungen (in diesem Dokument beschrieben) nachverfolgt.
  • Windows Vista (Standard): Apps, die während der Laufzeit nicht ordnungsgemäß installiert oder abstürzen, erhalten unter bestimmten Umständen 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 zugeordnet sind:

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

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

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

    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 postt bei Bedarf GUIDs für zukünftige Windows-Versionen.

Ein XML-Beispiel für ein aktualisiertes Manifest:

Anmerkung

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.the GUIDs for all the operating systems in the previous example provide down-level support. 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 getestet haben oder sich im Testvorgang befinden, die App auf diesem Betriebssystem. Windows Vista und frühere Betriebssystemversionen achten nicht auf diese Einträge. Ab Windows 7 wählt Windows die GUID der höchsten Version im Manifest bis zur ausgeführten Windows-Version aus und gibt der App Unterstützung auf dieser Ebene. So überprüfen Sie, ob die App mit dem neuen App-Manifestkompatibilitätsbereich funktioniert:

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

Betriebsmittel