Partager via

Manifeste d’application (exécutable)

  • Article

Plateformes

Clients – serveurs Windows 8 – Windows Server 2012

Description

La section de compatibilité du manifeste d’application (exécutable) introduite 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 aide Windows à offrir une plus grande compatibilité dans les futures versions de Windows. Par exemple, une application déclarant la prise en charge des Windows 8 uniquement dans la section de compatibilité continuera à recevoir Windows 8 comportement dans les versions ultérieures de Windows.

Manifestation

Les applications sans section de compatibilité dans leur manifeste auront le comportement de Windows Vista par défaut sur Windows 7 et Windows 8 et les versions ultérieures de Windows. N’oubliez pas que Windows XP et Windows Vista ignorent cette section de manifeste et qu’ils n’ont 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 est passé au pool de threads NT (pool par défaut). Pour Windows Vista, RPC a utilisé un pool de threads privés :

    • Pour les fichiers binaires compilés pour Windows 7 et versions ultérieures de Windows, le pool par défaut est utilisé.
    • Si I_RpcMgmtEnableDedicatedThreadPool est appelée avant l’appel d’une API RPC, le pool de threads privés 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é.

Verrouillage DirectDraw

  • Windows 8 et Windows 7 : Les applications manifestes pour Windows 7 et 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 de bureau principale ; cela entraîne une erreur et un pointeur NULL pour le serveur principal est retourné. Ce comportement est appliqué même si la composition du Gestionnaire de fenêtres de bureau n’est pas activée. Les applications avec compatibilité déclarées pour Windows 7 et versions ultérieures ne doivent pas verrouiller la mémoire tampon vidéo principale à afficher.
  • 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 le Gestionnaire de fenêtres de bureau.

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

  • Windows 8 et Windows 7 : les applications manifestes pour Windows 7 et les versions ultérieures de Windows ne peuvent pas effectuer un bitblt vers la mémoire tampon vidéo du bureau principal 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 de bureau. Les applications avec compatibilité déclarées 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 vers 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 de bureau.

GetOverlappedResult API

  • Windows 8 et Windows 7 : résout une condition de concurrence où une application multithread utilisant GetOverlappedResult peut retourner sans réinitialiser l’événement dans la structure superposée, 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 concurrence avant le comportement de Windows 7 doivent attendre l’événement qui se chevauche et, lorsqu’elles sont signalées, appelez GetOverlappedResult avec bWait == FALSE.

État des thèmes shell en mode contraste élevé

  • Windows 8 : retourne l’état réel des thèmes pour le moment en mode contraste élevé.
  • Windows 7 : retourne les thèmes comme non disponibles en mode contraste élevé, car DWM est toujours activé.
  • Windows Vista (valeur par défaut) : retourne les thèmes comme non disponibles en mode 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 d’accès relatif et échoue l’appel s’il l’est.

    La documentation publique décrivant ce comportement indique que l’argument de chemin 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 une vérification relative du chemin d’accès et permet aux applications de continuer à travailler avec 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 de l’ACP.
  • Windows 7 : Les applications avec la section de compatibilité sont suivies pour connaître les problèmes de compatibilité potentiels pour Windows 8 modifications (décrites dans ce document).
  • Windows Vista (par défaut) : les applications qui ne parviennent pas à s’installer correctement ou se bloquent pendant l’exécution dans certaines circonstances spécifiques obtiennent l’atténuation de l’ACP. 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 du 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’attribut et de balise 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 bas niveau. 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 si vous ê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 font pas attention à ces entrées. À compter de Windows 7, Windows choisit le GUID de version le plus élevé dans le manifeste jusqu’à la version Windows en cours d’exécution et assure 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 comportement de Windows 8 le plus récent.
  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 de 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 de Windows Vista.

Ressources