Partager via

Manifeste d’application (exécutable)

  • Article

Plateformes

Clients : Windows 8
Serveurs : Windows Server 2012

Description

La section de compatibilité du manifeste d’application (exécutable) introduit dans Windows permet au système d’exploitation de déterminer les versions de Windows qu’une application a été conçue pour cibler. En outre, le manifeste de l’application permet à Windows de fournir le comportement attendu par l’application en fonction de la version de Windows ciblée par l’application.

La section de compatibilité du manifeste permet à Windows de fournir un nouveau comportement aux logiciels nouvellement créés tout en conservant la compatibilité pour les logiciels existants. Cette section permet également à Windows d’offrir une meilleure compatibilité dans les versions ultérieures de Windows. Par exemple, une application déclarant prendre en charge uniquement Windows 8 dans la section de compatibilité continuera à recevoir Windows 8 comportement dans les versions futures de Windows.

Manifestation

Les applications sans section de compatibilité dans leur manifeste auront un comportement Windows Vista par défaut sur Windows 7 et Windows 8 et les versions futures de Windows. N’oubliez pas que Windows XP et Windows Vista ignorent cette section de manifeste et qu’elle n’a aucun impact sur eux.

Ces composants Windows fournissent un comportement divergent en fonction de la section de compatibilité :

Pool de threads par défaut d’appel de procédure distante (RPC)

  • Windows 8 et Windows 7 : Pour améliorer la scalabilité et réduire le nombre de threads, RPC a basculé vers le pool de threads NT (pool par défaut). Pour Windows Vista, RPC utilisait un pool de threads privé :

    • Pour les fichiers binaires compilés pour Windows 7 et les versions ultérieures de Windows, le pool par défaut est utilisé.
    • Si I_RpcMgmtEnableDedicatedThreadPool est appelé avant l’appel d’une API RPC, le pool de threads privé est utilisé (comportement Vista).
    • Si I_RpcMgmtEnableDedicatedThreadPool est appelé après un appel RPC, le pool par défaut est utilisé, I_RpcMgmtEnableDedicatedThreadPool retourne l’erreur 1764 et l’opération demandée n’est pas prise en charge.

  • Windows Vista (par défaut) : pour les fichiers binaires compilés pour Windows Vista et les versions antérieures de Windows, le pool privé est utilisé.

Verrou DirectDraw

  • Windows 8 et Windows 7 : les applications manifestées pour Windows 7 et les versions ultérieures du système d’exploitation ne peuvent pas appeler l’API de verrouillage dans DDRAW pour verrouiller la mémoire tampon vidéo du bureau principal; cela entraîne une erreur et un pointeur NULL pour le principal est retourné. Ce comportement est appliqué même si la composition du Gestionnaire de fenêtres du bureau n’est pas activée. Les applications dont la compatibilité est déclarée pour Windows 7 et versions ultérieures ne doivent pas verrouiller la mémoire tampon vidéo principale pour le rendu.
  • Windows Vista (par défaut) : les applications peuvent acquérir un verrou sur la mémoire tampon vidéo principale, car les applications héritées dépendent de ce comportement ; l’exécution de l’application désactive desktop Window Manager.

Transfert de bloc de bits DirectDraw (bitblt) vers le serveur principal sans fenêtre de découpage

  • Windows 8 et Windows 7 : les applications manifestées pour Windows 7 et les versions ultérieures de Windows ne peuvent pas exécuter un bitblt dans la mémoire tampon vidéo principale du bureau sans fenêtre de découpage ; cela entraîne une erreur et la zone de bits ne sera pas affichée. Windows applique ce comportement même si vous n’activez pas la composition du Gestionnaire de fenêtres du bureau. Les applications dont la compatibilité est déclarée pour Windows 7 et versions ultérieures doivent effectuer un bitblt dans une fenêtre de découpage.
  • Windows Vista (par défaut) : les applications doivent être en mesure d’effectuer un bitblt sur le serveur principal sans fenêtre de découpage, car les applications héritées dépendent de ce comportement ; l’exécution de cette application désactive le Gestionnaire de fenêtres du bureau.

GetOverlappedResult API

  • Windows 8 et Windows 7 : résout une condition de concurrence dans laquelle une application multithread utilisant GetOverlappedResult peut retourner sans réinitialiser l’événement dans la structure qui se chevauche, ce qui entraîne le retour prématuré de l’appel suivant à cette fonction.
  • Windows Vista (par défaut) : fournit le comportement avec la condition de concurrence sur laquelle les applications peuvent avoir une dépendance. Les applications qui doivent éviter cette course avant le comportement de Windows 7 doivent attendre l’événement qui se chevauche et, lorsqu’elles sont signalées, appeler GetOverlappedResult avec bWait == FALSE.

Thèmes de l’interpréteur de commandes status en mode contraste élevé

  • Windows 8 : retourne le status de thème réel pour quand en mode contraste élevé.
  • Windows 7 : retourne les thèmes comme indisponibles en mode de contraste élevé, car DWM est toujours activé.
  • Windows Vista (valeur par défaut) : retourne les thèmes comme étant indisponibles en mode de contraste élevé, car DWM est toujours activé.

Shell iPersistFile::Save, méthode

  • Windows 8 : CShellLink::Save détermine maintenant si le gestionnaire IPersistFile est appelé avec un argument de chemin relatif et échoue à l’appel s’il l’est.

    La documentation publique décrivant ce comportement indique que l’argument path doit être un chemin absolu :

  • Windows 7 et versions antérieures (par défaut) : CShellLink::Save ne détermine pas si le gestionnaire iPersistFile envoie un chemin d’accès relatif case activée et permet aux applications de continuer à utiliser des chemins absolus ou relatifs.

Assistant Compatibilité des programmes (PCA)

  • Windows 8 : Les applications avec la section de compatibilité n’obtiennent pas l’atténuation du PCA.
  • Windows 7 : Les applications avec la section de compatibilité sont suivies pour les problèmes de compatibilité potentiels liés aux modifications Windows 8 (décrits dans ce document).
  • Windows Vista (par défaut) : les applications qui ne parviennent pas à s’installer correctement ou qui se bloquent pendant l’exécution dans certaines circonstances spécifiques obtiennent l’atténuation du PCA. Pour plus d’informations, consultez la section Ressources.

Tirer parti des fonctionnalités

Mettez à jour le manifeste de l’application avec les dernières informations de compatibilité pour la prise en charge du système d’exploitation. Cette section décrit les ajouts au manifeste :

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

Nom de la section : Compatibilité (nouvelle section)

SupportedOS : GUID du système d’exploitation pris en charge : les GUID mappés aux systèmes d’exploitation pris en charge sont les suivants :

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

    pour Windows Vista : il s’agit de la valeur par défaut pour le contexte de basculement

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

    pour Windows 7 : Les applications qui définissent cette valeur dans le manifeste de l’application obtiennent le comportement de Windows 7

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

    pour Windows 8 : les applications qui définissent cette valeur dans le manifeste de l’application obtiennent le comportement Windows 8

Microsoft générera et publiera des GUID pour les futures versions de Windows en fonction des besoins.

Exemple XML d’un manifeste mis à jour :

Notes

Les noms d’attributs et d’étiquettes dans le manifeste de l’application respectent la casse.

 

<?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>

Les GUID de tous les systèmes d’exploitation de l’exemple précédent fournissent une prise en charge de niveau inférieur. Les applications qui prennent en charge plusieurs plateformes n’ont pas besoin de manifestes distincts pour chaque plateforme.

Tests

Une application peut spécifier plusieurs ID de système d’exploitation pris en charge. Vous devez ajouter un ID de système d’exploitation pris en charge si vous avez testé ou êtes en cours de test l’application sur ce système d’exploitation. Windows Vista et les versions antérieures du système d’exploitation ne prêtent pas attention à ces entrées. À compter de Windows 7, Windows choisit le GUID de version la plus élevée dans le manifeste jusqu’à la version windows en cours d’exécution, et fournit la prise en charge de l’application à ce niveau. Pour vérifier que l’application fonctionne avec la nouvelle section de compatibilité du manifeste d’application :

  1. Testez l’application avec la nouvelle section de compatibilité et l’ID SupportedOS = { 4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38} pour vous assurer que l’application fonctionne correctement à l’aide du dernier comportement Windows 8.
  2. Testez l’application avec la nouvelle section de compatibilité et l’ID SupportedOS = {35138b9a-5d96-4fbd-8e2d-a2440225f93a} pour vous assurer que l’application fonctionne correctement à l’aide du comportement Windows 7.
  3. Testez l’application avec la nouvelle section de compatibilité et l’ID SupportedOS = {e2011457-1546-43c5-a5fe-008deee3d3f0} pour vous assurer que l’application fonctionne correctement à l’aide du comportement Windows Vista.

Ressources