Comment fonctionne la compatibilité des applications Windows — mode de compatibilité, shims et Compatibility Administrator

« Une application métier de dix ans dont le code source a disparu ne démarre plus sur un nouveau PC Windows 11. J’ai coché “Windows XP” dans l’onglet Compatibilité de la boîte de dialogue Propriétés et elle s’est mise à fonctionner. — Que fait réellement cela ? Est-il raisonnable de continuer à s’y fier ? » C’est une consultation que nous entendons souvent.

Quand une seule case à cocher fait fonctionner quelque chose, le malaise est naturel. La véritable identité du mode de compatibilité, qui a l’air magique, est un ensemble de petits morceaux de code appelés shims qui s’interposent entre l’application et l’API Windows et renvoient un « mensonge ». Windows lui-même utilise ce palliatif à grande échelle pour faire tourner des applications de plusieurs générations, et il expose une partie du mécanisme aux utilisateurs et aux administrateurs.

Utilisé sans comprendre le mécanisme, la prolongation devient un « il ne faut pas y toucher parce qu’on ne sait pas pourquoi ça marche » instable. Comprendre le mécanisme permet de décider, avec des raisons, jusqu’où on peut s’y fier en sécurité, ce qui le cassera, et quand il faut réécrire.

flowchart TB
    accTitle: Comprendre le mécanisme change la qualité de la prolongation
    accDescr: Utiliser le mode de compatibilité sans comprendre le mécanisme mène à une prolongation instable qu'on n'ose pas toucher ; le comprendre permet de décider avec des raisons jusqu'où s'y fier, ce qui le cassera et quand réécrire
    unknown["Utiliser sans comprendre le mécanisme"] --> fear["Prolongation instable qu'on n'ose pas toucher"]
    known["Utiliser après avoir compris le mécanisme"] --> judge["Décisions avec des raisons"]
    judge -.-> j1["Jusqu'où on peut s'y fier"]
    judge -.-> j2["Ce qui le cassera"]
    judge -.-> j3["Quand il faut réécrire"]

Figure 1 : Même prolongation, la qualité change entre l’inquiétude de ne pas connaître le mécanisme et une décision fondée sur sa compréhension.

Destiné aux responsables informatiques des PME et aux développeurs d’applications Windows qui gardent d’anciennes applications métier, cet article organise, à partir des sources primaires Microsoft Learn, le mécanisme des shims qui est la véritable identité du mode de compatibilité, ce que peuvent les shims représentatifs, comment les appliquer en organisation avec Compatibility Administrator, les limites que les shims ne sauvent pas, et comment décider entre prolongation et migration.

1. D’abord la conclusion

• La véritable identité du mode de compatibilité, ce sont les shims (une couche de compatibilité). Les réglages de l’onglet Compatibilité sont écrits dans HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers, et un ensemble de shims est appliqué au processus au démarrage.¹²
• Un shim est un hook d’API en mode utilisateur qui réécrit la table d’adresses d’importation (IAT). Il intercepte le chemin par lequel l’application appelle les API Windows et renvoie les mêmes réponses qu’un ancien Windows. Il ne change pas le système lui-même.³
• Ce qu’un shim peut faire est le même périmètre que ce qu’une correction de code dans l’application peut faire. Il ne peut pas contourner les mécanismes de sécurité, ni corriger les problèmes en mode noyau (pilotes de périphérique).³
• Microsoft fournit un grand nombre de shims prêts à l’emploi — mensonges de version, remappage de chemins de fichiers, usurpation du registre, usurpation des contrôles d’administrateur, et d’autres. On peut les appliquer à des EXE individuels depuis Compatibility Administrator.⁴
• Windows lui-même utilise des shims par défaut. La base de compatibilité standard du système (.sdb) est confrontée à chaque lancement, et le PCA (Program Compatibility Assistant) peut aussi détecter un problème et appliquer automatiquement un réglage de compatibilité.¹⁵
• « Répondre comme s’il s’agissait d’un Windows plus ancien » est désormais le comportement par défaut. À partir de Windows 8.1, GetVersionEx ne renvoie pas une version de système que l’application n’a pas déclarée dans son manifeste. Le mode de compatibilité est une extension de ce mécanisme.⁶⁷
• Les shims ne fonctionnent pas sur les applications 16 bits, les dépendances de pilotes noyau, ni l’accès matériel direct. En particulier, les applications 16 bits ne peuvent pas du tout s’exécuter sur Windows 64 bits.⁸
• Pour les applications qui « exigent l’administrateur mais n’en ont pas réellement besoin », RunAsInvoker est le geste standard. __COMPAT_LAYER=RunAsInvoker supprime la demande d’élévation et laisse l’application tourner sous des privilèges standard.⁹
• Tourner sous un shim signifie qu’on peut prolonger la vie pour l’instant, mais le vrai chemin est « la faire tourner sans shim ». Si vous décidez de prolonger, consignez quels shims la font tourner et gérez cela comme matériau de décision de réécriture.

2. Le tableau d’ensemble de la compatibilité des applications — les couches de rétrocompatibilité que Windows a déjà

Avant de parler des shims, voici la liste des mécanismes que Windows a déjà pour les anciennes applications. Même quand on dit « ça s’est mis à marcher en mode de compatibilité », ce qui sauve réellement l’application est l’une de ces couches, ou une combinaison de plusieurs.

La virtualisation UAC est une mesure transitoire qui s’applique aux processus interactifs 32 bits sans manifeste, et Microsoft elle-même indique que c’est « une technologie temporaire que nous avons l’intention de retirer d’une future version de Windows ».¹⁰ Les dégâts réels de la redirection Wow6432Node et du VirtualStore, et comment y faire face, sont détaillés dans « Redirection et virtualisation du registre 32 bits/64 bits — Wow6432Node et le problème de la « valeur écrite qui n’existe pas » » ; cet article garde les shims au centre et n’évoque les autres couches que dans la mesure nécessaire.

flowchart TB
    accTitle: La place de la virtualisation UAC
    accDescr: La virtualisation UAC est une mesure transitoire pour les processus interactifs 32 bits sans manifeste ; elle redirige les écritures vers un VirtualStore par utilisateur, mais Microsoft elle-même indique que c'est une technologie temporaire destinée à être retirée d'un futur Windows
    proc["Processus interactif 32 bits sans manifeste"] --> uacv["La virtualisation UAC s'applique"]
    uacv --> vs["Redirigé vers un VirtualStore par utilisateur"]
    uacv -.-> tmp["Technologie temporaire destinée à un retrait futur"]

Figure 2 : La virtualisation UAC est une mesure transitoire pour les processus 32 bits sans manifeste, et on ne peut pas s’y fier de façon permanente.

En aparté sur la virtualisation DPI : une application qui n’a pas déclaré de prise en charge DPI est traitée comme dessinant à 96 DPI (100 %), et Windows étire le bitmap pour l’affichage. C’est pourquoi les anciennes applications paraissent « floues » sur un moniteur haute densité, et « Remplacer le comportement de mise à l’échelle haute densité » de l’onglet Compatibilité est l’interrupteur qui change ce comportement de virtualisation.¹¹

flowchart TB
    accTitle: Comment fonctionne la virtualisation DPI
    accDescr: Une application qui n'a pas déclaré de prise en charge DPI est traitée comme dessinant à 96 DPI ; Windows étire le bitmap donc elle paraît floue, et le remplacement des paramètres haute densité de l'onglet Compatibilité commute ce comportement de virtualisation
    app["Application qui ne déclare pas de prise en charge DPI"] --> treat["Traitée comme dessinant à 96 DPI"]
    treat --> stretch["Le bitmap est étiré pour l'affichage"]
    stretch --> blur["Paraît floue sur un moniteur haute densité"]
    tab["Remplacer le comportement de mise à l'échelle haute densité"] -.->|Commute le comportement de virtualisation| treat

Figure 3 : Une application non DPI-aware est traitée comme 96 DPI et étirée ; le remplacement de l’onglet Compatibilité est l’interrupteur de cette virtualisation.

3. Ce qu’est vraiment un shim — intercepter entre les API en réécrivant l’IAT

3.1. L’« interprète » qui se tient entre l’application et le système

Un exécutable Windows (format PE) appelle les API de DLL externes via la table d’adresses d’importation (IAT). Quand l’application appelle GetVersionEx, elle ne fait que sauter à l’adresse écrite dans l’IAT. Le mécanisme des shims exploite cela. Au chargement, il réécrit l’entrée IAT de l’API cible vers l’adresse du code du shim et s’insère entre l’application et Windows. Les API obtenues dynamiquement via GetProcAddress sont traitées en accrochant GetProcAddress lui-même.³

Une fois qu’il a intercepté, un shim peut renvoyer un ancien numéro de version à « quelle est la version actuelle du système ? », ou remapper un accès fichier vers un emplacement non inscriptible ailleurs, puis appeler la vraie API si besoin. Du point de vue de l’application, on dirait qu’elle « tourne sur un ancien Windows » ; du point de vue du système, on dirait qu’« une application bien élevée tourne » — le shim est l’interprète entre les deux.

flowchart TB
    accTitle: Le chemin par lequel un shim intercepte un appel d'API
    accDescr: L'appel d'API d'une application passe par l'IAT ; réécrire l'entrée IAT vers le shim au chargement permet au shim d'intercepter, d'usurper la même réponse qu'un ancien Windows, puis d'appeler la vraie API si besoin
    app["Application"] -->|Appel d'API| iat["Entrée IAT"]
    iat -->|Réécrite vers le shim au chargement| shim["Shim (interprète)"]
    shim -->|Si besoin| api["La vraie API Windows"]
    shim -.-> lie["Usurpe la même réponse qu'un ancien Windows"]
    gpa["Appels via GetProcAddress"] -.->|Traités par un hook| shim

Figure 4 : Un shim intercepte entre l’application et l’API Windows. Ce qui est réécrit est l’IAT côté application ; le système lui-même ne change pas.

Trois propriétés importantes découlent de cette conception.³

1. Un shim s’exécute comme du code côté application. Il ne fait pas partie du système, donc il est soumis aux mêmes contraintes de sécurité que l’application. Un shim ne peut pas contourner les mécanismes de sécurité du système, et il n’est pas nécessaire d’assouplir les réglages de sécurité pour utiliser un shim.
2. Ce qu’un shim peut corriger, une correction de code côté application peut aussi le corriger. Un shim est un substitut pour les cas où « il n’y a pas de source / on ne peut pas corriger » ; il n’est pas plus puissant qu’une correction de code.
3. Mode utilisateur uniquement. Les problèmes de compatibilité des pilotes de périphérique qui s’exécutent en mode noyau ne peuvent pas être corrigés par un shim.

3.2. La base de shims (.sdb) et l’appariement

La table de correspondance « quel shim appliquer à quel EXE » est la base de shims, un fichier binaire d’extension .sdb. Les exécutables cibles sont enregistrés dans la base par des attributs tels que le nom de fichier, la taille, la somme de contrôle et la version (attributs d’appariement), et ils sont appariés au démarrage du processus. Les remèdes comprennent Appfix (un shim), qui injecte un hook d’API, et Apphelp, qui affiche un message « cette application a un problème de compatibilité ». Un ensemble de plusieurs shims et indicateurs est une couche de compatibilité (mode de compatibilité).¹

Facile à manquer : cet appariement ne s’exécute pas seulement sur les applications qui ont le mode de compatibilité réglé, mais à chaque lancement de processus. Windows fournit une base standard de corrections pour des milliers d’applications connues (les fichiers vivent sous %WINDIR%\AppPatch), et sur votre PC aujourd’hui une ancienne application démarre presque certainement avec un shim attaché sans que personne ne le remarque. Les corrections de compatibilité fournies par Microsoft sont livrées avec Windows et mises à jour via Windows Update.³

flowchart TB
    accTitle: Appariement de la base de shims au démarrage du processus
    accDescr: Chaque lancement de processus est apparié à la base de shims ; si un enregistrement correspond aux attributs d'appariement, Appfix injecte un shim ou Apphelp affiche un message, sinon le processus démarre tel quel
    start["Démarrage du processus"] --> db["Apparier contre .sdb"]
    db -.-> attr["Nom de fichier, taille, etc."]
    db --> hit{"Un enregistrement ?"}
    hit -->|Oui| appfix["Appfix : injecter un shim"]
    hit -->|Oui| apphelp["Apphelp : un message"]
    hit -->|Non| plain["Démarrer tel quel"]
    layer["Couche de compatibilité"] -.->|Ensemble de shims et d'indicateurs| appfix

Figure 5 : L’appariement s’exécute à chaque lancement de processus, pas seulement sur les applications qui ont le mode de compatibilité réglé.

3.3. PCA — le mécanisme qui applique les shims automatiquement

Une autre voie par laquelle un shim peut être appliqué sans qu’un administrateur l’ait voulu est le PCA (Program Compatibility Assistant). Le PCA surveille l’exécution des applications et, lorsqu’il détecte des signes d’un problème de compatibilité connu, propose d’appliquer une correction à l’utilisateur ou, dans certains cas, applique automatiquement un réglage de compatibilité. Par exemple, une application qui se plante en appelant du code dans une DLL libérée se voit attribuer PINDLL, et une application qui échoue à écrire dans un fichier Windows protégé se voit attribuer WRPMITIGATION.⁵

flowchart TB
    accTitle: Comment le PCA applique automatiquement un réglage de compatibilité
    accDescr: Le PCA surveille l'exécution des applications et, lorsqu'il détecte des signes d'un problème de compatibilité connu, propose d'appliquer une correction à l'utilisateur ou, dans certains cas, applique automatiquement un réglage de compatibilité
    run["Exécution de l'application"] --> pca["Le PCA surveille"]
    pca --> sign{"Signes d'un problème connu ?"}
    sign -->|Oui| resp{"Quel cas ?"}
    resp -->|Traité par une proposition| suggest["Proposer d'appliquer une correction"]
    resp -->|Certains cas| auto["Appliquer automatiquement un réglage de compatibilité"]
    sign -->|Non| none["Exécuter tel quel"]
    auto -.-> ex["Exemple : PINDLL ou WRPMITIGATION"]

Figure 6 : Le PCA surveille l’exécution et, lorsqu’il détecte des signes d’un problème connu, propose une correction ou en applique une automatiquement.

L’identité de « je n’ai jamais rien réglé, mais à un moment la case du mode de compatibilité était cochée » est, dans bien des cas, cela. Ce n’est ni une panne ni un mauvais clic ; c’est Windows qui se comporte comme conçu.

4. Ce que peuvent les shims représentatifs

Parmi les shims prêts à l’emploi que Microsoft publie, voici une sélection qui revient réellement souvent quand on prolonge la vie d’une application métier.⁴

En regardant la liste, la plupart des shims sont « un mensonge qui renvoie la réponse que l’ancienne application attend ». Le disque fait au plus 2 Go, le système est XP, vous êtes administrateur — ils recréent, à l’intérieur de ce processus seulement, la vision du monde de l’époque où l’application est née.

L’usurpation de version est devenue un « comportement officiel par défaut »

L’usurpation de version n’est pas un piratage spécial. À partir de Windows 8.1, la valeur que GetVersionEx renvoie dépend du manifeste de l’application. Une application sans déclaration <supportedOS> dans la section <compatibility> du manifeste reçoit toujours l’équivalent de Windows 8 (6.2), quel que soit le système réel. Quand il y a une déclaration, la valeur jusqu’au système le plus élevé parmi ceux déclarés est renvoyée (par exemple, si vous avez déclaré jusqu’au GUID Windows 8.1, vous obtenez 6.3 même sur Windows 11).⁶⁷

Donc la « version Windows que l’application voit » se décide en ces étapes empilées.

1. La valeur jusqu’au système déclaré dans le manifeste est renvoyée (6.2 s’il n’y a pas de déclaration)
2. Si le mode de compatibilité (un shim de la famille VersionLie) est appliqué, la version du système sélectionné est renvoyée⁶

flowchart TB
    accTitle: Comment se décide la version de système que l'application voit
    accDescr: La valeur que GetVersionEx renvoie se décide selon qu'une déclaration supportedOS est dans le manifeste ; sans déclaration l'équivalent Windows 8 6.2 est renvoyé, avec une déclaration la valeur jusqu'au système déclaré le plus élevé, et si un shim VersionLie est appliqué elle est écrasée par la version du système sélectionné
    q["Requête GetVersionEx"] --> m{"Y a-t-il une déclaration supportedOS ?"}
    m -->|Non| v62["L'équivalent Windows 8 (6.2) est renvoyé"]
    m -->|Oui| decl["Valeur jusqu'au système déclaré le plus élevé"]
    v62 --> lie{"Shim de la famille VersionLie appliqué ?"}
    decl --> lie
    lie -->|Oui| fake["La valeur de système choisie en mode de compatibilité"]
    lie -->|Non| asis["La valeur est renvoyée telle quelle"]

Figure 7 : La version Windows que l’application voit se décide en étapes empilées par le manifeste et par les shims.

Si une application interne « branche sur la version du système et, de façon déconcertante, est jugée comme 8 alors que c’est Windows 11 », suspectez d’abord la déclaration supportedOS du manifeste. Dit autrement, une ancienne application qui refuse de démarrer sur un contrôle de version peut, avec une forte probabilité, passer grâce à un shim VersionLie. Dans bien des cas elle ne regarde que le numéro de version, et le comportement réel est correct sur un système plus récent.

flowchart TB
    accTitle: Deux symptômes dus à la version et comment y faire face
    accDescr: Si une application interne est jugée comme 8 alors que c'est Windows 11, suspectez la déclaration supportedOS du manifeste ; une ancienne application qui refuse de démarrer sur un contrôle de version peut, avec une forte probabilité, passer grâce à un shim VersionLie
    sym1["Jugée comme 8 alors que c'est Windows 11"] --> fix1["Suspecter la déclaration supportedOS"]
    sym2["Démarrage refusé sur un contrôle de version"] --> fix2["Essayer de passer avec VersionLie"]
    fix2 -.-> why["Le comportement réel est souvent correct sur un système plus récent"]

Figure 8 : Quand le jugement est périmé, suspectez le manifeste ; quand le démarrage est refusé, suspectez VersionLie.

5. Ce que fait la case du mode de compatibilité

Les réglages de Propriétés → onglet Compatibilité sont stockés dans la clé de registre AppCompatFlags\Layers. Les réglages de compatibilité d’application DXGI et analogues utilisent la même clé comme endroit pour spécifier une couche de compatibilité.² Regardons réellement.

reg query "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers"

Pour un EXE sur lequel vous avez réglé « Windows XP (Service Pack 3) », « Exécuter ce programme en tant qu’administrateur » et « Remplacer le comportement de mise à l’échelle haute densité » dans l’onglet Compatibilité, vous verrez une valeur du type suivant.

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
    C:\LegacyApp\Gyomu.exe    REG_SZ    ~ WINXPSP3 RUNASADMIN HIGHDPIAWARE

Correspondances représentatives entre les éléments de case à cocher et les valeurs (confirmées sous Windows 11 ; les noms d’éléments et les valeurs peuvent changer selon la version du système).

Trois points à retenir.

• « Exécuter ce programme en tant qu’administrateur » s’écrit au même endroit. Le mode de compatibilité et l’indicateur d’élévation vivent ensemble dans la même clé Layers, et c’est là que naît la confusion « j’ai réglé le mode de compatibilité et l’élévation est venue / a disparu ». Regarder la valeur directement sépare les deux.
• Ce qui est écrit dans HKCU est « le réglage de cet utilisateur ». Si vous le réglez depuis « Modifier les paramètres pour tous les utilisateurs » de l’onglet, c’est écrit dans la clé de même nom côté HKLM et s’applique à tous les utilisateurs. Quand vous le distribuez en imaging, soyez conscient du côté sur lequel vous écrivez.
• La case n’est que l’entrée des couches prêtes à l’emploi. L’onglet ne permet de choisir que des couches représentatives ; on ne peut pas choisir des shims individuels et les combiner. C’est ce que fait Compatibility Administrator au chapitre suivant.

flowchart TB
    accTitle: Le chemin d'un réglage de l'onglet Compatibilité jusqu'à la prise d'effet
    accDescr: Les réglages de l'onglet Compatibilité sont stockés comme un chemin d'EXE et une valeur dans la clé AppCompatFlags Layers ; au prochain démarrage de cet EXE, le chargeur lit la valeur et applique la couche de compatibilité correspondante au processus
    tab["Régler dans l'onglet Compatibilité"] --> reg["Stocker le chemin d'EXE et la valeur dans la clé Layers"]
    reg --> boot["Prochain démarrage de l'EXE"]
    boot --> loader["Le chargeur lit la valeur"]
    loader --> apply["Appliquer la couche de compatibilité au processus"]
    reg -.-> hkcu["HKCU est cet utilisateur seulement"]
    reg -.-> hklm["HKLM s'applique à tous les utilisateurs"]

Figure 9 : La case est en réalité une écriture dans la clé Layers, et l’application se produit au prochain démarrage.

6. Compatibility Administrator en pratique — construire et distribuer un .sdb personnalisé

6.1. Comment l’obtenir, et les précautions

Compatibility Administrator est un outil inclus dans le Windows ADK (Windows Assessment and Deployment Kit).¹² Après l’installation, les éditions 32 bits et 64 bits sont présentes, et il faut utiliser l’édition 32 bits pour les applications 32 bits et l’édition 64 bits pour les applications 64 bits.¹³

Il y a une autre précaution importante. Si vous démarrez Compatibility Administrator en mode élevé (en tant qu’administrateur) et testez, la virtualisation UAC et la redirection ne se comportent pas comme pour un utilisateur réel, et vous pouvez juger à tort que « c’est corrigé ». Confirmez toujours l’effet d’une correction avec le même compte et les mêmes privilèges que l’utilisateur réel.⁴

flowchart TB
    accTitle: Deux précautions lors de l'utilisation de Compatibility Administrator
    accDescr: Utilisez l'édition 32 bits pour les applications 32 bits et l'édition 64 bits pour les applications 64 bits, et confirmez l'effet d'une correction avec le même compte et les mêmes privilèges que l'utilisateur réel, pas dans un état élevé
    app32["Application 32 bits"] --> tool32["Utiliser l'édition 32 bits"]
    app64["Application 64 bits"] --> tool64["Utiliser l'édition 64 bits"]
    elev["Tester en état élevé"] -.-> wrong["Peut mal juger une correction"]
    user["Tester avec les privilèges de l'utilisateur"] --> ok["Confirmer l'effet"]

Figure 10 : Choisir l’édition 32 bits ou 64 bits, et confirmer avec les mêmes privilèges que l’utilisateur réel, sont les précautions à l’entrée.

6.2. Procédure pour construire une base de compatibilité personnalisée

Le plan est le suivant.¹⁴

1. Dans le volet gauche de Compatibility Administrator, créez une nouvelle base sous « Custom Databases » et choisissez « Create New » → « Application Fix »
2. Saisissez le nom de l’application et le nom de l’éditeur, et spécifiez le fichier EXE cible
3. Choisissez le mode de compatibilité (couche) à appliquer — essayer d’abord un ensemble tel que « compatibilité Windows XP » est le chemin court
4. Si besoin, ajoutez des corrections de compatibilité individuelles (shims) — vous pouvez réduire à un ensemble minimal tel que VersionLie seulement ou CorrectFilePaths seulement
5. Confirmez les conditions d’appariement (taille de fichier, somme de contrôle, version, etc.) et enregistrez

Les conditions d’appariement sont la clé de « n’appliquer ceci qu’à cet EXE ». Les conditions de base par défaut suffisent en général, mais nous recommandons de laisser une condition qui peut identifier la version de l’application. Cela évite l’accident d’un ancien mensonge qui continue de s’appliquer à une nouvelle version quand l’éditeur livrera plus tard une édition corrigée.¹⁴¹⁵

flowchart TB
    accTitle: Procédure pour construire une base de compatibilité personnalisée
    accDescr: Créez un Application Fix dans une nouvelle base, spécifiez le nom de l'application et l'EXE cible, essayez d'abord un ensemble de mode de compatibilité puis réduisez aux shims individuels si besoin, confirmez les conditions d'appariement et enregistrez
    new["Créer une nouvelle base"] --> fix["Choisir Application Fix"]
    fix --> info["Spécifier le nom de l'application et l'EXE cible"]
    info --> layer["Essayer un ensemble de mode de compatibilité"]
    layer --> single["Si besoin, réduire aux shims individuels"]
    single --> match["Confirmer les conditions d'appariement et enregistrer"]
    match -.-> ver["Laisser une condition qui identifie la version"]

Figure 11 : Pour un Application Fix, essayez d’abord un ensemble de mode de compatibilité, réduisez à un ensemble minimal, et limitez la cible avec les conditions d’appariement.

Testez d’abord le .sdb créé sur une machine de validation. Une fois qu’il fonctionne comme prévu, vous le déployez dans l’organisation.

6.3. Distribuer avec sdbinst

La commande qui applique un .sdb personnalisé à chaque PC est sdbinst.exe (nécessite des privilèges d’administrateur).¹⁵

:: Install (-q is silent with no confirmation)
sdbinst -q "C:\Deploy\MyCorpFixes.sdb"

:: Uninstall (by file)
sdbinst -q -u "C:\Deploy\MyCorpFixes.sdb"

:: Uninstall (by database GUID)
sdbinst -q -u -g {database GUID}

Comme stratégie de déploiement organisationnel, Microsoft recommande de consolider en une seule base personnalisée à l’échelle de l’entreprise (ou par service) et de la gérer de façon centralisée, plutôt que d’expédier un .sdb distinct avec l’installateur de chaque application. Plus vous avez de corrections, plus il est facile de mettre à jour et redistribuer une base que d’en distribuer beaucoup d’une ligne. Une base personnalisée a son propre GUID, et installer une nouvelle version avec le même GUID remplace automatiquement l’ancienne version, donc les opérations de mise à jour restent simples aussi. Placez la distribution elle-même sur un chemin existant qui peut s’exécuter avec des privilèges d’administrateur, par exemple un packaging MSI ou un script de démarrage.¹⁵

flowchart TB
    accTitle: Le chemin de la création d'un .sdb personnalisé jusqu'à sa distribution
    accDescr: Créez une base de compatibilité personnalisée dans Compatibility Administrator, testez-la sur une machine de validation, appliquez-la à chaque PC avec sdbinst, et à la mise à jour installez une nouvelle version avec le même GUID pour que l'ancienne version soit remplacée automatiquement
    make["Créer dans Compatibility Administrator"] --> test["Tester sur une machine de validation"]
    test --> deploy["Appliquer à chaque PC avec sdbinst"]
    deploy --> update["Installer une nouvelle version avec le même GUID"]
    update -.-> replace["L'ancienne version est remplacée automatiquement"]
    deploy -.-> inv["Enregistré dans Programmes et fonctionnalités"]

Figure 12 : Un .sdb personnalisé est déployé par création, validation et distribution sdbinst, et les mises à jour sont gérées par GUID.

Une base personnalisée installée est enregistrée comme un élément dans « Programmes et fonctionnalités (Applications installées) », donc vous pouvez aussi confirmer l’inventaire et la suppression depuis là. Quels PC ont quel .sdb est une information qui appartient au registre de gestion des actifs.

7. Les cas où cela ne fonctionne pas, et les limites

Les shims ne sont pas une balle d’argent. Par conception, ils ne fonctionnent pas dans les cas suivants.

• Problèmes en mode noyau. Un shim s’exécute à l’intérieur d’un processus en mode utilisateur, donc une incompatibilité de pilote de périphérique ne peut pas être corrigée. Si le pilote d’un ancien instrument de mesure, dongle USB ou imprimante ne prend pas en charge Windows 11, rien que vous appliquiez côté application ne le résoudra. Le code qui s’exécute dans le noyau, comme des parties d’un logiciel antivirus, est le même.³
• Applications 16 bits. Windows 64 bits ne prend pas en charge l’exécution d’applications 16 bits. Les handles ont 32 bits valides sous Windows 64 bits et ne peuvent pas être tronqués pour être passés à une application 16 bits, donc le démarrage échoue avec ERROR_BAD_EXE_FORMAT.⁸ Même quand l’application elle-même est 32 bits, il existe des packages de cette époque dont le stub d’installateur est 16 bits, et ils se présentent comme « l’application tournerait, mais on ne peut pas l’installer ».
• Accès matériel direct. Les applications industrielles qui supposent pouvoir toucher directement les ports d’E/S ou la mémoire physique n’y sont pas autorisées depuis le mode utilisateur sur Windows moderne, et cela dépasse le périmètre qu’un shim peut usurper.
• Contourner les mécanismes de sécurité. Parce qu’un shim s’exécute sous les mêmes contraintes de sécurité que l’application, il ne peut pas rendre possible « quelque chose que vous ne pouvez pas faire par manque de privilège ». ForceAdminAccess et WRPMitigation ne font qu’usurper le succès d’un contrôle ou d’une écriture pour que l’application puisse continuer ; ils ne réécrivent pas réellement une ressource protégée.³⁴
• Applications qui vérifient leur propre intégrité. Les applications avec une ancienne protection contre la copie ou une détection d’altération peuvent traiter le hook d’API lui-même comme anormal et cesser de fonctionner.

flowchart TB
    accTitle: Cas où un shim ne fonctionne pas
    accDescr: Un shim s'exécute à l'intérieur d'un processus en mode utilisateur, donc il ne fonctionne pas sur les problèmes de pilotes en mode noyau, les applications 16 bits, l'accès matériel direct, ni le contournement des mécanismes de sécurité
    shim["Shim (s'exécute en mode utilisateur)"] -->|Ne fonctionne pas| drv["Pilote noyau"]
    shim -->|Ne fonctionne pas| b16["Application 16 bits"]
    shim -->|Ne fonctionne pas| hw["Accès matériel direct"]
    shim -->|Ne fonctionne pas| sec["Contournement des mécanismes de sécurité"]
    b16 -.-> fmt["En 64 bits, le démarrage lui-même échoue"]
    sec -.-> fake["Usurpe seulement le succès pour que l'application continue"]

Figure 13 : Un shim est en mode utilisateur seulement et n’atteint pas le noyau, les applications 16 bits, l’accès matériel direct, ni le contournement de sécurité.

Et la limite essentielle commune à chaque shim est qu’il est un palliatif. Un shim est un mensonge taillé pour un usage particulier d’une API particulière, et si l’implémentation côté système change, l’hypothèse s’effondre. Les shims fournis par Microsoft sont maintenus comme partie de Windows via Windows Update,³ mais s’occuper des mensonges que vous avez appliqués avec une base personnalisée est le travail de votre organisation. Budgétez, comme coût de la prolongation, une opération qui valide la « liste des applications maintenues en vie par des shims » à chaque mise à jour de fonctionnalités.

flowchart TB
    accTitle: Les shims comme palliatif, et qui est responsable de leur maintenance
    accDescr: Un shim est un mensonge taillé pour un usage d'API particulier et l'hypothèse s'effondre si l'implémentation côté système change ; les shims Microsoft sont maintenus via Windows Update, mais s'occuper des mensonges appliqués avec une base personnalisée est le travail de l'organisation, et la validation à chaque mise à jour de fonctionnalités est un coût de prolongation
    shim["Shim = un mensonge palliatif"] --> break["Un changement du système le casse"]
    ms["Shims Microsoft"] --> wu["Via Windows Update"]
    own["Mensonges de la base personnalisée"] --> self["L'organisation s'en occupe"]
    self --> cost["Valider à chaque mise à jour est le coût de prolongation"]

Figure 14 : La responsabilité de maintenir le mensonge du shim se partage entre l’ensemble fourni par Microsoft et l’ensemble personnalisé de votre organisation.

8. La valeur pratique de RunAsInvoker — faire taire seulement la demande d’élévation

Parmi les shims, celui qui revient le plus dans le travail informatique quotidien est RunAsInvoker.

Certaines anciennes applications métier déclarent requireAdministrator dans le manifeste, ou sont mal détectées comme installateur d’après le nom ou le contenu de l’EXE, et demandent une élévation UAC à chaque démarrage. Beaucoup d’entre elles, toutefois, ne demandent l’administrateur que par inertie de l’ère XP et n’utilisent pas réellement les privilèges d’administrateur. Appliquer le shim RunAsInvoker écrase à la fois la détection d’installateur et le manifeste, et l’application démarre avec le jeton hérité du processus parent (= privilèges d’utilisateur standard).⁹

flowchart TB
    accTitle: Comment RunAsInvoker supprime une demande d'élévation
    accDescr: Une déclaration requireAdministrator dans le manifeste ou une mauvaise détection comme installateur provoque une demande d'élévation UAC au démarrage, mais appliquer RunAsInvoker écrase les deux et l'application démarre avec le jeton hérité du parent
    manifest["Déclaration requireAdministrator"] --> shim{"RunAsInvoker appliqué ?"}
    detect["Mal détectée comme installateur"] --> shim
    shim -->|Non| uac["Demande d'élévation UAC à chaque démarrage"]
    shim -->|Oui| token["Démarre avec le jeton du parent"]
    token -.-> limit["Le travail qui a vraiment besoin de l'administrateur échoue dans l'application"]

Figure 15 : RunAsInvoker n’écrase que la cause de la demande d’élévation ; les privilèges n’augmentent pas.

Même sans construire un .sdb dans Compatibility Administrator, vous pouvez appliquer temporairement la même couche avec la variable d’environnement __COMPAT_LAYER.

:: Apply RunAsInvoker to child processes started from this command prompt
set __COMPAT_LAYER=RunAsInvoker
start "" "C:\LegacyApp\Gyomu.exe"

# In PowerShell
$env:__COMPAT_LAYER = 'RunAsInvoker'
Start-Process 'C:\LegacyApp\Gyomu.exe'

Si vous transformez ces deux lignes en un fichier batch et le distribuez comme raccourci, vous pouvez éviter de remettre des privilèges d’administrateur local aux utilisateurs standard, et l’informatique n’est plus appelée à chaque fois pour un mot de passe UAC. C’est une technique de compatibilité qui durcit la défense, en ligne avec le moindre privilège.

flowchart TB
    accTitle: L'effet de distribuer un batch RunAsInvoker
    accDescr: Distribuer comme raccourci un batch de deux lignes qui règle RunAsInvoker permet d'éviter de remettre des privilèges d'administrateur local aux utilisateurs standard, l'informatique n'est plus appelée pour un mot de passe UAC, et l'exploitation suit le moindre privilège
    bat["Distribuer un batch de deux lignes"] --> noadmin["On peut éviter de remettre des privilèges d'administrateur"]
    bat --> nocall["L'informatique n'est pas appelée pour UAC"]
    noadmin --> lp["Une exploitation qui suit le moindre privilège"]
    nocall --> lp

Figure 16 : Distribuer un batch à lui seul peut réduire à la fois la remise de privilèges d’administrateur et les appels pour UAC.

Les précautions aussi, clairement.

• Les privilèges n’augmentent pas. Un travail qui a vraiment besoin des privilèges d’administrateur (écritures dans HKLM, mises à jour sous Program Files, etc.) produira une erreur dans l’application, ou, si les conditions sont réunies, sera redirigé vers le VirtualStore par la virtualisation UAC.¹⁰ Si l’enregistrement des réglages « a soudain cessé de fonctionner », suspectez la virtualisation.
• La méthode par variable d’environnement ne s’applique qu’aux processus enfants. Pour une application permanente, un réglage direct dans la clé Layers (RUNASINVOKER n’a pas d’élément dans l’onglet) ou une distribution via un .sdb est fiable.
• Corriger la destination d’écriture est le vrai chemin. Si vous pouvez changer l’application, déplacez le fichier de réglages sous %APPDATA% et déclarez asInvoker dans le manifeste — c’est la forme correcte.⁹

flowchart TB
    accTitle: Application temporaire et permanente de RunAsInvoker
    accDescr: L'application via la variable d'environnement COMPAT_LAYER ne s'applique qu'aux processus enfants démarrés depuis là ; pour une application permanente utilisez un réglage direct dans la clé Layers ou une distribution via un .sdb
    env["Régler via une variable d'environnement"] --> child["Ne s'applique qu'aux processus enfants"]
    child -.-> tmp["Application temporaire"]
    layers["Régler directement dans la clé Layers"] --> always["Application permanente"]
    sdb["Distribuer via un sdb"] --> always

Figure 17 : La méthode par variable d’environnement est une application temporaire limitée aux processus enfants ; la rendre permanente se fait avec la clé Layers ou un .sdb.

9. Décider entre prolongation et migration — quoi penser après que cela marche sous un shim

Le moment où cela marche sous un shim est un soulagement, mais il est important de ne pas arrêter de penser là. Marcher sous un shim signifie seulement que cela a coincé avec un réceptacle que Windows avait préparé. Les axes de la décision, en tableau.

Si vous décidez la prolongation, mettez les trois points suivants dans l’exploitation comme un ensemble.

1. Consigner. Quel EXE, quel shim/couche, et pourquoi. Laissez la valeur de la clé Layers et le GUID du .sdb dans un registre. « Personne ne sait pourquoi ça marche » est la plus grande dette que vous laissez à la personne suivante. C’est le même état d’esprit de préservation que dans « Quand vous héritez d’un système sans code source ni documentation — Procédure pratique pour l’exploiter et le maintenir sans interruption ».
2. Valider. Incluez le démarrage et les opérations principales des applications maintenues en vie par des shims dans les éléments de validation d’une mise à jour de fonctionnalités Windows. Reliez-le aussi au plan de remplacement du système (La solution pragmatique après la fin du support de Windows 10 — Tableau de décision ESU, LTSC et renouvellement de matériel).
3. Fixer une échéance. Décidez la fin de la prolongation — « jusqu’au prochain renouvellement du système cœur », « jusqu’en mars 2028 » — et menez en parallèle la réflexion sur la migration.

flowchart TB
    accTitle: L'ensemble d'exploitation en trois points une fois la prolongation décidée
    accDescr: Consignez dans un registre quel shim la fait tourner, validez le comportement des applications maintenues en vie par des shims à chaque mise à jour de fonctionnalités, fixez une échéance pour la fin de la prolongation, et menez en parallèle la réflexion sur la migration
    decide["Décider la prolongation"] --> rec["Consigner : quel shim la fait tourner, dans un registre"]
    rec --> verify["Valider : confirmer le comportement à chaque mise à jour de fonctionnalités"]
    verify --> deadline["Échéance : décider la fin de la prolongation"]
    deadline --> mig["Mener en parallèle la réflexion sur la migration"]

Figure 18 : La prolongation s’exploite comme un ensemble de trois points — consigner, valider et échéance — y compris mener en parallèle la réflexion sur la migration.

Côté migration, les options standard changent avec la technologie de l’application. Pour VB6, le choix à trois voies de la réécriture complète, de la conversion automatique et de la migration par étapes organisé dans « Jusqu’à quand les applications VB6 continueront-elles de fonctionner ? — état du support du runtime et démarche concrète vers une migration .NET » ; pour une dépendance ActiveX/OCX, le tableau de décision conserver / envelopper / remplacer dans « Comment traiter ActiveX / OCX aujourd’hui - Tableau de décision conserver / envelopper / remplacer ». La façon saine de positionner un shim est comme un achat de temps pour que la période de réflexion et de préparation de ce projet de migration puisse se dérouler en sécurité.

flowchart TB
    accTitle: Options côté migration, et où se situe un shim
    accDescr: Les options de migration standard changent avec la technologie de l'application ; pour VB6 le choix à trois voies est réécriture, conversion automatique et migration par étapes, pour une dépendance ActiveX le tableau conserver / envelopper / remplacer s'applique, et un shim est positionné comme un achat de temps pour la réflexion et la préparation du projet de migration
    tech{"Quelle est la technologie de l'application ?"} -->|VB6| vb["Réécriture, conversion automatique ou migration par étapes"]
    tech -->|Dépendance ActiveX| ax["Conserver, envelopper ou remplacer"]
    shim["Prolongation via un shim"] -.->|Achète du temps pour la réflexion et la préparation| tech

Figure 19 : Les options de migration standard se décident par la technologie de l’application, et un shim est positionné comme un achat de temps pour cette réflexion.

10. Synthèse

• La véritable identité du mode de compatibilité, ce sont les shims. Les réglages de l’onglet Compatibilité sont écrits dans la clé AppCompatFlags\Layers et injectés dans le processus au démarrage comme un hook d’API via la réécriture de l’IAT.
• Les shims sont une collection de « mensonges qui renvoient la réponse que l’ancienne application attend ». Des shims prêts à l’emploi pour l’usurpation de version, le remappage de chemins, l’usurpation du registre, l’usurpation des contrôles d’administrateur et analogues sont fournis.
• Windows lui-même utilise un grand nombre de shims par défaut, et le PCA peut les appliquer automatiquement. S’appuyer sur le mode de compatibilité est en soi un choix raisonnable qui chevauche un mécanisme officiel du système.
• Il y a une limite de principe — mode utilisateur seulement et pas de contournement de sécurité — et les pilotes noyau, les applications 16 bits et l’accès matériel direct ne peuvent pas être sauvés.
• Le déploiement organisationnel consiste à construire un .sdb personnalisé dans Compatibility Administrator (Windows ADK) et à le distribuer avec sdbinst. Choisir l’édition 32 bits/64 bits, tester avec le compte utilisateur réel et gérer les mises à jour par GUID sont les points pratiques.
• Les applications qui « exigent l’administrateur mais n’en ont pas réellement besoin » peuvent être ramenées aux privilèges standard avec __COMPAT_LAYER=RunAsInvoker. C’est une technique défensive qui fait taire la demande d’élévation plutôt que de distribuer des privilèges.
• Tourner sous un shim est une prolongation, pas une solution. Consigner ce qui la fait tourner, valider à chaque mise à jour de fonctionnalités, et fixer une échéance pour que la migration avance en parallèle — cet ensemble de trois points est inclus dans la décision de « s’appuyer sur le mode de compatibilité ».

La prochaine fois qu’une ancienne application se met à fonctionner après une case de mode de compatibilité, reposez la question. « Grâce à quel mensonge cette application tourne-t-elle ? Combien de temps ce mensonge restera-t-il valable ? » Si vous pouvez répondre, la prolongation est une stratégie respectable.

Articles connexes

• Redirection et virtualisation du registre 32 bits/64 bits — Wow6432Node et le problème de la « valeur écrite qui n’existe pas »
• Jusqu’à quand les applications VB6 continueront-elles de fonctionner ? — état du support du runtime et démarche concrète vers une migration .NET
• Comment traiter ActiveX / OCX aujourd’hui - Tableau de décision conserver / envelopper / remplacer
• La solution pragmatique après la fin du support de Windows 10 — Tableau de décision ESU, LTSC et renouvellement de matériel
• Quand vous héritez d’un système sans code source ni documentation — Procédure pratique pour l’exploiter et le maintenir sans interruption
• L’intégration au shell Windows aujourd’hui — menus contextuels, associations de fichiers, et ce qui a changé dans Windows 11

Domaines de conseil associés

KomuraSoft LLC prend en charge l’investigation du comportement d’anciennes applications métier sans code source et la conception de leur prolongation (sélection de shims et de modes de compatibilité, construction et déploiement d’un .sdb personnalisé), la validation de compatibilité des applications existantes pour une migration Windows 11, et la planification d’une réécriture ou d’une migration qui avance en parallèle de la prolongation. Une consultation dès l’étape « ça s’est mis à marcher en mode de compatibilité, mais est-il raisonnable de le laisser ainsi ? » convient.

• Réutilisation et migration d’actifs existants
• Développement d’applications Windows
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Si une application s'est mise à fonctionner après avoir coché le mode de compatibilité, puis-je continuer à l'utiliser ainsi ?

Pour maintenir l'activité à court terme, oui. Le mode de compatibilité est un hook d'API en mode utilisateur appelé shim, un mécanisme officiel fourni par le système. Un shim reste toutefois un palliatif pour faire tourner une application sans la corriger, et une autre mise à jour du système peut changer les hypothèses et la casser à nouveau. Consignez dans un registre le fait qu'elle tourne en mode de compatibilité, et traitez cet enregistrement comme un élément de la décision de réécrire l'application ou de prolonger volontairement sa vie.

Que fait réellement la case du mode de compatibilité ?

Lorsque vous enregistrez les paramètres de l'onglet Compatibilité de la boîte de dialogue Propriétés, Windows écrit le chemin de l'EXE cible et une valeur telle que « WINXPSP3 » ou « HIGHDPIAWARE » sous la clé HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers. Au prochain démarrage de cet EXE, le chargeur Windows lit la valeur et applique au processus la couche de compatibilité correspondante (un ensemble de shims). Le mode Windows XP, par exemple, usurpe la version du système en renvoyant une ancienne valeur depuis les API de requête de version. Le système lui-même n'est pas modifié ; seul ce processus se voit présenter un Windows plus ancien.

Peut-on exécuter des applications de l'ère 16 bits en mode de compatibilité sur Windows 64 bits ?

Non. Windows 64 bits exécute les applications 32 bits via WOW64, mais ne prend pas en charge l'exécution d'applications 16 bits ; une tentative de démarrage échoue avec ERROR_BAD_EXE_FORMAT. C'est une limite architecturale qu'un shim ne peut pas contourner. Les anciens packages dont le stub d'installateur est 16 bits échouent pour la même raison. S'il les faut vraiment, il faut regarder hors du mode de compatibilité — par exemple une machine virtuelle qui inclut Windows 32 bits.

Peut-on exécuter sous un compte utilisateur standard une application qui « ne démarre que si on l'exécute en tant qu'administrateur » ?

RunAsInvoker mérite d'être essayé. Si vous exécutez set __COMPAT_LAYER=RunAsInvoker à l'invite de commandes puis lancez l'application, les demandes d'élévation provenant d'un manifeste requireAdministrator ou de la détection d'installateur sont supprimées, et l'application démarre avec les mêmes privilèges (utilisateur standard) que l'appelant. Pour une application qui ne fait que demander des droits d'administrateur sans les utiliser vraiment, cela peut à lui seul retirer l'élévation de l'exploitation quotidienne. Les privilèges n'augmentent pas, donc un travail qui a vraiment besoin des droits d'administrateur échouera dans l'application. Ne l'adoptez qu'après avoir vérifié le comportement.

Où obtenir Compatibility Administrator ?

Il est inclus dans le Windows ADK (Windows Assessment and Deployment Kit). Téléchargez l'ADK depuis le site de Microsoft et, à l'installation, sélectionnez les fonctionnalités Application Compatibility Tools. Les éditions 32 bits et 64 bits sont installées ; il faut utiliser l'édition 32 bits pour les applications 32 bits et l'édition 64 bits pour les applications 64 bits. Appliquez une base de compatibilité personnalisée (.sdb) en exécutant la commande sdbinst sur chaque PC.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.