Wie die Anwendungskompatibilität unter Windows funktioniert — Kompatibilitätsmodus, Shims und Compatibility Administrator

„Eine zehn Jahre alte Geschäftsanwendung, deren Quellcode weg ist, startet auf einem neuen Windows-11-PC nicht. Ich habe auf der Registerkarte Kompatibilität des Eigenschaftendialogs ‚Windows XP‘ angehakt, und sie lief einfach. — Was macht das tatsächlich? Ist es in Ordnung, sich weiter darauf zu verlassen?“ Das ist eine Beratung, die wir oft hören.

Wenn ein einziges Kontrollkästchen etwas zum Laufen bringt, ist Unbehagen natürlich. Die wahre Identität des Kompatibilitätsmodus, der wie Magie wirkt, ist eine Sammlung kleiner Codestücke namens Shims, die sich zwischen Anwendung und Windows-API setzen und eine „Lüge“ zurückgeben. Windows selbst nutzt diese Notlösung in großem Maßstab, um Anwendungen vieler Generationen am Laufen zu halten, und legt einen Teil des Mechanismus Nutzern und Administratoren offen.

Ohne Verständnis des Mechanismus wird Lebensverlängerung zu einem instabilen „wir dürfen es nicht anfassen, weil wir nicht wissen, warum es läuft“. Verstehen Sie den Mechanismus, und Sie können mit Gründen entscheiden, wie weit Sie sich sicher darauf verlassen können, was es zerbrechen wird und wann Sie neu schreiben sollten.

flowchart TB
    accTitle: Den Mechanismus zu verstehen ändert die Qualität der Lebensverlängerung
    accDescr: Den Kompatibilitätsmodus ohne Verständnis des Mechanismus zu nutzen führt zu instabiler Lebensverlängerung, die man nicht anzufassen wagt; den Mechanismus zu verstehen erlaubt Entscheidungen mit Gründen, wie weit man sich verlassen kann, was es zerbricht und wann neu geschrieben werden sollte
    unknown["Nutzen ohne Verständnis des Mechanismus"] --> fear["Instabile Lebensverlängerung, die man nicht anfasst"]
    known["Nutzen nach Verständnis des Mechanismus"] --> judge["Entscheidungen mit Gründen"]
    judge -.-> j1["Wie weit man sich verlassen kann"]
    judge -.-> j2["Was es zerbrechen wird"]
    judge -.-> j3["Wann neu geschrieben werden sollte"]

Abbildung 1: Auch bei derselben Lebensverlängerung unterscheidet sich die Qualität zwischen der Angst aus Unkenntnis des Mechanismus und einer Entscheidung auf Grundlage des Verständnisses.

Gerichtet an IT-Verantwortliche in kleinen und mittleren Unternehmen und an Windows-Anwendungsentwickler, die alte Geschäftsanwendungen betreuen, ordnet dieser Artikel aus Microsoft-Learn-Primärquellen den Shim-Mechanismus, der die wahre Identität des Kompatibilitätsmodus ist, was die repräsentativen Shims können, wie man sie organisatorisch mit Compatibility Administrator anwendet, die Grenzen, die Shims nicht retten, und wie man zwischen Lebensverlängerung und Migration entscheidet.

1. Zuerst das Fazit

• Die wahre Identität des Kompatibilitätsmodus sind Shims (eine Kompatibilitätsschicht). Einstellungen der Registerkarte Kompatibilität werden nach HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers geschrieben, und beim Start wird ein Bündel von Shims auf den Prozess angewendet.¹²
• Ein Shim ist ein API-Hook im Benutzermodus, der die Import Address Table (IAT) umschreibt. Er fängt den Weg ab, auf dem die Anwendung Windows-APIs aufruft, und gibt dieselben Antworten zurück, die altes Windows gegeben hätte. Er ändert das Betriebssystem selbst nicht.³
• Was ein Shim tun kann, ist derselbe Umfang wie das, was eine Codekorrektur in der Anwendung tun kann. Er kann Sicherheitsmechanismen nicht umgehen und Kernelmodus-Probleme (Gerätetreiber) nicht beheben.³
• Microsoft liefert eine große Zahl fertiger Shims — Versionslügen, Dateipfad-Remapping, Registrierungsfälschung, Fälschung von Administratorprüfungen und mehr. Sie können sie in Compatibility Administrator auf einzelne EXEs anwenden.⁴
• Windows selbst nutzt Shims standardmäßig. Die OS-Standard-Kompatibilitätsdatenbank (.sdb) wird bei jedem Start abgeglichen, und PCA (Program Compatibility Assistant) kann ein Problem erkennen und automatisch eine Kompatibilitätseinstellung anwenden.¹⁵
• „Wie ein älteres Windows zu antworten“ ist inzwischen der Standard. Ab Windows 8.1 gibt GetVersionEx keine OS-Version zurück, die die Anwendung nicht in ihrem Manifest deklariert hat. Der Kompatibilitätsmodus ist eine Erweiterung dieses Mechanismus.⁶⁷
• Shims wirken nicht bei 16-Bit-Anwendungen, Kerneltreiber-Abhängigkeiten oder direktem Hardwarezugriff. Insbesondere können 16-Bit-Anwendungen auf 64-Bit-Windows gar nicht laufen.⁸
• Für Anwendungen, die „Administrator verlangen, ihn aber nicht wirklich brauchen“, ist RunAsInvoker der Standardzug. __COMPAT_LAYER=RunAsInvoker unterdrückt die Elevationsanfrage und lässt die Anwendung unter Standardrechten laufen.⁹
• Unter einem Shim zu laufen heißt, dass Sie das Leben vorerst verlängern können, aber der eigentliche Weg ist „ohne Shim zum Laufen bringen“. Entscheiden Sie sich für Lebensverlängerung, halten Sie fest, welche Shims sie zum Laufen bringen, und verwalten Sie das als Material für eine Neuschreib-Entscheidung.

2. Das Gesamtbild der Anwendungskompatibilität — die Abwärtskompatibilitätsschichten, die Windows schon hat

Bevor wir über Shims sprechen, hier die Mechanismen, die Windows bereits für alte Anwendungen hat. Auch wenn es heißt „im Kompatibilitätsmodus hat es angefangen zu laufen“, ist das, was die Anwendung tatsächlich rettet, eine dieser Schichten oder eine Kombination mehrerer.

UAC-Virtualisierung ist eine Übergangsmaßnahme für interaktive 32-Bit-Prozesse ohne Manifest, und Microsoft selbst bezeichnet sie als „eine vorübergehende Technologie, die wir aus einer künftigen Windows-Version entfernen wollen“.¹⁰ Der tatsächliche Schaden durch Wow6432Node-Umleitung und VirtualStore und der Umgang damit ist ausführlich in „Registry-32-Bit/64-Bit-Umleitung und Virtualisierungsfallen — Wow6432Node und das Problem „Der Wert, den ich geschrieben habe, ist nicht da““ behandelt; dieser Artikel hält Shims im Zentrum und erwähnt die anderen Schichten nur so weit nötig.

flowchart TB
    accTitle: Wo die UAC-Virtualisierung sitzt
    accDescr: UAC-Virtualisierung ist eine Übergangsmaßnahme für interaktive 32-Bit-Prozesse ohne Manifest; sie leitet Schreibzugriffe in einen benutzerspezifischen VirtualStore um, aber Microsoft selbst bezeichnet sie als vorübergehende Technologie, die aus einem künftigen Windows entfernt werden soll
    proc["Interaktiver 32-Bit-Prozess ohne Manifest"] --> uacv["UAC-Virtualisierung greift"]
    uacv --> vs["Umgeleitet in einen benutzerspezifischen VirtualStore"]
    uacv -.-> tmp["Vorübergehende Technologie, zur späteren Entfernung vorgesehen"]

Abbildung 2: UAC-Virtualisierung ist eine Übergangsmaßnahme für 32-Bit-Prozesse ohne Manifest, und man kann sich nicht dauerhaft darauf verlassen.

Als Nebenbemerkung zur DPI-Virtualisierung: Eine Anwendung, die keine DPI-Awareness deklariert hat, wird behandelt, als zeichne sie bei 96 DPI (100 %), und Windows streckt das Bitmap zur Anzeige. Deshalb wirken alte Anwendungen auf einem hochauflösenden Monitor „unscharf“, und „Verhalten der hohen DPI-Skalierung überschreiben“ auf der Registerkarte Kompatibilität ist der Schalter, der dieses Virtualisierungsverhalten ändert.¹¹

flowchart TB
    accTitle: Wie DPI-Virtualisierung funktioniert
    accDescr: Eine Anwendung, die keine DPI-Awareness deklariert hat, wird behandelt, als zeichne sie bei 96 DPI; Windows streckt das Bitmap, sodass sie unscharf wirkt, und das Überschreiben der hohen DPI-Einstellungen auf der Registerkarte Kompatibilität schaltet dieses Virtualisierungsverhalten um
    app["Anwendung, die keine DPI-Awareness deklariert"] --> treat["Behandelt als Zeichnen bei 96 DPI"]
    treat --> stretch["Bitmap wird zur Anzeige gestreckt"]
    stretch --> blur["Wirkt auf einem hochauflösenden Monitor unscharf"]
    tab["Verhalten der hohen DPI-Skalierung überschreiben"] -.->|Schaltet das Virtualisierungsverhalten um| treat

Abbildung 3: Eine nicht-DPI-fähige Anwendung wird als 96 DPI behandelt und gestreckt; das Überschreiben auf der Registerkarte Kompatibilität ist der Schalter für diese Virtualisierung.

3. Was ein Shim wirklich ist — zwischen APIs abfangen, indem die IAT umgeschrieben wird

3.1. Der „Dolmetscher“, der zwischen Anwendung und Betriebssystem steht

Eine Windows-Executable (PE-Format) ruft APIs in externen DLLs über die Import Address Table (IAT) auf. Wenn die Anwendung GetVersionEx aufruft, springt sie nur zu der in der IAT geschriebenen Adresse. Der Shim-Mechanismus nutzt das. Zur Ladezeit schreibt er den IAT-Eintrag der Ziel-API auf die Adresse des Shim-Codes um und setzt sich zwischen Anwendung und Windows. Dynamisch über GetProcAddress beschaffte APIs werden behandelt, indem GetProcAddress selbst gehookt wird.³

Sobald er abgefangen hat, kann ein Shim auf „was ist die aktuelle OS-Version?“ eine alte Versionsnummer zurückgeben oder einen Dateizugriff auf einen nicht beschreibbaren Ort woanders hin umlegen und dann bei Bedarf die echte API aufrufen. Aus Sicht der Anwendung sieht es aus, als liefe sie „auf altem Windows“; aus Sicht des Betriebssystems sieht es aus, als liefe „eine wohlerzogene Anwendung“ — der Shim ist der Dolmetscher dazwischen.

flowchart TB
    accTitle: Der Weg, auf dem ein Shim einen API-Aufruf abfängt
    accDescr: Der API-Aufruf einer Anwendung geht durch die IAT; das Umschreiben des IAT-Eintrags auf den Shim zur Ladezeit lässt den Shim abfangen, dieselbe Antwort fälschen, die altes Windows gegeben hätte, und dann bei Bedarf die echte API aufrufen
    app["Anwendung"] -->|API-Aufruf| iat["IAT-Eintrag"]
    iat -->|Zur Ladezeit auf den Shim umgeschrieben| shim["Shim (Dolmetscher)"]
    shim -->|Bei Bedarf| api["Die echte Windows-API"]
    shim -.-> lie["Fälscht dieselbe Antwort, die altes Windows gegeben hätte"]
    gpa["Aufrufe über GetProcAddress"] -.->|Durch einen Hook behandelt| shim

Abbildung 4: Ein Shim fängt zwischen Anwendung und Windows-API ab. Umschrieben wird die IAT auf der Anwendungsseite; das Betriebssystem selbst ändert sich nicht.

Aus diesem Entwurf folgen drei wichtige Eigenschaften.³

1. Ein Shim läuft als anwendungsseitiger Code. Er ist kein Teil des Betriebssystems, unterliegt also denselben Sicherheitsbeschränkungen wie die Anwendung. Ein Shim kann die OS-Sicherheitsmechanismen nicht umgehen, und Sie müssen Sicherheitseinstellungen nicht lockern, um einen Shim zu nutzen.
2. Was ein Shim beheben kann, kann auch eine anwendungsseitige Codekorrektur beheben. Ein Shim ist ein Ersatz für Fälle, in denen „es keinen Quellcode gibt / wir nicht korrigieren können“; er ist nicht mächtiger als eine Codekorrektur.
3. Nur Benutzermodus. Kompatibilitätsprobleme von Gerätetreibern, die im Kernelmodus laufen, kann ein Shim nicht beheben.

3.2. Die Shim-Datenbank (.sdb) und der Abgleich

Die Zuordnungstabelle „welchen Shim auf welche EXE anwenden“ ist die Shim-Datenbank, eine Binärdatei mit der Erweiterung .sdb. Ziel-Executables werden in der Datenbank über Attribute wie Dateiname, Größe, Prüfsumme und Version (Abgleichsattribute) registriert und beim Prozessstart abgeglichen. Heilmittel umfassen Appfix (ein Shim), der einen API-Hook injiziert, und Apphelp, der eine Meldung „diese Anwendung hat ein Kompatibilitätsproblem“ anzeigt. Ein Bündel mehrerer Shims und Flags ist eine Kompatibilitätsschicht (Kompatibilitätsmodus).¹

Leicht zu übersehen: Dieser Abgleich läuft nicht nur bei Anwendungen mit gesetztem Kompatibilitätsmodus, sondern bei jedem Prozessstart. Windows liefert eine OS-Standarddatenbank mit Korrekturen für Tausende bekannter Anwendungen (die Dateien liegen unter %WINDIR%\AppPatch), und auf Ihrem PC startet heute fast sicher irgendeine alte Anwendung mit angehängtem Shim, ohne dass es jemand bemerkt. Von Microsoft bereitgestellte Kompatibilitätskorrekturen werden als Teil von Windows ausgeliefert und über Windows Update aktualisiert.³

flowchart TB
    accTitle: Abgleich der Shim-Datenbank beim Prozessstart
    accDescr: Jeder Prozessstart wird gegen die Shim-Datenbank abgeglichen; stimmt eine Registrierung mit den Abgleichsattributen überein, injiziert Appfix einen Shim oder Apphelp zeigt eine Meldung, sonst startet der Prozess unverändert
    start["Prozessstart"] --> db["Gegen .sdb abgleichen"]
    db -.-> attr["Dateiname, Größe usw."]
    db --> hit{"Eine Registrierung?"}
    hit -->|Ja| appfix["Appfix: Shim injizieren"]
    hit -->|Ja| apphelp["Apphelp: eine Meldung"]
    hit -->|Nein| plain["Unverändert starten"]
    layer["Kompatibilitätsschicht"] -.->|Bündel von Shims und Flags| appfix

Abbildung 5: Der Abgleich läuft bei jedem Prozessstart, nicht nur bei Anwendungen mit gesetztem Kompatibilitätsmodus.

3.3. PCA — der Mechanismus, der Shims automatisch anwendet

Ein weiterer Weg, auf dem ein Shim ohne Absicht eines Administrators angewendet werden kann, ist PCA (Program Compatibility Assistant). PCA beobachtet die Anwendungsausführung und schlägt dem Benutzer bei Anzeichen eines bekannten Kompatibilitätsproblems eine Korrektur vor oder wendet in manchen Fällen automatisch eine Kompatibilitätseinstellung an. Einer Anwendung, die abstürzt, weil sie Code in einer freigegebenen DLL aufruft, wird zum Beispiel PINDLL zugewiesen, einer Anwendung, die das Schreiben in eine geschützte Windows-Datei nicht schafft, WRPMITIGATION.⁵

flowchart TB
    accTitle: Wie PCA automatisch eine Kompatibilitätseinstellung anwendet
    accDescr: PCA beobachtet die Anwendungsausführung und schlägt dem Benutzer bei Anzeichen eines bekannten Kompatibilitätsproblems eine Korrektur vor oder wendet in manchen Fällen automatisch eine Kompatibilitätseinstellung an
    run["Anwendungsausführung"] --> pca["PCA beobachtet"]
    pca --> sign{"Anzeichen eines bekannten Problems?"}
    sign -->|Ja| resp{"Welcher Fall?"}
    resp -->|Durch einen Vorschlag behandelt| suggest["Anwenden einer Korrektur vorschlagen"]
    resp -->|Manche Fälle| auto["Kompatibilitätseinstellung automatisch anwenden"]
    sign -->|Nein| none["Unverändert ausführen"]
    auto -.-> ex["Beispiel: PINDLL oder WRPMITIGATION"]

Abbildung 6: PCA beobachtet die Anwendungsausführung und schlägt bei Anzeichen eines bekannten Problems eine Korrektur vor oder wendet eine automatisch an.

Die Identität von „ich habe nie etwas eingestellt, aber irgendwann war das Kontrollkästchen des Kompatibilitätsmodus an“ ist in vielen Fällen genau das. Es ist weder ein Fehler noch ein Fehlklick; Windows verhält sich wie entworfen.

4. Was die repräsentativen Shims können

Aus den fertigen Shims, die Microsoft veröffentlicht, eine Auswahl, die bei der Lebensverlängerung einer Geschäftsanwendung tatsächlich oft vorkommt.⁴

Schaut man auf die Liste, sind die meisten Shims „eine Lüge, die die Antwort zurückgibt, die die alte Anwendung erwartet“. Die Festplatte ist höchstens 2 GB, das OS ist XP, Sie sind Administrator — sie erzeugen nur innerhalb dieses Prozesses das Weltbild der Zeit, in der die Anwendung entstanden ist.

Versionsfälschung ist „offizielles Standardverhalten“ geworden

Versionsfälschung ist kein besonderer Hack. Ab Windows 8.1 hängt der Wert, den GetVersionEx zurückgibt, vom Manifest der Anwendung ab. Eine Anwendung ohne <supportedOS>-Deklaration im <compatibility>-Abschnitt des Manifests erhält immer das Windows-8-Äquivalent (6.2), unabhängig vom tatsächlichen OS. Gibt es eine Deklaration, wird der Wert bis zum höchsten unter den deklarierten Betriebssystemen zurückgegeben (haben Sie zum Beispiel bis zur Windows-8.1-GUID deklariert, erhalten Sie auch unter Windows 11 6.3).⁶⁷

Die „Windows-Version, die die Anwendung sieht“, entscheidet sich also in diesen gestapelten Stufen.

1. Der Wert bis zum im Manifest deklarierten OS wird zurückgegeben (6.2, wenn es keine Deklaration gibt)
2. Ist der Kompatibilitätsmodus (ein Shim der VersionLie-Familie) angewendet, wird die Version des gewählten OS zurückgegeben⁶

flowchart TB
    accTitle: Wie die OS-Version, die die Anwendung sieht, entschieden wird
    accDescr: Der Wert, den GetVersionEx zurückgibt, entscheidet sich danach, ob eine supportedOS-Deklaration im Manifest steht; ohne Deklaration wird das Windows-8-Äquivalent 6.2 zurückgegeben, mit Deklaration der Wert bis zum höchsten deklarierten OS, und ist ein Shim der VersionLie-Familie angewendet, wird er mit der gewählten OS-Version überschrieben
    q["GetVersionEx-Abfrage"] --> m{"Gibt es eine supportedOS-Deklaration?"}
    m -->|Nein| v62["Windows-8-Äquivalent (6.2) wird zurückgegeben"]
    m -->|Ja| decl["Wert bis zum höchsten deklarierten OS"]
    v62 --> lie{"Shim der VersionLie-Familie angewendet?"}
    decl --> lie
    lie -->|Ja| fake["Der im Kompatibilitätsmodus gewählte OS-Wert"]
    lie -->|Nein| asis["Der Wert wird unverändert zurückgegeben"]

Abbildung 7: Die Windows-Version, die die Anwendung sieht, entscheidet sich in gestapelten Stufen durch das Manifest und durch Shims.

Wenn eine interne Anwendung „nach OS-Version verzweigt und, verwirrend, als 8 beurteilt wird, obwohl das Windows 11 ist“, verdächtigen Sie zuerst die supportedOS-Deklaration im Manifest. Andersherum: eine alte Anwendung, die den Start aufgrund einer Versionsprüfung verweigert, kann mit hoher Wahrscheinlichkeit mit einem VersionLie-Shim durchkommen. In vielen Fällen schaut sie nur auf die Versionsnummer, und das tatsächliche Verhalten ist auf einem neueren OS in Ordnung.

flowchart TB
    accTitle: Zwei versionsbedingte Symptome und wie man ihnen begegnet
    accDescr: Wird eine interne Anwendung als 8 beurteilt, obwohl das Windows 11 ist, verdächtigen Sie die supportedOS-Deklaration im Manifest; eine alte Anwendung, die den Start aufgrund einer Versionsprüfung verweigert, kann mit hoher Wahrscheinlichkeit mit einem VersionLie-Shim durchkommen
    sym1["Als 8 beurteilt, obwohl das Windows 11 ist"] --> fix1["Die supportedOS-Deklaration verdächtigen"]
    sym2["Start wegen einer Versionsprüfung verweigert"] --> fix2["Mit VersionLie durchzukommen versuchen"]
    fix2 -.-> why["Das tatsächliche Verhalten ist auf einem neueren OS oft in Ordnung"]

Abbildung 8: Ist die Beurteilung veraltet, verdächtigen Sie das Manifest; wird der Start verweigert, verdächtigen Sie VersionLie.

5. Was das Kontrollkästchen des Kompatibilitätsmodus tut

Einstellungen von Eigenschaften → Registerkarte Kompatibilität werden im Registrierungsschlüssel AppCompatFlags\Layers gespeichert. DXGI-Anwendungskompatibilitätseinstellungen und Ähnliches nutzen denselben Schlüssel als Ort, um eine Kompatibilitätsschicht anzugeben.² Schauen wir tatsächlich nach.

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

Für eine EXE, auf der Sie auf der Registerkarte Kompatibilität „Windows XP (Service Pack 3)“, „Dieses Programm als Administrator ausführen“ und „Verhalten der hohen DPI-Skalierung überschreiben“ gesetzt haben, sehen Sie einen Wert etwa wie den folgenden.

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

Repräsentative Entsprechungen zwischen Kontrollkästchen-Einträgen und Werten (unter Windows 11 bestätigt; Eintragsnamen und Werte können sich je nach OS-Version ändern).

Drei Punkte merken.

• „Dieses Programm als Administrator ausführen“ wird an derselben Stelle geschrieben. Kompatibilitätsmodus und Elevationsflag leben zusammen im selben Layers-Schlüssel, und dort entsteht die Verwirrung „ich habe den Kompatibilitätsmodus gesetzt und Elevation kam mit / verschwand“. Den Wert direkt anzusehen trennt die beiden.
• Was in HKCU geschrieben steht, ist „die Einstellung dieses Benutzers“. Setzen Sie es über „Einstellungen für alle Benutzer ändern“ der Registerkarte, wird es in den gleichnamigen Schlüssel auf der HKLM-Seite geschrieben und gilt für alle Benutzer. Wenn Sie es im Imaging verteilen, seien Sie sich bewusst, auf welche Seite Sie schreiben.
• Das Kontrollkästchen ist nur der Eingang zu den fertigen Schichten. Die Registerkarte lässt Sie nur repräsentative Schichten wählen; einzelne Shims können Sie nicht auswählen und kombinieren. Das macht Compatibility Administrator im nächsten Kapitel.

flowchart TB
    accTitle: Der Weg von einer Einstellung der Registerkarte Kompatibilität bis zur Wirkung
    accDescr: Einstellungen der Registerkarte Kompatibilität werden als EXE-Pfad und Wert im AppCompatFlags-Layers-Schlüssel gespeichert; beim nächsten Start dieser EXE liest der Lader den Wert und wendet die entsprechende Kompatibilitätsschicht auf den Prozess an
    tab["Auf der Registerkarte Kompatibilität setzen"] --> reg["EXE-Pfad und Wert im Layers-Schlüssel speichern"]
    reg --> boot["Nächster EXE-Start"]
    boot --> loader["Der Lader liest den Wert"]
    loader --> apply["Die Kompatibilitätsschicht auf den Prozess anwenden"]
    reg -.-> hkcu["HKCU gilt nur für diesen Benutzer"]
    reg -.-> hklm["HKLM gilt für alle Benutzer"]

Abbildung 9: Das Kontrollkästchen ist in Wirklichkeit ein Schreiben in den Layers-Schlüssel, und die Anwendung geschieht beim nächsten Start.

6. Compatibility Administrator in der Praxis — eine benutzerdefinierte .sdb bauen und verteilen

6.1. Wie man es bekommt, und Vorbehalte

Compatibility Administrator ist ein Werkzeug im Windows ADK (Windows Assessment and Deployment Kit).¹² Nach der Installation sind sowohl die 32-Bit- als auch die 64-Bit-Ausgabe vorhanden, und Sie müssen die 32-Bit-Ausgabe für 32-Bit-Anwendungen und die 64-Bit-Ausgabe für 64-Bit-Anwendungen verwenden.¹³

Es gibt einen weiteren wichtigen Vorbehalt. Starten Sie Compatibility Administrator erhöht (als Administrator) und testen, verhalten sich UAC-Virtualisierung und Umleitung nicht wie für einen echten Benutzer, und Sie können falsch urteilen, „es sei behoben“. Bestätigen Sie die Wirkung einer Korrektur immer mit demselben Konto und denselben Rechten wie der tatsächliche Benutzer.⁴

flowchart TB
    accTitle: Zwei Vorbehalte bei der Nutzung von Compatibility Administrator
    accDescr: Verwenden Sie die 32-Bit-Ausgabe für 32-Bit-Anwendungen und die 64-Bit-Ausgabe für 64-Bit-Anwendungen, und bestätigen Sie die Wirkung einer Korrektur mit demselben Konto und denselben Rechten wie der tatsächliche Benutzer, nicht in einem erhöhten Zustand
    app32["32-Bit-Anwendung"] --> tool32["32-Bit-Ausgabe verwenden"]
    app64["64-Bit-Anwendung"] --> tool64["64-Bit-Ausgabe verwenden"]
    elev["Im erhöhten Zustand testen"] -.-> wrong["Kann eine Korrektur falsch beurteilen"]
    user["Mit denselben Rechten wie der Benutzer testen"] --> ok["Die Wirkung bestätigen"]

Abbildung 10: Die Wahl der 32-Bit- oder 64-Bit-Ausgabe und die Bestätigung mit denselben Rechten wie der tatsächliche Benutzer sind die Vorbehalte am Eingang.

6.2. Vorgehen zum Aufbau einer benutzerdefinierten Kompatibilitätsdatenbank

Der Überblick ist wie folgt.¹⁴

1. Erstellen Sie im linken Bereich von Compatibility Administrator unter „Custom Databases“ eine neue Datenbank und wählen Sie „Create New“ → „Application Fix“
2. Geben Sie Anwendungsname und Herstellername ein und geben Sie die Ziel-EXE-Datei an
3. Wählen Sie den anzuwendenden Kompatibilitätsmodus (Schicht) — zuerst ein Bündel wie „Windows-XP-Kompatibilität“ zu versuchen ist der kurze Weg
4. Fügen Sie bei Bedarf einzelne Kompatibilitätskorrekturen (Shims) hinzu — Sie können auf ein Minimalset wie nur VersionLie oder nur CorrectFilePaths eingrenzen
5. Bestätigen Sie die Abgleichsbedingungen (Dateigröße, Prüfsumme, Version und so weiter) und speichern Sie

Abgleichsbedingungen sind der Schlüssel zu „nur auf diese EXE anwenden“. Die Standard-Grundbedingungen reichen meist, aber wir empfehlen, eine Bedingung zu lassen, die die Anwendungsversion identifizieren kann. Das verhindert den Unfall, dass eine alte Lüge weiter auf eine neue Version angewendet wird, wenn der Hersteller später eine korrigierte Ausgabe liefert.¹⁴¹⁵

flowchart TB
    accTitle: Vorgehen zum Aufbau einer benutzerdefinierten Kompatibilitätsdatenbank
    accDescr: Erstellen Sie ein Application Fix in einer neuen Datenbank, geben Sie Anwendungsname und Ziel-EXE an, versuchen Sie zuerst ein Kompatibilitätsmodus-Bündel und grenzen Sie bei Bedarf auf einzelne Shims ein, bestätigen Sie Abgleichsbedingungen und speichern Sie
    new["Eine neue Datenbank erstellen"] --> fix["Application Fix wählen"]
    fix --> info["Anwendungsname und Ziel-EXE angeben"]
    info --> layer["Ein Kompatibilitätsmodus-Bündel versuchen"]
    layer --> single["Bei Bedarf auf einzelne Shims eingrenzen"]
    single --> match["Abgleichsbedingungen bestätigen und speichern"]
    match -.-> ver["Eine Bedingung lassen, die die Version identifiziert"]

Abbildung 11: Bei einem Application Fix zuerst ein Kompatibilitätsmodus-Bündel versuchen, auf ein Minimalset eingrenzen und das Ziel mit Abgleichsbedingungen begrenzen.

Testen Sie die erstellte .sdb zuerst auf einer Validierungsmaschine. Sobald sie wie beabsichtigt funktioniert, rollen Sie sie in der Organisation aus.

6.3. Verteilen mit sdbinst

Der Befehl, der eine benutzerdefinierte .sdb auf jedem PC anwendet, ist sdbinst.exe (erfordert Administratorrechte).¹⁵

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

Als organisatorische Ausbringungsstrategie empfiehlt Microsoft, in eine unternehmensweite (oder abteilungsweise) benutzerdefinierte Datenbank zu konsolidieren und sie zentral zu verwalten, statt mit dem Installer jeder Anwendung eine eigene .sdb mitzuschicken. Je mehr Korrekturen Sie haben, desto leichter ist es, eine Datenbank zu aktualisieren und neu zu verteilen, als viele Einzeiler-Datenbanken zu verteilen. Eine benutzerdefinierte Datenbank hat ihre eigene GUID, und das Installieren einer neuen Version mit derselben GUID ersetzt automatisch die alte Version, sodass Update-Operationen ebenfalls einfach bleiben. Legen Sie die Verteilung selbst auf einen bestehenden Weg, der mit Administratorrechten laufen kann, etwa Verpackung als MSI oder ein Startskript.¹⁵

flowchart TB
    accTitle: Der Weg vom Erstellen einer benutzerdefinierten .sdb bis zur Verteilung
    accDescr: Erstellen Sie eine benutzerdefinierte Kompatibilitätsdatenbank in Compatibility Administrator, testen Sie sie auf einer Validierungsmaschine, wenden Sie sie mit sdbinst auf jedem PC an, und installieren Sie beim Update eine neue Version mit derselben GUID, sodass die alte Version automatisch ersetzt wird
    make["In Compatibility Administrator erstellen"] --> test["Auf einer Validierungsmaschine testen"]
    test --> deploy["Mit sdbinst auf jedem PC anwenden"]
    deploy --> update["Eine neue Version mit derselben GUID installieren"]
    update -.-> replace["Die alte Version wird automatisch ersetzt"]
    deploy -.-> inv["In Programme und Features registriert"]

Abbildung 12: Eine benutzerdefinierte .sdb wird über Erstellen, Validieren und sdbinst-Verteilung ausgerollt, und Updates werden über die GUID verwaltet.

Eine installierte benutzerdefinierte Datenbank wird als Eintrag in „Programme und Features (Installierte Apps)“ registriert, sodass Sie Bestand und Entfernung auch von dort bestätigen können. Welche PCs welche .sdb haben, gehört ins Asset-Management-Verzeichnis.

7. Fälle, in denen es nicht wirkt, und die Grenzen

Shims sind keine Silberkugel. Konstruktionsbedingt wirken sie in den folgenden Fällen nicht.

• Kernelmodus-Probleme. Ein Shim läuft innerhalb eines Benutzermodus-Prozesses, daher kann eine Gerätetreiber-Inkompatibilität nicht behoben werden. Unterstützt der Treiber eines alten Messgeräts, USB-Dongles oder Druckers Windows 11 nicht, löst nichts, was Sie auf der Anwendungsseite anwenden, das Problem. Code, der im Kernel läuft, etwa Teile von Antivirensoftware, ist dasselbe.³
• 16-Bit-Anwendungen. 64-Bit-Windows unterstützt die Ausführung von 16-Bit-Anwendungen nicht. Handles haben unter 64-Bit-Windows 32 gültige Bits und können nicht abgeschnitten werden, um sie an eine 16-Bit-Anwendung zu übergeben, daher scheitert der Start mit ERROR_BAD_EXE_FORMAT.⁸ Auch wenn die Anwendung selbst 32-Bit ist, gibt es Pakete jener Zeit, deren Installer-Stub 16-Bit ist, und sie erscheinen als „die Anwendung würde laufen, aber wir können sie nicht installieren“.
• Direkter Hardwarezugriff. Industrieanwendungen, die voraussetzen, I/O-Ports oder physischen Speicher direkt anfassen zu können, dürfen das im Benutzermodus unter modernem Windows von vornherein nicht, und das liegt jenseits dessen, was ein Shim fälschen kann.
• Umgehen von Sicherheitsmechanismen. Weil ein Shim unter denselben Sicherheitsbeschränkungen wie die Anwendung läuft, kann er „etwas, das Sie aus Mangel an Rechten nicht tun können“ nicht möglich machen. ForceAdminAccess und WRPMitigation fälschen nur den Erfolg einer Prüfung oder eines Schreibzugriffs, damit die Anwendung fortfahren kann; sie schreiben eine geschützte Ressource nicht wirklich um.³⁴
• Anwendungen, die ihre eigene Integrität prüfen. Anwendungen mit altem Kopierschutz oder Manipulationserkennung können den API-Hook selbst als abnormal behandeln und aufhören zu funktionieren.

flowchart TB
    accTitle: Fälle, in denen ein Shim nicht wirkt
    accDescr: Ein Shim läuft innerhalb eines Benutzermodus-Prozesses, daher wirkt er nicht auf Kernelmodus-Treiberprobleme, 16-Bit-Anwendungen, direkten Hardwarezugriff oder das Umgehen von Sicherheitsmechanismen
    shim["Shim (läuft im Benutzermodus)"] -->|Wirkt nicht| drv["Kerneltreiber"]
    shim -->|Wirkt nicht| b16["16-Bit-Anwendung"]
    shim -->|Wirkt nicht| hw["Direkter Hardwarezugriff"]
    shim -->|Wirkt nicht| sec["Umgehen von Sicherheitsmechanismen"]
    b16 -.-> fmt["Unter 64 Bit scheitert schon der Start"]
    sec -.-> fake["Fälscht nur Erfolg, damit die Anwendung fortfahren kann"]

Abbildung 13: Ein Shim ist nur Benutzermodus und erreicht nicht den Kernel, 16-Bit-Anwendungen, direkten Hardwarezugriff oder Sicherheitsumgehung.

Und die wesentliche Grenze, die jedem Shim gemeinsam ist: er ist eine Notlösung. Ein Shim ist eine Lüge, zugeschnitten auf eine bestimmte Nutzung einer bestimmten API, und ändert sich die implementierung auf der OS-Seite, bricht die Annahme zusammen. Von Microsoft bereitgestellte Shims werden als Teil von Windows über Windows Update gepflegt,³ aber sich um die Lügen zu kümmern, die Sie mit einer benutzerdefinierten Datenbank angewendet haben, ist die Aufgabe Ihrer Organisation. Budgetieren Sie als Kosten der Lebensverlängerung einen Betrieb, der die „Liste der durch Shims am Leben gehaltenen Anwendungen“ bei jedem Feature-Update validiert.

flowchart TB
    accTitle: Shims als Notlösung und wer für ihre Pflege verantwortlich ist
    accDescr: Ein Shim ist eine auf eine bestimmte API-Nutzung zugeschnittene Lüge und die Annahme bricht zusammen, wenn sich die OS-seitige Implementierung ändert; Microsoft-Shims werden über Windows Update gepflegt, aber sich um mit einer benutzerdefinierten Datenbank angewendete Lügen zu kümmern ist Aufgabe der Organisation, und die Validierung bei jedem Feature-Update ist eine Kosten der Lebensverlängerung
    shim["Shim = eine Notlügen-Lösung"] --> break["OS-Änderung zerbricht es"]
    ms["Microsoft-Shims"] --> wu["Über Windows Update"]
    own["Lügen der benutzerdefinierten Datenbank"] --> self["Die Organisation kümmert sich"]
    self --> cost["Validierung bei jedem Update als Kosten der Lebensverlängerung"]

Abbildung 14: Die Verantwortung für die Pflege der Shim-Lüge teilt sich zwischen dem von Microsoft bereitgestellten Satz und dem benutzerdefinierten Satz Ihrer Organisation.

8. Der praktische Wert von RunAsInvoker — nur die Elevationsanfrage zum Schweigen bringen

Unter den Shims ist der, der in der täglichen IT-Arbeit am häufigsten vorkommt, RunAsInvoker.

Manche alten Geschäftsanwendungen deklarieren requireAdministrator im Manifest oder werden anhand von EXE-Name oder Inhalt fälschlich als Installer erkannt und fordern bei jedem Start UAC-Elevation. Viele von ihnen verlangen Administrator aber nur aus XP-zeitlicher Trägheit und nutzen Administratorrechte nicht wirklich. Das Anwenden des RunAsInvoker-Shims überschreibt sowohl die Installer-Erkennung als auch das Manifest, und die Anwendung startet mit dem vom Elternprozess geerbten Token (= Standardbenutzerrechte).⁹

flowchart TB
    accTitle: Wie RunAsInvoker eine Elevationsanfrage unterdrückt
    accDescr: Eine requireAdministrator-Deklaration im Manifest oder eine Fehlkennung als Installer verursacht beim Start eine UAC-Elevationsanfrage, aber das Anwenden von RunAsInvoker überschreibt beides und die Anwendung startet mit dem vom Elternprozess geerbten Token
    manifest["requireAdministrator-Deklaration"] --> shim{"RunAsInvoker angewendet?"}
    detect["Fälschlich als Installer erkannt"] --> shim
    shim -->|Nein| uac["UAC-Elevationsanfrage bei jedem Start"]
    shim -->|Ja| token["Startet mit dem Token des Elternprozesses"]
    token -.-> limit["Arbeit, die wirklich Administrator braucht, scheitert in der Anwendung"]

Abbildung 15: RunAsInvoker überschreibt nur die Ursache der Elevationsanfrage; Rechte steigen nicht.

Auch ohne eine .sdb in Compatibility Administrator zu bauen, können Sie dieselbe Schicht vorübergehend mit der Umgebungsvariable __COMPAT_LAYER anwenden.

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

Machen Sie diese zwei Zeilen zu einer Batchdatei und verteilen Sie sie als Verknüpfung, können Sie vermeiden, Standardbenutzern lokale Administratorrechte zu geben, und die IT wird nicht mehr jedes Mal wegen eines UAC-Kennworts gerufen. Es ist eine Kompatibilitätstechnik, die die Verteidigung härtet, im Einklang mit Least Privilege.

flowchart TB
    accTitle: Die Wirkung der Verteilung einer RunAsInvoker-Batch
    accDescr: Das Verteilen einer Zwei-Zeilen-Batch, die RunAsInvoker setzt, als Verknüpfung bedeutet, dass Sie vermeiden können, Standardbenutzern lokale Administratorrechte zu geben, die IT nicht wegen eines UAC-Kennworts gerufen wird und der Betrieb Least Privilege folgt
    bat["Eine Zwei-Zeilen-Batch verteilen"] --> noadmin["Sie können vermeiden, Administratorrechte auszugeben"]
    bat --> nocall["Die IT wird nicht wegen UAC gerufen"]
    noadmin --> lp["Ein Betrieb, der Least Privilege folgt"]
    nocall --> lp

Abbildung 16: Allein das Verteilen einer Batch kann sowohl das Ausgeben von Administratorrechten als auch das Gerufenwerden wegen UAC verringern.

Die Vorbehalte ebenfalls klar.

• Rechte steigen nicht. Arbeit, die wirklich Administratorrechte braucht (Schreiben nach HKLM, Updates unter Program Files und so weiter), wird innerhalb der Anwendung fehlschlagen oder, wenn die Bedingungen erfüllt sind, von der UAC-Virtualisierung in den VirtualStore umgeleitet.¹⁰ Wenn das Speichern von Einstellungen plötzlich „nicht mehr funktioniert“, verdächtigen Sie die Virtualisierung.
• Die Umgebungsvariablenmethode gilt nur für Kindprozesse. Für eine dauerhafte Anwendung ist eine direkte Einstellung im Layers-Schlüssel (RUNASINVOKER hat keinen Eintrag auf der Registerkarte) oder die Verteilung über eine .sdb zuverlässig.
• Das Schreibziel zu korrigieren ist der eigentliche Weg. Können Sie die Anwendung ändern, verschieben Sie die Einstellungsdatei unter %APPDATA% und deklarieren Sie asInvoker im Manifest — das ist die richtige Form.⁹

flowchart TB
    accTitle: Vorübergehende und dauerhafte Anwendung von RunAsInvoker
    accDescr: Die Anwendung über die Umgebungsvariable COMPAT_LAYER gilt nur für Kindprozesse, die von dort gestartet werden; für eine dauerhafte Anwendung verwenden Sie eine direkte Einstellung im Layers-Schlüssel oder die Verteilung über eine .sdb
    env["Über eine Umgebungsvariable setzen"] --> child["Gilt nur für Kindprozesse"]
    child -.-> tmp["Vorübergehende Anwendung"]
    layers["Direkt im Layers-Schlüssel setzen"] --> always["Dauerhafte Anwendung"]
    sdb["Über eine sdb verteilen"] --> always

Abbildung 17: Die Umgebungsvariablenmethode ist eine vorübergehende, auf Kindprozesse begrenzte Anwendung; dauerhaft macht man es mit dem Layers-Schlüssel oder einer .sdb.

9. Die Entscheidung zwischen Lebensverlängerung und Migration — was nach dem Laufen unter einem Shim zu denken ist

Der Moment, in dem es unter einem Shim läuft, ist eine Erleichterung, aber es ist wichtig, dort nicht aufzuhören zu denken. Unter einem Shim zu laufen bedeutet nur, dass es zufällig in eine Fassung passte, die Windows vorbereitet hatte. Die Achsen der Entscheidung in einer Tabelle.

Entscheiden Sie sich für Lebensverlängerung, setzen Sie die folgenden drei Punkte als Satz in den Betrieb.

1. Festhalten. Welche EXE, welcher Shim/Schicht, und warum. Lassen Sie den Layers-Schlüsselwert und die .sdb-GUID in einem Verzeichnis. „Niemand weiß, warum es läuft“ ist die größte Schuld, die Sie der nächsten Person hinterlassen. Das ist dieselbe Erhaltungshaltung wie in „Wenn Sie ein System ohne Quellcode und ohne Dokumentation übernehmen — Ein praktisches Playbook, um es am Laufen zu halten“.
2. Validieren. Nehmen Sie Start und Hauptoperationen der durch Shims am Leben gehaltenen Anwendungen in die Validierungspunkte eines Windows-Feature-Updates auf. Binden Sie es auch an den OS-Ersatzplan (Praktische Optionen nach dem Support-Ende von Windows 10 — Eine Entscheidungstabelle für ESU, LTSC und Ersatz).
3. Eine Frist setzen. Entscheiden Sie das Ende der Lebensverlängerung — „bis zur nächsten Kernsystem-Erneuerung“, „bis März 2028“ — und führen Sie die Migrationsüberlegung parallel.

flowchart TB
    accTitle: Der Drei-Punkte-Betriebssatz, sobald Sie sich für Lebensverlängerung entscheiden
    accDescr: Halten Sie in einem Verzeichnis fest, welcher Shim sie zum Laufen bringt, validieren Sie das Verhalten der durch Shims am Leben gehaltenen Anwendungen bei jedem Feature-Update, setzen Sie eine Frist für das Ende der Lebensverlängerung und führen Sie die Migrationsüberlegung parallel
    decide["Sich für Lebensverlängerung entscheiden"] --> rec["Festhalten: welcher Shim sie zum Laufen bringt, ins Verzeichnis"]
    rec --> verify["Validieren: Verhalten bei jedem Feature-Update bestätigen"]
    verify --> deadline["Frist: das Ende der Lebensverlängerung entscheiden"]
    deadline --> mig["Die Migrationsüberlegung parallel führen"]

Abbildung 18: Lebensverlängerung wird als Drei-Punkte-Satz aus Festhalten, Validieren und Frist betrieben, einschließlich der parallelen Migrationsüberlegung.

Auf der Migrationsseite ändern sich die Standardoptionen mit der Technologie der Anwendung. Für VB6 die Dreiwege-Wahl aus vollständigem Neuschreiben, automatischer Konvertierung und gestufter Migration, geordnet in „Wie lange laufen VB6-Anwendungen noch? — Support-Status der Laufzeitumgebung und ein praxisnaher Weg zur .NET-Migration“; für eine ActiveX/OCX-Abhängigkeit die Behalten-/Kapseln-/Ersetzen-Entscheidungstabelle in „ActiveX / OCX heute behandeln - Entscheidungstabelle: Behalten, Kapseln, Ersetzen“. Die gesunde Positionierung eines Shims ist, Zeit zu kaufen, damit Überlegungs- und Vorbereitungszeit dieses Migrationsprojekts sicher laufen können.

flowchart TB
    accTitle: Optionen auf der Migrationsseite und wo ein Shim sitzt
    accDescr: Die Standard-Migrationsoptionen ändern sich mit der Technologie der Anwendung; für VB6 ist die Dreiwege-Wahl Neuschreiben, automatische Konvertierung und gestufte Migration, für eine ActiveX-Abhängigkeit gilt die Behalten-/Kapseln-/Ersetzen-Tabelle, und ein Shim wird als Zeitkauf für Überlegung und Vorbereitung des Migrationsprojekts positioniert
    tech{"Was ist die Technologie der Anwendung?"} -->|VB6| vb["Neuschreiben, automatische Konvertierung oder gestufte Migration"]
    tech -->|ActiveX-Abhängigkeit| ax["Behalten, kapseln oder ersetzen"]
    shim["Lebensverlängerung über einen Shim"] -.->|Kauft Zeit für Überlegung und Vorbereitung| tech

Abbildung 19: Die Standard-Migrationsoptionen entscheidet die Technologie der Anwendung, und ein Shim wird als Zeitkauf für diese Überlegung positioniert.

10. Zusammenfassung

• Die wahre Identität des Kompatibilitätsmodus sind Shims. Einstellungen der Registerkarte Kompatibilität werden in den Schlüssel AppCompatFlags\Layers geschrieben und beim Start als API-Hook über IAT-Umschreibung in den Prozess injiziert.
• Shims sind eine Sammlung von „Lügen, die die Antwort zurückgeben, die die alte Anwendung erwartet“. Fertige Shims für Versionsfälschung, Pfad-Remapping, Registrierungsfälschung, Fälschung von Administratorprüfungen und Ähnliches werden bereitgestellt.
• Windows selbst nutzt standardmäßig eine große Zahl von Shims, und PCA kann sie automatisch anwenden. Sich auf den Kompatibilitätsmodus zu verlassen ist selbst eine vernünftige Wahl, die auf einem offiziellen OS-Mechanismus reitet.
• Es gibt eine prinzipielle Grenze nur-Benutzermodus und keine Sicherheitsumgehung, und Kerneltreiber, 16-Bit-Anwendungen und direkter Hardwarezugriff können nicht gerettet werden.
• Organisatorische Ausbringung ist das Bauen einer benutzerdefinierten .sdb in Compatibility Administrator (Windows ADK) und das Verteilen mit sdbinst. Die Wahl der 32-Bit-/64-Bit-Ausgabe, das Testen mit dem tatsächlichen Benutzerkonto und das Verwalten von Updates über die GUID sind die praktischen Punkte.
• Anwendungen, die „Administrator verlangen, ihn aber nicht wirklich brauchen“, können mit __COMPAT_LAYER=RunAsInvoker auf Standardrechte heruntergebracht werden. Es ist eine defensive Technik, die die Elevationsanfrage zum Schweigen bringt, statt Rechte auszugeben.
• Unter einem Shim zu laufen ist Lebensverlängerung, keine Lösung. Festzuhalten, was sie zum Laufen bringt, bei jedem Feature-Update zu validieren und eine Frist zu setzen, damit Migration parallel läuft — dieser Drei-Punkte-Satz gehört zur Entscheidung, „sich auf den Kompatibilitätsmodus zu verlassen“.

Wenn das nächste Mal eine alte Anwendung nach einem Kontrollkästchen im Kompatibilitätsmodus wieder läuft, fragen Sie erneut. „Dank welcher Lüge läuft diese Anwendung? Wie lange wird diese Lüge weiterwirken?“ Können Sie antworten, ist Lebensverlängerung eine achtbare Strategie.

Verwandte Artikel

• Registry-32-Bit/64-Bit-Umleitung und Virtualisierungsfallen — Wow6432Node und das Problem „Der Wert, den ich geschrieben habe, ist nicht da“
• Wie lange laufen VB6-Anwendungen noch? — Support-Status der Laufzeitumgebung und ein praxisnaher Weg zur .NET-Migration
• ActiveX / OCX heute behandeln - Entscheidungstabelle: Behalten, Kapseln, Ersetzen
• Praktische Optionen nach dem Support-Ende von Windows 10 — Eine Entscheidungstabelle für ESU, LTSC und Ersatz
• Wenn Sie ein System ohne Quellcode und ohne Dokumentation übernehmen — Ein praktisches Playbook, um es am Laufen zu halten
• Windows-Shell-Integration heute — Kontextmenüs, Dateizuordnungen und was sich in Windows 11 geändert hat

Verwandte Beratungsbereiche

KomuraSoft LLC übernimmt die Untersuchung, wie alte Geschäftsanwendungen ohne Quellcode sich verhalten, und die Gestaltung ihrer Lebensverlängerung (Auswahl von Shims und Kompatibilitätsmodus, Aufbau und Ausrollen einer benutzerdefinierten .sdb), die Kompatibilitätsvalidierung bestehender Anwendungen für eine Windows-11-Migration sowie die Planung eines Neuschreibens oder einer Migration, die parallel zur Lebensverlängerung läuft. Eine Beratung schon ab der Stufe „es hat im Kompatibilitätsmodus angefangen zu laufen, aber ist es in Ordnung, es so zu lassen?“ ist willkommen.

• Nutzung und Migration bestehender Assets
• Windows-App-Entwicklung
• Technische Beratung und Design-Review
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wenn eine Anwendung nach dem Aktivieren des Kompatibilitätsmodus wieder läuft, darf ich sie so weiterverwenden?

Für den kurzfristigen Geschäftsbetrieb ja. Der Kompatibilitätsmodus ist ein API-Hook im Benutzermodus namens Shim und ein offizieller, vom Betriebssystem bereitgestellter Mechanismus. Ein Shim bleibt aber eine Notlösung, um eine Anwendung ohne Korrektur zum Laufen zu bringen, und ein weiteres OS-Update kann die Annahmen ändern und sie wieder zerbrechen. Halten Sie fest, dass sie im Kompatibilitätsmodus läuft, und behandeln Sie diesen Eintrag als Teil der Entscheidung, die Anwendung neu zu schreiben oder ihr Leben planvoll zu verlängern.

Was macht das Kontrollkästchen des Kompatibilitätsmodus tatsächlich?

Wenn Sie Einstellungen auf der Registerkarte Kompatibilität des Eigenschaftendialogs speichern, schreibt Windows den Pfad der Ziel-EXE und einen Wert wie "WINXPSP3" oder "HIGHDPIAWARE" unter den Schlüssel HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers. Beim nächsten Start dieser EXE liest der Windows-Lader den Wert und wendet die entsprechende Kompatibilitätsschicht (ein Bündel von Shims) auf den Prozess an. Der Windows-XP-Kompatibilitätsmodus fälscht zum Beispiel die OS-Version, indem Versionsabfrage-APIs einen alten Wert zurückgeben. Das Betriebssystem selbst wird nicht geändert; nur diesem Prozess wird ein vorgetäuschtes älteres Windows gezeigt.

Können Anwendungen aus der 16-Bit-Ära im Kompatibilitätsmodus auf 64-Bit-Windows laufen?

Nein. 64-Bit-Windows führt 32-Bit-Anwendungen über WOW64 aus, unterstützt aber keine 16-Bit-Anwendungen; ein Startversuch scheitert mit ERROR_BAD_EXE_FORMAT. Das ist eine architektonische Grenze, die ein Shim nicht umgehen kann. Ältere Pakete, deren Installer-Stub 16-Bit ist, scheitern aus demselben Grund. Wenn Sie sie wirklich brauchen, müssen Sie außerhalb des Kompatibilitätsmodus suchen — etwa eine virtuelle Maschine mit 32-Bit-Windows.

Kann ich eine Anwendung, die "nur als Administrator startet", unter einem Standardbenutzerkonto ausführen?

RunAsInvoker ist einen Versuch wert. Wenn Sie an der Eingabeaufforderung set __COMPAT_LAYER=RunAsInvoker ausführen und dann die Anwendung starten, werden Elevationsanfragen aus einem requireAdministrator-Manifest oder aus der Installer-Erkennung unterdrückt, und die Anwendung startet mit denselben (Standardbenutzer-)Rechten wie der Aufrufer. Bei einer Anwendung, die nur Administratorrechte verlangt und sie nie wirklich nutzt, kann das allein die Elevation aus dem Alltag nehmen. Rechte steigen nicht, daher scheitert Arbeit, die wirklich Administratorrechte braucht, innerhalb der Anwendung. Übernehmen Sie es erst nach einer Verhaltensprüfung.

Wo bekomme ich Compatibility Administrator?

Es ist im Windows ADK (Windows Assessment and Deployment Kit) enthalten. Laden Sie das ADK von der Microsoft-Website herunter und wählen Sie bei der Installation die Features Application Compatibility Tools. Sowohl die 32-Bit- als auch die 64-Bit-Ausgabe werden installiert; für 32-Bit-Anwendungen müssen Sie die 32-Bit-Ausgabe verwenden, für 64-Bit-Anwendungen die 64-Bit-Ausgabe. Eine selbst erstellte benutzerdefinierte Kompatibilitätsdatenbank (.sdb) wenden Sie an, indem Sie auf jedem PC den Befehl sdbinst ausführen.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.