Cara kerja kompatibilitas aplikasi Windows — memperpanjang umur aplikasi lama dengan mode kompatibilitas, shim, dan Compatibility Administrator

«Aplikasi bisnis berumur sepuluh tahun yang kode sumbernya sudah tidak ada tidak mau mulai di PC Windows 11 baru. Setelah «Windows XP» dicentang di tab Kompatibilitas pada dialog properti, aplikasi itu langsung berjalan. — Apa yang sebenarnya terjadi? Apakah aman terus mengandalkan keadaan ini?» Itu konsultasi yang sering kami terima dari klien.

Kalau satu centang saja membuat sesuatu berjalan, justru muncul rasa waswas. Identitas mode kompatibilitas yang tampak seperti sihir adalah kumpulan kode kecil yang disebut shim: potongan yang menyelip di antara aplikasi dan Windows API lalu mengembalikan «kebohongan». Windows sendiri memakai tindakan darurat ini secara besar-besaran agar aplikasi dari beberapa generasi tetap berjalan, dan membuka sebagian mekanismenya kepada pengguna dan administrator.

Dipakai tanpa memahami mekanismenya, yang terjadi adalah perpanjangan umur yang goyah: «jangan disentuh karena tidak jelas mengapa berjalan». Sebaliknya, jika mekanismenya dipahami, sejauh mana masih aman diandalkan, apa yang akan merusaknya, dan kapan harus ditulis ulang dapat diputuskan dengan alasan.

flowchart TB
    accTitle: Memahami mekanisme mengubah mutu perpanjangan umur
    accDescr: Memakai mode kompatibilitas tanpa memahami mekanisme mengarah ke perpanjangan umur goyah yang tidak berani disentuh; memahami mekanisme memungkinkan keputusan beralasan tentang sejauh mana bisa diandalkan, apa yang merusaknya, dan kapan harus menulis ulang
    unknown["Memakai tanpa memahami mekanisme"] --> fear["Perpanjangan umur goyah 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: Untuk perpanjangan umur yang sama pun, mutunya berbeda antara kecemasan karena mekanisme tidak diketahui dan keputusan berdasarkan pemahaman.

Artikel ini ditujukan kepada staf IT usaha kecil dan menengah serta pengembang aplikasi Windows yang merawat aplikasi bisnis lama. Dari sumber primer Microsoft Learn, artikel merapikan mekanisme shim sebagai identitas mode kompatibilitas, apa yang dapat dilakukan shim yang sering dipakai, penerapan organisasi dengan Compatibility Administrator, batas yang tidak dapat diselamatkan shim, serta keputusan «memperpanjang umur atau bermigrasi».

1. Kesimpulan dulu

• Identitas mode kompatibilitas adalah shim (lapisan kompatibilitas). Pengaturan tab Kompatibilitas ditulis ke HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers, dan bundel shim diterapkan ke proses itu saat mulai.¹²
• Shim adalah hook API di user mode melalui penggantian import table (IAT). Ia mencegat jalur aplikasi memanggil Windows API dan mengembalikan jawaban yang sama seperti Windows lama. OS itu sendiri tidak diubah.³
• Apa yang dapat dilakukan shim berada pada rentang yang sama dengan perbaikan kode aplikasi. Mekanisme keamanan tidak dapat dilalui, dan masalah kernel mode (driver perangkat) juga tidak dapat diperbaiki.³
• Ada banyak shim siap pakai dari Microsoft: pemalsuan versi, pemetaan ulang jalur berkas, pemalsuan registri, pemalsuan pemeriksaan administrator, dan lainnya. Shim itu dapat diterapkan ke EXE individu dari Compatibility Administrator.⁴
• Windows sendiri memakai shim secara bawaan. Basis data kompatibilitas standar OS (.sdb) dicocokkan setiap kali proses mulai, dan PCA (Program Compatibility Assistant) kadang mendeteksi masalah lalu menerapkan pengaturan kompatibilitas secara otomatis.¹⁵
• Perilaku «menjawab seolah-olah ini Windows lama» kini sudah bawaan. Sejak Windows 8.1, GetVersionEx tidak mengembalikan versi OS yang belum dideklarasikan di manifes. Mode kompatibilitas adalah kelanjutan mekanisme itu.⁶⁷
• Shim tidak berlaku untuk aplikasi 16-bit, ketergantungan driver kernel, atau akses perangkat keras langsung. Khususnya di Windows 64-bit, aplikasi 16-bit sama sekali tidak dapat dijalankan.⁸
• Untuk aplikasi yang «meminta administrator tetapi sebenarnya tidak membutuhkannya», RunAsInvoker adalah langkah standar. __COMPAT_LAYER=RunAsInvoker menekan permintaan elevasi dan memungkinkan aplikasi berjalan dengan hak biasa.⁹
• Berjalan berkat shim berarti umur dapat diperpanjang untuk saat ini, tetapi jalur utamanya adalah «membuatnya berjalan tanpa shim». Jika diputuskan memperpanjang umur, catat shim mana yang membuatnya berjalan dan kelola itu sebagai bahan keputusan penulisan ulang.

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 16, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Gambaran keseluruhan kompatibilitas aplikasi — lapisan kompatibilitas mundur yang dimiliki Windows

Sebelum masuk ke shim, berikut daftar mekanisme yang sudah dimiliki Windows untuk aplikasi lama. Meski orang berkata «berjalan di mode kompatibilitas», yang benar-benar menyelamatkan aplikasi biasanya salah satu lapisan ini, atau kombinasi beberapa di antaranya.

Virtualisasi UAC adalah langkah transisi yang berlaku untuk proses interaktif 32-bit tanpa manifes, dan Microsoft sendiri menyatakan itu «teknologi sementara yang dimaksudkan untuk dihapus dari Windows di masa depan».¹⁰ Kerusakan nyata dari pengalihan ke Wow6432Node dan VirtualStore, serta cara mengatasinya, dibahas rinci di «Jebakan pengalihan dan virtualisasi registri 32-bit/64-bit». Artikel ini menempatkan shim di pusat, dan menyinggung lapisan lain hanya sejauh diperlukan.

flowchart TB
    accTitle: Posisi virtualisasi UAC
    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 tidak dapat diandalkan secara permanen.

Sebagai catatan tambahan tentang virtualisasi DPI: aplikasi yang belum mendeklarasikan kesadaran DPI diperlakukan seolah menggambar pada 96 DPI (100%), lalu Windows meregangkan bitmap untuk ditampilkan. Itulah sebabnya aplikasi lama terlihat «kabur» di monitor DPI tinggi, dan «Ganti pengaturan 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 ditampilkan"]
    stretch --> blur["Terlihat kabur di monitor DPI tinggi"]
    tab["Ganti pengaturan DPI tinggi"] -.->|Mengganti perilaku virtualisasi| treat

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

3. Identitas shim — mencegat di antara API dengan mengganti IAT

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

Berkas eksekusi Windows (format PE) memanggil API di DLL eksternal melalui import address table (IAT). Ketika aplikasi memanggil GetVersionEx, yang terjadi hanyalah lompat ke alamat yang tertulis di IAT. Mekanisme shim memanfaatkan titik itu. Saat aplikasi dimuat, entri IAT API sasaran ditulis ulang ke alamat kode shim, sehingga shim menyelip di antara aplikasi dan Windows. API yang diperoleh secara dinamis lewat GetProcAddress ditangani dengan mengait GetProcAddress itu sendiri.³

Setelah mencegat, shim misalnya mengembalikan nomor versi lama ke pertanyaan «berapa versi OS saat ini?», atau memetakan ulang akses berkas ke lokasi yang tidak dapat ditulis ke tempat lain, lalu memanggil API sungguhan jika perlu. Dari sisi aplikasi seolah «berjalan di Windows lama»; dari sisi 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.

Dari rancangan ini mengikuti tiga sifat penting.³

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 pengaturan keamanan tidak perlu dilonggarkan hanya untuk memakai shim.
2. Apa yang dapat diperbaiki shim, perbaikan kode aplikasi juga dapat memperbaikinya. Shim adalah pengganti untuk kasus «tidak ada sumber / tidak dapat diperbaiki»; 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 berekstensi .sdb. Berkas eksekusi aplikasi sasaran didaftarkan di basis data menurut atribut seperti nama berkas, ukuran, checksum, dan versi (atribut pencocokan), lalu dicocokkan saat proses mulai. Solusinya mencakup 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 sudah diatur mode kompatibilitasnya, tetapi pada setiap peluncuran proses. Windows menyertakan basis data standar OS yang memuat 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: Pencocokan basis data shim saat proses mulai
    accDescr: Setiap peluncuran proses dicocokkan dengan basis data shim; jika ada pendaftaran yang cocok menurut atribut pencocokan, Appfix menyuntikkan shim atau Apphelp menampilkan pesan; jika tidak ada, proses mulai seperti biasa
    start["Proses mulai"] --> db["Dicocokkan dengan basis data shim (.sdb)"]
    db -.-> attr["Dicocokkan menurut nama berkas, ukuran, dsb."]
    db --> hit{"Ada pendaftaran?"}
    hit -->|Ya| appfix["Appfix (menyuntikkan shim)"]
    hit -->|Ya| apphelp["Apphelp (menampilkan pesan)"]
    hit -->|Tidak| plain["Mulai seperti biasa"]
    layer["Lapisan kompatibilitas (mode kompatibilitas)"] -.->|Bundel beberapa shim dan flag| appfix

Gambar 5: Pencocokan tidak hanya untuk aplikasi yang diatur mode kompatibilitasnya, tetapi untuk setiap peluncuran proses.

3.3. PCA — mekanisme yang menerapkan shim secara otomatis

Ada satu jalur lagi yang menerapkan shim meski administrator tidak berniat: PCA (Program Compatibility Assistant). PCA memantau eksekusi aplikasi dan, jika mendeteksi tanda masalah kompatibilitas yang sudah dikenal, mengusulkan penerapan perbaikan kepada pengguna, atau dalam sebagian kasus menerapkan pengaturan kompatibilitas secara otomatis. Misalnya, aplikasi yang crash karena memanggil kode di dalam DLL yang sudah dibebaskan mendapat PINDLL, dan aplikasi yang gagal menulis ke berkas Windows yang dilindungi mendapat mode kompatibilitas seperti WRPMITIGATION.⁵

flowchart TB
    accTitle: Alur PCA menerapkan pengaturan kompatibilitas secara otomatis
    accDescr: PCA memantau eksekusi aplikasi; jika mendeteksi tanda masalah kompatibilitas yang dikenal, ia mengusulkan penerapan perbaikan kepada pengguna, atau dalam sebagian kasus menerapkan pengaturan kompatibilitas secara otomatis
    run["Eksekusi aplikasi"] --> pca["PCA memantau"]
    pca --> sign{"Ada tanda masalah yang dikenal?"}
    sign -->|Ada| resp{"Kasusnya?"}
    resp -->|Ditangani dengan usulan| suggest["Mengusulkan penerapan perbaikan"]
    resp -->|Sebagian kasus| auto["Menerapkan pengaturan kompatibilitas secara otomatis"]
    sign -->|Tidak ada| none["Berjalan seperti biasa"]
    auto -.-> ex["Contoh: PINDLL atau WRPMITIGATION"]

Gambar 6: PCA memantau eksekusi aplikasi dan, jika mendeteksi tanda masalah yang dikenal, mengusulkan perbaikan atau menerapkannya secara otomatis.

Identitas «tidak diatur apa-apa, tetapi suatu saat kotak centang mode kompatibilitas sudah terisi» dalam banyak kasus adalah ini. Bukan kerusakan dan bukan salah operasi; itu perilaku sesuai rancangan Windows.

4. Apa yang dapat dilakukan shim yang sering dipakai

Dari shim siap pakai yang dipublikasikan Microsoft, berikut cuplikan yang benar-benar sering dipakai untuk memperpanjang umur aplikasi bisnis.⁴

Jika dilihat, sebagian besar shim adalah «kebohongan yang mengembalikan jawaban yang diharapkan aplikasi lama». Disk paling 2 GB, OS adalah XP, Anda adalah administrator — pandangan dunia dari zaman aplikasi itu lahir hanya direproduksi di dalam proses itu.

Pemalsuan versi sudah menjadi «perilaku bawaan resmi»

Pemalsuan versi bukan peretasan istimewa. Sejak Windows 8.1, nilai yang dikembalikan GetVersionEx bergantung pada manifes aplikasi. Aplikasi tanpa deklarasi <supportedOS> di bagian <compatibility> manifes, berapa pun OS sebenarnya, mendapat nilai setara Windows 8 (6.2). Jika ada deklarasi, nilai sampai OS tertinggi yang dideklarasikan yang dikembalikan (contoh: jika GUID Windows 8.1 dideklarasikan, bahkan di Windows 11 yang dikembalikan 6.3).⁶⁷

Dengan kata lain, «versi Windows yang dilihat aplikasi» ditentukan secara berlapis sebagai berikut.

1. Nilai sampai OS yang dideklarasikan di manifes yang dikembalikan (tanpa deklarasi: 6.2)
2. Jika mode kompatibilitas (shim keluarga VersionLie) diterapkan, versi OS yang dipilih yang dikembalikan⁶

flowchart TB
    accTitle: Cara versi OS yang dilihat aplikasi ditentukan
    accDescr: Nilai GetVersionEx ditentukan oleh ada-tidaknya deklarasi supportedOS di manifes; tanpa deklarasi dikembalikan 6.2 setara Windows 8, dengan deklarasi dikembalikan nilai sampai OS tertinggi yang dideklarasikan, dan jika shim keluarga VersionLie diterapkan maka ditimpa versi OS yang dipilih
    q["Kueri GetVersionEx"] --> m{"Ada deklarasi supportedOS?"}
    m -->|Tidak| v62["Dikembalikan setara Windows 8 (6.2)"]
    m -->|Ya| decl["Nilai sampai 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 itu dikembalikan apa adanya"]

Gambar 7: Versi Windows yang dilihat aplikasi ditentukan berlapis oleh manifes dan shim.

Jika aplikasi buatan sendiri «bercabang menurut versi OS, tetapi di Windows 11 justru dinilai sebagai 8» dan membingungkan, pertama-tama curigai deklarasi supportedOS di manifes. Sebaliknya, aplikasi lama yang menolak mulai karena pemeriksaan versi, dengan VersionLie dari shim, berpeluang tinggi untuk ditembus. Sering kali yang dilihat hanya nomor versi, sementara perilaku sebenarnya tidak bermasalah di OS baru.

flowchart TB
    accTitle: Dua gejala karena versi dan penanganannya
    accDescr: Jika aplikasi sendiri menilai Windows 11 sebagai 8, curigai deklarasi supportedOS di manifes; aplikasi lama yang menolak mulai karena pemeriksaan versi berpeluang tinggi ditembus dengan shim VersionLie
    sym1["Dinilai 8 padahal Windows 11"] --> fix1["Curigai deklarasi supportedOS"]
    sym2["Menolak mulai karena pemeriksaan versi"] --> fix2["Coba tembus dengan VersionLie"]
    fix2 -.-> why["Perilaku itu sendiri sering tidak bermasalah di OS baru"]

Gambar 8: Gejala penilaian yang menua dicurigai ke manifes; penolakan mulai dicurigai ke VersionLie.

5. Apa yang dilakukan kotak centang mode kompatibilitas

Pengaturan Properti → tab Kompatibilitas disimpan di kunci registri AppCompatFlags\Layers. Pengaturan kompatibilitas aplikasi DXGI dan sejenisnya juga memakai kunci yang sama; itu tempat menaruh spesifikasi lapisan kompatibilitas.² Mari diperiksa langsung.

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

Untuk EXE yang di tab Kompatibilitas diatur «Windows XP (Service Pack 3)», «Jalankan program ini sebagai administrator», dan «Ganti pengaturan DPI tinggi», misalnya nilai berikut terlihat.

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

Berikut contoh korespondensi item centang dan nilainya (contoh yang dikonfirmasi di Windows 11; nama item dan nilai dapat berbeda menurut versi OS).

Ada tiga poin yang perlu dipegang.

• «Jalankan program ini sebagai administrator» juga ditulis di tempat yang sama. Mode kompatibilitas dan spesifikasi elevasi tinggal bersama di kunci Layers yang sama; kebingungan «setelah mode kompatibilitas diatur, elevasi ikut datang/hilang» lahir dari sini. Jika nilainya dilihat langsung, masalahnya dapat diisolasi.
• Yang ditulis ke HKCU adalah «pengaturan pengguna itu». Jika diatur dari «Ubah pengaturan untuk semua pengguna» di tab, ditulis ke kunci bernama sama di sisi HKLM dan berlaku untuk semua pengguna. Saat didistribusikan lewat penyiapan PC massal, perhatikan ke mana ditulis.
• Kotak centang hanyalah pintu masuk ke lapisan siap pakai. Dari tab hanya lapisan perwakilan yang dapat dipilih; memilih dan merangkai shim individu tidak bisa. Itu dikerjakan Compatibility Administrator di bab berikutnya.

flowchart TB
    accTitle: Alur sampai pengaturan tab Kompatibilitas berlaku
    accDescr: Pengaturan tab Kompatibilitas disimpan sebagai jalur EXE dan nilai di kunci Layers pada AppCompatFlags; saat EXE itu dijalankan berikutnya, loader membaca nilai dan menerapkan lapisan kompatibilitas yang sesuai ke proses
    tab["Diatur di tab Kompatibilitas"] --> reg["Menyimpan jalur EXE dan nilai ke kunci Layers"]
    reg --> boot["Peluncuran EXE berikutnya"]
    boot --> loader["Loader membaca nilai"]
    loader --> apply["Menerapkan lapisan kompatibilitas ke proses"]
    reg -.-> hkcu["HKCU hanya untuk pengguna itu"]
    reg -.-> hklm["HKLM berlaku untuk semua pengguna"]

Gambar 9: Identitas kotak centang adalah penulisan ke kunci Layers; penerapan terjadi saat peluncuran berikutnya.

6. Praktik Compatibility Administrator — membuat dan mendistribusikan .sdb kustom

6.1. Cara memperoleh dan catatan penting

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

Ada satu catatan penting lagi. Jika Compatibility Administrator dijalankan dengan hak administrator (keadaan ter-elevate) lalu diuji, virtualisasi UAC dan pengalihan tidak bekerja seperti semestinya, sehingga mudah salah menilai «sudah beres». Efek perbaikan wajib dikonfirmasi dengan akun dan hak yang sama seperti pengguna sebenarnya.⁴

flowchart TB
    accTitle: Dua catatan saat memakai Compatibility Administrator
    accDescr: Perbaikan aplikasi 32-bit memakai edisi 32-bit, aplikasi 64-bit memakai edisi 64-bit; efek perbaikan dikonfirmasi bukan dalam keadaan ter-elevate, melainkan dengan akun dan hak yang sama seperti pengguna sebenarnya
    app32["Aplikasi 32-bit"] --> tool32["Diperbaiki dengan edisi 32-bit"]
    app64["Aplikasi 64-bit"] --> tool64["Diperbaiki dengan edisi 64-bit"]
    elev["Diuji dalam keadaan ter-elevate"] -.-> wrong["Risiko salah menilai sudah beres"]
    user["Diuji dengan hak yang sama seperti pengguna sebenarnya"] --> ok["Efek dikonfirmasi dengan benar"]

Gambar 10: Pembagian edisi 32-bit dan 64-bit, serta konfirmasi dengan hak yang sama seperti pengguna sebenarnya, adalah catatan di pintu masuk.

6.2. Langkah membuat basis data kompatibilitas kustom

Alur kasarnya sebagai berikut.¹⁴

1. Di panel kiri Compatibility Administrator, buat basis data baru di «Custom Databases», lalu pilih «Create New» → «Application Fix»
2. Masukkan nama aplikasi dan nama vendor, lalu tentukan berkas EXE sasaran
3. Pilih mode kompatibilitas (lapisan) yang akan diterapkan — jalan pintasnya adalah mencoba dulu bundel seperti «kompatibilitas Windows XP»
4. Jika perlu, tambahkan perbaikan kompatibilitas (shim) individu — komposisi dapat dipersempit, misalnya hanya VersionLie atau hanya CorrectFilePaths
5. Konfirmasi syarat pencocokan (ukuran berkas, checksum, versi, dsb.) lalu simpan

Syarat pencocokan adalah kunci agar «hanya berlaku pada EXE ini». Syarat dasar bawaan biasanya cukup, tetapi disarankan menyisakan syarat yang dapat mengidentifikasi versi aplikasi. Alasannya: jika nanti vendor merilis edisi yang sudah diperbaiki, kebohongan lama tidak terus diterapkan sampai versi baru.¹⁴¹⁵

flowchart TB
    accTitle: Langkah membuat basis data kompatibilitas kustom
    accDescr: Buat Application Fix di basis data baru, tentukan nama aplikasi dan EXE sasaran, coba bundel mode kompatibilitas lalu jika perlu persempit ke shim individu, konfirmasi syarat pencocokan lalu simpan
    new["Membuat basis data baru"] --> fix["Memilih Application Fix"]
    fix --> info["Menentukan nama aplikasi dan EXE sasaran"]
    info --> layer["Mencoba bundel mode kompatibilitas"]
    layer --> single["Jika perlu, mempersempit ke shim individu"]
    single --> match["Mengonfirmasi syarat pencocokan lalu menyimpan"]
    match -.-> ver["Menyisakan syarat identifikasi versi"]

Gambar 11: Application Fix dicoba dulu sebagai bundel mode kompatibilitas, dipersempit ke komposisi minimal, lalu sasaran dibatasi dengan syarat pencocokan.

Berkas .sdb yang dibuat diuji dulu di mesin verifikasi. Jika berjalan sesuai sasaran, baru disebar ke organisasi.

6.3. Distribusi dengan sdbinst

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

:: Instalasi (-q = senyap tanpa konfirmasi)
sdbinst -q "C:\Deploy\MyCorpFixes.sdb"

:: Uninstal (menurut berkas)
sdbinst -q -u "C:\Deploy\MyCorpFixes.sdb"

:: Uninstal (menurut GUID basis data)
sdbinst -q -u -g {GUID basis data}

Sebagai strategi penyebaran organisasi, Microsoft merekomendasikan, daripada menyertakan .sdb terpisah di penginstal tiap aplikasi, mengonsolidasikan ke satu basis data kustom tingkat perusahaan (atau per departemen) lalu mengelolanya terpusat. Semakin banyak perbaikan, memperbarui dan mendistribusikan ulang satu basis data lebih mudah dikelola daripada menyebar banyak basis data satu baris. Basis data kustom memiliki GUID unik, dan menginstal versi baru dengan GUID yang sama secara otomatis mengganti versi lama, sehingga operasi pembaruan juga sederhana. Distribusi itu sendiri diletakkan pada jalur distribusi yang sudah ada yang dapat dijalankan dengan hak administrator, misalnya pemaketan MSI atau skrip startup.¹⁵

flowchart TB
    accTitle: Alur dari pembuatan .sdb kustom sampai distribusi
    accDescr: Buat basis data kompatibilitas kustom dengan Compatibility Administrator, uji di mesin verifikasi, terapkan ke setiap PC dengan sdbinst; saat pembaruan, menginstal versi baru dengan GUID yang sama secara otomatis mengganti versi lama
    make["Dibuat dengan Compatibility Administrator"] --> test["Diuji di mesin verifikasi"]
    test --> deploy["Diterapkan ke setiap PC dengan sdbinst"]
    deploy --> update["Menginstal versi baru dengan GUID yang sama"]
    update -.-> replace["Versi lama diganti secara otomatis"]
    deploy -.-> inv["Terdaftar di Program and Features"]

Gambar 12: .sdb kustom disebar lewat alur buat, verifikasi, dan distribusi sdbinst; pembaruan dikelola dengan GUID.

Basis data kustom yang sudah terinstal terdaftar sebagai item di «Program and Features (aplikasi yang terinstal)», jadi inventarisasi dan penghapusan juga dapat dicek dari sana. .sdb mana yang ada di PC mana adalah informasi yang seharusnya masuk inventaris aset.

7. Kasus yang tidak berlaku dan batasnya

Shim tidak serba bisa. Karena mekanismenya, kasus berikut tidak dapat ditangani.

• Masalah kernel mode. Shim berjalan di dalam proses user mode, jadi ketidakcocokan driver perangkat tidak dapat diperbaiki. Jika driver alat ukur lama, dongle USB, atau printer tidak mendukung Windows 11, apa pun yang diterapkan di sisi aplikasi tidak menyelesaikan masalah. Kode yang berjalan di kernel, misalnya sebagian perangkat lunak antivirus, sama saja.³
• Aplikasi 16-bit. Windows 64-bit tidak mendukung eksekusi aplikasi 16-bit. Handle di Windows 64-bit punya bit valid 32-bit dan tidak dapat dipotong lalu diserahkan ke aplikasi 16-bit; peluncuran gagal dengan ERROR_BAD_EXE_FORMAT.⁸ Ada juga paket zaman itu yang badan aplikasinya 32-bit tetapi bagian pemicu penginstal (stub) 16-bit; dalam kasus itu gejalanya «aplikasi bisa berjalan, tetapi tidak bisa diinstal».
• Akses langsung ke perangkat keras. Aplikasi industri yang mengandaikan menyentuh port I/O atau memori fisik secara langsung, di Windows modern memang tidak diizinkan dari user mode; itu di luar jangkauan yang dapat dipalsukan shim.
• Melewati mekanisme keamanan. Karena shim berjalan di bawah batasan keamanan yang sama dengan aplikasi, ia tidak dapat membuat «yang tidak bisa dilakukan karena tidak punya hak» menjadi mungkin. ForceAdminAccess dan WRPMitigation hanya memalsukan keberhasilan pemeriksaan atau penulisan agar aplikasi maju; sumber daya yang dilindungi tidak benar-benar ditulis ulang.³⁴
• Aplikasi yang memeriksa keutuhan dirinya sendiri. Aplikasi dengan proteksi salinan lama atau deteksi perusakan kadang menganggap hook API itu sendiri sebagai anomali dan berhenti berjalan.

flowchart TB
    accTitle: Kasus yang tidak ditangani shim
    accDescr: Karena shim berjalan di dalam proses user mode, ia tidak menangani masalah driver kernel mode, aplikasi 16-bit, akses langsung ke perangkat keras, atau melewati mekanisme keamanan
    shim["Shim (berjalan di user mode)"] -->|Tidak berlaku| drv["Driver kernel"]
    shim -->|Tidak berlaku| b16["Aplikasi 16-bit"]
    shim -->|Tidak berlaku| hw["Akses langsung ke perangkat keras"]
    shim -->|Tidak berlaku| sec["Melewati mekanisme keamanan"]
    b16 -.-> fmt["Di 64-bit, peluncuran itu sendiri gagal"]
    sec -.-> fake["Hanya memalsukan keberhasilan agar maju"]

Gambar 13: Shim terbatas pada user mode; ia tidak menjangkau kernel, 16-bit, akses perangkat keras langsung, atau pengelakan keamanan.

Lalu, batas esensial yang sama pada semua shim adalah bahwa ia tindakan darurat. Shim adalah kebohongan yang disesuaikan dengan cara pemakaian API tertentu; jika implementasi sisi OS berubah, asumsinya runtuh. Shim yang disediakan Microsoft dipelihara sebagai bagian Windows melalui Windows Update,³ tetapi kebohongan yang diterapkan lewat basis data kustom menjadi tanggung jawab organisasi sendiri. Operasi memverifikasi «daftar aplikasi yang umurnya diperpanjang dengan shim» setiap pembaruan fitur harus dianggarkan sebagai biaya perpanjangan umur.

flowchart TB
    accTitle: Shim sebagai tindakan darurat dan tanggung jawab pemeliharaan
    accDescr: Shim adalah kebohongan yang disesuaikan dengan pemakaian API tertentu dan asumsinya runtuh jika implementasi OS berubah; shim Microsoft dipelihara lewat Windows Update, tetapi kebohongan basis data kustom menjadi tanggung jawab organisasi sendiri, dan verifikasi setiap pembaruan fitur menjadi biaya perpanjangan umur
    shim["Shim adalah kebohongan tindakan darurat"] --> break["Jika implementasi OS berubah, asumsi runtuh"]
    ms["Shim yang disediakan Microsoft"] --> wu["Dipelihara lewat Windows Update"]
    own["Kebohongan basis data kustom"] --> self["Yang merawat adalah organisasi sendiri"]
    self --> cost["Verifikasi setiap pembaruan fitur adalah biaya perpanjangan umur"]

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

8. Nilai praktis RunAsInvoker — hanya membungkam permintaan elevasi

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

Aplikasi bisnis lama ada yang mendeklarasikan requireAdministrator di manifes, atau salah terdeteksi sebagai penginstal dari nama atau isi EXE, lalu meminta elevasi UAC setiap kali mulai. Padahal banyak di antaranya hanya meminta administrator karena kelembaman zaman XP, dan sebenarnya tidak memakai hak administrator. Jika shim RunAsInvoker diterapkan, deteksi penginstal maupun manifes ditimpa, dan aplikasi mulai dengan token yang diwarisi dari proses induk (= hak pengguna biasa).⁹

flowchart TB
    accTitle: Cara RunAsInvoker menekan permintaan elevasi
    accDescr: Deklarasi requireAdministrator di manifes atau salah deteksi sebagai penginstal menjadi penyebab permintaan elevasi UAC saat mulai; jika RunAsInvoker diterapkan keduanya ditimpa, dan aplikasi mulai dengan token yang diwarisi dari proses induk
    manifest["Deklarasi requireAdministrator"] --> shim{"RunAsInvoker diterapkan?"}
    detect["Salah terdeteksi sebagai penginstal"] --> shim
    shim -->|Tidak| uac["Permintaan elevasi UAC setiap kali mulai"]
    shim -->|Ya| token["Mulai dengan token induk"]
    token -.-> limit["Pekerjaan yang wajib administrator gagal di dalam aplikasi"]

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

Tanpa membuat .sdb di Compatibility Administrator, lapisan yang sama dapat diterapkan sementara lewat variabel lingkungan __COMPAT_LAYER.

:: Menerapkan RunAsInvoker ke proses anak yang dimulai dari command prompt ini
set __COMPAT_LAYER=RunAsInvoker
start "" "C:\LegacyApp\Gyomu.exe"

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

Jika dua baris itu dijadikan berkas batch dan dibagikan sebagai pengganti pintasan, hak administrator lokal tidak perlu dibagikan ke pengguna biasa, dan staf IT tidak dipanggil setiap kali untuk memasukkan kata sandi UAC. Ini teknik kompatibilitas yang memperkuat pertahanan, selaras dengan prinsip hak minimal.

flowchart TB
    accTitle: Efek distribusi batch RunAsInvoker
    accDescr: Jika berkas batch dua baris yang mengatur RunAsInvoker dibagikan sebagai pengganti pintasan, hak administrator lokal tidak perlu dibagikan ke pengguna biasa, staf IT tidak dipanggil untuk kata sandi UAC, dan operasi selaras dengan prinsip hak minimal
    bat["Mendistribusikan batch dua baris"] --> noadmin["Hak administrator tidak perlu dibagikan"]
    bat --> nocall["Staf IT tidak dipanggil karena UAC"]
    noadmin --> lp["Operasi yang selaras dengan prinsip hak minimal"]
    nocall --> lp

Gambar 16: Hanya dengan distribusi batch, baik pembagian hak administrator maupun panggilan karena UAC dapat dikurangi.

Catatannya juga perlu dibuat tegas.

• Hak tidak bertambah. Pekerjaan yang benar-benar membutuhkan hak administrator (penulisan ke HKLM, pembaruan di bawah Program Files, dsb.) akan error di dalam aplikasi, atau jika syarat terpenuhi dialihkan ke VirtualStore oleh virtualisasi UAC.¹⁰ Jika penyimpanan pengaturan tampak «tidak mempan», curigai virtualisasi.
• Cara variabel lingkungan hanya berlaku pada proses anak. Untuk penerapan permanen, yang andal adalah tab Kompatibilitas (RUNASINVOKER tidak ada sebagai item di tab, jadi diatur langsung ke kunci Layers) atau distribusi lewat .sdb.
• Memperbaiki tujuan penulisan adalah jalur utama. Jika aplikasi dapat diubah, pindahkan berkas pengaturan ke bawah %APPDATA% dan deklarasikan asInvoker di manifes — itulah bentuk yang benar.⁹

flowchart TB
    accTitle: Penerapan sementara dan permanen RunAsInvoker
    accDescr: Penerapan lewat variabel lingkungan COMPAT_LAYER hanya berlaku pada proses anak yang dimulai dari situ; untuk penerapan permanen dipakai pengaturan langsung ke kunci Layers atau distribusi .sdb
    env["Diatur lewat variabel lingkungan"] --> child["Hanya berlaku pada proses anak"]
    child -.-> tmp["Penerapan sementara"]
    layers["Diatur langsung ke kunci Layers"] --> always["Penerapan permanen"]
    sdb["Didistribusikan lewat sdb"] --> always

Gambar 17: Cara variabel lingkungan adalah penerapan sementara terbatas pada proses anak; penerapan permanen dilakukan lewat kunci Layers atau .sdb.

9. Memutuskan memperpanjang umur atau bermigrasi — yang dipikirkan setelah shim membuatnya berjalan

Saat shim membuat aplikasi berjalan, lega. Namun penting untuk tidak berhenti berpikir di situ. Berjalan berkat shim = kebetulan masuk ke wadah yang disediakan Windows, tidak lebih. Berikut kriteria keputusannya.

Jika diputuskan memperpanjang umur, masukkan tiga poin berikut sebagai satu set ke operasi.

1. Mencatat. EXE mana, shim/lapisan mana, dan mengapa diterapkan. Nilai kunci Layers dan GUID .sdb disimpan di inventaris. Keadaan «tidak ada yang tahu mengapa berjalan» adalah utang terbesar bagi petugas berikutnya. Cara berpikir ini sama dengan gagasan pelestarian di «Jika mewarisi sistem tanpa kode sumber maupun spesifikasi».
2. Memverifikasi. Masukkan peluncuran dan operasi utama aplikasi yang umurnya diperpanjang dengan shim ke butir verifikasi pembaruan fitur Windows. Kaitkan juga dengan rencana penggantian OS (Solusi realistis setelah dukungan Windows 10 berakhir).
3. Memberi batas waktu. Tetapkan akhir perpanjangan umur, misalnya «sampai penggantian sistem inti berikutnya» atau «sampai Maret 2028», dan jalankan kajian migrasi secara paralel.

flowchart TB
    accTitle: Tiga set operasi jika diputuskan memperpanjang umur
    accDescr: Catat di inventaris shim mana yang membuatnya berjalan, verifikasi perilaku aplikasi yang diperpanjang umurnya dengan shim setiap pembaruan fitur, tetapkan akhir perpanjangan umur, dan jalankan kajian migrasi secara paralel
    decide["Memutuskan memperpanjang umur"] --> rec["Mencatat: shim apa yang membuatnya berjalan, ke inventaris"]
    rec --> verify["Memverifikasi: konfirmasi perilaku setiap pembaruan fitur"]
    verify --> deadline["Batas waktu: menetapkan akhir perpanjangan umur"]
    deadline --> mig["Menjalankan kajian migrasi secara paralel"]

Gambar 18: Perpanjangan umur dioperasikan sebagai tiga set catat, verifikasi, dan batas waktu, termasuk kajian migrasi yang berjalan paralel.

Pilihan di sisi migrasi, langkah bakunya berubah menurut teknologi aplikasi. Jika buatan VB6, tiga pilihan tulis ulang total, konversi otomatis, dan migrasi bertahap yang dirapikan di «Sampai kapan aplikasi VB6 masih berjalan»; jika bergantung pada ActiveX/OCX, tabel keputusan tetap, bungkus, atau ganti di «Bagaimana menangani ActiveX / OCX sekarang» dapat dipakai. Posisi yang sehat: shim adalah penghemat waktu agar periode kajian dan persiapan proyek migrasi itu aman.

flowchart TB
    accTitle: Pilihan sisi migrasi dan posisi shim
    accDescr: Langkah baku migrasi berubah menurut teknologi aplikasi; jika VB6, tiga pilihan tulis ulang, konversi otomatis, dan migrasi bertahap; jika bergantung ActiveX, tabel keputusan tetap, bungkus, atau ganti; shim diposisikan sebagai penghemat waktu untuk periode kajian dan persiapan proyek migrasi
    tech{"Teknologi aplikasinya?"} -->|Buatan VB6| vb["Tulis ulang, konversi otomatis, migrasi bertahap"]
    tech -->|Bergantung ActiveX| ax["Tetap, bungkus, atau ganti"]
    shim["Perpanjangan umur dengan shim"] -.->|Menghemat waktu kajian dan persiapan| tech

Gambar 19: Langkah baku migrasi ditentukan oleh teknologi aplikasi; shim diposisikan sebagai penghemat waktu untuk periode kajian itu.

10. Ringkasan

• Identitas mode kompatibilitas adalah shim. Pengaturan tab Kompatibilitas ditulis ke kunci AppCompatFlags\Layers, lalu saat mulai disuntikkan ke proses sebagai hook API melalui penggantian IAT.
• Shim adalah kumpulan «kebohongan yang mengembalikan jawaban yang diharapkan aplikasi lama». Shim siap pakai seperti pemalsuan versi, pemetaan ulang jalur, pemalsuan registri, dan pemalsuan pemeriksaan administrator sudah disediakan.
• Windows sendiri memakai shim dalam jumlah besar secara bawaan, dan PCA kadang menerapkannya otomatis. Mengandalkan mode kompatibilitas itu sendiri adalah pilihan yang sah, karena menumpang pada mekanisme resmi OS.
• Ada batas prinsip: hanya user mode dan tidak dapat melewati keamanan. Driver kernel, aplikasi 16-bit, dan akses perangkat keras langsung tidak dapat diselamatkan.
• Penyebaran organisasi: buat .sdb kustom dengan Compatibility Administrator (Windows ADK), lalu distribusikan dengan sdbinst. Pembagian edisi 32-bit/64-bit, pengujian dengan akun pemakaian nyata, dan pengelolaan pembaruan lewat GUID adalah titik praktisnya.
• Aplikasi yang «meminta administrator tetapi sebenarnya tidak membutuhkannya» dapat dijalankan dengan hak biasa lewat __COMPAT_LAYER=RunAsInvoker. Bukan membagikan hak, melainkan membungkam permintaan elevasi — teknik yang bersifat defensif.
• Berjalan berkat shim adalah perpanjangan umur, bukan penyelesaian. Mencatat dengan apa ia berjalan, memverifikasi setiap pembaruan fitur, dan memberi batas waktu sambil menjalankan migrasi secara paralel — tiga set itu termasuk dalam keputusan «mengandalkan mode kompatibilitas».

Saat aplikasi lama berikutnya berjalan karena centang mode kompatibilitas, tanyakan ulang. «Aplikasi ini berjalan berkat kebohongan yang mana? Sampai kapan kebohongan itu masih berlaku?» Jika itu dapat dijawab, perpanjangan umur adalah strategi yang sah.

Artikel terkait

• Jebakan pengalihan dan virtualisasi registri 32-bit/64-bit — Wow6432Node dan masalah «nilai yang seharusnya sudah ditulis tidak ada»
• Sampai kapan aplikasi VB6 masih berjalan — status dukungan runtime dan cara migrasi .NET yang realistis
• Bagaimana menangani ActiveX / OCX sekarang - tabel keputusan tetap, bungkus, atau ganti
• Solusi realistis setelah dukungan Windows 10 berakhir — tabel keputusan ESU, LTSC, dan penggantian
• Jika mewarisi sistem tanpa kode sumber maupun spesifikasi — langkah praktis agar operasi dan pemeliharaan tetap jalan tanpa dihentikan
• Integrasi shell Windows sekarang — menu klik kanan, asosiasi berkas, dan perubahan di Windows 11

Bidang konsultasi terkait

Di Komura Soft LLC, kami menangani investigasi perilaku dan rancangan perpanjangan umur aplikasi bisnis lama tanpa kode sumber (pemilihan shim dan mode kompatibilitas, pembuatan serta penyebaran .sdb kustom), verifikasi kompatibilitas aplikasi yang ada seiring migrasi ke Windows 11, serta perencanaan penulisan ulang dan migrasi yang berjalan paralel dengan perpanjangan umur. Konsultasi dari tahap «sudah berjalan di mode kompatibilitas, tetapi apakah boleh dibiarkan?» pun tidak masalah.

• Pemanfaatan aset yang ada dan dukungan migrasi
• Pengembangan aplikasi Windows
• Konsultasi teknis dan tinjauan rancangan
• 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 mode kompatibilitas dicentang, bolehkah terus dipakai seperti itu?

Untuk kelangsungan operasi dalam jangka pendek, tidak masalah untuk terus dipakai. Identitas mode kompatibilitas adalah hook API di user mode yang disebut shim, mekanisme resmi yang disediakan sebagai pengaturan OS. Namun shim tetap tindakan darurat agar aplikasi berjalan tanpa diperbaiki; jika pembaruan OS mengubah asumsinya, aplikasi itu bisa berhenti lagi. Catat di inventaris bahwa aplikasi berjalan berkat mode kompatibilitas, dan kelola catatan itu bersama keputusan: menulis ulang aplikasi, atau memperpanjang umurnya secara terencana.

Kotak centang mode kompatibilitas sebenarnya melakukan apa?

Saat pengaturan di tab Kompatibilitas pada dialog properti disimpan, Windows menulis jalur EXE sasaran dan nilai seperti "WINXPSP3" atau "HIGHDPIAWARE" ke kunci HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers. Saat EXE itu dijalankan berikutnya, loader Windows membaca nilai tersebut dan menerapkan lapisan kompatibilitas yang sesuai (bundel shim) ke proses. Misalnya pada mode kompatibilitas Windows XP, pemalsuan versi bekerja: API yang menanyakan versi OS mengembalikan nilai lama. Bukan OS itu sendiri yang diubah; hanya proses itu yang disuguhi seolah-olah ini Windows lama.

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

Tidak. Windows 64-bit menjalankan aplikasi 32-bit melalui WOW64, tetapi tidak mendukung eksekusi aplikasi 16-bit; percobaan memulai gagal dengan ERROR_BAD_EXE_FORMAT. Ini batasan arsitektur yang tidak dapat dielakkan shim. Paket lama yang bagian pemicu penginstalnya saja yang 16-bit gagal karena alasan yang sama. Jika benar-benar diperlukan, pertimbangkan sarana di luar mode kompatibilitas, misalnya mesin virtual yang menyertakan Windows 32-bit.

Bisakah aplikasi yang "tidak mau mulai kecuali dijalankan sebagai administrator" dijalankan dengan hak pengguna biasa?

Yang layak dicoba adalah RunAsInvoker. Jika set __COMPAT_LAYER=RunAsInvoker dijalankan di command prompt lalu aplikasi dimulai, permintaan elevasi dari deklarasi requireAdministrator pada manifes atau dari deteksi penginstal ditekan, dan aplikasi mulai dengan hak yang sama (pengguna biasa) seperti pemanggil. Untuk aplikasi yang hanya meminta hak administrator tanpa benar-benar memakainya, ini saja dapat mengeluarkan elevasi dari operasi sehari-hari. Hak tidak bertambah, jadi pekerjaan yang benar-benar membutuhkan hak administrator akan gagal di dalam aplikasi. Adopsi setelah memverifikasi perilakunya.

Di mana Compatibility Administrator diperoleh?

Termasuk dalam Windows ADK (Windows Assessment and Deployment Kit). Unduh ADK dari situs Microsoft dan, saat instalasi, pilih fitur kelompok Application Compatibility Tools. Edisi 32-bit dan 64-bit keduanya terinstal; untuk memperbaiki aplikasi 32-bit pakai edisi 32-bit, untuk aplikasi 64-bit pakai edisi 64-bit. Basis data kompatibilitas kustom (.sdb) yang dibuat diterapkan 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.