Windows-Anwendungskompatibilität — Kompatibilitätsmodus, Shims und Compatibility Administrator

„Eine zehn Jahre alte Geschäftsanwendung, deren Quellcode nicht mehr da ist, startet auf einem neuen Windows-11-PC nicht. Auf der Registerkarte Kompatibilität ‚Windows XP‘ gewählt, und sie lief. Darf man sie so weiterverwenden?“ Solche Anfragen kommen aus Betrieben, die alte Geschäftsanwendungen weiterbetreiben.

Der Kompatibilitätsmodus setzt das OS nicht auf ein älteres Windows zurück. Er ist ein Mechanismus, der nur dieser Anwendung das Verhalten nachholt, das ein älteres Windows voraussetzte. Im Zentrum stehen kleine Kompatibilitätskorrekturen, die zwischen Anwendung und Windows-API treten: Shims.¹

Dieser Artikel richtet sich an IT-Verantwortliche in kleinen und mittleren Unternehmen und an Entwicklerinnen und Entwickler von Windows-Apps. Die Reihenfolge ist was sich beheben lässt → warum es läuft → wie man es anwendet und verteilt → wie man zwischen Weiterbetrieb und Migration entscheidet. Anhand von Microsoft-Learn-Primärquellen prüfen wir, was hinter dem Kontrollkästchen geschieht.

1. Zuerst das Fazit — den Kompatibilitätsmodus darf man nutzen. Als Weiterbetrieb muss man ihn führen

Den Geschäftsbetrieb vorerst im Kompatibilitätsmodus fortzusetzen ist an sich eine vertretbare Wahl; sie nutzt einen Mechanismus, den Windows offiziell bereitstellt. Windows selbst wendet Kompatibilitätskorrekturen auf bekannte Apps an.¹ Die App ist damit jedoch nicht korrigiert. Das eigentliche Ziel ist, sie ohne Shims lauffähig zu machen.

Ob man ihn nutzt, lässt sich in dieser Reihenfolge klären.

Besonders gilt: „Erfolg auf die Frage, ob jemand Administrator ist, zurückgeben“ und „Administratorrechte vergeben“ sind zwei verschiedene Dinge. Ein Shim unterliegt denselben Sicherheitsbeschränkungen wie die App und umgeht den Schutz des OS nicht.¹² RunAsInvoker unterdrückt ebenfalls die Erhöhungsanfrage und startet mit denselben Rechten wie der Aufrufer; es ist keine Funktion, die Rechte hinzufügt.³

Wer den Mechanismus versteht, kann aus „wir fassen es nicht an, weil niemand weiß, warum es läuft“ einen Weiterbetrieb machen, bei dem sich sagen lässt, wie weit man sich darauf stützen kann, unter welchen Bedingungen es bricht und wann neu geschrieben werden soll.

flowchart TB
    accTitle: Das Verstehen des Mechanismus ändert die Qualität des Weiterbetriebs
    accDescr: Den Kompatibilitätsmodus ohne Kenntnis des Mechanismus zu nutzen führt zu unsicherem Weiterbetrieb, den niemand anfasst; wer den Mechanismus versteht, kann begründet entscheiden, wie weit man sich stützen kann, was ihn bricht und wann neu geschrieben werden soll
    unknown["Nutzen, ohne den Mechanismus zu kennen"] --> fear["Unsicherer Weiterbetrieb, den niemand anfasst"]
    known["Nutzen, nachdem der Mechanismus verstanden ist"] --> judge["Begründete Entscheidung"]
    judge -.-> j1["Wie weit man sich stützen kann"]
    judge -.-> j2["Was ihn bricht"]
    judge -.-> j3["Wann neu geschrieben werden soll"]

Abbildung 1: Derselbe Weiterbetrieb hat eine andere Qualität, je nachdem, ob Unsicherheit ohne Kenntnis des Mechanismus herrscht oder eine Entscheidung auf Verständnis gründet.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (16 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Die erste Eingrenzung — ist es ein Problem, das ein Shim beheben kann?

2.1. Behebbar ist ein Problem der App im Benutzermodus

Was ein Shim kann, bleibt im Rahmen dessen, was auch eine Codekorrektur in der App leisten könnte. Es ist ein Ersatz, wenn der Quellcode fehlt, der Herstellersupport endete oder sich jetzt nicht korrigieren lässt; es ist nicht mächtiger als eine Codekorrektur.¹

Probleme wie Startverweigerung nach Blick auf die OS-Version, Annahme eines alten Schreiborts oder Anfordern nicht wirklich nötiger Administratorrechte sind Kandidaten. Kapitel 5 sieht sich die konkreten Shims an.

2.2. Fälle, die kein Ausprobieren von Einstellungen löst

Die folgenden Probleme brauchen andere Maßnahmen als den Kompatibilitätsmodus.

Kernelmodus-Probleme und Sicherheitsgrenzen folgen aus dem Ort, an dem der Shim läuft.¹ ForceAdminAccess und WRPMitigation täuschen nur Erfolg bei Prüfung oder Schreiben vor, damit die App weiterläuft; sie schreiben geschützte Ressourcen nicht wirklich um.²

Bei 16-Bit prüfen Sie nicht nur die App selbst, sondern auch den Installer. Ist nur der Startteil (Stub) eines alten Pakets 16-Bit, obwohl die App 32-Bit ist, ergibt sich „die App läuft, die Installation nicht“. Auf 64-Bit-Windows haben Handles 32 gültige Bits und lassen sich nicht auf 16-Bit kürzen; 16-Bit-Apps werden nicht unterstützt, der Start scheitert mit ERROR_BAD_EXE_FORMAT.⁴

flowchart TB
    accTitle: Fälle, in denen ein Shim nicht wirkt
    accDescr: Ein Shim läuft im Benutzermodusprozess und wirkt daher nicht auf Kernelmodus-Treiberprobleme, 16-Bit-Apps, direkten Hardwarezugriff und die Umgehung von Sicherheitsmechanismen
    shim["Shim (läuft im Benutzermodus)"] -->|wirkt nicht| drv["Kerneltreiber"]
    shim -->|wirkt nicht| b16["16-Bit-App"]
    shim -->|wirkt nicht| hw["Direkter Hardwarezugriff"]
    shim -->|wirkt nicht| sec["Umgehung von Sicherheitsmechanismen"]
    b16 -.-> fmt["Auf 64-Bit scheitert schon der Start"]
    sec -.-> fake["Nur Erfolg vortäuschen, damit es weitergeht"]

Abbildung 2: Ein Shim ist auf den Benutzermodus beschränkt und reicht nicht an Kernel, 16-Bit, direkten Hardwarezugriff oder Sicherheitsumgehung heran.

Außerdem können Apps mit Kopierschutz oder Integritätsprüfung den API-Hook selbst als Anomalie werten. Nicht jede Benutzermodus-App lässt sich mit einem Shim retten.

3. Ähnliche Funktionen trennen — Shim, UAC-Virtualisierung, WOW64, DPI-Virtualisierung

Wenn „die alte App lief“, muss nicht nur ein Shim am Werk gewesen sein. Windows hat mehrere Schichten der Abwärtskompatibilität. In der Praxis können mehrere zusammenwirken.

3.1. UAC-Virtualisierung: Schreibziele je Benutzer umleiten

Die UAC-Virtualisierung ist eine Übergangsmaßnahme für interaktive 32-Bit-Prozesse ohne Manifest. Microsoft selbst stuft sie als vorläufige Technik ein, die aus einem künftigen Windows entfernt werden soll.⁵ WOW64, das 32-Bit-Apps ausführt, und UAC-Virtualisierung, die Schreibziele je Benutzer umleitet, sind verschiedene Mechanismen.

Umleitung nach Wow6432Node und die praktischen Folgen von VirtualStore behandelt „Fallstricke der 32-/64-Bit-Registrierungsumleitung und -virtualisierung“. Dieser Artikel bleibt bei der Abgrenzung zum Shim.

flowchart TB
    accTitle: Einordnung der UAC-Virtualisierung
    accDescr: Die UAC-Virtualisierung ist eine Übergangsmaßnahme für interaktive 32-Bit-Prozesse ohne Manifest, leitet Schreibzugriffe in einen benutzerspezifischen VirtualStore um und wird von Microsoft als vorläufige Technik bezeichnet, die aus einem künftigen Windows entfernt werden soll
    proc["Interaktiver 32-Bit-Prozess ohne Manifest"] --> uacv["UAC-Virtualisierung greift"]
    uacv --> vs["Umleitung in den benutzerspezifischen VirtualStore"]
    uacv -.-> tmp["Vorläufige Technik, die entfernt werden soll"]

Abbildung 3: Die UAC-Virtualisierung ist eine Übergangsmaßnahme für 32-Bit-Prozesse ohne Manifest und dauerhaft nicht belastbar.

3.2. DPI-Virtualisierung: alte Zeichnung strecken

Apps, die keine DPI-Unterstützung erklären, werden so behandelt, als zeichneten sie bei 96 DPI (100 %). Windows streckt dieses Bitmap, daher wirkt die Anzeige auf hochauflösenden Monitoren unscharf. „Hohe DPI-Einstellungen überschreiben“ auf der Registerkarte Kompatibilität ist der Schalter für dieses Virtualisierungsverhalten.⁶

flowchart TB
    accTitle: Mechanik der DPI-Virtualisierung
    accDescr: Apps ohne DPI-Erklärung werden als bei 96 DPI zeichnend behandelt, Windows streckt das Bitmap und die Anzeige wird unscharf; das Überschreiben der hohen DPI-Einstellungen auf der Registerkarte Kompatibilität schaltet dieses Verhalten um
    app["App ohne DPI-Erklärung"] --> treat["Als 96 DPI zeichnend behandelt"]
    treat --> stretch["Bitmap gestreckt angezeigt"]
    stretch --> blur["Auf hochauflösenden Monitoren unscharf"]
    tab["Hohe DPI-Einstellungen überschreiben"] -.->|schaltet das Virtualisierungsverhalten| treat

Abbildung 4: DPI-unfähige Apps werden als 96 DPI behandelt und gestreckt; das Überschreiben auf der Registerkarte Kompatibilität ist der Schalter dieser Virtualisierung.

4. Warum der Kompatibilitätsmodus sie zum Laufen bringt — Shims und die Anwendung beim Start

4.1. Das Ziel von API-Aufrufen ersetzen

Der Weg, auf dem eine Windows-EXE (PE-Format) APIs einer externen DLL aufruft, führt über die Import Address Table (IAT). Ein Aufruf von GetVersionEx geht etwa an die in der IAT stehende Adresse.

Ein Shim schreibt diesen IAT-Eintrag beim Laden der App auf die Adresse des Shim-Codes um. Das ist der API-Hook. Auch APIs, die dynamisch über GetProcAddress geholt werden, behandelt er, indem er GetProcAddress selbst hookt.¹

Der eingeschaltete Shim gibt etwa eine alte OS-Version zurück oder hängt Dateizugriffe um und ruft bei Bedarf die echte API. Der App zeigt er „das erwartete Windows-Verhalten“, dem OS übergibt er Aufrufe, die zum heutigen Mechanismus passen — ein Dolmetscher.

flowchart TB
    accTitle: Der Weg, auf dem ein Shim in API-Aufrufe tritt
    accDescr: API-Aufrufe der App laufen über die IAT; beim Laden wird der IAT-Eintrag auf den Shim umgeschrieben, der Shim tritt ein, täuscht dieselbe Antwort wie ein älteres Windows vor und ruft bei Bedarf die echte API
    app["App"] -->|API-Aufruf| iat["IAT-Eintrag"]
    iat -->|beim Laden auf den Shim umgeschrieben| shim["Shim (Dolmetscher)"]
    shim -->|bei Bedarf| api["Echte Windows-API"]
    shim -.-> lie["Dieselbe Antwort wie ein älteres Windows vortäuschen"]
    gpa["Aufruf über GetProcAddress"] -.->|per Hook behandelt| shim

Abbildung 5: Zwischen App und Windows-API tritt ein Shim. Umgeschrieben wird die IAT der App; das OS selbst ändert sich nicht.

Was sich ändert, ist der Aufrufweg der App, nicht das OS. Der Shim läuft unter denselben Sicherheitsbeschränkungen wie die App; für die Nutzung müssen SicherheitsEinstellungen des OS nicht gelockert werden.¹

4.2. Die .sdb entscheidet, welche EXE was erhält

Die Shim-Datenbank ist eine Binärdatei mit der Erweiterung .sdb. Sie identifiziert die EXE über Abgleichsattribute wie Dateiname, Größe, Prüfsumme und Version und gleicht beim Prozessstart ab. Die Begriffe trennen sich so:⁷

Abgeglichen wird nicht nur bei Apps, für die jemand den Kompatibilitätsmodus gesetzt hat. Bei jedem Prozessstart findet ein Abgleich mit der Standarddatenbank des OS statt. Windows enthält Korrekturen für Tausende bekannter Apps; die Dateien liegen unter %WINDIR%\AppPatch. Von Microsoft bereitgestellte Kompatibilitätskorrekturen werden als Teil von Windows ausgeliefert und über Windows Update aktualisiert.¹

flowchart TB
    accTitle: Abgleich mit der Shim-Datenbank beim Prozessstart
    accDescr: Bei jedem Prozessstart wird mit der Shim-Datenbank abgeglichen; gibt es einen Treffer nach Abgleichsattributen, folgen Shim-Einbindung per Appfix oder eine Apphelp-Meldung, sonst der unveränderte Start
    start["Prozessstart"] --> db["Abgleich mit der Shim-Datenbank (.sdb)"]
    db -.-> attr["Abgleich nach Dateiname, Größe und so weiter"]
    db --> hit{"Eintrag vorhanden?"}
    hit -->|Ja| appfix["Appfix (Shim einbinden)"]
    hit -->|Ja| apphelp["Apphelp (Meldung anzeigen)"]
    hit -->|Nein| plain["Unverändert starten"]
    layer["Kompatibilitätsschicht (Kompatibilitätsmodus)"] -.->|Bündel mehrerer Shims und Flags| appfix

Abbildung 6: Der Abgleich läuft nicht nur bei Apps mit gesetztem Kompatibilitätsmodus, sondern bei jedem Prozessstart.

Eine Kompatibilitätsschicht enthält neben API-Hooks auch Flags beim Start. RunAsInvoker in Kapitel 7 fängt keine API ab, sondern wirkt als Lader-Flag auf die Ausführungsebene beim Start.³

4.3. PCA kann ein Problem finden und anwenden

Auch ohne manuelle Einstellung durch die Administration kann PCA (Program Compatibility Assistant) Kompatibilitätseinstellungen anwenden. PCA beobachtet die Ausführung der App, erkennt Anzeichen bekannter Probleme und schlägt eine Korrektur vor oder wendet sie in manchen Fällen automatisch an.⁸

Für eine App, die abstürzt, weil sie Code in einer bereits freigegebenen DLL aufruft, wird etwa PINDLL genutzt, für eine, die am Schreiben in geschützte Windows-Dateien scheitert, WRPMITIGATION.⁸

flowchart TB
    accTitle: Ablauf, in dem PCA Kompatibilitätseinstellungen automatisch setzt
    accDescr: PCA beobachtet die Ausführung der App, erkennt Anzeichen bekannter Kompatibilitätsprobleme und schlägt dem Benutzer eine Korrektur vor oder wendet in manchen Fällen automatisch Kompatibilitätseinstellungen an
    run["Ausführung der App"] --> pca["PCA beobachtet"]
    pca --> sign{"Anzeichen eines bekannten Problems?"}
    sign -->|Ja| resp{"Welcher Fall?"}
    resp -->|per Vorschlag| suggest["Anwenden einer Korrektur vorschlagen"]
    resp -->|manche Fälle| auto["Kompatibilitätseinstellungen automatisch anwenden"]
    sign -->|Nein| none["Unverändert ausführen"]
    auto -.-> ex["Beispiel: PINDLL oder WRPMITIGATION"]

Abbildung 7: PCA beobachtet die Ausführung der App und schlägt bei Anzeichen bekannter Probleme eine Korrektur vor oder wendet sie automatisch an.

„Ich habe nichts gesetzt, und doch war das Häkchen im Kompatibilitätsmodus da“ folgt oft diesem Weg. Es muss kein Defekt oder Fehlbedienung sein; Windows kann auf ein Problem reagiert haben.

5. Die Korrektur nach dem Symptom wählen — typische Shims und Versionsprüfung

5.1. Was fertige Shims nachholen können

Aus den von Microsoft veröffentlichten fertigen Shims die, die beim Weiterbetrieb von Geschäftsanwendungen häufig vorkommen.²

Viele Shims geben die Antwort zurück, die die alte App erwartet. „Datenträgerplatz bis 2 GB“, „OS ist XP“, „Administratorprüfung erfolgreich“ — die Annahmen der Entstehungszeit werden nur in diesem Prozess nachgebildet. Wie in Kapitel 2 gesehen, sind das Vortäuschen einer Antwort und die Änderung tatsächlicher Rechte oder Ressourcen verschieden.

5.2. Der Wert von GetVersionEx ändert sich auch ohne gewählten Kompatibilitätsmodus

Versionsfälschung ist nicht nur die Folge eines manuell gewählten Kompatibilitätsmodus. Ab Windows 8.1 hängt der von GetVersionEx zurückgegebene Wert vom Manifest der App ab. Ohne <supportedOS>-Erklärung in <compatibility> kommt auch auf neuem Windows ein Windows-8-äquivalentes 6.2. Mit Erklärung kommt der Wert bis zum höchsten erklärten OS. Eine App, die die GUID von Windows 8.1 erklärt, erhält auch auf Windows 11 6.3.⁹¹⁰

Ist zusätzlich ein Shim der VersionLie-Familie angewendet, wird die im Kompatibilitätsmodus gewählte OS-Version gemeldet. Standardantwort aus dem Manifest und Ersetzung durch den Shim müssen der Reihe nach betrachtet werden.⁹

flowchart TB
    accTitle: Wie die OS-Version entsteht, die die App sieht
    accDescr: Den von GetVersionEx zurückgegebenen Wert bestimmt das Vorhandensein der supportedOS-Erklärung im Manifest; ohne Erklärung kommt Windows-8-äquivalentes 6.2, mit Erklärung der Wert bis zum höchsten erklärten OS, und ein Shim der VersionLie-Familie überschreibt mit der gewählten OS-Version
    q["Abfrage von GetVersionEx"] --> m{"supportedOS-Erklärung vorhanden?"}
    m -->|Nein| v62["Windows-8-äquivalent (6.2) kommt zurück"]
    m -->|Ja| decl["Wert bis zum höchsten erklärten OS"]
    v62 --> lie{"Shim der VersionLie-Familie angewendet?"}
    decl --> lie
    lie -->|Ja| fake["Wert des im Kompatibilitätsmodus gewählten OS"]
    lie -->|Nein| asis["Der Wert kommt unverändert zurück"]

Abbildung 8: Die Windows-Version, die die App sieht, entsteht mehrstufig aus Manifest und Shim.

Deshalb teilen sich auch die Prüfstellen nach Symptom. Hält die eigene App Windows 11 für Windows 8, prüfen Sie zuerst die supportedOS-Erklärung. Verweigert eine alte App den Start nur wegen der Versionsprüfung, lohnt ein Versuch mit VersionLie. Das eigentliche Verhalten ist auf dem neuen OS oft unproblematisch; dieser Typ lässt sich mit einem Shim wahrscheinlich über die Startverweigerung bringen.

flowchart TB
    accTitle: Zwei versionsbedingte Symptome und die Gegenmaßnahmen
    accDescr: Hält die eigene App Windows 11 für 8, ist die supportedOS-Erklärung im Manifest verdächtig; eine alte App, die den Start nach Versionsprüfung verweigert, lässt sich mit einem VersionLie-Shim oft durchbringen
    sym1["Windows 11, aber als 8 erkannt"] --> fix1["supportedOS-Erklärung prüfen"]
    sym2["Startverweigerung nach Versionsprüfung"] --> fix2["Mit VersionLie durchzubringen versuchen"]
    fix2 -.-> why["Das Verhalten selbst ist auf dem neuen OS oft unproblematisch"]

Abbildung 9: Veraltete Erkennung spricht für das Manifest, Startverweigerung für VersionLie.

6. Zuerst auf einem Rechner prüfen — Registerkarte Kompatibilität und Layers-Schlüssel

6.1. Sehen, wohin die Kontrollkästchen gespeichert werden

Auf der Registerkarte Kompatibilität gespeicherte Einstellungen stehen im Registrierungsschlüssel AppCompatFlags\Layers. Dieselbe Stelle nutzen auch DXGI-Kompatibilitätseinstellungen für die Angabe der Kompatibilitätsschicht.¹¹

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

Bei einer EXE mit „Windows XP (Service Pack 3)“, „Dieses Programm als Administrator ausführen“ und „Hohe DPI-Einstellungen überschreiben“ sieht man etwa:

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

Typische Zuordnungen von Eintrag und Wert sind die folgenden. Es sind Beispiele unter Windows 11; Namen und Werte können je nach OS-Version abweichen.

6.2. Benutzer der Anwendung und Zeitpunkt der Anwendung trennen

Die HKCU-Seite gilt nur für diesen Benutzer. Speichern Sie über „Einstellungen für alle Benutzer ändern“, steht derselbe Schlüssel unter HKLM und gilt für alle Benutzer. Beim Provisionieren prüfen Sie, wo gespeichert wurde.

Angewendet auf den Prozess wird die Einstellung beim nächsten Start dieser EXE. Der Lader liest den gespeicherten Wert und wendet die zugehörige Kompatibilitätsschicht an.

flowchart TB
    accTitle: Ablauf, bis die Einstellung der Registerkarte Kompatibilität greift
    accDescr: Die Einstellung der Registerkarte Kompatibilität wird als EXE-Pfad und Wert im Layers-Schlüssel von AppCompatFlags gespeichert; beim nächsten Start dieser EXE liest der Lader den Wert und wendet die zugehörige 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 Start der EXE"]
    boot --> loader["Lader liest den Wert"]
    loader --> apply["Kompatibilitätsschicht auf den Prozess anwenden"]
    reg -.-> hkcu["HKCU gilt nur für diesen Benutzer"]
    reg -.-> hklm["HKLM gilt für alle Benutzer"]

Abbildung 10: Die Substanz des Kontrollkästchens ist das Schreiben in den Layers-Schlüssel; angewendet wird beim nächsten Start.

6.3. Kompatibilitätsmodus und Erhöhungseinstellung nicht vermengen

RUNASADMIN sitzt im selben Layers-Schlüssel wie WINXPSP3. Wirkt es, als hätte „Kompatibilitätsmodus setzen“ die Erhöhung mitgeliefert oder entfernt, trennt ein Blick auf den Wert die Angabe der Kompatibilitätsschicht von der der Erhöhung.

Die Registerkarte Kompatibilität ist der Eingang zu typischen Fertigschichten. Einzelne Shims zu wählen und zu kombinieren übernimmt Compatibility Administrator in Kapitel 8. Zuvor RunAsInvoker, das im Alltag häufig vorkommt.

7. RunAsInvoker — nur unnötige Erhöhungsanfragen unterdrücken

7.1. „Verlangt Administrator“ und „braucht Administratorrechte“ trennen

Manche alten Geschäftsanwendungen verlangen bei jedem Start eine UAC-Erhöhung, weil das Manifest requireAdministrator setzt oder Name und Inhalt der EXE als Installer fehl erkannt werden. Oft wird das nur aus der XP-Zeit weiter verlangt, ohne dass Administratorrechte wirklich genutzt werden.

RunAsInvoker überschreibt sowohl Installer-Erkennung als auch Manifestverarbeitung und startet mit dem vom Elternprozess geerbten Token. Ist der Aufrufer ein Standardbenutzer, bleibt es dabei.³

flowchart TB
    accTitle: Wie RunAsInvoker Erhöhungsanfragen unterdrückt
    accDescr: Die requireAdministrator-Erklärung im Manifest und die Fehlkennung als Installer verursachen die UAC-Erhöhungsanfrage beim Start; mit RunAsInvoker werden beide überschrieben, und der Start erfolgt mit dem vom Elternprozess geerbten Token
    manifest["requireAdministrator-Erklärung"] --> shim{"RunAsInvoker angewendet?"}
    detect["Als Installer fehl erkannt"] --> shim
    shim -->|Nein| uac["Bei jedem Start UAC-Erhöhungsanfrage"]
    shim -->|Ja| token["Start mit dem Token des Elternprozesses"]
    token -.-> limit["Arbeit, die Administrator braucht, scheitert in der App"]

Abbildung 11: RunAsInvoker überschreibt nur die Ursache der Erhöhungsanfrage; Rechte steigen nicht.

7.2. Vorübergehend über eine Umgebungsvariable versuchen

Ohne .sdb lässt sich dieselbe Schicht vorübergehend über die Umgebungsvariable __COMPAT_LAYER anwenden. Die folgenden Beispiele gelten für Kindprozesse, die von dieser Eingabeaufforderung oder PowerShell gestartet werden.

:: RunAsInvoker auf Kindprozesse anwenden, die von dieser Eingabeaufforderung starten
set __COMPAT_LAYER=RunAsInvoker
start "" "C:\LegacyApp\Gyomu.exe"

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

Übernehmen Sie es erst, wenn die für das Geschäft nötigen Vorgänge mit denselben Standardrechten wie beim tatsächlichen Benutzer laufen.² Braucht die App keine Administratorrechte, lässt sich der Befehl als Batchdatei statt einer Verknüpfung verteilen und so die Ausgabe lokaler Administratorrechte und das Rufen der IT wegen jedes UAC-Kennworts verringern. Eine Kompatibilitätstechnik in Richtung geringster Rechte.

flowchart TB
    accTitle: Wirkung der Verteilung einer RunAsInvoker-Batch
    accDescr: Eine Zwei-Zeilen-Batch, die RunAsInvoker setzt, als Verknüpfung zu verteilen vermeidet die Ausgabe lokaler Administratorrechte an Standardbenutzer, die IT wird nicht wegen UAC-Kennwort gerufen, und der Betrieb folgt dem Prinzip der geringsten Rechte
    bat["Zwei-Zeilen-Batch verteilen"] --> noadmin["Administratorrechte müssen nicht ausgegeben werden"]
    bat --> nocall["IT wird nicht wegen UAC gerufen"]
    noadmin --> lp["Betrieb nach dem Prinzip der geringsten Rechte"]
    nocall --> lp

Abbildung 12: Allein die Verteilung einer Batch kann Ausgabe von Administratorrechten und Rufe wegen UAC verringern.

7.3. Wirkungsbereich, dauerhafte Anwendung und Korrektur der App trennen

RunAsInvoker erhöht keine Rechte. Schreiben nach HKLM oder Aktualisieren unter Program Files, das wirklich Administratorrechte braucht, scheitert in der App. Unter den passenden Bedingungen kann UAC-Virtualisierung in den VirtualStore umleiten. Wirkt das Speichern von Einstellungen „plötzlich unwirksam“, verdächtigen Sie die Virtualisierung.⁵

Die Umgebungsvariablenmethode gilt für Kindprozesse, die diese Umgebung erben. Für dauerhafte Anwendung dienen die direkte Einstellung im Layers-Schlüssel oder die Verteilung einer .sdb. Einen Eintrag RUNASINVOKER gibt es auf der Registerkarte Kompatibilität nicht.

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 starten; dauerhaft setzen Sie direkt im Layers-Schlüssel oder verteilen über eine .sdb
    env["Über 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 sdb verteilen"] --> always

Abbildung 13: Die Umgebungsvariablenmethode ist vorübergehend und auf Kindprozesse begrenzt; Dauerhaftes geschieht über Layers-Schlüssel oder .sdb.

Lässt sich die App korrigieren, ist das eigentliche Vorgehen nicht mehr Kompatibilitätseinstellungen, sondern Speicherort der Einstellungsdatei unter %APPDATA% und asInvoker im Manifest.³

8. In der Organisation ausbringen — Compatibility Administrator und sdbinst

8.1. 32-Bit/64-Bit von App und Werkzeug zusammenbringen

Compatibility Administrator liegt im Windows ADK (Windows Assessment and Deployment Kit).¹² Es werden 32-Bit- und 64-Bit-Ausgabe installiert; für 32-Bit-Apps die 32-Bit-Ausgabe, für 64-Bit-Apps die 64-Bit-Ausgabe.¹³

Ein weiterer Vorbehalt: nicht als Administrator testen und „behoben“ urteilen. Im erhöhten Zustand greifen UAC-Virtualisierung und Umleitung nicht wie vorgesehen, und das Ergebnis wird falsch gelesen. Die Wirkung der Korrektur prüfen Sie mit demselben Konto und denselben Rechten wie der tatsächliche Benutzer.²

flowchart TB
    accTitle: Zwei Vorbehalte bei der Nutzung von Compatibility Administrator
    accDescr: Für 32-Bit-Apps die 32-Bit-Ausgabe, für 64-Bit-Apps die 64-Bit-Ausgabe verwenden, und die Wirkung der Korrektur nicht im erhöhten Zustand, sondern mit demselben Konto und denselben Rechten wie der tatsächliche Benutzer prüfen
    app32["32-Bit-App"] --> tool32["Mit der 32-Bit-Ausgabe korrigieren"]
    app64["64-Bit-App"] --> tool64["Mit der 64-Bit-Ausgabe korrigieren"]
    elev["Im erhöhten Zustand testen"] -.-> wrong["Gefahr, fälschlich ‚behoben‘ zu urteilen"]
    user["Mit denselben Rechten wie der tatsächliche Benutzer testen"] --> ok["Wirkung korrekt prüfen"]

Abbildung 14: Die Wahl der 32-/64-Bit-Ausgabe und die Prüfung mit denselben Rechten wie der tatsächliche Benutzer sind die Einstiegsvorbehalte.

8.2. Zuerst eine Schicht versuchen, dann auf nötige Shims und die Ziel-EXE eingrenzen

Eine benutzerdefinierte Kompatibilitätsdatenbank entsteht in dieser Reihenfolge.¹⁴

1. Im linken Bereich unter „Custom Databases“ eine neue Datenbank anlegen und „Create New“ → „Application Fix“ wählen.
2. App-Name und Hersteller eingeben und die Ziel-EXE angeben.
3. Einen Kompatibilitätsmodus (Schicht) wie „Windows XP-Kompatibilität“ wählen und zuerst das Shim-Bündel versuchen.
4. Bei Bedarf einzelne Kompatibilitätskorrekturen wählen. Es lässt sich auf ein Minimum eingrenzen, etwa nur VersionLie oder nur CorrectFilePaths.
5. Abgleichsbedingungen wie Dateigröße, Prüfsumme und Version prüfen und speichern.

„Den wirkenden Shim wählen“ und „ihn nur auf die richtige EXE wirken lassen“ sind beide nötig. Der Abgleich reicht mit den Standard-Basisbedingungen meist, aber Bedingungen, die die App-Version identifizieren, sollten bleiben. Sonst träfe nach einer Korrekturfassung des Herstellers die alte Korrektur weiter die neue Version.¹⁴¹⁵

flowchart TB
    accTitle: Schritte zum Anlegen einer benutzerdefinierten Kompatibilitätsdatenbank
    accDescr: In einer neuen Datenbank ein Application Fix anlegen, App-Name und Ziel-EXE angeben, das Bündel des Kompatibilitätsmodus versuchen, bei Bedarf auf einzelne Shims eingrenzen, Abgleichsbedingungen prüfen und speichern
    new["Neue Datenbank anlegen"] --> fix["Application Fix wählen"]
    fix --> info["App-Name und Ziel-EXE angeben"]
    info --> layer["Bündel des Kompatibilitätsmodus versuchen"]
    layer --> single["Bei Bedarf auf einzelne Shims eingrenzen"]
    single --> match["Abgleichsbedingungen prüfen und speichern"]
    match -.-> ver["Bedingung zur Versionsidentifikation belassen"]

Abbildung 15: Ein Application Fix versucht zuerst das Bündel des Kompatibilitätsmodus, grenzt auf ein Minimum ein und begrenzt das Ziel über Abgleichsbedingungen.

Die erstellte .sdb auf einem Prüfgerät versuchen und erst nach bestätigtem gewünschten Verhalten verteilen.

8.3. Mit sdbinst anwenden und entfernen, Updates über die GUID führen

Die Anwendung auf jedem PC erfolgt mit Administratorrechten über sdbinst.exe. Neben der Installation ist die Deinstallation per Datei oder Datenbank-GUID möglich.¹⁵

:: Installation (-q ist still, ohne Nachfrage)
sdbinst -q "C:\Deploy\MyCorpFixes.sdb"

:: Deinstallation (per Datei)
sdbinst -q -u "C:\Deploy\MyCorpFixes.sdb"

:: Deinstallation (per Datenbank-GUID)
sdbinst -q -u -g {GUID der Datenbank}

In Organisationen mit wachsenden Kompatibilitätskorrekturen empfiehlt sich eher, nicht je App-Installer eine eigene .sdb zu halten, sondern eine unternehmens- oder abteilungsweite benutzerdefinierte Datenbank zu bündeln und zentral zu führen. Viele Einzeiler-Datenbanken nachzuziehen ist schwerer als eine gebündelte Datenbank zu aktualisieren und erneut zu verteilen.¹⁵

Eine benutzerdefinierte Datenbank hat eine eigene GUID. Installieren Sie eine neue Version mit derselben GUID, wird die alte automatisch ersetzt. Die Verteilung legen Sie auf vorhandene Wege, die mit Administratorrechten laufen, etwa MSI-Pakete oder Startskripte.¹⁵

flowchart TB
    accTitle: Ablauf von der Erstellung einer benutzerdefinierten .sdb bis zur Verteilung
    accDescr: Die benutzerdefinierte Kompatibilitätsdatenbank in Compatibility Administrator anlegen, auf einem Prüfgerät testen, mit sdbinst auf die PCs anwenden; beim Update ersetzt die Installation einer neuen Version mit derselben GUID die alte automatisch
    make["In Compatibility Administrator anlegen"] --> test["Auf einem Prüfgerät testen"]
    test --> deploy["Mit sdbinst auf die PCs anwenden"]
    deploy --> update["Neue Version mit derselben GUID installieren"]
    update -.-> replace["Alte Version wird automatisch ersetzt"]
    deploy -.-> inv["Wird unter Programme und Features eingetragen"]

Abbildung 16: Eine benutzerdefinierte .sdb wird über Anlegen, Prüfen und sdbinst-Verteilung ausgebracht; Updates laufen über die GUID.

Installierte benutzerdefinierte Datenbanken erscheinen auch unter „Programme und Features“ (installierte Apps) und dienen der Bestandsaufnahme und der Prüfung der Entfernung. Welche .sdb auf welchem PC liegt, bleibt auch im Anlagenverzeichnis.

9. Nach dem Laufen entscheiden — Wartung des Weiterbetriebs und Frist der Migration

9.1. Vom OS bereitgestellte Korrekturen und die eigene Anwendungsentscheidung trennen

Dass es mit einem Shim läuft, hat das Problem der App nicht selbst behoben. Ein Shim ist eine Notlösung für eine bestimmte API-Nutzung; ändert sich die OS-Implementierung, können die Annahmen fallen.

Von Microsoft bereitgestellte Shims selbst werden als Teil von Windows über Windows Update gewartet.¹ Was eine benutzerdefinierte Datenbank anwendet und ob sich mit dieser Kombination der Betrieb fortsetzen lässt, führt die eigene Organisation. Die Prüfung bei jedem Feature-Update gehört zu den Kosten des Weiterbetriebs.

flowchart TB
    accTitle: Shim als Notlösung und die Wartungsverantwortung
    accDescr: Ein Shim ist eine auf eine bestimmte API-Nutzung zugeschnittene Notlösung, deren Annahmen fallen, wenn sich die OS-Implementierung ändert; von Microsoft bereitgestellte Shims wartet Windows Update, die Notlösung einer benutzerdefinierten Datenbank wartet die eigene Organisation, und die Prüfung bei jedem Feature-Update ist eine Kosten des Weiterbetriebs
    shim["Ein Shim ist eine Notlösung"] --> break["Ändert sich die OS-Implementierung, fallen die Annahmen"]
    ms["Von Microsoft bereitgestellte Shims"] --> wu["Wartung über Windows Update"]
    own["Notlösung der benutzerdefinierten Datenbank"] --> self["Die eigene Organisation wartet sie"]
    self --> cost["Prüfung bei jedem Feature-Update ist eine Kosten des Weiterbetriebs"]

Abbildung 17: Die Wartungsverantwortung für die Notlösung Shim teilt sich in den Microsoft-Teil und den eigenen benutzerdefinierten Teil.

9.2. Nach Restnutzungsdauer, Abhängigkeit und Prüfkapazität entscheiden

Allein die Tatsache „im Kompatibilitätsmodus lief es“ sollte keine langfristige Nutzung festlegen. Dass es mit einem Shim läuft, heißt, es passte in eine von Windows bereitgestellte Fassung. Entscheiden Sie entlang der folgenden Achsen gemeinsam.

9.3. Beim Weiterbetrieb Aufzeichnung, Prüfung und Frist als Satz nehmen

1. Aufzeichnen. Welche EXE, welcher Shim oder welche Schicht, warum. Werte des Layers-Schlüssels und GUID der .sdb ins Verzeichnis. Den nächsten Verantwortlichen nicht im Zustand „niemand weiß, warum es läuft“ zu lassen, ist dieselbe Erhaltung wie in „Wenn Sie ein System ohne Quellcode und ohne Dokumentation übernehmen“.
2. Prüfen. Bei Feature-Updates von Windows Start und Hauptvorgänge der im Weiterbetrieb befindlichen Apps bestätigen. Koppeln Sie das an die OS-Austauschplanung in „Praktische Optionen nach dem Support-Ende von Windows 10“.
3. Eine Frist setzen. Das Ende des Weiterbetriebs festlegen, etwa „bis zum nächsten Austausch des Kernsystems“ oder „bis März 2028“, und die Migrationsüberlegung parallel führen.

flowchart TB
    accTitle: Drei-Punkte-Satz für den beschlossenen Weiterbetrieb
    accDescr: Aufzeichnen, mit welchem Shim es läuft, bei jedem Feature-Update das Verhalten der im Weiterbetrieb befindlichen Apps prüfen, das Ende des Weiterbetriebs festlegen und die Migrationsüberlegung parallel führen
    decide["Weiterbetrieb beschließen"] --> rec["Aufzeichnen: welcher Shim, ins Verzeichnis"]
    rec --> verify["Prüfen: Verhalten bei jedem Feature-Update"]
    verify --> deadline["Frist: Ende des Weiterbetriebs festlegen"]
    deadline --> mig["Migrationsüberlegung parallel führen"]

Abbildung 18: Weiterbetrieb umfasst Aufzeichnung, Prüfung und Frist plus parallele Migrationsüberlegung.

9.4. Shims nutzen, um Zeit für Überlegung und Vorbereitung der Migration zu gewinnen

Die Migrationsoptionen hängen von der Technik der App ab. Bei VB6 sind der Ausgangspunkt die drei Wege vollständiges Neuschreiben, automatische Konvertierung und stufenweise Migration in „Wie lange laufen VB6-Anwendungen noch?“. Bei ActiveX/OCX-Abhängigkeit hilft die Entscheidungstabelle „behalten, kapseln, ersetzen“ in „ActiveX / OCX heute behandeln“.

Gesund ist, Shims als Mittel zu sehen, die Überlegungs- und Vorbereitungszeit eines solchen Migrationsprojekts sicher zu gewinnen.

flowchart TB
    accTitle: Migrationsoptionen und die Einordnung von Shims
    accDescr: Die üblichen Migrationswege hängen von der Technik der App ab; bei VB6 drei Wege Neuschreiben, automatische Konvertierung und stufenweise Migration, bei ActiveX die Entscheidungstabelle behalten, kapseln, ersetzen; Shims dienen dazu, Zeit für Überlegung und Vorbereitung des Migrationsprojekts sicher zu gewinnen
    tech{"Technik der App?"} -->|VB6| vb["Neuschreiben, automatische Konvertierung, stufenweise Migration"]
    tech -->|ActiveX-Abhängigkeit| ax["Behalten, kapseln, ersetzen"]
    shim["Weiterbetrieb mit Shim"] -.->|gewinnt Zeit für Überlegung und Vorbereitung| tech

Abbildung 19: Die üblichen Migrationswege bestimmt die Technik der App; Shims gewinnen die Zeit für diese Überlegung.

10. Zusammenfassung

Der Kompatibilitätsmodus holt nur für die App das Verhalten nach, das ein älteres Windows voraussetzte. Der zentrale Shim tritt über IAT-Umschreibung in API-Aufrufe ein und ergänzt Versionsprüfung und Zugriffsorte. Windows selbst nutzt ihn über die Standarddatenbank und PCA.

Das Vorgehen: zuerst klären, ob der Anwendungsbereich eines Shims vorliegt, dann nötige Einstellungen über Registerkarte Kompatibilität und RunAsInvoker prüfen, in der Organisation mit Compatibility Administrator und sdbinst führen. Wahl der 32-/64-Bit-Werkzeuge, Prüfung mit den Rechten des tatsächlichen Benutzers, Führung von Ziel und Fassung über Abgleichsbedingungen und GUID sind die praktischen Punkte.

Er bleibt jedoch auf den Benutzermodus beschränkt und umgeht keine Sicherheitsmechanismen. Kerneltreiber, 16-Bit-Apps auf 64-Bit-Windows und direkter Hardwarezugriff brauchen andere Maßnahmen. RunAsInvoker unterdrückt nur unnötige Erhöhungsanfragen und erhöht keine Rechte.

Nach dem Laufen Einstellungen aufzeichnen, bei jedem Feature-Update prüfen, eine Frist setzen und die Migration parallel führen. Das gehört zur Entscheidung, sich auf den Kompatibilitätsmodus zu stützen.

Wenn das nächste Mal eine alte App nach einem Kontrollkästchen läuft, fragen Sie erneut. „Dank welcher Notlösung läuft diese App? Wie lange gilt diese Notlösung?“ Lässt sich das beantworten, ist Weiterbetrieb 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 ihres Weiterbetriebs (Auswahl von Shims und Kompatibilitätsmodus, Aufbau und Ausrollen einer benutzerdefinierten .sdb), die Kompatibilitätsprüfung bestehender Anwendungen für eine Windows-11-Migration sowie die Planung eines Neuschreibens oder einer Migration parallel zum Weiterbetrieb. 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 Erhöhungsanfragen 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 Erhöhung 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.