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

« Une application métier vieille de dix ans, dont le code source n’existe plus, ne démarre pas sur un nouveau PC Windows 11. Pourtant, en choisissant « Windows XP » dans l’onglet Compatibilité, elle tourne. Peut-on continuer ainsi ? » Les équipes qui ont la charge d’anciennes applications métier posent ce type de question.

Le mode de compatibilité n’est pas une fonction qui ramène l’OS tout entier à un ancien Windows. C’est un mécanisme qui, pour cette application seulement, complète le comportement attendu d’un ancien Windows. Au centre se trouvent de petites corrections de compatibilité qui s’intercalent entre l’application et l’API Windows : les shims.¹

Cet article s’adresse aux responsables informatiques des PME et aux développeurs d’applications Windows. Il organise le sujet dans l’ordre ce que l’on peut corriger → pourquoi cela tourne → comment appliquer et distribuer → comment décider entre prolongation et migration. À partir des sources primaires de Microsoft Learn, on vérifie ce qui se passe au-delà de la case à cocher.

1. D’abord la conclusion ── le mode de compatibilité est utilisable. Mais on le gère comme une prolongation

Continuer l’activité à court terme en mode de compatibilité est, en soi, un choix raisonnable qui utilise un mécanisme que Windows fournit officiellement. Windows lui-même applique des corrections de compatibilité aux applications connues.¹ L’application n’a toutefois pas été corrigée. L’objectif réel est, au bout du compte, de la corriger pour qu’elle tourne sans shim.

Pour décider de l’utiliser, on s’y retrouve en jugeant dans l’ordre suivant.

En particulier, « renvoyer un succès au contrôle « est-ce un administrateur ? » » et « donner des privilèges d’administrateur » sont deux choses distinctes. Un shim subit les mêmes contraintes de sécurité que l’application et ne contourne pas la protection de l’OS.¹² RunAsInvoker aussi ne fait que supprimer la demande d’élévation et démarrer avec les mêmes privilèges que l’appelant ; ce n’est pas une fonction qui augmente les privilèges.³

Comprendre le mécanisme permet de passer d’une prolongation « on n’y touche pas parce qu’on ne sait pas pourquoi cela tourne » à une prolongation où l’on peut expliquer jusqu’où l’on peut s’y fier, dans quelles conditions cela casse, et quand réécrire.

flowchart TB
    accTitle: Comprendre le mécanisme change la qualité de la prolongation
    accDescr: Utiliser le mode de compatibilité sans en comprendre le mécanisme mène à une prolongation instable que l'on n'ose pas toucher ; le comprendre permet de juger, avec des arguments, jusqu'où l'on peut s'y fier, ce qui le ferait casser, et quand réécrire
    unknown["Utiliser sans comprendre le mécanisme"] --> fear["Prolongation instable que l'on n'ose pas toucher"]
    known["Utiliser en comprenant le mécanisme"] --> judge["Jugement fondé"]
    judge -.-> j1["Jusqu'où peut-on s'y fier"]
    judge -.-> j2["Qu'est-ce qui le ferait casser"]
    judge -.-> j3["Quand faut-il réécrire"]

Figure 1 : Même prolongation, mais la qualité change entre l’inquiétude sans compréhension et un jugement fondé sur le mécanisme.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (16 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Premier triage ── un problème qu’un shim peut corriger ?

2.1. Ce que l’on peut corriger, ce sont les problèmes côté application en mode utilisateur

Ce qu’un shim peut faire reste dans le périmètre que l’on pourrait aussi corriger en corrigeant le code de l’application. C’est un moyen de substitution quand le code source n’existe pas, que le support du fournisseur est terminé, ou que l’on ne peut pas corriger tout de suite, et ce n’est pas plus puissant qu’une correction du code.¹

Par exemple, refuser de démarrer d’après la version de l’OS, supposer d’anciens emplacements d’écriture, ou demander des privilèges d’administrateur dont on n’a pas vraiment besoin, sont des problèmes à examiner. Les shims concrets sont confirmés au chapitre 5.

2.2. Les cas où continuer à essayer des paramètres ne résout rien

Les problèmes suivants exigent une autre mesure que le mode de compatibilité.

Les problèmes en mode noyau et les contraintes de sécurité viennent du lieu où le shim s’exécute.¹ ForceAdminAccess et WRPMitigation ne font que usurper un succès du contrôle ou de l’écriture pour faire avancer l’application ; ils ne réécrivent pas vraiment une ressource protégée.²

Pour un problème 16 bits, vérifiez non seulement l’application elle-même, mais aussi l’installateur. Même si le corps est 32 bits, un ancien package dont seule la partie de lancement (le stub) est 16 bits donne « l’application tourne, mais on ne peut pas l’installer ». Sur Windows 64 bits, les handles ont 32 bits utiles et ne peuvent pas être tronqués en 16 bits, entre autres raisons, donc les applications 16 bits ne sont pas prises en charge et le démarrage échoue avec ERROR_BAD_EXE_FORMAT.⁴

flowchart TB
    accTitle: Cas où un shim n'a pas d'effet
    accDescr: Un shim tourne dans le processus en mode utilisateur, donc il n'a pas d'effet sur un problème de pilote en mode noyau, une application 16 bits, un accès direct au matériel, ni le contournement d'un mécanisme de sécurité
    shim["Shim (s'exécute en mode utilisateur)"] -->|n'a pas d'effet| drv["Pilote noyau"]
    shim -->|n'a pas d'effet| b16["Application 16 bits"]
    shim -->|n'a pas d'effet| hw["Accès direct au matériel"]
    shim -->|n'a pas d'effet| sec["Contournement d'un mécanisme de sécurité"]
    b16 -.-> fmt["Sur 64 bits, le démarrage lui-même échoue"]
    sec -.-> fake["On ne fait qu'usurper un succès pour avancer"]

Figure 2 : Un shim est limité au mode utilisateur ; il n’atteint pas le noyau, le 16 bits, l’accès direct au matériel ni le contournement de la sécurité.

De plus, une application qui a un contrôle d’intégrité, copie protégée ancienne ou détection de falsification, peut considérer le hook d’API lui-même comme une anomalie. Ce n’est pas parce qu’une application est en mode utilisateur qu’un shim la sauvera forcément.

3. Distinguer des fonctions proches ── shim, virtualisation UAC, WOW64, virtualisation PPP

Quand « une ancienne application s’est mise à tourner », ce n’est pas forcément un shim qui travaille. On sépare les couches de rétrocompatibilité que Windows possède. En pratique, plusieurs mécanismes se combinent parfois.

3.1. Virtualisation UAC : détourner l’écriture vers un emplacement par utilisateur

La virtualisation UAC est une mesure transitoire qui s’applique aux processus interactifs 32 bits sans manifeste. Microsoft elle-même la positionne comme une technique provisoire qu’elle a l’intention de retirer des Windows futurs.⁵ WOW64, qui fait tourner une application 32 bits, et la virtualisation UAC, qui transfère l’écriture vers un emplacement par utilisateur, sont des mécanismes distincts.

La redirection vers Wow6432Node et les effets collatéraux de VirtualStore, ainsi que les parades, sont traités dans Redirection et virtualisation du registre 32 bits/64 bits. Cet article se limite à ce qui est nécessaire pour distinguer un shim.

flowchart TB
    accTitle: Place de la virtualisation UAC
    accDescr: La virtualisation UAC est une mesure transitoire qui s'applique aux processus interactifs 32 bits sans manifeste, transfère l'écriture vers un VirtualStore par utilisateur, et Microsoft elle-même la déclare technique provisoire destinée à être retirée des Windows futurs
    proc["Processus interactif 32 bits sans manifeste"] --> uacv["La virtualisation UAC s'applique"]
    uacv --> vs["Transfert vers un VirtualStore par utilisateur"]
    uacv -.-> tmp["Technique provisoire destinée à être retirée"]

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

3.2. Virtualisation PPP : étirer un ancien dessin

Une application qui n’a pas déclaré la prise en charge PPP est traitée comme dessinant à 96 PPP (100 %). Windows étire ce bitmap, donc l’affichage est flou sur un moniteur à PPP élevé. « Remplacer les paramètres PPP élevés » de l’onglet Compatibilité est le commutateur de ce comportement de virtualisation.⁶

flowchart TB
    accTitle: Fonctionnement de la virtualisation PPP
    accDescr: Une application qui n'a pas déclaré la prise en charge PPP est traitée comme dessinant à 96 PPP, Windows étire le bitmap pour l'afficher donc elle paraît floue sur un moniteur à PPP élevé, et le remplacement des paramètres PPP élevés de l'onglet Compatibilité commute ce comportement de virtualisation
    app["Application qui ne déclare pas la prise en charge PPP"] --> treat["Traitée comme dessinant à 96 PPP"]
    treat --> stretch["Affichage en étirant le bitmap"]
    stretch --> blur["Floue sur un moniteur à PPP élevé"]
    tab["Remplacer les paramètres PPP élevés"] -.->|commute le comportement de virtualisation| treat

Figure 4 : Une application non compatible PPP est traitée à 96 PPP et étirée ; le remplacement de l’onglet Compatibilité est le commutateur de cette virtualisation.

4. Pourquoi le mode de compatibilité fait tourner ── le shim et l’application au démarrage

4.1. Remplacer la destination des appels d’API

Le chemin par lequel un exécutable Windows (format PE) appelle une API d’une DLL externe passe par la table d’adresses d’importation (IAT). Par exemple, un appel à GetVersionEx transfère le traitement à l’adresse écrite dans l’IAT.

Un shim, au chargement de l’application, réécrit cette entrée d’IAT vers l’adresse du code du shim. C’est un hook d’API. Les API obtenues dynamiquement par GetProcAddress sont aussi prises en charge en hookant GetProcAddress lui-même.¹

Le shim intercalé renvoie une ancienne version d’OS, redirige un accès fichier, et appelle au besoin la véritable API. Il montre à l’application « le comportement Windows qu’elle attend » et passe à l’OS un appel adapté au mécanisme actuel : un interprète, en quelque sorte.

flowchart TB
    accTitle: Chemin par lequel un shim s'intercale dans un appel d'API
    accDescr: L'appel d'API de l'application passe par l'IAT ; au chargement, l'entrée d'IAT est réécrite vers le shim, le shim s'intercale, usurpe la même réponse qu'un ancien Windows, puis appelle au besoin la véritable API
    app["Application"] -->|appel d'API| iat["Entrée IAT"]
    iat -->|réécriture vers le shim au chargement| shim["Shim (interprète)"]
    shim -->|au besoin| api["Véritable API Windows"]
    shim -.-> lie["Usurpe la même réponse qu'un ancien Windows"]
    gpa["Appel via GetProcAddress"] -.->|pris en charge par un hook| shim

Figure 5 : Un shim s’intercale entre l’application et l’API Windows. Ce qui est réécrit, c’est l’IAT côté application ; l’OS lui-même ne change pas.

Ce qui change, c’est le chemin d’appel côté application, pas l’OS lui-même. Un shim s’exécute sous les mêmes contraintes de sécurité que l’application, donc il n’est pas nécessaire d’assouplir les paramètres de sécurité de l’OS pour l’utiliser.¹

4.2. Le .sdb décide « quel shim appliquer à quel EXE »

La base de shims est un fichier binaire d’extension .sdb. Elle identifie l’exécutable par des attributs de rapprochement tels que le nom de fichier, la taille, la somme de contrôle et la version, et les rapproche au démarrage du processus. Les termes utilisés ici se distinguent comme suit.⁷

Ce n’est pas seulement les applications pour lesquelles l’utilisateur a défini le mode de compatibilité qui sont rapprochées. À chaque démarrage de processus, un rapprochement avec la base standard de l’OS a lieu. Windows embarque des milliers de corrections pour des applications connues ; le contenu se trouve sous %WINDIR%\AppPatch. Les corrections de compatibilité fournies par Microsoft sont livrées comme une partie de Windows et mises à jour par Windows Update.¹

flowchart TB
    accTitle: Rapprochement avec la base de shims au démarrage d'un processus
    accDescr: À chaque démarrage de processus, un rapprochement a lieu avec la base de shims ; s'il existe une inscription qui correspond aux attributs de rapprochement, une injection de shim par Appfix ou un affichage de message Apphelp a lieu, sinon le démarrage se fait tel quel
    start["Démarrage du processus"] --> db["Rapprochement avec la base de shims (.sdb)"]
    db -.-> attr["Rapprochement par nom de fichier, taille, etc."]
    db --> hit{"Inscription présente ?"}
    hit -->|Oui| appfix["Appfix (injecter un shim)"]
    hit -->|Oui| apphelp["Apphelp (afficher un message)"]
    hit -->|Non| plain["Démarrer tel quel"]
    layer["Couche de compatibilité (mode de compatibilité)"] -.->|ensemble de plusieurs shims et indicateurs| appfix

Figure 6 : Le rapprochement a lieu à chaque démarrage de processus, pas seulement pour les applications avec le mode de compatibilité.

Une couche de compatibilité inclut non seulement des hooks d’API, mais aussi des indicateurs au démarrage. Le RunAsInvoker du chapitre 7 n’intercepte pas d’API ; c’est une correction de compatibilité qui agit, comme indicateur du chargeur, sur le niveau d’exécution au démarrage.³

4.3. Le PCA peut aussi trouver un problème et l’appliquer

Même sans paramétrage manuel par un administrateur, le PCA (Program Compatibility Assistant, Assistant de compatibilité des programmes) peut appliquer des paramètres de compatibilité. Le PCA surveille l’exécution des applications et, s’il détecte des signes d’un problème connu, propose une correction ou, dans certains cas, l’applique automatiquement.⁸

Par exemple, une application qui plante en appelant du code dans une DLL déjà libérée se voit appliquer un mode de compatibilité tel que PINDLL, et une application qui échoue à écrire dans un fichier Windows protégé, WRPMITIGATION.⁸

flowchart TB
    accTitle: Flux par lequel le PCA applique automatiquement des paramètres de compatibilité
    accDescr: Le PCA surveille l'exécution des applications et, s'il détecte des signes d'un problème de compatibilité connu, propose à l'utilisateur d'appliquer une correction ou, dans certains cas, applique automatiquement des paramètres 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 -->|Réponse par proposition| suggest["Proposer d'appliquer une correction"]
    resp -->|Certains cas| auto["Appliquer automatiquement des paramètres de compatibilité"]
    sign -->|Non| none["Exécuter tel quel"]
    auto -.-> ex["Ex. : PINDLL ou WRPMITIGATION"]

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

Le phénomène « je n’ai aucun souvenir d’avoir paramétré, mais la case du mode de compatibilité était cochée » passe souvent par ce chemin. Ce n’est pas forcément une panne ou une mauvaise manipulation ; c’est aussi le résultat de Windows qui a répondu à un problème.

5. Choisir une correction d’après le symptôme ── shims représentatifs et détermination de version

5.1. Ce que les shims tout faits peuvent compléter

Parmi les shims tout faits que Microsoft publie, voici ceux que l’on utilise souvent pour prolonger une application métier.²

Ce que font beaucoup de shims, c’est renvoyer la réponse qu’une ancienne application attend. « L’espace disque va jusqu’à 2 Go », « l’OS est XP », « le contrôle administrateur réussit » : les postulats de l’époque où l’application a été écrite sont reproduits dans ce processus seulement. Comme on l’a vu au chapitre 2, usurper une réponse et changer réellement les privilèges ou les ressources sont deux choses distinctes.

5.2. La valeur de GetVersionEx change même sans choisir le mode de compatibilité

L’usurpation de version n’est pas seulement l’affaire d’un mode de compatibilité choisi à la main. Depuis Windows 8.1, la valeur renvoyée par GetVersionEx dépend du manifeste de l’application. S’il n’y a pas de déclaration <supportedOS> dans <compatibility>, même sur un Windows plus récent, c’est 6.2 équivalent à Windows 8 qui est renvoyé. S’il y a une déclaration, la valeur jusqu’à l’OS le plus élevé déclaré est renvoyée. Par exemple, une application qui a déclaré le GUID de Windows 8.1 reste 6.3 même sur Windows 11.⁹¹⁰

Ensuite, si un shim de la famille VersionLie est appliqué, c’est la version de l’OS choisi en mode de compatibilité qui est rapportée. Il faut regarder dans l’ordre la réponse par défaut du manifeste, puis le remplacement de cette réponse par un shim.⁹

flowchart TB
    accTitle: Comment se décide la version d'OS vue par l'application
    accDescr: La valeur renvoyée par GetVersionEx dépend de la présence d'une déclaration supportedOS dans le manifeste ; sans déclaration, 6.2 équivalent à Windows 8 est renvoyé ; avec déclaration, la valeur jusqu'à l'OS le plus élevé déclaré ; si un shim VersionLie est appliqué, la version de l'OS choisi en mode de compatibilité écrase
    q["Interrogation GetVersionEx"] --> m{"Déclaration supportedOS ?"}
    m -->|Non| v62["6.2 équivalent à Windows 8 est renvoyé"]
    m -->|Oui| decl["Valeur jusqu'à l'OS le plus élevé déclaré"]
    v62 --> lie{"Shim VersionLie appliqué ?"}
    decl --> lie
    lie -->|Oui| fake["Valeur de l'OS choisi en mode de compatibilité"]
    lie -->|Non| asis["La valeur telle quelle est renvoyée"]

Figure 8 : La version de Windows vue par l’application se décide en plusieurs étages, manifeste et shim.

Les lieux à vérifier se séparent donc selon le symptôme. Si une application maison juge Windows 11 comme Windows 8, on commence par vérifier la déclaration supportedOS. En revanche, si une ancienne application refuse de démarrer au seul contrôle de version, VersionLie mérite d’être essayé. Le comportement réel est souvent sans problème sur un OS plus récent, donc ce type a de bonnes chances de voir le refus de démarrage levé par un shim.

flowchart TB
    accTitle: Deux symptômes liés à la version et leurs parades
    accDescr: Si une application maison juge Windows 11 comme 8, on suspecte la déclaration supportedOS du manifeste ; une ancienne application qui refuse de démarrer au contrôle de version a de fortes chances d'être débloquée par un shim VersionLie
    sym1["Juge Windows 11 comme 8"] --> fix1["Suspecter la déclaration supportedOS"]
    sym2["Refuse de démarrer au contrôle de version"] --> fix2["Essayer de débloquer avec VersionLie"]
    fix2 -.-> why["Le comportement lui-même est souvent sans problème sur un OS plus récent"]

Figure 9 : Un jugement devenu ancien se traite par le manifeste ; un refus de démarrage, par VersionLie.

6. Confirmer d’abord sur une machine ── onglet Compatibilité et clé Layers

6.1. Voir où la case à cocher est enregistrée

Les paramètres enregistrés dans l’onglet Compatibilité des propriétés sont écrits dans la clé de registre AppCompatFlags\Layers. C’est aussi la destination des paramètres de compatibilité d’application DXGI.¹¹

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

Pour un EXE où l’on a défini « Windows XP (Service Pack 3) », « Exécuter ce programme en tant qu’administrateur » et « Remplacer les paramètres PPP élevés », on voit par exemple une valeur comme suit.

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

La correspondance représentative entre les éléments et les valeurs est la suivante. C’est un exemple sous Windows 11 ; les noms d’éléments et les valeurs peuvent changer selon la version de l’OS.

6.2. Distinguer l’utilisateur d’application et le moment d’application

Le côté HKCU n’est le paramètre que de cet utilisateur. Enregistrer depuis « Modifier les paramètres pour tous les utilisateurs » écrit dans la clé homonyme côté HKLM, et s’applique à tous les utilisateurs. Lors du kitage, confirmez de quel côté l’enregistrement est fait.

De plus, le paramètre s’applique au processus la prochaine fois que cet EXE démarre. Le chargeur lit la valeur enregistrée et applique la couche de compatibilité correspondante.

flowchart TB
    accTitle: Flux jusqu'à ce que le paramètre de l'onglet Compatibilité prenne effet
    accDescr: Le paramètre de l'onglet Compatibilité est enregistré comme chemin d'EXE et valeur dans la clé Layers de AppCompatFlags ; au prochain démarrage de cet EXE, le chargeur lit la valeur et applique au processus la couche de compatibilité correspondante
    tab["Paramétrer dans l'onglet Compatibilité"] --> reg["Enregistrer 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 n'est que pour cet utilisateur"]
    reg -.-> hklm["HKLM s'applique à tous les utilisateurs"]

Figure 10 : La réalité de la case à cocher est une écriture dans la clé Layers ; l’application a lieu au prochain démarrage.

6.3. Ne pas confondre mode de compatibilité et spécification d’élévation

RUNASADMIN cohabite dans la même clé Layers que WINXPSP3. Si l’on a l’impression que « en paramétrant le mode de compatibilité, l’élévation s’est aussi ajoutée ou a disparu », vérifier la valeur directement permet de séparer la spécification de couche de compatibilité et la spécification d’élévation.

L’onglet Compatibilité est l’entrée vers des couches tout faites représentatives. Le choix et la combinaison de shims individuels relèvent de Compatibility Administrator au chapitre 8. Avant cela, on examine RunAsInvoker, qui a souvent sa place dans l’exploitation quotidienne.

7. RunAsInvoker ── ne supprimer que les demandes d’élévation inutiles

7.1. Distinguer « demander un administrateur » et « avoir besoin de privilèges d’administrateur »

Certaines anciennes applications métier demandent une élévation UAC à chaque démarrage, par une spécification requireAdministrator du manifeste ou par une fausse détection d’installateur d’après le nom ou le contenu de l’EXE. Pourtant, beaucoup ne font que reprendre une demande héritée d’une conception de l’époque XP, sans réellement utiliser de privilèges d’administrateur.

RunAsInvoker écrase à la fois la détection d’installateur et le traitement du manifeste, et fait démarrer avec le jeton hérité du processus parent. Si l’appelant a des privilèges d’utilisateur standard, on reste à ces privilèges.³

flowchart TB
    accTitle: Comment RunAsInvoker supprime une demande d'élévation
    accDescr: Une déclaration requireAdministrator du manifeste ou une fausse détection d'installateur cause une demande d'élévation UAC au démarrage ; si RunAsInvoker est appliqué, les deux sont écrasés et le démarrage se fait avec le jeton hérité du processus parent
    manifest["Déclaration requireAdministrator"] --> shim{"RunAsInvoker appliqué ?"}
    detect["Fausse détection comme installateur"] --> shim
    shim -->|Non| uac["Demande d'élévation UAC à chaque démarrage"]
    shim -->|Oui| token["Démarrer avec le jeton du parent"]
    token -.-> limit["Un traitement qui exige un administrateur échoue dans l'application"]

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

7.2. Essayer temporairement avec une variable d’environnement

Sans créer de .sdb, on peut appliquer temporairement la même couche avec la variable d’environnement __COMPAT_LAYER. Voici un exemple qui s’applique aux processus enfants lancés depuis cette invite de commandes ou ce PowerShell.

:: Appliquer RunAsInvoker aux processus enfants lancés depuis cette invite
set __COMPAT_LAYER=RunAsInvoker
start "" "C:\LegacyApp\Gyomu.exe"

# Dans le cas de PowerShell
$env:__COMPAT_LAYER = 'RunAsInvoker'
Start-Process 'C:\LegacyApp\Gyomu.exe'

On adopte après avoir confirmé, avec les mêmes privilèges d’utilisateur standard que l’utilisateur réel, que les opérations nécessaires au métier tournent.² Pour une application qui n’a pas besoin de privilèges d’administrateur, distribuer la commande en fichier de commandes à la place d’un raccourci permet de réduire la distribution de privilèges d’administrateur local et les appels à l’informatique à chaque saisie de mot de passe UAC. C’est une technique de compatibilité dans le sens du principe du moindre privilège.

flowchart TB
    accTitle: Effet de la distribution d'un fichier de commandes RunAsInvoker
    accDescr: Distribuer à la place d'un raccourci un fichier de commandes de deux lignes qui définit RunAsInvoker évite de distribuer des privilèges d'administrateur local aux utilisateurs standard, évite que l'informatique soit appelée pour une saisie de mot de passe UAC, et mène à une exploitation alignée sur le principe du moindre privilège
    bat["Distribuer un fichier de commandes de deux lignes"] --> noadmin["On n'a plus à distribuer de privilèges d'administrateur"]
    bat --> nocall["L'informatique n'est plus appelée pour l'UAC"]
    noadmin --> lp["Exploitation alignée sur le principe du moindre privilège"]
    nocall --> lp

Figure 12 : La seule distribution d’un fichier de commandes réduit à la fois la distribution de privilèges d’administrateur et les appels liés à l’UAC.

7.3. Distinguer le périmètre d’effet, l’application permanente et la correction

RunAsInvoker n’augmente pas les privilèges. Une écriture vers HKLM ou une mise à jour sous Program Files qui a vraiment besoin de privilèges d’administrateur échoue dans l’application. Si les conditions sont réunies, la virtualisation UAC peut aussi transférer vers VirtualStore. Si l’enregistrement des paramètres semble « ne plus marcher », on suspecte la virtualisation.⁵

La méthode par variable d’environnement n’a d’effet que sur les processus enfants lancés en héritant de cet environnement. Pour une application permanente, on utilise un paramétrage direct de la clé Layers ou la distribution d’un .sdb. Il n’y a pas d’élément RUNASINVOKER dans l’onglet Compatibilité.

flowchart TB
    accTitle: Application temporaire et permanente de RunAsInvoker
    accDescr: L'application par la variable d'environnement COMPAT_LAYER n'a d'effet que sur les processus enfants lancés depuis là ; pour appliquer de façon permanente, on utilise un paramétrage direct de la clé Layers ou une distribution par .sdb
    env["Paramétrer par variable d'environnement"] --> child["N'a d'effet que sur les processus enfants"]
    child -.-> tmp["Application temporaire"]
    layers["Paramétrer directement la clé Layers"] --> always["Application permanente"]
    sdb["Distribuer par sdb"] --> always

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

Si l’on peut corriger l’application, plutôt que d’ajouter des paramètres de compatibilité, la correction véritable est de déplacer l’enregistrement des fichiers de paramètres sous %APPDATA% et de déclarer asInvoker dans le manifeste.³

8. Déployer dans l’organisation ── Compatibility Administrator et sdbinst

8.1. Aligner le 32 bits / 64 bits de l’application et de l’outil

Compatibility Administrator est inclus dans le Windows ADK (Windows Assessment and Deployment Kit).¹² Les éditions 32 bits et 64 bits sont installées ; on utilise l’édition 32 bits pour corriger une application 32 bits, l’édition 64 bits pour une application 64 bits.¹³

Une autre attention est de ne pas juger « c’est corrigé » en testant en tant qu’administrateur. En état élevé, la virtualisation UAC et la redirection ne s’appliquent pas comme prévu, et l’on peut mal juger le résultat. L’effet d’une correction se confirme avec le même compte et les mêmes privilèges que l’utilisateur réel.²

flowchart TB
    accTitle: Deux points d'attention à l'usage de Compatibility Administrator
    accDescr: Pour corriger une application 32 bits on utilise l'édition 32 bits, pour une application 64 bits l'édition 64 bits, et l'effet d'une correction se confirme non pas en état élevé mais avec le même compte et les mêmes privilèges que l'utilisateur réel
    app32["Application 32 bits"] --> tool32["Corriger avec l'édition 32 bits"]
    app64["Application 64 bits"] --> tool64["Corriger avec l'édition 64 bits"]
    elev["Tester en état élevé"] -.-> wrong["Risque de juger à tort que c'est corrigé"]
    user["Tester avec les mêmes privilèges que l'utilisateur réel"] --> ok["Confirmer correctement l'effet"]

Figure 14 : Le choix entre éditions 32 bits et 64 bits, et la confirmation avec les mêmes privilèges que l’utilisateur réel, sont les points d’entrée.

8.2. Essayer d’abord une couche, puis restreindre aux shims et à l’EXE cibles nécessaires

La création d’une base de compatibilité personnalisée avance dans l’ordre suivant.¹⁴

1. Dans le volet gauche, créer une nouvelle base sous « Custom Databases », puis choisir « Create New » → « Application Fix ».
2. Saisir le nom de l’application et du fournisseur, et spécifier le fichier EXE cible.
3. Choisir un mode de compatibilité (couche) tel que « Windows XP compatible », et essayer d’abord un ensemble de shims.
4. Au besoin, choisir des corrections de compatibilité individuelles. On peut restreindre à une configuration minimale, VersionLie seulement, CorrectFilePaths seulement, etc.
5. Confirmer les conditions de rapprochement, taille de fichier, somme de contrôle, version, etc., et enregistrer.

« Choisir le shim qui a de l’effet » et « ne le faire agir que sur le bon EXE » sont tous deux nécessaires. Le rapprochement suffit en général avec les conditions de base par défaut, mais il faut laisser une condition qui identifie la version de l’application. C’est pour ne pas continuer d’appliquer une ancienne correction à une nouvelle version après que le fournisseur a publié une version corrigée.¹⁴¹⁵

flowchart TB
    accTitle: Procédure pour créer une base de compatibilité personnalisée
    accDescr: Créer un Application Fix dans une nouvelle base, spécifier le nom de l'application et l'EXE cible, essayer un ensemble de mode de compatibilité, puis au besoin restreindre à des shims individuels, confirmer les conditions de rapprochement et enregistrer
    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["Au besoin, restreindre à des shims individuels"]
    single --> match["Confirmer les conditions de rapprochement et enregistrer"]
    match -.-> ver["Laisser une condition qui identifie la version"]

Figure 15 : Un Application Fix s’essaie d’abord avec un ensemble de mode de compatibilité, se restreint à une configuration minimale, et limite la cible par les conditions de rapprochement.

On essaie le .sdb créé sur une machine de validation, on confirme qu’il se comporte comme prévu, puis on passe à la distribution.

8.3. Appliquer et retirer avec sdbinst, et gérer les mises à jour par GUID

L’application sur chaque PC se fait en exécutant sdbinst.exe avec des privilèges d’administrateur. On peut non seulement installer, mais aussi désinstaller en spécifiant un fichier ou le GUID de la base.¹⁵

:: Installation (-q est un silencieux sans confirmation)
sdbinst -q "C:\Deploy\MyCorpFixes.sdb"

:: Désinstallation (spécification de fichier)
sdbinst -q -u "C:\Deploy\MyCorpFixes.sdb"

:: Désinstallation (spécification du GUID de la base)
sdbinst -q -u -g {GUID de la base}

Dans une organisation où les corrections de compatibilité se multiplient, plutôt que de faire porter un .sdb individuel à chaque installateur d’application, on recommande un mode de gestion centralisée, une base personnalisée pour l’entreprise ou par service. Il est plus facile de gérer en mettant à jour et redistribuant une base regroupée qu’en suivant de nombreuses bases d’une ligne.¹⁵

Une base personnalisée a un GUID unique. Installer une nouvelle version du même GUID remplace automatiquement l’ancienne version. La distribution se place sur un chemin existant exécutable avec des privilèges d’administrateur, package MSI ou script de démarrage.¹⁵

flowchart TB
    accTitle: Flux de la création d'un .sdb personnalisé jusqu'à la distribution
    accDescr: Créer une base de compatibilité personnalisée avec Compatibility Administrator, tester sur une machine de validation, appliquer à chaque PC avec sdbinst ; à la mise à jour, installer une nouvelle version du même GUID remplace automatiquement l'ancienne version
    make["Créer avec Compatibility Administrator"] --> test["Tester sur une machine de validation"]
    test --> deploy["Appliquer à chaque PC avec sdbinst"]
    deploy --> update["Installer une nouvelle version du même GUID"]
    update -.-> replace["L'ancienne version est remplacée automatiquement"]
    deploy -.-> inv["Enregistré dans Programmes et fonctionnalités"]

Figure 16 : Un .sdb personnalisé se déploie selon le flux création, validation, distribution sdbinst, et les mises à jour se gèrent par GUID.

Une base personnalisée installée s’enregistre aussi dans « Programmes et fonctionnalités (applications installées) », ce qui sert à l’inventaire et à la confirmation de suppression. On consigne aussi dans le registre de gestion des actifs quel .sdb a été mis sur quel PC.

9. Décider après que cela tourne ── maintenance de la prolongation et échéance de migration

9.1. Distinguer les corrections fournies par l’OS et le jugement d’application de sa propre organisation

Même si un shim fait tourner, le problème de l’application lui-même n’a pas été corrigé. Un shim est un palliatif adapté à un usage particulier d’API, et si l’implémentation de l’OS change, le postulat peut s’effondrer.

Les shims fournis par Microsoft eux-mêmes sont maintenus par Windows Update comme une partie de Windows.¹ En revanche, gérer ce que l’on a appliqué dans une base personnalisée, et si cette combinaison permet de continuer l’activité, revient à sa propre organisation. Incluez dans le coût de la prolongation jusqu’à la validation à chaque mise à jour de fonctionnalités.

flowchart TB
    accTitle: Le shim comme palliatif et la responsabilité de maintenance
    accDescr: Un shim est un mensonge adapté à un usage particulier d'API, et si l'implémentation côté OS change le postulat s'effondre ; les shims fournis par Microsoft sont maintenus par Windows Update, mais s'occuper du mensonge appliqué dans une base personnalisée revient à sa propre organisation, et la validation à chaque mise à jour de fonctionnalités devient un coût de prolongation
    shim["Un shim est un mensonge palliatif"] --> break["Si l'implémentation de l'OS change, le postulat s'effondre"]
    ms["Shims fournis par Microsoft"] --> wu["Maintenus par Windows Update"]
    own["Mensonge d'une base personnalisée"] --> self["S'en occuper revient à sa propre organisation"]
    self --> cost["La validation à chaque mise à jour de fonctionnalités est un coût de prolongation"]

Figure 17 : La responsabilité de maintenance de ce « mensonge » qu’est un shim se sépare entre la part fournie par Microsoft et la part personnalisée de sa propre organisation.

9.2. Juger d’après la durée d’utilisation restante, la profondeur de dépendance et le dispositif de validation

Il est important de ne pas décider d’une utilisation de long terme sur le seul fait que « cela a tourné en mode de compatibilité ». Qu’un shim fasse tourner signifie que l’on est entré dans le filet que Windows a préparé. On juge en rapprochant les axes suivants.

9.3. Si l’on prolonge, réunir enregistrement, validation et échéance

1. Enregistrer. On consigne quel shim ou quelle couche a été appliqué à quel EXE, et pourquoi. On met aussi dans le registre la valeur de la clé Layers et le GUID du .sdb. Ne pas transmettre au suivant un état « personne ne sait pourquoi cela tourne » est la même idée de préservation que dans Quand vous héritez d’un système sans code source ni documentation.
2. Valider. À chaque mise à jour de fonctionnalités de Windows, on confirme le démarrage et les opérations principales des applications en prolongation. On le fait aussi en lien avec le plan de remplacement d’OS traité dans La solution pragmatique après la fin du support de Windows 10.
3. Fixer une échéance. On décide la fin de la prolongation, « jusqu’au prochain renouvellement du système de base », « jusqu’en mars 2028 », et on fait avancer en parallèle l’examen de la migration.

flowchart TB
    accTitle: Trio d'exploitation une fois la prolongation décidée
    accDescr: Enregistrer dans un registre avec quel shim cela tourne, valider le comportement des applications en prolongation par shim à chaque mise à jour de fonctionnalités, fixer l'échéance de la prolongation et faire avancer en parallèle l'examen de la migration
    decide["Décider de prolonger"] --> rec["Enregistrer : dans le registre, avec quel shim cela tourne"]
    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["Faire avancer en parallèle l'examen de la migration"]

Figure 18 : Une prolongation s’exploite avec le trio enregistrement, validation, échéance, jusqu’à l’examen de migration en parallèle.

9.4. Un shim sert à gagner le temps d’examen et de préparation de la migration

Les options de migration changent selon la technique de l’application. Si c’est du VB6, le point de départ est le triple choix réécriture complète, conversion automatique, migration par étapes, organisé dans Jusqu’à quand les applications VB6 continueront-elles de fonctionner ?. Si cela dépend d’ActiveX/OCX, le tableau de décision « conserver, envelopper, remplacer » de Comment traiter ActiveX / OCX aujourd’hui s’utilise.

Positionner un shim comme un moyen de gagner en sécurité le temps d’examen et de préparation d’un tel projet de migration est sain.

flowchart TB
    accTitle: Options côté migration et place du shim
    accDescr: Les recettes de migration changent selon la technique de l'application ; si c'est du VB6, le triple choix réécriture, conversion automatique, migration par étapes ; si cela dépend d'ActiveX, le tableau conserver, envelopper, remplacer ; un shim se positionne comme un gain de temps qui gagne en sécurité le temps d'examen et de préparation du projet de migration
    tech{"Quelle est la technique de l'application ?"} -->|VB6| vb["Réécriture, conversion automatique, migration par étapes"]
    tech -->|Dépendance ActiveX| ax["Conserver, envelopper, remplacer"]
    shim["Prolongation par shim"] -.->|gagner le temps d'examen et de préparation| tech

Figure 19 : Les recettes de migration se décident d’après la technique de l’application ; un shim se positionne comme un gain de temps pour cette période d’examen.

10. Résumé

Le mode de compatibilité est un mécanisme qui, pour l’application seulement, complète le comportement attendu d’un ancien Windows. Le shim au centre s’intercale dans les appels d’API par remplacement de l’IAT, entre autres, et complète la détermination de version et les destinations d’accès. Windows lui-même l’utilise aussi via la base par défaut et le PCA.

La réponse se pense dans l’ordre : d’abord trier si c’est dans le périmètre d’un shim, confirmer les paramètres nécessaires avec l’onglet Compatibilité ou RunAsInvoker, et pour un déploiement d’organisation, gérer avec Compatibility Administrator et sdbinst. Le choix d’outil 32 bits / 64 bits, la validation avec les privilèges de l’utilisateur réel, et la gestion de la cible et de la version par conditions de rapprochement et GUID sont les points pratiques.

Toutefois, c’est limité au mode utilisateur, et ce n’est pas un contournement des mécanismes de sécurité. Un pilote noyau, une application 16 bits sur Windows 64 bits, un accès direct au matériel exigent une autre mesure. RunAsInvoker aussi ne fait que supprimer une demande d’élévation inutile, sans augmenter les privilèges.

Après que cela tourne, enregistrer les paramètres, valider à chaque mise à jour de fonctionnalités, fixer une échéance et faire avancer la migration en parallèle. C’est jusqu’à là qu’un jugement de s’appuyer sur le mode de compatibilité va.

La prochaine fois qu’une ancienne application se met à tourner d’une seule case, reposez-vous la question. « Grâce à quel mensonge cette application tourne-t-elle ? Jusqu’à quand ce mensonge tiendra-t-il ? » Si l’on peut répondre, la prolongation est une stratégie tout à fait honorable.

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 ── menu contextuel, associations de fichiers et les changements de Windows 11

Domaines de conseil associés

KomuraSoft LLC prend en charge l’investigation du comportement et la conception de prolongation d’anciennes applications métier sans code source (choix de shims et de mode de compatibilité, création et déploiement d’un .sdb personnalisé), la validation de compatibilité des applications existantes à l’occasion d’une migration Windows 11, et l’élaboration d’un plan de réécriture et de migration en parallèle de la prolongation. Une consultation dès le stade « cela a tourné en mode de compatibilité, mais est-ce bien ainsi » convient tout à fait.

• Valorisation et migration des 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 comme paramètre de l'OS. Un shim reste toutefois un palliatif pour faire tourner une application sans la corriger, et une mise à jour de l'OS qui change les hypothèses peut 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ù peut-on se procurer Compatibility Administrator ?

Il est inclus dans le Windows ADK (Windows Assessment and Deployment Kit). Téléchargez l'ADK depuis le site Microsoft et, à l'installation, sélectionnez les fonctionnalités de type Application Compatibility Tools. Notez que les éditions 32 bits et 64 bits sont toutes deux installées, et qu'il faut utiliser l'édition 32 bits pour corriger une application 32 bits, l'édition 64 bits pour une application 64 bits. Une base de compatibilité personnalisée (.sdb) créée s'applique 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.