App-Manifest (ausführbare Datei)

Plattformen

Clients – Windows 8 Server – Windows Server 2012

Beschreibung

Der in Windows eingeführte Kompatibilitätsabschnitt des in Windows eingeführten App-Manifests hilft dem Betriebssystem, die Versionen von Windows zu ermitteln, auf die eine App ausgerichtet wurde. Darüber hinaus ermöglicht das App-Manifest Windows das Verhalten, das die App basierend auf der von der App gezielten Version von Windows 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 auch bei der Bereitstellung einer größeren Kompatibilität in zukünftigen Versionen von Windows. 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 im Manifest verfügen standardmäßig über das Windows Vista-Verhalten unter Windows 7 und Windows 8 und zukünftigen Windows-Versionen. Beachten Sie, dass Windows XP und Windows Vista diesen Manifestabschnitt ignorieren und keine Auswirkungen darauf haben.

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

Remoteprozeduraufruf (RPC) Standardthreadpool

• 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:

  • Bei binärdateien, die für Windows 7- und höher-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 den Fehler 1764 zurückgibt, 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 werden, 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 erzwungen, auch wenn die Komposition von Desktopfenster-Managern nicht aktiviert ist. Apps mit der für Windows 7 deklarierten Kompatibilität dürfen den primären Videopuffer nicht sperren, um zu rendern.
• 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 primäres Fenster ohne Clipping

• Windows 8 und Windows 7: Apps, die für Windows 7 und höhere Versionen von Windows manifestiert sind, werden verhindert, dass ein Bitblt auf den primären Desktopvideopuffer ohne ein Clippingfenster ausgeführt wird. Dies führt zu einem Fehler, und der Bitblt-Bereich wird nicht gerendert. Windows erzwingt dieses Verhalten auch dann, wenn Sie die Komposition des Desktopfenster-Managers nicht aktivieren. Apps mit der für Windows 7 deklarierten Kompatibilität und höher müssen ein Bitblt für ein Clippingfenster ausführen.
• Windows Vista (Standard): Apps müssen in der Lage sein, ein Bitblt auf das primäre Fenster ohne Clippingfenster 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 Rennbedingung auf, in der eine Multithread-App mit GetOverlappedResult zurückgegeben werden 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 Rennbedingung bereit, dass Apps möglicherweise eine Abhängigkeit haben. Apps, die dieses Rennen vor dem Windows 7-Verhalten vermeiden müssen, sollten auf das überlappende Ereignis warten, und rufen Sie getOverlappedResult mit bWait == FALSE auf.

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 das Design als nicht verfügbar zurück, wenn der Modus "Hoher Kontrast" aktiviert ist, da DWM weiterhin aktiviert ist.
• Windows Vista (Standard): Gibt Design als nicht verfügbar zurück, wenn der Modus "Hoher Kontrast" aktiviert ist, da DWM weiterhin aktiviert ist.

Shell iPersistFile::Save-Methode

• Windows 8: CShellLink::Save bestimmt jetzt, ob der IPersistFile-Handler mit einem relativen Pfadargument aufgerufen wird und den Aufruf bei Bedarf fehlschlägt.

  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 fortsetzen kann.

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 für potenzielle 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 Unterstützung des Betriebssystems. 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-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 postt BEI Bedarf GUIDs für zukünftige Windows-Versionen.

Ein XML-Beispiel für ein aktualisiertes Manifest:

Hinweis

Die Attribut- und Tagnamen im App-Manifest sind groß- und kleinschreibungsempfindlich.

<?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ätsabschnitt und der SupportedOS-ID = { 4a2f28e3-53b9-4441-ba9c-d69d4a4a4a6e38}, 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.

Ressourcen

• QueryActCtxW-Funktion
• UAC-Manifest
• Anwendungsmanifeste für Windows-Anwendungen
• Desktopfenster-Manager (DWM)
• Kontextübereinstimmungsupdate
• Programmkompatibilitäts-Assistent