Cara kerja kompatibilitas aplikasi Windows — mode kompatibilitas, shim, dan Compatibility Administrator

«Aplikasi bisnis berusia sepuluh tahun yang kode sumbernya sudah hilang tidak mau mulai di PC Windows 11 baru. Saya mencentang ‘Windows XP’ di tab Kompatibilitas pada dialog properti dan langsung jalan. — Apa yang sebenarnya terjadi? Apakah aman terus mengandalkan ini?» Itu konsultasi yang sering kami dengar.

Ketika satu kotak centang membuat sesuatu berjalan, rasa waswas itu wajar. Identitas sebenarnya mode kompatibilitas, yang tampak seperti sihir, adalah kumpulan potongan kode kecil yang disebut shim yang duduk di antara aplikasi dan Windows API dan mengembalikan «kebohongan». Windows sendiri memakai jalan pintas ini secara besar-besaran untuk menjaga aplikasi dari banyak generasi tetap berjalan, dan membuka sebagian mekanismenya kepada pengguna dan administrator.

Dipakai tanpa memahami mekanisme, perpanjangan umur menjadi «kita tidak boleh menyentuhnya karena kita tidak tahu mengapa berjalan» yang tidak stabil. Pahami mekanismenya dan Anda dapat memutuskan, dengan alasan, sejauh mana Anda dapat mengandalkannya dengan aman, apa yang akan merusaknya, dan kapan Anda harus menulis ulang.

flowchart TB
    accTitle: Memahami mekanisme mengubah mutu perpanjangan umur
    accDescr: Memakai mode kompatibilitas tanpa memahami mekanisme mengarah ke perpanjangan umur tidak stabil yang tidak berani disentuh; memahami mekanisme memungkinkan keputusan beralasan sejauh mana bisa diandalkan, apa yang merusaknya, dan kapan harus menulis ulang
    unknown["Memakai tanpa memahami mekanisme"] --> fear["Perpanjangan umur tidak stabil yang tidak berani disentuh"]
    known["Memakai setelah memahami mekanisme"] --> judge["Keputusan dengan alasan"]
    judge -.-> j1["Sejauh mana bisa diandalkan"]
    judge -.-> j2["Apa yang akan merusaknya"]
    judge -.-> j3["Kapan harus menulis ulang"]

Gambar 1: Bahkan untuk perpanjangan umur yang sama, mutunya berbeda antara kecemasan karena tidak mengetahui mekanisme dan keputusan berdasarkan pemahaman.

Ditujukan kepada staf IT usaha kecil dan menengah serta pengembang aplikasi Windows yang merawat aplikasi bisnis lama, artikel ini merapikan, dari sumber primer Microsoft Learn, mekanisme shim yang merupakan identitas sebenarnya mode kompatibilitas, apa yang dapat dilakukan shim perwakilan, cara menerapkannya secara organisasi dengan Compatibility Administrator, batas yang tidak dapat diselamatkan shim, dan cara memutuskan antara perpanjangan umur dan migrasi.

1. Kesimpulan dulu

• Identitas sebenarnya mode kompatibilitas adalah shim (lapisan kompatibilitas). Pengaturan dari tab Kompatibilitas ditulis ke HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers, dan bundel shim diterapkan ke proses saat mulai.¹²
• Shim adalah hook API user-mode yang menulis ulang import address table (IAT). Ia mencegat jalur aplikasi memanggil Windows API dan mengembalikan jawaban yang sama seperti Windows lama. Ia tidak mengubah OS itu sendiri.³
• Apa yang dapat dilakukan shim adalah rentang yang sama dengan perbaikan kode di aplikasi. Ia tidak dapat melewati mekanisme keamanan, dan tidak dapat memperbaiki masalah kernel-mode (driver perangkat).³
• Microsoft mengirimkan banyak shim siap pakai — kebohongan versi, pemetaan ulang jalur file, pemalsuan registri, pemalsuan pemeriksaan administrator, dan lainnya. Anda dapat menerapkannya ke EXE individu dari Compatibility Administrator.⁴
• Windows sendiri memakai shim secara default. Basis data kompatibilitas standar OS (.sdb) dicocokkan pada setiap peluncuran, dan PCA (Program Compatibility Assistant) juga dapat mendeteksi masalah dan menerapkan pengaturan kompatibilitas secara otomatis.¹⁵
• «Menjawab seolah-olah ini Windows yang lebih lama» kini menjadi default. Mulai Windows 8.1, GetVersionEx tidak mengembalikan versi OS yang belum dideklarasikan aplikasi di manifesnya. Mode kompatibilitas adalah perpanjangan mekanisme itu.⁶⁷
• Shim tidak bekerja pada aplikasi 16-bit, ketergantungan driver kernel, atau akses perangkat keras langsung. Khususnya, aplikasi 16-bit sama sekali tidak dapat berjalan di Windows 64-bit.⁸
• Untuk aplikasi yang «memerlukan administrator tetapi sebenarnya tidak membutuhkannya», RunAsInvoker adalah langkah standar. __COMPAT_LAYER=RunAsInvoker menekan permintaan elevasi dan membiarkan aplikasi berjalan di bawah hak standar.⁹
• Berjalan di bawah shim berarti Anda dapat memperpanjang umur untuk saat ini, tetapi jalur sebenarnya adalah «membuatnya berjalan tanpa shim». Jika Anda memutuskan memperpanjang umur, catat shim mana yang membuatnya berjalan dan kelola itu sebagai bahan keputusan penulisan ulang.

2. Gambar besar kompatibilitas aplikasi — lapisan kompatibilitas mundur yang sudah dimiliki Windows

Sebelum berbicara tentang shim, berikut daftar mekanisme yang sudah dimiliki Windows untuk aplikasi lama. Bahkan ketika orang berkata «mulai berjalan di mode kompatibilitas», yang sebenarnya menyelamatkan aplikasi adalah salah satu lapisan ini, atau kombinasi beberapa.

Virtualisasi UAC adalah langkah transisi yang berlaku untuk proses interaktif 32-bit tanpa manifes, dan Microsoft sendiri menyatakan itu «teknologi sementara yang kami maksudkan untuk dihapus dari versi Windows di masa depan».¹⁰ Kerusakan nyata dari pengalihan Wow6432Node dan VirtualStore, serta cara mengatasinya, dibahas rinci di «Registry 32-bit/64-bit Redirection and Virtualization Pitfalls»; artikel ini menempatkan shim di pusat dan menyebut lapisan lain hanya sejauh diperlukan.

flowchart TB
    accTitle: Di mana virtualisasi UAC duduk
    accDescr: Virtualisasi UAC adalah langkah transisi untuk proses interaktif 32-bit tanpa manifes; ia mengalihkan penulisan ke VirtualStore per pengguna, tetapi Microsoft sendiri menyatakan itu teknologi sementara yang dimaksudkan untuk dihapus dari Windows di masa depan
    proc["Proses interaktif 32-bit tanpa manifes"] --> uacv["Virtualisasi UAC berlaku"]
    uacv --> vs["Dialihkan ke VirtualStore per pengguna"]
    uacv -.-> tmp["Teknologi sementara yang dimaksudkan untuk dihapus nanti"]

Gambar 2: Virtualisasi UAC adalah langkah transisi untuk proses 32-bit tanpa manifes, dan Anda tidak dapat mengandalkannya secara permanen.

Sebagai catatan samping tentang virtualisasi DPI: aplikasi yang belum mendeklarasikan kesadaran DPI diperlakukan sebagai menggambar pada 96 DPI (100%), dan Windows meregangkan bitmap untuk tampilan. Itulah mengapa aplikasi lama terlihat «kabur» di monitor DPI tinggi, dan «Ganti perilaku penskalaan DPI tinggi» di tab Kompatibilitas adalah sakelar yang mengubah perilaku virtualisasi ini.¹¹

flowchart TB
    accTitle: Cara kerja virtualisasi DPI
    accDescr: Aplikasi yang belum mendeklarasikan kesadaran DPI diperlakukan sebagai menggambar pada 96 DPI; Windows meregangkan bitmap sehingga terlihat kabur, dan penggantian pengaturan DPI tinggi di tab Kompatibilitas mengganti perilaku virtualisasi ini
    app["Aplikasi yang tidak mendeklarasikan kesadaran DPI"] --> treat["Diperlakukan sebagai menggambar pada 96 DPI"]
    treat --> stretch["Bitmap diregangkan untuk tampilan"]
    stretch --> blur["Terlihat kabur di monitor DPI tinggi"]
    tab["Ganti perilaku penskalaan DPI tinggi"] -.->|Mengganti perilaku virtualisasi| treat

Gambar 3: Aplikasi yang tidak sadar DPI diperlakukan sebagai 96 DPI dan diregangkan; penggantian di tab Kompatibilitas adalah sakelar virtualisasi ini.

3. Apa sebenarnya shim — mencegat di antara API dengan menulis ulang IAT

3.1. «Penerjemah» yang berdiri di antara aplikasi dan OS

Eksekutable Windows (format PE) memanggil API di DLL eksternal melalui import address table (IAT). Ketika aplikasi memanggil GetVersionEx, ia hanya meloncat ke alamat yang tertulis di IAT. Mekanisme shim memanfaatkan itu. Saat muat ia menulis ulang entri IAT API target ke alamat kode shim dan menyelipkan dirinya di antara aplikasi dan Windows. API yang diperoleh secara dinamis melalui GetProcAddress ditangani dengan mengait GetProcAddress itu sendiri.³

Setelah mencegat, shim mungkin mengembalikan nomor versi lama ke «apa versi OS saat ini?», atau memetakan ulang akses file ke lokasi yang tidak dapat ditulis ke tempat lain, lalu memanggil API sungguhan jika diperlukan. Dari sudut pandang aplikasi seolah «berjalan di Windows lama»; dari sudut pandang OS seolah «aplikasi yang sopan sedang berjalan» — shim adalah penerjemah di antara keduanya.

flowchart TB
    accTitle: Jalur shim mencegat panggilan API
    accDescr: Panggilan API aplikasi melewati IAT; menulis ulang entri IAT ke shim saat muat memungkinkan shim mencegat, memalsukan respons yang sama seperti Windows lama, lalu memanggil API sungguhan jika diperlukan
    app["Aplikasi"] -->|Panggilan API| iat["Entri IAT"]
    iat -->|Ditulis ulang ke shim saat muat| shim["Shim (penerjemah)"]
    shim -->|Jika diperlukan| api["Windows API sungguhan"]
    shim -.-> lie["Memalsukan respons yang sama seperti Windows lama"]
    gpa["Panggilan via GetProcAddress"] -.->|Ditangani oleh hook| shim

Gambar 4: Shim mencegat di antara aplikasi dan Windows API. Yang ditulis ulang adalah IAT sisi aplikasi; OS itu sendiri tidak berubah.

Tiga sifat penting mengikuti dari rancangan ini.³

1. Shim berjalan sebagai kode sisi aplikasi. Ia bukan bagian OS, jadi tunduk pada batasan keamanan yang sama dengan aplikasi. Shim tidak dapat melewati mekanisme keamanan OS, dan Anda tidak perlu longgarkan pengaturan keamanan untuk memakai shim.
2. Apa yang dapat diperbaiki shim, perbaikan kode sisi aplikasi juga dapat memperbaikinya. Shim adalah pengganti untuk kasus «tidak ada sumber / kita tidak dapat memperbaiki»; ia tidak lebih kuat daripada perbaikan kode.
3. Hanya user mode. Masalah kompatibilitas driver perangkat yang berjalan di kernel mode tidak dapat diperbaiki oleh shim.

3.2. Basis data shim (.sdb) dan pencocokan

Tabel korespondensi «shim mana yang diterapkan ke EXE mana» adalah basis data shim, berkas biner dengan ekstensi .sdb. Eksekutable aplikasi target didaftarkan di basis data menurut atribut seperti nama file, ukuran, checksum, dan versi (atribut pencocokan), dan dicocokkan saat proses mulai. Obat termasuk Appfix (shim), yang menyuntikkan hook API, dan Apphelp, yang menampilkan pesan «aplikasi ini punya masalah kompatibilitas». Bundel beberapa shim dan flag adalah lapisan kompatibilitas (mode kompatibilitas).¹

Mudah terlewat: pencocokan ini tidak hanya berjalan pada aplikasi yang punya mode kompatibilitas, tetapi pada setiap peluncuran proses. Windows mengirimkan basis data standar OS berisi perbaikan untuk ribuan aplikasi yang dikenal (berkasnya di bawah %WINDIR%\AppPatch), dan di PC Anda hari ini hampir pasti ada aplikasi lama yang mulai dengan shim terpasang tanpa siapa pun menyadari. Perbaikan kompatibilitas yang disediakan Microsoft dikirim sebagai bagian Windows dan diperbarui melalui Windows Update.³

flowchart TB
    accTitle: Mencocokkan basis data shim saat proses mulai
    accDescr: Setiap peluncuran proses dicocokkan dengan basis data shim; jika pendaftaran cocok dengan atribut pencocokan, Appfix menyuntikkan shim atau Apphelp menampilkan pesan, jika tidak proses mulai apa adanya
    start["Proses mulai"] --> db["Cocokkan dengan .sdb"]
    db -.-> attr["Nama file, ukuran, dll."]
    db --> hit{"Ada pendaftaran?"}
    hit -->|Ya| appfix["Appfix: suntikkan shim"]
    hit -->|Ya| apphelp["Apphelp: sebuah pesan"]
    hit -->|Tidak| plain["Mulai apa adanya"]
    layer["Lapisan kompatibilitas"] -.->|bundel shim dan flag| appfix

Gambar 5: Pencocokan berjalan pada setiap peluncuran proses, bukan hanya pada aplikasi yang punya mode kompatibilitas.

3.3. PCA — mekanisme yang menerapkan shim secara otomatis

Jalur lain di mana shim dapat diterapkan tanpa niat administrator adalah PCA (Program Compatibility Assistant). PCA mengawasi eksekusi aplikasi dan, ketika mendeteksi tanda masalah kompatibilitas yang dikenal, mengusulkan menerapkan perbaikan kepada pengguna atau, dalam beberapa kasus, menerapkan pengaturan kompatibilitas secara otomatis. Misalnya, aplikasi yang mogok karena memanggil kode di dalam DLL yang sudah dibebaskan diberi PINDLL, dan aplikasi yang gagal menulis ke berkas Windows yang dilindungi diberi WRPMITIGATION.⁵

flowchart TB
    accTitle: Cara PCA menerapkan pengaturan kompatibilitas secara otomatis
    accDescr: PCA mengawasi eksekusi aplikasi dan, ketika mendeteksi tanda masalah kompatibilitas yang dikenal, mengusulkan menerapkan perbaikan kepada pengguna atau, dalam beberapa kasus, menerapkan pengaturan kompatibilitas secara otomatis
    run["Eksekusi aplikasi"] --> pca["PCA mengawasi"]
    pca --> sign{"Tanda masalah yang dikenal?"}
    sign -->|Ya| resp{"Kasus yang mana?"}
    resp -->|Ditangani dengan usulan| suggest["Usulkan menerapkan perbaikan"]
    resp -->|Beberapa kasus| auto["Terapkan pengaturan kompatibilitas secara otomatis"]
    sign -->|Tidak| none["Jalankan apa adanya"]
    auto -.-> ex["Contoh: PINDLL atau WRPMITIGATION"]

Gambar 6: PCA mengawasi eksekusi aplikasi dan, ketika mendeteksi tanda masalah yang dikenal, mengusulkan perbaikan atau menerapkan satu secara otomatis.

Identitas «saya tidak pernah mengatur apa pun, tetapi pada suatu saat kotak centang mode kompatibilitas menyala» dalam banyak kasus adalah ini. Bukan kerusakan dan bukan salah klik; Windows berperilaku sesuai rancangan.

4. Apa yang dapat dilakukan shim perwakilan

Dari shim siap pakai yang diterbitkan Microsoft, berikut pilihan yang benar-benar sering muncul saat memperpanjang umur aplikasi bisnis.⁴

Melihat daftarnya, sebagian besar shim adalah «kebohongan yang mengembalikan jawaban yang diharapkan aplikasi lama». Disk paling banyak 2GB, OS adalah XP, Anda adalah administrator — mereka menciptakan kembali, hanya di dalam proses itu, pandangan dunia era ketika aplikasi lahir.

Pemalsuan versi telah menjadi «perilaku default resmi»

Pemalsuan versi bukan peretasan khusus. Mulai Windows 8.1, nilai yang dikembalikan GetVersionEx bergantung pada manifes aplikasi. Aplikasi tanpa deklarasi <supportedOS> di bagian <compatibility> manifes selalu diberi setara Windows 8 (6.2), apa pun OS sebenarnya. Ketika ada deklarasi, nilai hingga OS tertinggi di antara yang dideklarasikan dikembalikan (misalnya, jika Anda telah mendeklarasikan hingga GUID Windows 8.1, Anda mendapat 6.3 bahkan di Windows 11).⁶⁷

Jadi «versi Windows yang dilihat aplikasi» diputuskan dalam tahap bertumpuk ini.

1. Nilai hingga OS yang dideklarasikan di manifes dikembalikan (6.2 jika tidak ada deklarasi)
2. Jika mode kompatibilitas (shim keluarga VersionLie) diterapkan, versi OS yang dipilih dikembalikan⁶

flowchart TB
    accTitle: Cara versi OS yang dilihat aplikasi diputuskan
    accDescr: Nilai yang dikembalikan GetVersionEx diputuskan oleh apakah ada deklarasi supportedOS di manifes; tanpa deklarasi setara Windows 8 6.2 dikembalikan, dengan deklarasi nilai hingga OS tertinggi yang dideklarasikan, dan jika shim keluarga VersionLie diterapkan ia ditimpa dengan versi OS yang dipilih
    q["Kueri GetVersionEx"] --> m{"Ada deklarasi supportedOS?"}
    m -->|Tidak| v62["Setara Windows 8 (6.2) dikembalikan"]
    m -->|Ya| decl["Nilai hingga OS tertinggi yang dideklarasikan"]
    v62 --> lie{"Shim keluarga VersionLie diterapkan?"}
    decl --> lie
    lie -->|Ya| fake["Nilai OS yang dipilih di mode kompatibilitas"]
    lie -->|Tidak| asis["Nilai dikembalikan apa adanya"]

Gambar 7: Versi Windows yang dilihat aplikasi diputuskan dalam tahap bertumpuk oleh manifes dan oleh shim.

Jika aplikasi internal «bercabang pada versi OS dan, membingungkan, dinilai sebagai 8 meskipun ini Windows 11», curigai dulu deklarasi supportedOS di manifes. Sebaliknya, aplikasi lama yang menolak mulai berdasarkan pemeriksaan versi, dengan probabilitas tinggi, dapat diloloskan dengan shim VersionLie. Dalam banyak kasus ia hanya melihat nomor versi, dan perilaku sebenarnya baik-baik saja di OS yang lebih baru.

flowchart TB
    accTitle: Dua gejala akibat versi dan cara mengatasinya
    accDescr: Jika aplikasi internal dinilai sebagai 8 meskipun ini Windows 11, curigai deklarasi supportedOS di manifes; aplikasi lama yang menolak mulai pada pemeriksaan versi, dengan probabilitas tinggi, dapat diloloskan dengan shim VersionLie
    sym1["Dinilai sebagai 8 meskipun ini Windows 11"] --> fix1["Curigai deklarasi supportedOS"]
    sym2["Mulai ditolak pada pemeriksaan versi"] --> fix2["Coba loloskan dengan VersionLie"]
    fix2 -.-> why["Perilaku sebenarnya sering baik-baik saja di OS yang lebih baru"]

Gambar 8: Ketika penilaian sudah usang, curigai manifes; ketika mulai ditolak, curigai VersionLie.

5. Apa yang dilakukan kotak centang mode kompatibilitas

Pengaturan dari Properti → tab Kompatibilitas disimpan di kunci registri AppCompatFlags\Layers. Pengaturan kompatibilitas aplikasi DXGI dan sejenisnya memakai kunci yang sama sebagai tempat menentukan lapisan kompatibilitas.² Mari lihat sebenarnya.

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

Untuk EXE yang Anda atur «Windows XP (Service Pack 3)», «Jalankan program ini sebagai administrator», dan «Ganti perilaku penskalaan DPI tinggi» di tab Kompatibilitas, Anda akan melihat nilai seperti berikut.

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

Korespondensi perwakilan antara item kotak centang dan nilai (dikonfirmasi di Windows 11; nama item dan nilai dapat berubah menurut versi OS).

Tiga poin untuk diingat.

• «Jalankan program ini sebagai administrator» ditulis di tempat yang sama. Mode kompatibilitas dan flag elevasi hidup bersama di kunci Layers yang sama, dan di situlah kebingungan «saya mengatur mode kompatibilitas dan elevasi ikut datang / hilang» lahir. Melihat nilai secara langsung memisahkan keduanya.
• Yang ditulis di HKCU adalah «pengaturan pengguna itu». Jika Anda mengaturnya dari «Ubah pengaturan untuk semua pengguna» di tab, itu ditulis ke kunci bernama sama di sisi HKLM dan berlaku untuk semua pengguna. Saat mendistribusikannya dalam imaging, sadari ke sisi mana Anda menulis.
• Kotak centang hanyalah pintu masuk ke lapisan siap pakai. Tab hanya membiarkan Anda memilih lapisan perwakilan; Anda tidak dapat memilih shim individu dan menggabungkannya. Itulah yang dilakukan Compatibility Administrator di bab berikutnya.

flowchart TB
    accTitle: Jalur dari pengaturan tab Kompatibilitas hingga berlaku
    accDescr: Pengaturan tab Kompatibilitas disimpan sebagai jalur EXE dan nilai di kunci AppCompatFlags Layers; saat EXE itu mulai berikutnya, loader membaca nilai dan menerapkan lapisan kompatibilitas yang sesuai ke proses
    tab["Atur di tab Kompatibilitas"] --> reg["Simpan jalur EXE dan nilai di kunci Layers"]
    reg --> boot["Mulai EXE berikutnya"]
    boot --> loader["Loader membaca nilai"]
    loader --> apply["Terapkan lapisan kompatibilitas ke proses"]
    reg -.-> hkcu["HKCU hanya pengguna itu"]
    reg -.-> hklm["HKLM berlaku untuk semua pengguna"]

Gambar 9: Kotak centang pada kenyataannya adalah penulisan ke kunci Layers, dan penerapan terjadi pada mulai berikutnya.

6. Compatibility Administrator dalam praktik — membangun dan mendistribusikan .sdb kustom

6.1. Cara mendapatkannya, dan peringatan

Compatibility Administrator adalah alat yang termasuk dalam Windows ADK (Windows Assessment and Deployment Kit).¹² Setelah instalasi, edisi 32-bit dan 64-bit keduanya ada, dan Anda harus memakai edisi 32-bit untuk aplikasi 32-bit dan edisi 64-bit untuk aplikasi 64-bit.¹³

Ada peringatan penting lain. Jika Anda memulai Compatibility Administrator dalam keadaan terangkat (sebagai administrator) dan menguji, virtualisasi UAC dan pengalihan tidak berperilaku seperti untuk pengguna nyata, dan Anda dapat salah menilai bahwa «sudah diperbaiki». Selalu konfirmasi efek perbaikan dengan akun dan hak yang sama seperti pengguna sebenarnya.⁴

flowchart TB
    accTitle: Dua peringatan saat memakai Compatibility Administrator
    accDescr: Pakai edisi 32-bit untuk aplikasi 32-bit dan edisi 64-bit untuk aplikasi 64-bit, dan konfirmasi efek perbaikan dengan akun dan hak yang sama seperti pengguna sebenarnya, bukan dalam keadaan terangkat
    app32["Aplikasi 32-bit"] --> tool32["Pakai edisi 32-bit"]
    app64["Aplikasi 64-bit"] --> tool64["Pakai edisi 64-bit"]
    elev["Uji dalam keadaan terangkat"] -.-> wrong["Dapat salah menilai perbaikan"]
    user["Uji dengan hak yang sama seperti pengguna"] --> ok["Konfirmasi efek"]

Gambar 10: Memilih edisi 32-bit atau 64-bit, dan mengonfirmasi dengan hak yang sama seperti pengguna sebenarnya, adalah peringatan di pintu masuk.

6.2. Prosedur membangun basis data kompatibilitas kustom

Garis besarnya sebagai berikut.¹⁴

1. Di panel kiri Compatibility Administrator, buat basis data baru di bawah «Custom Databases» dan pilih «Create New» → «Application Fix»
2. Masukkan nama aplikasi dan nama vendor, dan tentukan berkas EXE target
3. Pilih mode kompatibilitas (lapisan) yang akan diterapkan — mencoba bundel seperti «kompatibilitas Windows XP» dulu adalah jalan pendek
4. Jika diperlukan, tambahkan perbaikan kompatibilitas individu (shim) — Anda dapat mempersempit ke himpunan minimal seperti hanya VersionLie atau hanya CorrectFilePaths
5. Konfirmasi kondisi pencocokan (ukuran file, checksum, versi, dan sebagainya) dan simpan

Kondisi pencocokan adalah kunci «terapkan ini hanya ke EXE ini». Kondisi dasar default biasanya cukup, tetapi kami merekomendasikan meninggalkan kondisi yang dapat mengidentifikasi versi aplikasi. Itu mencegah kecelakaan kebohongan lama terus diterapkan ke versi baru ketika vendor nanti mengirim edisi yang sudah diperbaiki.¹⁴¹⁵

flowchart TB
    accTitle: Prosedur membangun basis data kompatibilitas kustom
    accDescr: Buat Application Fix di basis data baru, tentukan nama aplikasi dan EXE target, coba bundel mode kompatibilitas dulu lalu persempit ke shim individu jika diperlukan, konfirmasi kondisi pencocokan, dan simpan
    new["Buat basis data baru"] --> fix["Pilih Application Fix"]
    fix --> info["Tentukan nama aplikasi dan EXE target"]
    info --> layer["Coba bundel mode kompatibilitas"]
    layer --> single["Jika diperlukan, persempit ke shim individu"]
    single --> match["Konfirmasi kondisi pencocokan dan simpan"]
    match -.-> ver["Tinggalkan kondisi yang mengidentifikasi versi"]

Gambar 11: Untuk Application Fix, coba bundel mode kompatibilitas dulu, persempit ke himpunan minimal, dan batasi sasaran dengan kondisi pencocokan.

Uji .sdb yang Anda buat di mesin validasi dulu. Setelah berjalan sesuai niat, Anda menggelarnya ke organisasi.

6.3. Mendistribusikan dengan sdbinst

Perintah yang menerapkan .sdb kustom ke setiap PC adalah sdbinst.exe (memerlukan hak administrator).¹⁵

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

Sebagai strategi penerapan organisasi, Microsoft merekomendasikan mengonsolidasikan menjadi satu basis data kustom di seluruh perusahaan (atau per departemen) dan mengelolanya secara terpusat, daripada mengirim .sdb terpisah bersama penginstal setiap aplikasi. Semakin banyak perbaikan, semakin mudah memperbarui dan mendistribusikan ulang satu basis data daripada mendistribusikan banyak basis data satu baris. Basis data kustom punya GUID sendiri, dan menginstal versi baru dengan GUID yang sama secara otomatis mengganti versi lama, jadi operasi pembaruan juga tetap sederhana. Letakkan distribusi itu sendiri pada jalur yang sudah ada yang dapat berjalan dengan hak administrator, misalnya pengemasan sebagai MSI atau skrip startup.¹⁵

flowchart TB
    accTitle: Jalur dari membuat .sdb kustom hingga mendistribusikannya
    accDescr: Buat basis data kompatibilitas kustom di Compatibility Administrator, uji di mesin validasi, terapkan ke setiap PC dengan sdbinst, dan saat pembaruan instal versi baru dengan GUID yang sama agar versi lama diganti secara otomatis
    make["Buat di Compatibility Administrator"] --> test["Uji di mesin validasi"]
    test --> deploy["Terapkan ke setiap PC dengan sdbinst"]
    deploy --> update["Instal versi baru dengan GUID yang sama"]
    update -.-> replace["Versi lama diganti secara otomatis"]
    deploy -.-> inv["Didaftarkan di Program and Features"]

Gambar 12: .sdb kustom digelar melalui buat, validasi, dan distribusi sdbinst, dan pembaruan dikelola menurut GUID.

Basis data kustom yang terinstal didaftarkan sebagai item di «Program and Features (Aplikasi terinstal)», jadi Anda juga dapat mengonfirmasi inventaris dan penghapusan dari sana. PC mana yang punya .sdb mana adalah informasi yang termasuk dalam buku besar manajemen aset.

7. Kasus di mana tidak bekerja, dan batasnya

Shim bukan peluru perak. Secara rancangan mereka tidak bekerja dalam kasus berikut.

• Masalah kernel-mode. Shim berjalan di dalam proses user-mode, jadi ketidakcocokan driver perangkat tidak dapat diperbaiki. Jika driver instrumen ukur lama, dongle USB, atau printer tidak mendukung Windows 11, apa pun yang Anda terapkan di sisi aplikasi tidak akan menyelesaikannya. Kode yang berjalan di kernel, seperti bagian perangkat lunak antivirus, sama saja.³
• Aplikasi 16-bit. Windows 64-bit tidak mendukung menjalankan aplikasi 16-bit. Handle punya 32 bit valid di Windows 64-bit dan tidak dapat dipotong untuk diteruskan ke aplikasi 16-bit, jadi mulai gagal dengan ERROR_BAD_EXE_FORMAT.⁸ Bahkan ketika aplikasi itu sendiri 32-bit, paket dari era itu yang stub penginstalnya 16-bit ada, dan muncul sebagai «aplikasinya akan berjalan, tetapi kita tidak dapat menginstalnya».
• Akses perangkat keras langsung. Aplikasi industri yang mengasumsikan dapat menyentuh port I/O atau memori fisik secara langsung tidak diizinkan melakukannya dari user mode di Windows modern, dan itu di luar rentang yang dapat dipalsukan shim.
• Melewati mekanisme keamanan. Karena shim berjalan di bawah batasan keamanan yang sama dengan aplikasi, ia tidak dapat membuat «sesuatu yang tidak dapat Anda lakukan karena kurang hak» menjadi mungkin. ForceAdminAccess dan WRPMitigation hanya memalsukan keberhasilan pemeriksaan atau penulisan agar aplikasi dapat lanjut; mereka tidak benar-benar menulis ulang sumber daya yang dilindungi.³⁴
• Aplikasi yang memeriksa integritasnya sendiri. Aplikasi dengan perlindungan salinan lama atau deteksi gangguan dapat memperlakukan hook API itu sendiri sebagai tidak normal dan berhenti bekerja.

flowchart TB
    accTitle: Kasus di mana shim tidak bekerja
    accDescr: Shim berjalan di dalam proses user-mode, jadi tidak bekerja pada masalah driver kernel-mode, aplikasi 16-bit, akses perangkat keras langsung, atau melewati mekanisme keamanan
    shim["Shim (berjalan di user mode)"] -->|Tidak bekerja| drv["Driver kernel"]
    shim -->|Tidak bekerja| b16["Aplikasi 16-bit"]
    shim -->|Tidak bekerja| hw["Akses perangkat keras langsung"]
    shim -->|Tidak bekerja| sec["Melewati mekanisme keamanan"]
    b16 -.-> fmt["Di 64-bit, mulai itu sendiri gagal"]
    sec -.-> fake["Hanya memalsukan keberhasilan agar aplikasi lanjut"]

Gambar 13: Shim hanya user-mode dan tidak menjangkau kernel, aplikasi 16-bit, akses perangkat keras langsung, atau bypass keamanan.

Dan batas esensial yang sama bagi setiap shim adalah bahwa ia adalah jalan pintas. Shim adalah kebohongan yang disesuaikan dengan pemakaian tertentu dari API tertentu, dan jika implementasi sisi OS berubah, asumsinya runtuh. Shim yang disediakan Microsoft dipelihara sebagai bagian Windows melalui Windows Update,³ tetapi merawat kebohongan yang Anda terapkan dengan basis data kustom adalah pekerjaan organisasi Anda. Anggarkan, sebagai biaya perpanjangan umur, operasi yang memvalidasi «daftar aplikasi yang dijaga hidup oleh shim» pada setiap pembaruan fitur.

flowchart TB
    accTitle: Shim sebagai jalan pintas, dan siapa yang bertanggung jawab merawatnya
    accDescr: Shim adalah kebohongan yang disesuaikan dengan pemakaian API tertentu dan asumsi runtuh jika implementasi sisi OS berubah; shim Microsoft dipelihara melalui Windows Update, tetapi merawat kebohongan yang diterapkan dengan basis data kustom adalah pekerjaan organisasi, dan validasi pada setiap pembaruan fitur adalah biaya perpanjangan umur
    shim["Shim = kebohongan jalan pintas"] --> break["Perubahan OS merusaknya"]
    ms["Shim Microsoft"] --> wu["Melalui Windows Update"]
    own["Kebohongan basis data kustom"] --> self["Organisasi merawatnya"]
    self --> cost["Validasi setiap pembaruan adalah biaya perpanjangan umur"]

Gambar 14: Tanggung jawab merawat kebohongan shim terbagi antara himpunan yang disediakan Microsoft dan himpunan kustom organisasi Anda.

8. Nilai praktis RunAsInvoker — menenangkan hanya permintaan elevasi

Di antara shim, yang paling sering muncul dalam pekerjaan IT sehari-hari adalah RunAsInvoker.

Beberapa aplikasi bisnis lama mendeklarasikan requireAdministrator di manifes, atau salah dideteksi sebagai penginstal dari nama atau isi EXE, dan meminta elevasi UAC setiap kali mulai. Banyak dari mereka, meski begitu, hanya meminta administrator karena inersia era XP dan tidak benar-benar memakai hak administrator. Menerapkan shim RunAsInvoker menimpa deteksi penginstal dan manifes, dan aplikasi mulai dengan token yang diwarisi dari proses induk (= hak pengguna standar).⁹

flowchart TB
    accTitle: Cara RunAsInvoker menekan permintaan elevasi
    accDescr: Deklarasi requireAdministrator di manifes atau salah deteksi sebagai penginstal menyebabkan permintaan elevasi UAC saat mulai, tetapi menerapkan RunAsInvoker menimpa keduanya dan aplikasi mulai dengan token yang diwarisi dari induk
    manifest["Deklarasi requireAdministrator"] --> shim{"RunAsInvoker diterapkan?"}
    detect["Salah dideteksi sebagai penginstal"] --> shim
    shim -->|Tidak| uac["Permintaan elevasi UAC setiap mulai"]
    shim -->|Ya| token["Mulai dengan token induk"]
    token -.-> limit["Pekerjaan yang benar-benar membutuhkan administrator gagal di dalam aplikasi"]

Gambar 15: RunAsInvoker hanya menimpa penyebab permintaan elevasi; hak istimewa tidak meningkat.

Bahkan tanpa membangun .sdb di Compatibility Administrator, Anda dapat menerapkan lapisan yang sama sementara dengan variabel lingkungan __COMPAT_LAYER.

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

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

Jika Anda mengubah dua baris itu menjadi berkas batch dan mendistribusikannya sebagai pintasan, Anda dapat menghindari menyerahkan hak administrator lokal kepada pengguna standar, dan IT tidak lagi dipanggil setiap kali untuk kata sandi UAC. Ini teknik kompatibilitas yang mengeraskan pertahanan, sejalan dengan hak istimewa paling sedikit.

flowchart TB
    accTitle: Efek mendistribusikan batch RunAsInvoker
    accDescr: Mendistribusikan batch dua baris yang mengatur RunAsInvoker sebagai pintasan berarti Anda dapat menghindari menyerahkan hak administrator lokal kepada pengguna standar, IT tidak dipanggil untuk kata sandi UAC, dan operasi mengikuti hak istimewa paling sedikit
    bat["Distribusikan batch dua baris"] --> noadmin["Anda dapat menghindari menyerahkan hak administrator"]
    bat --> nocall["IT tidak dipanggil untuk UAC"]
    noadmin --> lp["Operasi yang mengikuti hak istimewa paling sedikit"]
    nocall --> lp

Gambar 16: Mendistribusikan batch saja dapat mengurangi baik penyerahan hak administrator maupun dipanggil untuk UAC.

Peringatannya juga, dengan jelas.

• Hak istimewa tidak meningkat. Pekerjaan yang benar-benar membutuhkan hak administrator (penulisan ke HKLM, pembaruan di bawah Program Files, dan sebagainya) akan error di dalam aplikasi, atau, jika kondisinya terpenuhi, dialihkan ke VirtualStore oleh virtualisasi UAC.¹⁰ Jika menyimpan pengaturan tiba-tiba «berhenti bekerja», curigai virtualisasi.
• Metode variabel lingkungan hanya berlaku untuk proses anak. Untuk penerapan permanen, pengaturan langsung di kunci Layers (RUNASINVOKER tidak punya item di tab) atau distribusi melalui .sdb lebih andal.
• Memperbaiki tujuan penulisan adalah jalur sebenarnya. Jika Anda dapat mengubah aplikasi, pindahkan berkas pengaturan ke bawah %APPDATA% dan deklarasikan asInvoker di manifes — itu bentuk yang benar.⁹

flowchart TB
    accTitle: Penerapan sementara dan permanen RunAsInvoker
    accDescr: Penerapan melalui variabel lingkungan COMPAT_LAYER hanya berlaku untuk proses anak yang dimulai dari sana; untuk penerapan permanen pakai pengaturan langsung di kunci Layers atau distribusi melalui .sdb
    env["Atur melalui variabel lingkungan"] --> child["Hanya berlaku untuk proses anak"]
    child -.-> tmp["Penerapan sementara"]
    layers["Atur langsung di kunci Layers"] --> always["Penerapan permanen"]
    sdb["Distribusikan melalui sdb"] --> always

Gambar 17: Metode variabel lingkungan adalah penerapan sementara yang terbatas pada proses anak; membuatnya permanen dilakukan dengan kunci Layers atau .sdb.

9. Memutuskan antara perpanjangan umur dan migrasi — apa yang dipikirkan setelah berjalan di bawah shim

Saat berjalan di bawah shim adalah kelegaan, tetapi penting untuk tidak berhenti berpikir di situ. Berjalan di bawah shim hanya berarti ia kebetulan cocok dengan wadah yang disiapkan Windows. Sumbu keputusan, dalam tabel.

Jika Anda memutuskan perpanjangan umur, masukkan tiga poin berikut ke operasi sebagai satu set.

1. Catat. EXE mana, shim/lapisan mana, dan mengapa. Tinggalkan nilai kunci Layers dan GUID .sdb dalam buku besar. «Tidak ada yang tahu mengapa berjalan» adalah utang terbesar yang Anda tinggalkan kepada orang berikutnya. Ini pola pikir sadar pelestarian yang sama seperti di «When You Inherit a System With No Source Code and No Documentation».
2. Validasi. Sertakan mulai dan operasi utama aplikasi yang dijaga hidup oleh shim dalam item validasi pembaruan fitur Windows. Ikat juga ke rencana penggantian OS (Practical Options After Windows 10 End of Support).
3. Tetapkan tenggat. Putuskan akhir perpanjangan umur — «hingga penyegaran sistem inti berikutnya», «hingga Maret 2028» — dan jalankan pertimbangan migrasi secara paralel.

flowchart TB
    accTitle: Set operasi tiga poin setelah memutuskan perpanjangan umur
    accDescr: Catat di buku besar shim mana yang membuatnya berjalan, validasi perilaku aplikasi yang dijaga hidup oleh shim pada setiap pembaruan fitur, tetapkan tenggat akhir perpanjangan umur, dan jalankan pertimbangan migrasi secara paralel
    decide["Putuskan perpanjangan umur"] --> rec["Catat: shim mana yang membuatnya berjalan, ke buku besar"]
    rec --> verify["Validasi: konfirmasi perilaku pada setiap pembaruan fitur"]
    verify --> deadline["Tenggat: putuskan akhir perpanjangan umur"]
    deadline --> mig["Jalankan pertimbangan migrasi secara paralel"]

Gambar 18: Perpanjangan umur dioperasikan sebagai set tiga poin catat, validasi, dan tenggat, termasuk menjalankan pertimbangan migrasi secara paralel.

Di sisi migrasi, opsi standar berubah menurut teknologi aplikasi. Untuk VB6, pilihan tiga arah penulisan ulang penuh, konversi otomatis, dan migrasi bertahap yang dirapikan di «How Long Will VB6 Apps Keep Running?»; untuk ketergantungan ActiveX/OCX, tabel keputusan pertahankan / bungkus / ganti di «How to Handle ActiveX / OCX Today». Cara sehat menempatkan shim adalah sebagai membeli waktu agar periode pertimbangan dan persiapan proyek migrasi itu dapat berjalan dengan aman.

flowchart TB
    accTitle: Opsi di sisi migrasi, dan di mana shim duduk
    accDescr: Opsi migrasi standar berubah menurut teknologi aplikasi; untuk VB6 pilihan tiga arah adalah tulis ulang, konversi otomatis, dan migrasi bertahap, untuk ketergantungan ActiveX berlaku tabel pertahankan / bungkus / ganti, dan shim diposisikan sebagai membeli waktu untuk pertimbangan dan persiapan proyek migrasi
    tech{"Apa teknologi aplikasinya?"} -->|VB6| vb["Tulis ulang, konversi otomatis, atau migrasi bertahap"]
    tech -->|Ketergantungan ActiveX| ax["Pertahankan, bungkus, atau ganti"]
    shim["Perpanjangan umur via shim"] -.->|Membeli waktu untuk pertimbangan dan persiapan| tech

Gambar 19: Opsi migrasi standar diputuskan oleh teknologi aplikasi, dan shim diposisikan sebagai membeli waktu untuk pertimbangan itu.

10. Ringkasan

• Identitas sebenarnya mode kompatibilitas adalah shim. Pengaturan dari tab Kompatibilitas ditulis ke kunci AppCompatFlags\Layers dan disuntikkan ke proses saat mulai sebagai hook API melalui penulisan ulang IAT.
• Shim adalah kumpulan «kebohongan yang mengembalikan jawaban yang diharapkan aplikasi lama». Shim siap pakai untuk pemalsuan versi, pemetaan ulang jalur, pemalsuan registri, pemalsuan pemeriksaan administrator, dan sejenisnya disediakan.
• Windows sendiri memakai banyak shim secara default, dan PCA dapat menerapkannya secara otomatis. Mengandalkan mode kompatibilitas sendiri adalah pilihan wajar yang menunggangi mekanisme resmi OS.
• Ada batas prinsip hanya-user-mode dan tidak ada bypass keamanan, dan driver kernel, aplikasi 16-bit, serta akses perangkat keras langsung tidak dapat diselamatkan.
• Rollout organisasi adalah membangun .sdb kustom di Compatibility Administrator (Windows ADK) dan mendistribusikannya dengan sdbinst. Memilih edisi 32-bit/64-bit, menguji dengan akun pengguna sebenarnya, dan mengelola pembaruan menurut GUID adalah poin praktis.
• Aplikasi yang «memerlukan administrator tetapi sebenarnya tidak membutuhkannya» dapat diturunkan ke hak standar dengan __COMPAT_LAYER=RunAsInvoker. Ini teknik defensif yang menenangkan permintaan elevasi alih-alih membagikan hak.
• Berjalan di bawah shim adalah perpanjangan umur, bukan solusi. Mencatat apa yang membuatnya berjalan, memvalidasi pada setiap pembaruan fitur, dan menetapkan tenggat agar migrasi berjalan paralel — set tiga poin itu termasuk dalam keputusan «mengandalkan mode kompatibilitas».

Lain kali aplikasi lama mulai berjalan setelah kotak centang mode kompatibilitas, tanyakan lagi. «Kebohongan mana yang membuat aplikasi ini berjalan? Berapa lama kebohongan itu akan tetap bekerja?» Jika Anda dapat menjawab, perpanjangan umur adalah strategi yang terhormat.

Artikel terkait

• Registry 32-bit/64-bit Redirection and Virtualization Pitfalls — Wow6432Node and the “The Value I Wrote Isn’t There” Problem
• How Long Will VB6 Apps Keep Running? — Runtime Support Status and a Practical Path to .NET Migration
• How to Handle ActiveX / OCX Today - A Keep / Wrap / Replace Decision Table
• Practical Options After Windows 10 End of Support — A Decision Table for ESU, LTSC, and Replacement
• When You Inherit a System With No Source Code and No Documentation — A Practical Playbook for Keeping It Running
• Integrasi shell Windows hari ini — menu konteks, asosiasi file, dan apa yang berubah di Windows 11

Area konsultasi terkait

KomuraSoft LLC menangani investigasi bagaimana aplikasi bisnis lama tanpa kode sumber berperilaku dan merancang perpanjangan umurnya (memilih shim dan mode kompatibilitas, membangun dan menggelar .sdb kustom), validasi kompatibilitas aplikasi yang ada untuk migrasi Windows 11, dan perencanaan penulisan ulang atau migrasi yang berjalan paralel dengan perpanjangan umur. Konsultasi dari tahap «mulai berjalan di mode kompatibilitas, tetapi apakah aman membiarkannya seperti ini?» tidak masalah.

• Pemanfaatan ulang dan migrasi aset yang ada
• Pengembangan aplikasi Windows
• Konsultasi teknis dan tinjauan desain
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Jika aplikasi mulai berjalan setelah saya mencentang mode kompatibilitas, bolehkah terus dipakai seperti itu?

Untuk menjaga bisnis berjalan dalam jangka pendek, ya. Mode kompatibilitas adalah hook API user-mode yang disebut shim, mekanisme resmi yang disediakan OS. Namun shim tetap jalan pintas agar aplikasi berjalan tanpa diperbaiki, dan pembaruan OS lain dapat mengubah asumsi dan merusaknya lagi. Catat fakta bahwa aplikasi berjalan di mode kompatibilitas dalam buku besar, dan perlakukan catatan itu sebagai bagian dari keputusan menulis ulang aplikasi atau memperpanjang umurnya dengan sengaja.

Apa yang sebenarnya dilakukan kotak centang mode kompatibilitas?

Saat Anda menyimpan pengaturan di tab Kompatibilitas pada dialog properti, Windows menulis jalur EXE target dan nilai seperti "WINXPSP3" atau "HIGHDPIAWARE" di bawah kunci HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers. Saat EXE itu mulai berikutnya, loader Windows membaca nilai tersebut dan menerapkan lapisan kompatibilitas yang sesuai (bundel shim) ke proses. Mode kompatibilitas Windows XP, misalnya, memalsukan versi OS dengan mengembalikan nilai lama dari API kueri versi. OS itu sendiri tidak diubah; hanya proses itu yang ditunjukkan Windows lama yang pura-pura.

Bisakah aplikasi era 16-bit dijalankan di mode kompatibilitas pada Windows 64-bit?

Tidak. Windows 64-bit menjalankan aplikasi 32-bit melalui WOW64, tetapi tidak mendukung menjalankan aplikasi 16-bit, dan percobaan memulai gagal dengan ERROR_BAD_EXE_FORMAT. Itu batas arsitektur yang tidak dapat dielakkan shim. Paket lama yang stub penginstalnya 16-bit gagal karena alasan yang sama. Jika benar-benar dibutuhkan, Anda harus melihat di luar mode kompatibilitas — misalnya mesin virtual yang menyertakan Windows 32-bit.

Bisakah saya menjalankan aplikasi yang "tidak akan mulai kecuali dijalankan sebagai administrator" di bawah akun pengguna standar?

RunAsInvoker layak dicoba. Jika Anda menjalankan set __COMPAT_LAYER=RunAsInvoker di command prompt lalu memulai aplikasi, permintaan elevasi dari manifes requireAdministrator atau dari deteksi penginstal ditekan, dan aplikasi mulai dengan hak istimewa yang sama (pengguna standar) seperti pemanggil. Untuk aplikasi yang hanya meminta hak administrator dan tidak pernah benar-benar memakainya, ini saja dapat mengeluarkan elevasi dari operasi sehari-hari. Hak istimewa tidak meningkat, jadi pekerjaan yang benar-benar membutuhkan hak administrator akan gagal di dalam aplikasi. Adopsi hanya setelah Anda memverifikasi perilakunya.

Di mana saya mendapatkan Compatibility Administrator?

Termasuk dalam Windows ADK (Windows Assessment and Deployment Kit). Unduh ADK dari situs Microsoft dan, saat instalasi, pilih fitur Application Compatibility Tools. Edisi 32-bit dan 64-bit keduanya terinstal; Anda harus memakai edisi 32-bit untuk aplikasi 32-bit dan edisi 64-bit untuk aplikasi 64-bit. Terapkan basis data kompatibilitas kustom (.sdb) yang Anda buat dengan menjalankan perintah sdbinst di setiap PC.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.