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

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

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

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

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

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

छोटे-मझोले व्यवसायों के IT कर्मचारियों और पुराने व्यावसायिक ऐप सँभालने वाले Windows ऐप डेवलपरों के लिए, यह लेख Microsoft Learn प्राथमिक स्रोतों से उस shim तंत्र को व्यवस्थित करता है जो संगतता मोड की असली पहचान है, प्रतिनिधि shim क्या कर सकते हैं, Compatibility Administrator से संगठनात्मक रूप से कैसे लागू करें, वे सीमाएँ जिन्हें shim नहीं बचाता, और आयु-विस्तार व माइग्रेशन के बीच कैसे निर्णय लें।

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

• संगतता मोड की असली पहचान shim हैं (संगतता परत)। Compatibility टैब की सेटिंग HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers में लिखी जाती हैं, और शुरू होते समय उस प्रक्रिया पर shim बंडल लागू होता है।¹²
• Shim user-mode API हुक है जो import address table (IAT) फिर लिखता है। वह पथ काटता है जिससे ऐप Windows API बुलाता है और वही उत्तर लौटाता है जो पुराना Windows देता। OS स्वयं नहीं बदलता।³
• Shim जो कर सकता है वही सीमा है जो ऐप में कोड सुधार कर सकता है। सुरक्षा तंत्र नहीं घेर सकता, और कर्नेल-मोड (डिवाइस-ड्राइवर) समस्याएँ नहीं सुधार सकता।³
• Microsoft बहुत से तैयार shim भेजता है — संस्करण झूठ, फ़ाइल-पथ पुनर्मानचित्रण, रजिस्ट्री नकल, व्यवस्थापक जाँच की नकल, और अन्य। Compatibility Administrator से उन्हें अलग-अलग EXE पर लागू कर सकते हैं।⁴
• Windows स्वयं डिफ़ॉल्ट रूप से shim उपयोग करता है। OS-मानक संगतता डेटाबेस (.sdb) हर लॉन्च पर मिलाया जाता है, और PCA (Program Compatibility Assistant) समस्या पहचानकर संगतता सेटिंग स्वतः भी लागू कर सकता है।¹⁵
• «ऐसे उत्तर देना मानो यह पुराना Windows हो» अब डिफ़ॉल्ट है। Windows 8.1 से GetVersionEx वह OS संस्करण नहीं लौटाता जिसे ऐप ने मैनिफेस्ट में घोषित नहीं किया। संगतता मोड उसी तंत्र का विस्तार है।⁶⁷
• Shim 16-बिट ऐप, कर्नेल-ड्राइवर निर्भरता, या सीधे हार्डवेयर पहुँच पर नहीं चलते। विशेषकर 16-बिट ऐप 64-बिट Windows पर बिल्कुल नहीं चल सकते।⁸
• उन ऐप के लिए जो «व्यवस्थापक माँगते हैं पर वास्तव में नहीं चाहिए», RunAsInvoker मानक कदम है। __COMPAT_LAYER=RunAsInvoker उन्नयन अनुरोध दबाता है और ऐप मानक अनुमति के नीचे चलता है।⁹
• Shim के नीचे चलना मतलब अभी आयु बढ़ा सकते हैं, पर असली पथ «बिना shim चलाएँ» है। यदि आयु बढ़ाने का निर्णय लें तो लिखें कौन से shim चलाते हैं और उसे फिर-लेखन निर्णय की सामग्री के रूप में प्रबंधित करें।

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

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

UAC वर्चुअलाइज़ेशन संक्रमण उपाय है जो बिना मैनिफेस्ट 32-बिट इंटरैक्टिव प्रक्रियाओं पर लागू होता है, और Microsoft स्वयं कहता है यह «अस्थायी तकनीक है जिसे हम भविष्य के Windows संस्करण से हटाने का इरादा रखते हैं»।¹⁰ Wow6432Node पुनर्निर्देशन और VirtualStore से वास्तविक क्षति, और उससे निपटना, विस्तार से «Registry 32-bit/64-bit Redirection and Virtualization Pitfalls» में है; यह लेख shim को केंद्र रखता है और अन्य परतों का उल्लेख केवल जितना चाहिए।

flowchart TB
    accTitle: UAC वर्चुअलाइज़ेशन कहाँ बैठता है
    accDescr: UAC वर्चुअलाइज़ेशन बिना मैनिफेस्ट 32-बिट इंटरैक्टिव प्रक्रियाओं का संक्रमण उपाय है; लेखन प्रति-उपयोगकर्ता VirtualStore में मोड़ता है पर Microsoft स्वयं कहता है यह अस्थायी तकनीक है जिसे भविष्य के Windows से हटाने का इरादा है
    proc["बिना मैनिफेस्ट 32-बिट इंटरैक्टिव प्रक्रिया"] --> uacv["UAC वर्चुअलाइज़ेशन लागू"]
    uacv --> vs["प्रति-उपयोगकर्ता VirtualStore में मोड़ा"]
    uacv -.-> tmp["अस्थायी तकनीक जिसे बाद में हटाने का इरादा"]

चित्र 2: UAC वर्चुअलाइज़ेशन बिना मैनिफेस्ट 32-बिट प्रक्रियाओं का संक्रमण उपाय है, और स्थायी रूप से भरोसा नहीं कर सकते।

DPI वर्चुअलाइज़ेशन पर टिप्पणी: जिस ऐप ने DPI जागरूकता घोषित नहीं की उसे 96 DPI (100%) पर चित्रित माना जाता है, और Windows प्रदर्शन के लिए बिटमैप खींचता है। इसीलिए पुराने ऐप उच्च-DPI मॉनिटर पर «धुंधले» दिखते हैं, और Compatibility टैब का «उच्च DPI स्केलिंग व्यवहार ओवरराइड करें» वह स्विच है जो इस वर्चुअलाइज़ेशन व्यवहार को बदलता है।¹¹

flowchart TB
    accTitle: DPI वर्चुअलाइज़ेशन कैसे काम करता है
    accDescr: जिस ऐप ने DPI जागरूकता घोषित नहीं की उसे 96 DPI पर चित्रित माना जाता है; Windows बिटमैप खींचता है जिससे धुंधला दिखता है और Compatibility टैब का उच्च-DPI ओवरराइड इस वर्चुअलाइज़ेशन व्यवहार को बदलता है
    app["ऐप जो DPI जागरूकता घोषित नहीं करता"] --> treat["96 DPI पर चित्रित माना जाता है"]
    treat --> stretch["प्रदर्शन के लिए बिटमैप खींचा जाता है"]
    stretch --> blur["उच्च-DPI मॉनिटर पर धुंधला दिखता है"]
    tab["उच्च DPI स्केलिंग व्यवहार ओवरराइड"] -.->|वर्चुअलाइज़ेशन व्यवहार बदलता है| treat

चित्र 3: DPI-अनजान ऐप को 96 DPI माना जाता है और खींचा जाता है; Compatibility टैब ओवरराइड इस वर्चुअलाइज़ेशन का स्विच है।

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

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

Windows निष्पादन योग्य (PE प्रारूप) बाहरी DLL के API import address table (IAT) से बुलाता है। जब ऐप GetVersionEx बुलाता है वह केवल IAT में लिखे पते पर कूदता है। Shim तंत्र उसी का लाभ उठाता है। लोड समय लक्ष्य API की IAT प्रविष्टि को shim कोड के पते पर फिर लिखता है और खुद को ऐप व Windows के बीच डालता है। GetProcAddress से गतिशील मिले API स्वयं GetProcAddress हुक करके सँभाले जाते हैं।³

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

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

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

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

1. Shim ऐप-पक्ष कोड के रूप में चलता है। वह OS का भाग नहीं, इसलिए ऐप जैसी ही सुरक्षा बाधाओं के अधीन है। Shim OS सुरक्षा तंत्र नहीं घेर सकता, और shim उपयोग के लिए सुरक्षा सेटिंग ढीली करने की आवश्यकता नहीं।
2. जो shim सुधार सकता है, ऐप-पक्ष कोड सुधार भी सुधार सकता है। Shim «स्रोत नहीं / सुधार नहीं सकते» स्थितियों का विकल्प है; कोड सुधार से अधिक शक्तिशाली नहीं।
3. केवल user mode। कर्नेल मोड में चलने वाले डिवाइस ड्राइवर की संगतता समस्याएँ shim नहीं सुधार सकता।

3.2. Shim डेटाबेस (.sdb) और मिलान

«किस EXE पर कौन सा shim लागू करें» की तालिका shim डेटाबेस है, .sdb एक्सटेंशन वाली बाइनरी फ़ाइल। लक्ष्य ऐप निष्पादन योग्य फ़ाइल नाम, आकार, चेकसम और संस्करण जैसी विशेषताओं (मिलान विशेषताएँ) से डेटाबेस में पंजीकृत होते हैं, और प्रक्रिया शुरू होते समय मिलाए जाते हैं। उपचारों में Appfix (shim) है जो API हुक घुसाता है, और Apphelp जो «इस ऐप में संगतता समस्या है» संदेश दिखाता है। कई shim और फ़्लैग का बंडल संगतता परत (संगतता मोड) है।¹

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

flowchart TB
    accTitle: प्रक्रिया शुरू होते समय shim डेटाबेस मिलान
    accDescr: हर प्रक्रिया लॉन्च shim डेटाबेस से मिलाया जाता है; यदि पंजीकरण मिलान विशेषताओं से मेल खाए तो Appfix shim घुसाता है या Apphelp संदेश दिखाता है वरना प्रक्रिया ज्यों की त्यों शुरू होती है
    start["प्रक्रिया शुरू"] --> db[".sdb से मिलान"]
    db -.-> attr["फ़ाइल नाम आकार आदि"]
    db --> hit{"पंजीकरण?"}
    hit -->|हाँ| appfix["Appfix: shim घुसाएँ"]
    hit -->|हाँ| apphelp["Apphelp: संदेश"]
    hit -->|नहीं| plain["ज्यों का त्यों शुरू"]
    layer["संगतता परत"] -.->|shim और फ़्लैग का बंडल| appfix

चित्र 5: मिलान हर प्रक्रिया लॉन्च पर चलता है, केवल संगतता मोड सेट ऐप पर नहीं।

3.3. PCA — वह तंत्र जो shim स्वतः लागू करता है

एक और पथ जिससे प्रशासक के इरादे बिना shim लागू हो सकता है PCA (Program Compatibility Assistant) है। PCA ऐप निष्पादन देखता है, और ज्ञात संगतता समस्या के संकेत मिलने पर उपयोगकर्ता को सुधार लागू करने का प्रस्ताव देता है या कुछ मामलों में संगतता सेटिंग स्वतः लागू करता है। उदाहरण के लिए मुक्त DLL के भीतर कोड बुलाकर क्रैश करने वाले ऐप को PINDLL मिलता है, और सुरक्षित Windows फ़ाइल लेखन में विफल ऐप को WRPMITIGATION।⁵

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

चित्र 6: PCA ऐप निष्पादन देखता है, और ज्ञात समस्या के संकेत मिलने पर सुधार प्रस्तावित करता है या स्वतः लागू करता है।

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

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

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

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

संस्करण नकल «आधिकारिक डिफ़ॉल्ट व्यवहार» बन गई

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

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

1. मैनिफेस्ट में घोषित OS तक का मान लौटता है (घोषणा न हो तो 6.2)
2. यदि संगतता मोड (VersionLie-परिवार shim) लागू हो तो चुने OS का संस्करण लौटता है⁶

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

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

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

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

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

5. संगतता मोड चेकबॉक्स क्या करता है

गुण → Compatibility टैब की सेटिंग रजिस्ट्री की AppCompatFlags\Layers कुंजी में संग्रहीत होती हैं। DXGI ऐप-संगतता सेटिंग आदि संगतता परत निर्दिष्ट करने का स्थान उसी कुंजी का उपयोग करती हैं।² वास्तव में देखें।

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

जिस EXE पर Compatibility टैब पर «Windows XP (Service Pack 3)», «इस प्रोग्राम को व्यवस्थापक के रूप में चलाएँ» और «उच्च DPI स्केलिंग व्यवहार ओवरराइड करें» सेट किया, आपको निम्न जैसा मान दिखेगा।

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

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

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

• «इस प्रोग्राम को व्यवस्थापक के रूप में चलाएँ» उसी जगह लिखा जाता है। संगतता मोड और उन्नयन फ़्लैग एक ही Layers कुंजी में साथ रहते हैं, और वहीं से भ्रम «संगतता मोड सेट किया और उन्नयन आ गया / गायब हो गया» जन्म लेता है। मान सीधे देखने से दोनों अलग होते हैं।
• HKCU में लिखा «उस उपयोगकर्ता की सेटिंग» है। टैब के «सभी उपयोगकर्ताओं के लिए सेटिंग बदलें» से सेट करें तो HKLM पक्ष की समनाम कुंजी में लिखा जाता है और सभी उपयोगकर्ताओं पर लागू होता है। इमेजिंग में वितरित करते समय सचेत रहें किस पक्ष लिख रहे हैं।
• चेकबॉक्स केवल तैयार परतों का प्रवेश है। टैब प्रतिनिधि परतें ही चुनने देता है; अलग-अलग shim चुनकर नहीं जोड़ सकते। वह अगले अध्याय का Compatibility Administrator करता है।

flowchart TB
    accTitle: Compatibility टैब सेटिंग से प्रभावी होने तक का पथ
    accDescr: Compatibility टैब सेटिंग EXE पथ और मान के रूप में AppCompatFlags Layers कुंजी में संग्रहीत होती हैं; अगली बार वह EXE शुरू हो तो लोडर मान पढ़कर संगतता परत प्रक्रिया पर लागू करता है
    tab["Compatibility टैब पर सेट"] --> reg["Layers कुंजी में EXE पथ और मान संग्रह"]
    reg --> boot["अगला EXE शुरू"]
    boot --> loader["लोडर मान पढ़ता है"]
    loader --> apply["प्रक्रिया पर संगतता परत लागू"]
    reg -.-> hkcu["HKCU केवल उसी उपयोगकर्ता"]
    reg -.-> hklm["HKLM सभी उपयोगकर्ताओं पर लागू"]

चित्र 9: चेकबॉक्स वास्तव में Layers कुंजी में लेखन है, और लागू अगले शुरू पर होता है।

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

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

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

एक और महत्वपूर्ण चेतावनी है। Compatibility Administrator उन्नत (व्यवस्थापक) शुरू करके परीक्षण करें तो UAC वर्चुअलाइज़ेशन और पुनर्निर्देशन वास्तविक उपयोगकर्ता जैसे व्यवहार नहीं करते, और आप गलत निर्णय ले सकते हैं कि «सुधार हो गया»। सुधार का प्रभाव हमेशा वास्तविक उपयोगकर्ता जैसे खाते और अनुमति से पुष्टि करें।⁴

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

चित्र 10: 32-बिट या 64-बिट संस्करण चुनना, और वास्तविक उपयोगकर्ता जैसी अनुमति से पुष्टि, प्रवेश की चेतावनियाँ हैं।

6.2. कस्टम संगतता डेटाबेस बनाने की प्रक्रिया

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

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

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

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

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

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

6.3. sdbinst से वितरण

प्रत्येक PC पर कस्टम .sdb लागू करने वाला कमांड sdbinst.exe है (व्यवस्थापक अनुमति चाहिए)।¹⁵

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

संगठनात्मक-तैनाती रणनीति के रूप में Microsoft सुझाता है प्रत्येक ऐप के इंस्टॉलर के साथ अलग .sdb भेजने के बजाय एक कंपनी-व्यापी (या विभाग-वार) कस्टम डेटाबेस में समेकित कर केंद्र से प्रबंधित करें। जितने अधिक सुधार, एक डेटाबेस अपडेट और पुनर्वितरित करना कई एक-पंक्ति डेटाबेस बाँटने से आसान। कस्टम डेटाबेस का अपना GUID होता है, और उसी GUID से नया संस्करण इंस्टॉल करने पर पुराना संस्करण स्वतः बदल जाता है, इसलिए अपडेट संचालन भी सरल रहता है। वितरण स्वयं किसी मौजूदा पथ पर रखें जो व्यवस्थापक अनुमति से चल सके, जैसे MSI पैकेज या स्टार्टअप स्क्रिप्ट।¹⁵

flowchart TB
    accTitle: कस्टम .sdb बनाने से वितरित करने तक का पथ
    accDescr: Compatibility Administrator में कस्टम संगतता डेटाबेस बनाएँ सत्यापन मशीन पर परीक्षण करें sdbinst से प्रत्येक PC पर लागू करें और अपडेट पर उसी GUID से नया संस्करण इंस्टॉल करें जिससे पुराना स्वतः बदल जाए
    make["Compatibility Administrator में बनाएँ"] --> test["सत्यापन मशीन पर परीक्षण"]
    test --> deploy["sdbinst से प्रत्येक PC पर लागू"]
    deploy --> update["उसी GUID से नया संस्करण इंस्टॉल"]
    update -.-> replace["पुराना संस्करण स्वतः बदलता है"]
    deploy -.-> inv["प्रोग्राम और सुविधाओं में पंजीकृत"]

चित्र 12: कस्टम .sdb बनाना, सत्यापित करना और sdbinst वितरण से रोल आउट होता है, और अपडेट GUID से प्रबंधित होते हैं।

इंस्टॉल कस्टम डेटाबेस «प्रोग्राम और सुविधाएँ (इंस्टॉल ऐप)» में आइटम के रूप में पंजीकृत होता है, इसलिए वहाँ से भी इन्वेंटरी और हटाना पुष्टि कर सकते हैं। किन PC पर कौन सा .sdb है वह जानकारी संपत्ति-प्रबंधन लेजर की है।

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

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

• कर्नेल-मोड समस्याएँ। Shim user-mode प्रक्रिया के भीतर चलता है, इसलिए डिवाइस-ड्राइवर असंगति नहीं सुधर सकती। पुराने मापन यंत्र, USB डॉंगल या प्रिंटर का ड्राइवर Windows 11 समर्थित न हो तो ऐप पक्ष जो भी लागू करें हल नहीं होगा। कर्नेल में चलने वाला कोड, जैसे एंटीवायरस सॉफ़्टवेयर के भाग, वही।³
• 16-बिट ऐप। 64-बिट Windows 16-बिट ऐप चलाना समर्थित नहीं करता। हैंडल पर 64-बिट Windows में 32 वैध बिट होते हैं और 16-बिट ऐप को देने के लिए काटे नहीं जा सकते, इसलिए शुरू ERROR_BAD_EXE_FORMAT से विफल होता है।⁸ ऐप स्वयं 32-बिट हो तब भी उस युग के पैकेज हैं जिनका इंस्टॉलर स्टब 16-बिट है, और वे «ऐप चलता पर इंस्टॉल नहीं कर सकते» के रूप में दिखते हैं।
• सीधी हार्डवेयर पहुँच। औद्योगिक ऐप जो मानते हैं कि I/O पोर्ट या भौतिक मेमोरी सीधे छू सकते हैं उन्हें आधुनिक Windows पर user mode से वैसा करने की अनुमति पहले से नहीं, और वह सीमा shim नकल नहीं कर सकता।
• सुरक्षा तंत्र घेरना। क्योंकि shim ऐप जैसी ही सुरक्षा बाधाओं के नीचे चलता है, वह «अनुमति न होने से नहीं कर सकते» को संभव नहीं बना सकता। ForceAdminAccess और WRPMitigation केवल जाँच या लेखन की सफलता नकली करते हैं ताकि ऐप आगे बढ़े; वे वास्तव में सुरक्षित संसाधन फिर नहीं लिखते।³⁴
• अपनी अखंडता जाँचने वाले ऐप। पुरानी कॉपी सुरक्षा या छेड़छाड़ पहचान वाले ऐप API हुक को स्वयं असामान्य मानकर रुक सकते हैं।

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

चित्र 13: Shim केवल user-mode है और कर्नेल, 16-बिट ऐप, सीधी हार्डवेयर पहुँच या सुरक्षा बाईपास तक नहीं पहुँचता।

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

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

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

8. RunAsInvoker का व्यावहारिक मूल्य — केवल उन्नयन अनुरोध शांत करना

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

कुछ पुराने व्यावसायिक ऐप मैनिफेस्ट में requireAdministrator घोषित करते हैं, या EXE नाम या सामग्री से इंस्टॉलर गलत पहचाने जाते हैं, और हर शुरू पर UAC उन्नयन माँगते हैं। फिर भी बहुत से XP-युग की जड़ता से केवल व्यवस्थापक माँगते हैं और वास्तव में व्यवस्थापक अनुमति उपयोग नहीं करते। RunAsInvoker shim लागू करने से इंस्टॉलर पहचान और मैनिफेस्ट दोनों अधिलेखित होते हैं, और ऐप पैरेंट प्रक्रिया से विरासत टोकन (= मानक-उपयोगकर्ता अनुमति) से शुरू होता है।⁹

flowchart TB
    accTitle: RunAsInvoker उन्नयन अनुरोध कैसे दबाता है
    accDescr: मैनिफेस्ट में requireAdministrator घोषणा या इंस्टॉलर गलत पहचान शुरू पर UAC उन्नयन अनुरोध पैदा करती है पर RunAsInvoker लागू करने से दोनों अधिलेखित होते हैं और ऐप पैरेंट टोकन से शुरू होता है
    manifest["requireAdministrator घोषणा"] --> shim{"RunAsInvoker लागू?"}
    detect["इंस्टॉलर गलत पहचाना"] --> shim
    shim -->|नहीं| uac["हर शुरू पर UAC उन्नयन अनुरोध"]
    shim -->|हाँ| token["पैरेंट टोकन से शुरू"]
    token -.-> limit["सच में व्यवस्थापक चाहिए काम ऐप के भीतर विफल"]

चित्र 15: RunAsInvoker केवल उन्नयन अनुरोध का कारण अधिलेखित करता है; अनुमतियाँ नहीं बढ़तीं।

Compatibility Administrator में .sdb बनाए बिना भी __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'

उन दो पंक्तियों को बैच फ़ाइल बनाकर शॉर्टकट के रूप में बाँटें तो मानक उपयोगकर्ताओं को स्थानीय व्यवस्थापक अनुमति सौंपने से बच सकते हैं, और IT हर बार UAC पासवर्ड के लिए नहीं बुलाया जाता। यह संगतता तकनीक रक्षा कड़ी करती है, न्यूनतम विशेषाधिकार के अनुरूप।

flowchart TB
    accTitle: RunAsInvoker बैच बाँटने का प्रभाव
    accDescr: RunAsInvoker सेट करने वाली दो-पंक्ति बैच शॉर्टकट के रूप में बाँटने से मानक उपयोगकर्ताओं को व्यवस्थापक अनुमति सौंपने से बच सकते हैं IT UAC पासवर्ड के लिए नहीं बुलाया जाता और संचालन न्यूनतम विशेषाधिकार का पालन करता है
    bat["दो-पंक्ति बैच बाँटें"] --> noadmin["व्यवस्थापक अनुमति सौंपने से बच सकते हैं"]
    bat --> nocall["IT UAC के लिए नहीं बुलाया जाता"]
    noadmin --> lp["न्यूनतम विशेषाधिकार वाला संचालन"]
    nocall --> lp

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

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

• अनुमतियाँ नहीं बढ़तीं। सच में व्यवस्थापक अनुमति चाहिए काम (HKLM लेखन, Program Files के नीचे अपडेट आदि) ऐप के भीतर त्रुटि देगा, या शर्तें पूरी हों तो UAC वर्चुअलाइज़ेशन VirtualStore को मोड़ देगा।¹⁰ सेटिंग सहेजना अचानक «रुक गया» लगे तो वर्चुअलाइज़ेशन संदेह करें।
• पर्यावरण-चर विधि केवल संतान प्रक्रियाओं पर लागू होती है। स्थायी लागू करने के लिए Layers कुंजी में सीधी सेटिंग (RUNASINVOKER का टैब पर आइटम नहीं) या .sdb से वितरण विश्वसनीय है।
• लेखन गंतव्य सुधारना असली पथ है। ऐप बदल सकें तो सेटिंग फ़ाइल %APPDATA% के नीचे ले जाएँ और मैनिफेस्ट में asInvoker घोषित करें — वही सही आकार है।⁹

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

चित्र 17: पर्यावरण-चर विधि संतान प्रक्रियाओं तक सीमित अस्थायी लागू है; स्थायी Layers कुंजी या .sdb से होता है।

9. आयु-विस्तार और माइग्रेशन के बीच निर्णय — shim के नीचे चलने के बाद क्या सोचें

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

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

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

flowchart TB
    accTitle: आयु-विस्तार निर्णय के बाद तीन-बिंदु संचालन सेट
    accDescr: लेजर में लिखें कौन सा shim चलाता है हर फीचर अपडेट पर shim से जीवित ऐप का व्यवहार सत्यापित करें आयु-विस्तार के अंत की समय सीमा तय करें और माइग्रेशन विचार समानांतर चलाएँ
    decide["आयु-विस्तार का निर्णय"] --> rec["लिखें: कौन सा shim चलाता है लेजर में"]
    rec --> verify["सत्यापित: हर फीचर अपडेट पर व्यवहार पुष्टि"]
    verify --> deadline["समय सीमा: आयु-विस्तार का अंत तय करें"]
    deadline --> mig["माइग्रेशन विचार समानांतर चलाएँ"]

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

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

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

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

10. सार

• संगतता मोड की असली पहचान shim हैं। Compatibility टैब की सेटिंग AppCompatFlags\Layers कुंजी में लिखी जाती हैं और शुरू होते समय IAT फिर-लेखन से API हुक के रूप में प्रक्रिया में घुसती हैं।
• Shim «पुराना ऐप जिस उत्तर की अपेक्षा करता है वह लौटाने वाले झूठ» का संग्रह हैं। संस्करण नकल, पथ पुनर्मानचित्रण, रजिस्ट्री नकल, व्यवस्थापक जाँच नकल आदि के तैयार shim दिए गए हैं।
• Windows स्वयं डिफ़ॉल्ट रूप से बहुत से shim उपयोग करता है, और PCA उन्हें स्वतः लागू कर सकता है। संगतता मोड पर भरोसा स्वयं आधिकारिक OS तंत्र पर सवार उचित चयन है।
• केवल user-mode और कोई सुरक्षा बाईपास का सैद्धांतिक सीमा है, और कर्नेल ड्राइवर, 16-बिट ऐप तथा सीधी हार्डवेयर पहुँच नहीं बच सकते।
• संगठनात्मक रोलआउट Compatibility Administrator (Windows ADK) में कस्टम .sdb बनाना और sdbinst से वितरित करना है। 32-बिट/64-बिट संस्करण चुनना, वास्तविक उपयोगकर्ता खाते से परीक्षण, और GUID से अपडेट प्रबंधित करना व्यावहारिक बिंदु हैं।
• «व्यवस्थापक माँगते हैं पर वास्तव में नहीं चाहिए» ऐप __COMPAT_LAYER=RunAsInvoker से मानक अनुमति तक लाए जा सकते हैं। यह रक्षा तकनीक उन्नयन अनुरोध शांत करती है अनुमति सौंपने के बजाय।
• Shim के नीचे चलना आयु-विस्तार है, समाधान नहीं। क्या चलाता है लिखना, हर फीचर अपडेट पर सत्यापन, और समय सीमा ताकि माइग्रेशन समानांतर चले — वह तीन-बिंदु सेट «संगतता मोड पर भरोसा» निर्णय में शामिल है।

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

संबंधित लेख

• 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 शेल इंटीग्रेशन ── कॉन्टेक्स्ट मेनू, फ़ाइल असोसिएशन, और Windows 11 में क्या बदला

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

KomuraSoft LLC बिना स्रोत कोड पुराने व्यावसायिक ऐप कैसे व्यवहार करते हैं इसकी जाँच और उनकी आयु-विस्तार डिज़ाइन (shim और संगतता मोड चयन, कस्टम .sdb बनाना और रोल आउट), Windows 11 माइग्रेशन के लिए मौजूदा ऐप की संगतता सत्यापन, तथा आयु-विस्तार के समानांतर फिर-लेखन या माइग्रेशन योजना सँभालती है। «संगतता मोड में चलने लगा, पर ऐसे छोड़ना ठीक है?» चरण से परामर्श ठीक है।

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

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

यदि संगतता मोड टिक करने के बाद ऐप चलने लगा, क्या उसी तरह चलाना ठीक है?

व्यवसाय को अल्पकाल में चलाए रखने के लिए हाँ। संगतता मोड user-mode API हुक है जिसे shim कहते हैं, OS द्वारा दिया आधिकारिक तंत्र। फिर भी shim ऐप को बिना सुधारे चलाने का अस्थायी उपाय है, और दूसरा OS अपडेट धारणाएँ बदल कर फिर तोड़ सकता है। संगतता मोड में चलने का तथ्य लेजर में लिखें, और उस रिकॉर्ड को ऐप फिर लिखने या जान-बूझकर आयु बढ़ाने के निर्णय का हिस्सा मानें।

संगतता मोड का चेकबॉक्स वास्तव में क्या करता है?

गुण संवाद के Compatibility टैब पर सेटिंग सहेजने पर Windows लक्ष्य EXE का पथ और "WINXPSP3" या "HIGHDPIAWARE" जैसा मान HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers कुंजी के नीचे लिखता है। अगली बार वह EXE शुरू हो तो Windows लोडर मान पढ़कर संगतता परत (shim बंडल) प्रक्रिया पर लागू करता है। Windows XP संगतता मोड, उदाहरण के लिए, संस्करण-क्वेरी API से पुराना मान लौटाकर OS संस्करण नकली करता है। OS स्वयं नहीं बदलता; केवल उस प्रक्रिया को दिखावटी पुराना Windows दिखाया जाता है।

क्या 16-बिट युग के ऐप 64-बिट Windows पर संगतता मोड में चल सकते हैं?

नहीं। 64-बिट Windows 32-बिट ऐप WOW64 से चलाता है, पर 16-बिट ऐप चलाना समर्थित नहीं, और शुरू करने का प्रयास ERROR_BAD_EXE_FORMAT से विफल होता है। वह वास्तुकला सीमा है जिसे shim घेर नहीं सकता। पुराने पैकेज जिनका इंस्टॉलर स्टब 16-बिट है उसी कारण विफल होते हैं। सच में चाहिए तो संगतता मोड के बाहर देखें — उदाहरण के लिए वह वर्चुअल मशीन जिसमें 32-बिट Windows हो।

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

RunAsInvoker आज़माने लायक है। कमांड प्रॉम्प्ट पर set __COMPAT_LAYER=RunAsInvoker चलाकर फिर ऐप शुरू करें तो requireAdministrator मैनिफेस्ट या इंस्टॉलर पहचान से उन्नयन अनुरोध दब जाते हैं, और ऐप कॉलर जैसी ही (मानक-उपयोगकर्ता) अनुमति से शुरू होता है। जो ऐप केवल व्यवस्थापक अधिकार माँगता है और वास्तव में उपयोग नहीं करता, अकेले इससे रोज़मर्रा संचालन से उन्नयन निकल सकता है। अनुमतियाँ नहीं बढ़तीं, इसलिए सच में व्यवस्थापक अधिकार चाहिए काम ऐप के भीतर विफल होगा। व्यवहार सत्यापित करने के बाद ही अपनाएँ।

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

Windows ADK (Windows Assessment and Deployment Kit) में शामिल है। Microsoft साइट से ADK डाउनलोड करें और इंस्टॉल समय Application Compatibility Tools सुविधाएँ चुनें। 32-बिट और 64-बिट दोनों संस्करण इंस्टॉल होते हैं; 32-बिट ऐप के लिए 32-बिट संस्करण और 64-बिट ऐप के लिए 64-बिट संस्करण ही उपयोग करें। आपका बनाया कस्टम संगतता डेटाबेस (.sdb) प्रत्येक PC पर sdbinst कमांड चलाकर लागू करें।

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

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

Go Komura

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

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