Windows ऐप compatibility कैसे काम करती है ── compatibility mode, shim और Compatibility Administrator से पुराने ऐप जीवित रखना

«दस साल पुराना business ऐप जिसका source code खो चुका है नए Windows 11 PC पर शुरू नहीं होता। Properties dialog के Compatibility टैब पर ‘Windows XP’ tick किया और बस चल पड़ा। — वास्तव में क्या हो रहा है? क्या इस पर भरोसा बनाए रखना ठीक है?» यह परामर्श हम अक्सर सुनते हैं।

एक checkbox जब कुछ चला दे तो बेचैनी स्वाभाविक है। जादू जैसे दिखने वाले compatibility mode की असली पहचान छोटे code टुकड़ों का संग्रह है जिन्हें shim कहते हैं जो ऐप और Windows API के बीच बैठकर «झूठ» लौटाते हैं। Windows स्वयं इस अस्थायी उपाय का बड़े पैमाने पर उपयोग करता है ताकि कई पीढ़ियों के ऐप चलते रहें, और mechanism का कुछ भाग users व admins को खोलता है।

Mechanism समझे बिना उपयोग करने पर life-extension «हम छू नहीं सकते क्योंकि नहीं जानते क्यों चलता है» अस्थिर हो जाता है। Mechanism समझें तो कारणों के साथ तय कर सकते हैं कितनी दूर सुरक्षित भरोसा कर सकते हैं, क्या तोड़ेगा, और कब फिर लिखना चाहिए।

flowchart TB
    accTitle: Mechanism समझने से life-extension की गुणवत्ता बदलती है
    accDescr: Mechanism समझे बिना compatibility mode उपयोग अस्थिर life-extension की ओर ले जाता है जिसे छूने का साहस नहीं; mechanism समझने से कारण सहित निर्णय होता है कितनी दूर भरोसा क्या तोड़ेगा और कब फिर लिखें
    unknown["Mechanism समझे बिना उपयोग"] --> fear["अस्थिर life-extension जिसे छूने का साहस नहीं"]
    known["Mechanism समझने के बाद उपयोग"] --> judge["कारणों वाले निर्णय"]
    judge -.-> j1["कितनी दूर भरोसा कर सकते हैं"]
    judge -.-> j2["क्या इसे तोड़ेगा"]
    judge -.-> j3["कब फिर लिखना चाहिए"]

चित्र 1: एक ही life-extension के लिए भी गुणवत्ता अलग है mechanism न जानने की चिंता और समझ पर आधारित निर्णय के बीच।

SME के IT staff और पुराने business apps सँभालने वाले Windows app developers के लिए, यह लेख Microsoft Learn primary sources से उस shim mechanism को व्यवस्थित करता है जो compatibility mode की असली पहचान है, प्रतिनिधि shim क्या कर सकते हैं, Compatibility Administrator से संगठनात्मक रूप से कैसे apply करें, वे सीमाएँ जिन्हें shim नहीं बचाता, और life-extension व migration के बीच कैसे निर्णय लें।

1. निष्कर्ष पहले

• Compatibility mode की असली पहचान shim हैं (compatibility layer)। Compatibility टैब की settings HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers में लिखी जाती हैं, और शुरू होते समय उस process पर shim bundle apply होता है।¹²
• Shim user-mode API hook है जो import address table (IAT) फिर लिखता है। वह path काटता है जिससे ऐप Windows API बुलाता है और वही उत्तर लौटाता है जो पुराना Windows देता। OS स्वयं नहीं बदलता।³
• Shim जो कर सकता है वही सीमा है जो ऐप में code सुधार कर सकता है। Security mechanism नहीं घेर सकता, और kernel-mode (device-driver) समस्याएँ नहीं सुधार सकता।³
• Microsoft बहुत से तैयार shim भेजता है — version lie, file-path remapping, registry नकल, Administrator जाँच की नकल, और अन्य। Compatibility Administrator से उन्हें अलग-अलग EXE पर apply कर सकते हैं।⁴
• Windows स्वयं default रूप से shim उपयोग करता है। OS-standard compatibility database (.sdb) हर launch पर मिलाया जाता है, और PCA (Program Compatibility Assistant) समस्या पहचानकर compatibility settings स्वतः भी apply कर सकता है।¹⁵
• «ऐसे उत्तर देना मानो यह पुराना Windows हो» अब default है। Windows 8.1 से GetVersionEx वह OS version नहीं लौटाता जिसे ऐप ने manifest में घोषित नहीं किया। Compatibility mode उसी mechanism का विस्तार है।⁶⁷
• Shim 16-bit ऐप, kernel-driver निर्भरता, या सीधे hardware access पर नहीं चलते। विशेषकर 16-bit ऐप 64-bit Windows पर बिल्कुल नहीं चल सकते।⁸
• उन ऐप के लिए जो «Administrator माँगते हैं पर वास्तव में नहीं चाहिए», RunAsInvoker मानक कदम है। __COMPAT_LAYER=RunAsInvoker elevation request दबाता है और ऐप standard permission के नीचे चलता है।⁹
• Shim के नीचे चलना मतलब अभी life-extend कर सकते हैं, पर असली path «बिना shim चलाएँ» है। अगर life-extend करने का निर्णय लें तो लिखें कौन से shim चलाते हैं और उसे फिर-लेखन निर्णय की content के रूप में प्रबंधित करें।

2. ऐप compatibility का बड़ा चित्र — backward-compatibility परतें जो Windows के पास पहले से हैं

Shim की बात से पहले, पुराने ऐप के लिए Windows के पास पहले से जो mechanisms हैं उनकी सूची। लोग जब कहते हैं «compatibility mode में चलने लगा», वास्तव में ऐप बचाने वाली इनमें से एक परत है, या कई का संयोजन।

UAC virtualization संक्रमण उपाय है जो बिना manifest 32-bit interactive processes पर apply होता है, और Microsoft स्वयं कहता है यह «अस्थायी technique है जिसे हम भविष्य के Windows version से हटाने का इरादा रखते हैं»।¹⁰ Wow6432Node redirection और VirtualStore से वास्तविक क्षति, और उससे निपटना, विस्तार से «Registry 32-bit/64-bit Redirection and Virtualization Pitfalls» में है; यह लेख shim को केंद्र रखता है और अन्य परतों का उल्लेख केवल जितना चाहिए।

flowchart TB
    accTitle: UAC virtualization कहाँ बैठता है
    accDescr: UAC virtualization बिना manifest 32-bit interactive processes का संक्रमण उपाय है; लेखन per-user VirtualStore में मोड़ता है पर Microsoft स्वयं कहता है यह अस्थायी technique है जिसे भविष्य के Windows से हटाने का इरादा है
    proc["बिना manifest 32-bit interactive process"] --> uacv["UAC virtualization apply"]
    uacv --> vs["Per-user VirtualStore में मोड़ा"]
    uacv -.-> tmp["अस्थायी technique जिसे बाद में हटाने का इरादा"]

चित्र 2: UAC virtualization बिना manifest 32-bit processes का संक्रमण उपाय है, और स्थायी रूप से भरोसा नहीं कर सकते।

DPI virtualization पर टिप्पणी: जिस ऐप ने DPI awareness घोषित नहीं की उसे 96 DPI (100%) पर चित्रित माना जाता है, और Windows प्रदर्शन के लिए bitmap खींचता है। इसीलिए पुराने ऐप high-DPI monitor पर «धुंधले» दिखते हैं, और Compatibility टैब का «Override high DPI scaling behavior» वह switch है जो इस virtualization व्यवहार को बदलता है।¹¹

flowchart TB
    accTitle: DPI virtualization कैसे काम करता है
    accDescr: जिस ऐप ने DPI awareness घोषित नहीं की उसे 96 DPI पर चित्रित माना जाता है; Windows bitmap खींचता है जिससे धुंधला दिखता है और Compatibility टैब का high-DPI override इस virtualization व्यवहार को बदलता है
    app["ऐप जो DPI awareness घोषित नहीं करता"] --> treat["96 DPI पर चित्रित माना जाता है"]
    treat --> stretch["प्रदर्शन के लिए bitmap खींचा जाता है"]
    stretch --> blur["High-DPI monitor पर धुंधला दिखता है"]
    tab["Override high DPI scaling behavior"] -.->|Virtualization व्यवहार बदलता है| treat

चित्र 3: DPI-unaware ऐप को 96 DPI माना जाता है और खींचा जाता है; Compatibility टैब override इस virtualization का switch है।

3. Shim वास्तव में क्या है — IAT फिर लिखकर API के बीच काटना

3.1. ऐप और OS के बीच खड़ा «दुभाषिया»

Windows executable (PE format) बाहरी DLL के API import address table (IAT) से बुलाता है। जब ऐप GetVersionEx बुलाता है वह केवल IAT में लिखे address पर कूदता है। Shim mechanism उसी का लाभ उठाता है। Load समय target API की IAT entry को shim code के address पर फिर लिखता है और खुद को ऐप व Windows के बीच डालता है। GetProcAddress से dynamically मिले API स्वयं GetProcAddress hook करके सँभाले जाते हैं।³

काटने के बाद shim «वर्तमान OS version क्या है?» पर पुराना version संख्या लौटा सकता है, या अलिखनीय स्थान की फ़ाइल पहुँच अन्यत्र remap कर सकता है, फिर अगर चाहिए तो वास्तविक API बुलाता है। ऐप की दृष्टि से «पुराने Windows पर चल रहा है»; OS की दृष्टि से «सभ्य ऐप चल रहा है» — shim दोनों के बीच दुभाषिया है।

flowchart TB
    accTitle: वह path जिससे shim API call काटता है
    accDescr: ऐप की API call IAT से गुजरती है; load समय IAT entry shim पर फिर लिखने से shim काट सकता है पुराने Windows जैसी प्रतिक्रिया नकली कर सकता है फिर अगर चाहिए वास्तविक API बुला सकता है
    app["ऐप"] -->|API call| iat["IAT entry"]
    iat -->|Load समय shim पर फिर लिखा| shim["Shim (दुभाषिया)"]
    shim -->|अगर चाहिए| api["वास्तविक Windows API"]
    shim -.-> lie["पुराने Windows जैसी वही प्रतिक्रिया नकली करता है"]
    gpa["GetProcAddress से call"] -.->|Hook से सँभाला| shim

चित्र 4: Shim ऐप और Windows API के बीच काटता है। फिर लिखा जाता है ऐप-पक्ष IAT; OS स्वयं नहीं बदलता।

इस डिज़ाइन से तीन महत्वपूर्ण गुण निकलते हैं।³

1. Shim ऐप-पक्ष code के रूप में चलता है। वह OS का भाग नहीं, इसलिए ऐप जैसी ही security barriers के अधीन है। Shim OS security mechanism नहीं घेर सकता, और shim उपयोग के लिए security settings ढीली करने की आवश्यकता नहीं।
2. जो shim सुधार सकता है, ऐप-पक्ष code सुधार भी सुधार सकता है। Shim «source नहीं / सुधार नहीं सकते» स्थितियों का विकल्प है; code सुधार से अधिक शक्तिशाली नहीं।
3. केवल user mode। Kernel mode में चलने वाले device drivers की compatibility समस्याएँ shim नहीं सुधार सकता।

3.2. Shim database (.sdb) और मिलान

«किस EXE पर कौन सा shim apply करें» की तालिका shim database है, .sdb extension वाली binary फ़ाइल। Target ऐप executable फ़ाइल नाम, आकार, checksum और version जैसी विशेषताओं (matching attributes) से database में registered होते हैं, और process शुरू होते समय मिलाए जाते हैं। उपचारों में Appfix (shim) है जो API hook घुसाता है, और Apphelp जो «इस ऐप में compatibility समस्या है» संदेश दिखाता है। कई shim और flags का bundle compatibility layer (compatibility mode) है।¹

चूकना आसान: यह मिलान केवल उन ऐप पर नहीं चलता जिन पर compatibility mode सेट है, बल्कि हर process launch पर। Windows हज़ारों ज्ञात ऐप के fixes का OS-standard database भेजता है (फ़ाइलें %WINDIR%\AppPatch के नीचे), और आपके PC पर आज लगभग निश्चित कोई पुराना ऐप बिना किसी के ध्यान shim जुड़े शुरू होता है। Microsoft-प्रदत्त compatibility fixes Windows का भाग बनकर आते हैं और Windows Update से update होते हैं।³

flowchart TB
    accTitle: Process शुरू होते समय shim database मिलान
    accDescr: हर process launch shim database से मिलाया जाता है; अगर registration matching attributes से मेल खाए तो Appfix shim घुसाता है या Apphelp संदेश दिखाता है वरना process ज्यों की त्यों शुरू होती है
    start["Process शुरू"] --> db[".sdb से मिलान"]
    db -.-> attr["फ़ाइल नाम आकार आदि"]
    db --> hit{"Registration?"}
    hit -->|हाँ| appfix["Appfix: shim घुसाएँ"]
    hit -->|हाँ| apphelp["Apphelp: संदेश"]
    hit -->|नहीं| plain["ज्यों का त्यों शुरू"]
    layer["Compatibility layer"] -.->|Shim और flags का bundle| appfix

चित्र 5: मिलान हर process launch पर चलता है, केवल compatibility mode सेट ऐप पर नहीं।

3.3. PCA — वह mechanism जो shim स्वतः apply करता है

एक और path जिससे admin के इरादे बिना shim apply हो सकता है PCA (Program Compatibility Assistant) है। PCA ऐप execution देखता है, और ज्ञात compatibility समस्या के संकेत मिलने पर user को fix apply करने का प्रस्ताव देता है या कुछ मामलों में compatibility settings स्वतः apply करता है। उदाहरण के लिए मुक्त DLL के भीतर code बुलाकर crash करने वाले ऐप को PINDLL मिलता है, और सुरक्षित Windows फ़ाइल लेखन में fail ऐप को WRPMITIGATION।⁵

flowchart TB
    accTitle: PCA compatibility settings स्वतः कैसे apply करता है
    accDescr: PCA ऐप execution देखता है और ज्ञात compatibility समस्या के संकेत मिलने पर user को fix apply करने का प्रस्ताव देता है या कुछ मामलों में compatibility settings स्वतः apply करता है
    run["ऐप execution"] --> pca["PCA देखता है"]
    pca --> sign{"ज्ञात समस्या के संकेत?"}
    sign -->|हाँ| resp{"कौन सा मामला?"}
    resp -->|प्रस्ताव से सँभाला| suggest["Fix apply करने का प्रस्ताव"]
    resp -->|कुछ मामले| auto["Compatibility settings स्वतः apply"]
    sign -->|नहीं| none["ज्यों का त्यों चलाएँ"]
    auto -.-> ex["उदाहरण: PINDLL या WRPMITIGATION"]

चित्र 6: PCA ऐप execution देखता है, और ज्ञात समस्या के संकेत मिलने पर fix प्रस्तावित करता है या स्वतः apply करता है।

«मैंने कुछ सेट नहीं किया, पर किसी बिंदु compatibility mode checkbox चालू था» की पहचान बहुत मामलों में यही है। न दोष है न गलत क्लिक; Windows डिज़ाइन के अनुसार व्यवहार कर रहा है।

4. प्रतिनिधि shim क्या कर सकते हैं

Microsoft द्वारा प्रकाशित तैयार shim में से यह चयन business ऐप की आयु बढ़ाते समय वास्तव में अक्सर आता है।⁴

सूची देखने पर अधिकांश shim «वह झूठ जो पुराना ऐप जिस उत्तर की अपेक्षा करता है वह लौटाता है» हैं। Disk अधिकतम 2GB, OS XP है, आप Administrator हैं — वे केवल उस process के भीतर ऐप के जन्म के युग का विश्वदृश्य फिर बनाते हैं।

Version lie «official default व्यवहार» बन गई

Version lie विशेष hack नहीं। Windows 8.1 से GetVersionEx जो मान लौटाता है वह ऐप के manifest पर निर्भर है। Manifest के <compatibility> खंड में <supportedOS> घोषणा रहित ऐप को, वास्तविक OS जो भी हो, हमेशा Windows 8-समकक्ष (6.2) दिया जाता है। घोषणा हो तो घोषित OS में सबसे ऊँचे तक का मान लौटता है (उदाहरण के लिए Windows 8.1 GUID तक घोषित हो तो Windows 11 पर भी 6.3 मिलता है)।⁶⁷

इसलिए «ऐप जो Windows version देखता है» इन परतदार चरणों में तय होता है।

1. Manifest में घोषित OS तक का मान लौटता है (घोषणा न हो तो 6.2)
2. अगर compatibility mode (VersionLie-परिवार shim) apply हो तो चुने OS का version लौटता है⁶

flowchart TB
    accTitle: ऐप जो OS version देखता है वह कैसे तय होता है
    accDescr: GetVersionEx का मान manifest में supportedOS घोषणा से तय होता है; घोषणा न हो तो Windows 8-समकक्ष 6.2 घोषणा हो तो सबसे ऊँचे घोषित OS तक मान और VersionLie-परिवार shim apply हो तो चुने OS version से अधिलेखित
    q["GetVersionEx query"] --> m{"supportedOS घोषणा है?"}
    m -->|नहीं| v62["Windows 8-समकक्ष (6.2) लौटता है"]
    m -->|हाँ| decl["सबसे ऊँचे घोषित OS तक मान"]
    v62 --> lie{"VersionLie-परिवार shim apply?"}
    decl --> lie
    lie -->|हाँ| fake["Compatibility mode में चुना OS मान"]
    lie -->|नहीं| asis["मान ज्यों का त्यों लौटता है"]

चित्र 7: ऐप जो Windows version देखता है वह manifest और shim की परतदार चरणों में तय होता है।

अगर internal ऐप «OS version पर शाखा करता है और उलझन से 8 माना जाता है जबकि यह Windows 11 है», पहले manifest की supportedOS घोषणा संदेह करें। उलटा कहें तो version जाँच पर शुरू अस्वीकार करने वाला पुराना ऐप उच्च संभावना से VersionLie shim से निकल सकता है। कई मामलों में वह केवल version संख्या देखता है, और वास्तविक व्यवहार नए OS पर ठीक है।

flowchart TB
    accTitle: Version से दो लक्षण और उनसे निपटना
    accDescr: अगर internal ऐप Windows 11 होते हुए भी 8 माना जाए तो manifest की supportedOS घोषणा संदेह करें; version जाँच पर शुरू अस्वीकार पुराना ऐप उच्च संभावना से VersionLie से निकल सकता है
    sym1["Windows 11 होते हुए भी 8 माना गया"] --> fix1["supportedOS घोषणा संदेह करें"]
    sym2["Version जाँच पर शुरू अस्वीकार"] --> fix2["VersionLie से निकलने का प्रयास"]
    fix2 -.-> why["वास्तविक व्यवहार अक्सर नए OS पर ठीक"]

चित्र 8: निर्णय पुराना हो तो manifest संदेह करें; शुरू अस्वीकार हो तो VersionLie संदेह करें।

5. Compatibility mode checkbox क्या करता है

Properties → Compatibility टैब की settings registry की AppCompatFlags\Layers key में संग्रहीत होती हैं। DXGI ऐप-compatibility settings आदि compatibility layer specify करने का स्थान उसी key का उपयोग करती हैं।² वास्तव में देखें।

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

जिस EXE पर Compatibility टैब पर «Windows XP (Service Pack 3)», «Run this program as an administrator» और «Override high DPI scaling behavior» सेट किया, आपको निम्न जैसा मान दिखेगा।

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

Checkbox आइटम और मानों के प्रतिनिधि मेल (Windows 11 पर पुष्ट; आइटम नाम और मान OS version से बदल सकते हैं)।

तीन बातें रखें।

• «Run this program as an administrator» उसी जगह लिखा जाता है। Compatibility mode और elevation flag एक ही Layers key में साथ रहते हैं, और वहीं से भ्रम «compatibility mode सेट किया और elevation आ गया / गायब हो गया» जन्म लेता है। मान सीधे देखने से दोनों अलग होते हैं।
• HKCU में लिखा «उस user की settings» है। टैब के «Change settings for all users» से सेट करें तो HKLM पक्ष की समनाम key में लिखा जाता है और सभी users पर apply होता है। Imaging में वितरित करते समय सचेत रहें किस पक्ष लिख रहे हैं।
• Checkbox केवल तैयार layers का प्रवेश है। टैब प्रतिनिधि layers ही चुनने देता है; अलग-अलग shim चुनकर नहीं जोड़ सकते। वह अगले अध्याय का Compatibility Administrator करता है।

flowchart TB
    accTitle: Compatibility टैब settings से प्रभावी होने तक का path
    accDescr: Compatibility टैब settings EXE path और मान के रूप में AppCompatFlags Layers key में संग्रहीत होती हैं; अगली बार वह EXE शुरू हो तो loader मान पढ़कर compatibility layer process पर apply करता है
    tab["Compatibility टैब पर सेट"] --> reg["Layers key में EXE path और मान संग्रह"]
    reg --> boot["अगला EXE शुरू"]
    boot --> loader["Loader मान पढ़ता है"]
    loader --> apply["Process पर compatibility layer apply"]
    reg -.-> hkcu["HKCU केवल उसी user"]
    reg -.-> hklm["HKLM सभी users पर apply"]

चित्र 9: Checkbox वास्तव में Layers key में लेखन है, और apply अगले शुरू पर होता है।

6. Compatibility Administrator व्यवहार में — custom .sdb बनाना और वितरित करना

6.1. कैसे मिले, और चेतावनियाँ

Compatibility Administrator Windows ADK (Windows Assessment and Deployment Kit) में शामिल उपकरण है।¹² Install के बाद 32-bit और 64-bit दोनों versions होते हैं, और 32-bit ऐप के लिए 32-bit version तथा 64-bit ऐप के लिए 64-bit version ही उपयोग करें।¹³

एक और महत्वपूर्ण चेतावनी है। Compatibility Administrator elevated (Administrator) शुरू करके परीक्षण करें तो UAC virtualization और redirection वास्तविक user जैसे व्यवहार नहीं करते, और आप गलत निर्णय ले सकते हैं कि «सुधार हो गया»। सुधार का प्रभाव हमेशा वास्तविक user जैसे account और permission से पुष्टि करें।⁴

flowchart TB
    accTitle: Compatibility Administrator उपयोग की दो चेतावनियाँ
    accDescr: 32-bit ऐप के लिए 32-bit version और 64-bit ऐप के लिए 64-bit version उपयोग करें और सुधार का प्रभाव elevated अवस्था में नहीं वास्तविक user जैसे account और permission से पुष्टि करें
    app32["32-bit ऐप"] --> tool32["32-bit version उपयोग करें"]
    app64["64-bit ऐप"] --> tool64["64-bit version उपयोग करें"]
    elev["Elevated अवस्था में परीक्षण"] -.-> wrong["सुधार का गलत निर्णय हो सकता है"]
    user["वास्तविक user जैसी permission से परीक्षण"] --> ok["प्रभाव पुष्टि करें"]

चित्र 10: 32-bit या 64-bit version चुनना, और वास्तविक user जैसी permission से पुष्टि, प्रवेश की चेतावनियाँ हैं।

6.2. Custom compatibility database बनाने की procedure

रूपरेखा इस प्रकार है।¹⁴

1. Compatibility Administrator के बाएँ फलक में «Custom Databases» के नीचे नया database बनाएँ और «Create New» → «Application Fix» चुनें
2. ऐप नाम और vendor नाम दर्ज करें, और target EXE फ़ाइल specify करें
3. Apply करने योग्य compatibility mode (layer) चुनें — पहले «Windows XP compatibility» जैसा bundle आज़माना छोटा पथ है
4. अगर चाहिए व्यक्तिगत compatibility fixes (shim) जोड़ें — VersionLie केवल या CorrectFilePaths केवल जैसे न्यूनतम सेट तक संकीर्ण कर सकते हैं
5. Matching शर्तें (फ़ाइल आकार, checksum, version आदि) पुष्टि करें और सहेजें

Matching शर्तें «इसे केवल इस EXE पर apply करें» की कुंजी हैं। Default बुनियादी शर्तें आमतौर पर काफ़ी हैं, पर हम सुझाते हैं ऐप version पहचान सकने वाली शर्त छोड़ें। इससे वह दुर्घटना रुकती है जिसमें vendor बाद में सुधारा version भेजे तो पुराना झूठ नए version पर apply रहता है।¹⁴¹⁵

flowchart TB
    accTitle: Custom compatibility database बनाने की procedure
    accDescr: नए database में Application Fix बनाएँ ऐप नाम और target EXE specify करें पहले compatibility-mode bundle आज़माएँ फिर अगर चाहिए व्यक्तिगत shim तक संकीर्ण करें matching शर्तें पुष्टि करें और सहेजें
    new["नया database बनाएँ"] --> fix["Application Fix चुनें"]
    fix --> info["ऐप नाम और target EXE specify करें"]
    info --> layer["Compatibility-mode bundle आज़माएँ"]
    layer --> single["अगर चाहिए व्यक्तिगत shim तक संकीर्ण"]
    single --> match["Matching शर्तें पुष्टि करें और सहेजें"]
    match -.-> ver["Version पहचानने वाली शर्त छोड़ें"]

चित्र 11: Application Fix के लिए पहले compatibility-mode bundle आज़माएँ, न्यूनतम सेट तक संकीर्ण करें, और matching शर्तों से लक्ष्य सीमित करें।

बनाया .sdb पहले सत्यापन मशीन पर परीक्षण करें। इरादे के अनुसार चले तो संगठन में roll out करें।

6.3. sdbinst से वितरण

प्रत्येक PC पर custom .sdb apply करने वाला command sdbinst.exe है (Administrator permission चाहिए)।¹⁵

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

संगठनात्मक-deployment रणनीति के रूप में Microsoft सुझाता है प्रत्येक ऐप के installer के साथ अलग .sdb भेजने के बजाय एक कंपनी-व्यापी (या विभाग-वार) custom database में समेकित कर केंद्र से प्रबंधित करें। जितने अधिक fixes, एक database update और redistribute करना कई एक-पंक्ति databases बाँटने से आसान। Custom database का अपना GUID होता है, और उसी GUID से नया version install करने पर पुराना version स्वतः बदल जाता है, इसलिए update संचालन भी सरल रहता है। वितरण स्वयं किसी मौजूदा पथ पर रखें जो Administrator permission से चल सके, जैसे MSI package या startup script।¹⁵

flowchart TB
    accTitle: Custom .sdb बनाने से वितरित करने तक का path
    accDescr: Compatibility Administrator में custom compatibility database बनाएँ सत्यापन मशीन पर परीक्षण करें sdbinst से प्रत्येक PC पर apply करें और update पर उसी GUID से नया version install करें जिससे पुराना स्वतः बदल जाए
    make["Compatibility Administrator में बनाएँ"] --> test["सत्यापन मशीन पर परीक्षण"]
    test --> deploy["sdbinst से प्रत्येक PC पर apply"]
    deploy --> update["उसी GUID से नया version install"]
    update -.-> replace["पुराना version स्वतः बदलता है"]
    deploy -.-> inv["Programs and Features में registered"]

चित्र 12: Custom .sdb बनाना, सत्यापित करना और sdbinst वितरण से roll out होता है, और updates GUID से प्रबंधित होते हैं।

Install custom database «Programs and Features (installed apps)» में आइटम के रूप में registered होता है, इसलिए वहाँ से भी inventory और हटाना पुष्टि कर सकते हैं। किन PC पर कौन सा .sdb है वह जानकारी संपत्ति-प्रबंधन ledger की है।

7. जहाँ काम नहीं करता, और सीमाएँ

Shim चाँदी की गोली नहीं। डिज़ाइन से निम्नलिखित मामलों में काम नहीं करते।

• Kernel-mode समस्याएँ। Shim user-mode process के भीतर चलता है, इसलिए device-driver incompatibility नहीं सुधर सकती। पुराने मापन यंत्र, USB dongle या printer का driver Windows 11 supported न हो तो ऐप पक्ष जो भी apply करें हल नहीं होगा। Kernel में चलने वाला code, जैसे antivirus software के भाग, वही।³
• 16-bit ऐप। 64-bit Windows 16-bit ऐप चलाना supported नहीं करता। Handles पर 64-bit Windows में 32 valid bits होते हैं और 16-bit ऐप को देने के लिए काटे नहीं जा सकते, इसलिए शुरू ERROR_BAD_EXE_FORMAT से fail होता है।⁸ ऐप स्वयं 32-bit हो तब भी उस युग के packages हैं जिनका installer stub 16-bit है, और वे «ऐप चलता पर install नहीं कर सकते» के रूप में दिखते हैं।
• सीधी hardware access। Industrial ऐप जो मानते हैं कि I/O ports या physical memory सीधे छू सकते हैं उन्हें आधुनिक Windows पर user mode से वैसा करने की permission पहले से नहीं, और वह सीमा shim नकल नहीं कर सकता।
• Security mechanism घेरना। क्योंकि shim ऐप जैसी ही security barriers के नीचे चलता है, वह «permission न होने से नहीं कर सकते» को संभव नहीं बना सकता। ForceAdminAccess और WRPMitigation केवल जाँच या लेखन की सफलता नकली करते हैं ताकि ऐप आगे बढ़े; वे वास्तव में सुरक्षित resources फिर नहीं लिखते।³⁴
• अपनी integrity जाँचने वाले ऐप। पुरानी copy protection या tamper detection वाले ऐप API hook को स्वयं असामान्य मानकर रुक सकते हैं।

flowchart TB
    accTitle: जहाँ shim काम नहीं करता
    accDescr: Shim user-mode process के भीतर चलता है इसलिए kernel-mode driver समस्याओं 16-bit ऐप सीधी hardware access या security mechanism घेरने पर काम नहीं करता
    shim["Shim (user mode में चलता है)"] -->|काम नहीं करता| drv["Kernel driver"]
    shim -->|काम नहीं करता| b16["16-bit ऐप"]
    shim -->|काम नहीं करता| hw["सीधी hardware access"]
    shim -->|काम नहीं करता| sec["Security mechanism घेरना"]
    b16 -.-> fmt["64-bit पर शुरू स्वयं fail"]
    sec -.-> fake["केवल सफलता नकली ताकि ऐप आगे बढ़े"]

चित्र 13: Shim केवल user-mode है और kernel, 16-bit ऐप, सीधी hardware access या security bypass तक नहीं पहुँचता।

और हर shim की साझा मूल सीमा यह है कि यह अस्थायी उपाय है। Shim किसी विशेष API के विशेष उपयोग के लिए सिली झूठ है, और OS-पक्ष implementation बदले तो धारणा गिर जाती है। Microsoft-प्रदत्त shim Windows Update से Windows के भाग के रूप में रखे जाते हैं,³ पर custom database से apply झूठ सँभालना आपके संगठन का काम है। Life-extension की लागत के रूप में हर feature update पर «shim से जीवित रखे ऐप की सूची» सत्यापित करने वाला संचालन बजट करें।

flowchart TB
    accTitle: अस्थायी उपाय के रूप में shim और उन्हें कौन बनाए रखता है
    accDescr: Shim विशेष API उपयोग के लिए सिली झूठ है और OS-पक्ष implementation बदले तो धारणा गिरती है; Microsoft shim Windows Update से रखे जाते हैं पर custom-database झूठ संगठन सँभालता है और हर feature update पर सत्यापन life-extension लागत है
    shim["Shim = अस्थायी झूठ"] --> break["OS बदलाव तोड़ता है"]
    ms["Microsoft shim"] --> wu["Windows Update से"]
    own["Custom-database झूठ"] --> self["संगठन सँभालता है"]
    self --> cost["हर update पर सत्यापन life-extension लागत है"]

चित्र 14: Shim झूठ बनाए रखने की ज़िम्मेदारी Microsoft-प्रदत्त सेट और आपके संगठन के custom सेट के बीच बँटी है।

8. RunAsInvoker का practical मूल्य — केवल elevation request शांत करना

Shim में रोज़ IT काम में सबसे अधिक आने वाला RunAsInvoker है।

कुछ पुराने business apps manifest में requireAdministrator घोषित करते हैं, या EXE नाम या content से installer गलत पहचाने जाते हैं, और हर शुरू पर UAC elevation माँगते हैं। फिर भी बहुत से XP-युग की जड़ता से केवल Administrator माँगते हैं और वास्तव में Administrator permission उपयोग नहीं करते। RunAsInvoker shim apply करने से installer detection और manifest दोनों अधिलेखित होते हैं, और ऐप parent process से inherited token (= standard-user permission) से शुरू होता है।⁹

flowchart TB
    accTitle: RunAsInvoker elevation request कैसे दबाता है
    accDescr: Manifest में requireAdministrator घोषणा या installer गलत पहचान शुरू पर UAC elevation request पैदा करती है पर RunAsInvoker apply करने से दोनों अधिलेखित होते हैं और ऐप parent token से शुरू होता है
    manifest["requireAdministrator घोषणा"] --> shim{"RunAsInvoker apply?"}
    detect["Installer गलत पहचाना"] --> shim
    shim -->|नहीं| uac["हर शुरू पर UAC elevation request"]
    shim -->|हाँ| token["Parent token से शुरू"]
    token -.-> limit["सच में Administrator चाहिए काम ऐप के भीतर fail"]

चित्र 15: RunAsInvoker केवल elevation request का कारण अधिलेखित करता है; permissions नहीं बढ़तीं।

Compatibility Administrator में .sdb बनाए बिना भी __COMPAT_LAYER environment variable से वही layer अस्थायी apply कर सकते हैं।

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

उन दो पंक्तियों को batch फ़ाइल बनाकर shortcut के रूप में बाँटें तो standard users को local Administrator permission सौंपने से बच सकते हैं, और IT हर बार UAC password के लिए नहीं बुलाया जाता। यह compatibility technique रक्षा कड़ी करती है, least privilege के अनुरूप।

flowchart TB
    accTitle: RunAsInvoker batch बाँटने का प्रभाव
    accDescr: RunAsInvoker सेट करने वाली दो-पंक्ति batch shortcut के रूप में बाँटने से standard users को Administrator permission सौंपने से बच सकते हैं IT UAC password के लिए नहीं बुलाया जाता और संचालन least privilege का पालन करता है
    bat["दो-पंक्ति batch बाँटें"] --> noadmin["Administrator permission सौंपने से बच सकते हैं"]
    bat --> nocall["IT UAC के लिए नहीं बुलाया जाता"]
    noadmin --> lp["Least privilege वाला संचालन"]
    nocall --> lp

चित्र 16: अकेले batch बाँटना Administrator permission सौंपना और UAC के लिए बुलाना दोनों घटा सकता है।

चेतावनियाँ भी, स्पष्ट।

• Permissions नहीं बढ़तीं। सच में Administrator permission चाहिए काम (HKLM लेखन, Program Files के नीचे update आदि) ऐप के भीतर error देगा, या शर्तें पूरी हों तो UAC virtualization VirtualStore को मोड़ देगा।¹⁰ Settings सहेजना अचानक «रुक गया» लगे तो virtualization संदेह करें।
• Environment-variable विधि केवल child processes पर apply होती है। स्थायी apply करने के लिए Layers key में सीधी setting (RUNASINVOKER का टैब पर आइटम नहीं) या .sdb से वितरण विश्वसनीय है।
• लेखन गंतव्य सुधारना असली path है। ऐप बदल सकें तो settings फ़ाइल %APPDATA% के नीचे ले जाएँ और manifest में asInvoker घोषित करें — वही सही आकार है।⁹

flowchart TB
    accTitle: RunAsInvoker का अस्थायी और स्थायी apply
    accDescr: COMPAT_LAYER environment variable से apply केवल वहाँ से शुरू child processes पर होता है; स्थायी apply के लिए Layers key में सीधी setting या .sdb वितरण उपयोग करें
    env["Environment variable से सेट"] --> child["केवल child processes पर apply"]
    child -.-> tmp["अस्थायी apply"]
    layers["Layers key में सीधे सेट"] --> always["स्थायी apply"]
    sdb["sdb से वितरित"] --> always

चित्र 17: Environment-variable विधि child processes तक सीमित अस्थायी apply है; स्थायी Layers key या .sdb से होता है।

9. Life-extension और migration के बीच निर्णय — shim के नीचे चलने के बाद क्या सोचें

Shim के नीचे चलने का क्षण राहत है, पर वहीं सोचना बंद न करना महत्वपूर्ण है। Shim के नीचे चलना केवल मतलब है Windows ने जो पात्र तैयार किया उससे संयोग से मेल खा गया। निर्णय के अक्ष, तालिका में।

Life-extension का निर्णय लें तो निम्न तीन बिंदु संचालन में सेट के रूप में डालें।

1. लिखें। कौन सा EXE, कौन सा shim/layer, और क्यों। Layers-key मान और .sdb GUID ledger में छोड़ें। «कोई नहीं जानता क्यों चलता है» अगले व्यक्ति पर सबसे बड़ा ऋण है। यह वही संरक्षण सोच है जो «When You Inherit a System With No Source Code and No Documentation» में है।
2. सत्यापित करें। Windows feature update के सत्यापन आइटम में shim से जीवित रखे ऐप का शुरू और मुख्य संचालन शामिल करें। OS-प्रतिस्थापन योजना से भी बाँधें (Practical Options After Windows 10 End of Support)।
3. समय सीमा तय करें। Life-extension का अंत तय करें — «अगले मुख्य-सिस्टम refresh तक», «मार्च 2028 तक» — और migration विचार समानांतर चलाएँ।

flowchart TB
    accTitle: Life-extension निर्णय के बाद तीन-बिंदु संचालन सेट
    accDescr: Ledger में लिखें कौन सा shim चलाता है हर feature update पर shim से जीवित ऐप का व्यवहार सत्यापित करें life-extension के अंत की समय सीमा तय करें और migration विचार समानांतर चलाएँ
    decide["Life-extension का निर्णय"] --> rec["लिखें: कौन सा shim चलाता है ledger में"]
    rec --> verify["सत्यापित: हर feature update पर व्यवहार पुष्टि"]
    verify --> deadline["समय सीमा: Life-extension का अंत तय करें"]
    deadline --> mig["Migration विचार समानांतर चलाएँ"]

चित्र 18: Life-extension लेखन, सत्यापन और समय सीमा के तीन-बिंदु सेट के रूप में संचालित होता है, migration विचार समानांतर सहित।

Migration पक्ष पर मानक विकल्प ऐप की तकनीक से बदलते हैं। VB6 के लिए पूर्ण फिर-लेखन, automatic conversion और चरणबद्ध migration का त्रिविध चयन «How Long Will VB6 Apps Keep Running?» में व्यवस्थित; ActiveX/OCX निर्भरता के लिए रखें / लपेटें / बदलें निर्णय तालिका «How to Handle ActiveX / OCX Today» में। Shim को स्वस्थ स्थान देना उस migration परियोजना के विचार और तैयारी काल को सुरक्षित चलाने के लिए समय खरीदना है।

flowchart TB
    accTitle: Migration पक्ष के विकल्प और shim कहाँ बैठता है
    accDescr: मानक migration विकल्प ऐप की तकनीक से बदलते हैं; VB6 के लिए फिर-लेखन automatic conversion या चरणबद्ध migration ActiveX निर्भरता के लिए रखें लपेटें या बदलें तालिका और shim migration परियोजना के विचार और तैयारी के लिए समय खरीदने के रूप में रखा जाता है
    tech{"ऐप की तकनीक क्या है?"} -->|VB6| vb["फिर-लेखन automatic conversion या चरणबद्ध migration"]
    tech -->|ActiveX निर्भरता| ax["रखें लपेटें या बदलें"]
    shim["Shim से life-extension"] -.->|विचार और तैयारी के लिए समय खरीदता है| tech

चित्र 19: मानक migration विकल्प ऐप की तकनीक से तय होते हैं, और shim उस विचार के लिए समय खरीदने के रूप में रखा जाता है।

10. सार

• Compatibility mode की असली पहचान shim हैं। Compatibility टैब की settings AppCompatFlags\Layers key में लिखी जाती हैं और शुरू होते समय IAT फिर-लेखन से API hook के रूप में process में घुसती हैं।
• Shim «पुराना ऐप जिस उत्तर की अपेक्षा करता है वह लौटाने वाले झूठ» का संग्रह हैं। Version lie, path remapping, registry नकल, Administrator जाँच नकल आदि के तैयार shim दिए गए हैं।
• Windows स्वयं default रूप से बहुत से shim उपयोग करता है, और PCA उन्हें स्वतः apply कर सकता है। Compatibility mode पर भरोसा स्वयं official OS mechanism पर सवार उचित चयन है।
• केवल user-mode और कोई security bypass का सैद्धांतिक सीमा है, और kernel drivers, 16-bit ऐप तथा सीधी hardware access नहीं बच सकते।
• संगठनात्मक rollout Compatibility Administrator (Windows ADK) में custom .sdb बनाना और sdbinst से वितरित करना है। 32-bit/64-bit version चुनना, वास्तविक user account से परीक्षण, और GUID से update प्रबंधित करना practical बिंदु हैं।
• «Administrator माँगते हैं पर वास्तव में नहीं चाहिए» ऐप __COMPAT_LAYER=RunAsInvoker से standard permission तक लाए जा सकते हैं। यह रक्षा technique elevation request शांत करती है permission सौंपने के बजाय।
• Shim के नीचे चलना life-extension है, समाधान नहीं। क्या चलाता है लिखना, हर feature update पर सत्यापन, और समय सीमा ताकि migration समानांतर चले — वह तीन-बिंदु सेट «compatibility mode पर भरोसा» निर्णय में शामिल है।

अगली बार पुराना ऐप compatibility mode checkbox के बाद चलने लगे तो फिर पूछें। «किस झूठ की बदौलत यह ऐप चल रहा है? वह झूठ कब तक काम करेगा?» उत्तर दे सकें तो life-extension सम्मानजनक रणनीति है।

संबंधित लेख

• 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
• आज का Windows shell integration ── context menu, file association, और Windows 11 में क्या बदला

संबंधित परामर्श क्षेत्र

KomuraSoft LLC बिना source code पुराने business apps कैसे व्यवहार करते हैं इसकी जाँच और उनकी life-extension डिज़ाइन (shim और compatibility mode चयन, custom .sdb बनाना और roll out), Windows 11 migration के लिए मौजूदा ऐप की compatibility सत्यापन, तथा life-extension के समानांतर फिर-लेखन या migration योजना सँभालती है। «Compatibility mode में चलने लगा, पर ऐसे छोड़ना ठीक है?» चरण से परामर्श ठीक है।

• मौजूदा संपत्तियों का पुनरुपयोग और माइग्रेशन
• Windows ऐप विकास
• तकनीकी परामर्श और डिज़ाइन समीक्षा
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

अगर compatibility mode tick करने के बाद ऐप चलने लगा, क्या उसी तरह चलाना ठीक है?

व्यवसाय को अल्पकाल में चलाए रखने के लिए हाँ। Compatibility mode user-mode API hook है जिसे shim कहते हैं, OS द्वारा दिया official mechanism। फिर भी shim ऐप को बिना सुधारे चलाने का अस्थायी उपाय है, और दूसरा OS update धारणाएँ बदल कर फिर तोड़ सकता है। Compatibility mode में चलने का तथ्य ledger में लिखें, और उस record को ऐप फिर लिखने या जान-बूझकर life-extend करने के निर्णय का हिस्सा मानें।

Compatibility mode का checkbox वास्तव में क्या करता है?

Properties dialog के Compatibility टैब पर settings सहेजने पर Windows target EXE का path और "WINXPSP3" या "HIGHDPIAWARE" जैसा मान HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers key के नीचे लिखता है। अगली बार वह EXE शुरू हो तो Windows loader मान पढ़कर compatibility layer (shim bundle) process पर apply करता है। Windows XP compatibility mode, उदाहरण के लिए, version-query API से पुराना मान लौटाकर OS version नकली करता है। OS स्वयं नहीं बदलता; केवल उस process को दिखावटी पुराना Windows दिखाया जाता है।

क्या 16-bit युग के ऐप 64-bit Windows पर compatibility mode में चल सकते हैं?

नहीं। 64-bit Windows 32-bit ऐप WOW64 से चलाता है, पर 16-bit ऐप चलाना supported नहीं, और शुरू करने का प्रयास ERROR_BAD_EXE_FORMAT से fail होता है। वह architecture सीमा है जिसे shim घेर नहीं सकता। पुराने packages जिनका installer stub 16-bit है उसी कारण fail होते हैं। सच में चाहिए तो compatibility mode के बाहर देखें — उदाहरण के लिए वह virtual machine जिसमें 32-bit Windows हो।

क्या «Administrator के रूप में चलाए बिना शुरू नहीं होगा» वाला ऐप standard user account के नीचे चला सकता हूँ?

RunAsInvoker आज़माने लायक है। Command prompt पर set __COMPAT_LAYER=RunAsInvoker चलाकर फिर ऐप शुरू करें तो requireAdministrator manifest या installer detection से elevation request दब जाते हैं, और ऐप caller जैसी ही (standard-user) permission से शुरू होता है। जो ऐप केवल Administrator अधिकार माँगता है और वास्तव में उपयोग नहीं करता, अकेले इससे रोज़मर्रा संचालन से elevation निकल सकता है। Permissions नहीं बढ़तीं, इसलिए सच में Administrator अधिकार चाहिए काम ऐप के भीतर fail होगा। व्यवहार सत्यापित करने के बाद ही अपनाएँ।

Compatibility Administrator कहाँ से मिले?

Windows ADK (Windows Assessment and Deployment Kit) में शामिल है। Microsoft साइट से ADK download करें और install समय Application Compatibility Tools सुविधाएँ चुनें। 32-bit और 64-bit दोनों versions install होते हैं; 32-bit ऐप के लिए 32-bit version और 64-bit ऐप के लिए 64-bit version ही उपयोग करें। आपका बनाया custom compatibility database (.sdb) प्रत्येक PC पर sdbinst command चलाकर apply करें।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।