आज का Windows shell integration ── context menu, file association, और Windows 11 में क्या बदला

मुझसे सलाह माँगी गई: «हमने PC Windows 11 से बदल दिए, और सालों पहले आपके बनाए ऐप का context menu गायब हो गया»। और ध्यान से सुनने पर वह गायब नहीं हुआ था। फ़ाइल पर right-click करें, menu के नीचे “Show more options” चुनें, और परिचित menu वैसा ही आता है जैसा हमेशा आता था। यानी in-house ऐप के menu आइटम एक क्लिक और अंदर छिप गए। Field से «एक क्लिक ज़्यादा» और «आइटम नहीं मिलता, ऐसी पूछताछ बढ़ गई» सुनाई देता है।

यह न तो खराबी है न गलत configuration; यह Windows 11 का डिज़ाइन परिवर्तन है। File Explorer का context menu पुराने और नए की दो-परत structure बन गया, और नए menu पर आइटम रखने की शर्तें पहले से पूरी तरह अलग चीज़ हो गईं।

इधर नीचे की file-association और shell-extension machinery अभी भी COM और registry की पुरानी दुनिया है। Extension key ProgID की ओर इशारा करती है, ProgID का verb command line रखता है, और ज़्यादा उलझा extension Explorer में load होने वाले in-process COM server (DLL) के रूप में चलता है — यह structure बीस साल से अधिक नहीं बदली। अगर आप न बदली हुई नींव और Windows 11 द्वारा दो भागों में बाँटे गए menu दोनों न जानें, तो «menu नहीं दिखता», «छिप गया» या «दो बार दिखता है» अलग नहीं कर सकते।

यह लेख SME के IT staff और business apps सँभालने वाले Windows developers के लिए है। यह एक ही चित्र में file association की तीन-परत structure, क्लासिक shell extension की सावधानियाँ, Windows 11 नए context menu को निशाना बनाना, और installer registration, cleanup तथा troubleshooting जोड़ता है।

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

• Context menu और file association की नींव तीन-परत registry structure «extension key → ProgID → verb» है। Extension key ProgID की ओर pointer है, ProgID सार है, और उसके नीचे shell\<verb>\command command line रखता है।¹
• HKEY_CLASSES_ROOT (HKCR) स्वतंत्र hive नहीं है; यह HKLM\Software\Classes और HKCU\Software\Classes का merged view है। सभी-user registration HKLM पर लिखें, per-user HKCU पर, और HKCR को read-only मानें।²
• Default app (double-click पर खुलने वाला) user द्वारा चुना जाने के लिए डिज़ाइन है, और program उसे चुरा नहीं सकता। OS user की पसंद की रक्षा करता है; installer उम्मीदवार के रूप में register कर सकता है।³
• क्लासिक shell extension Explorer में load होने वाला in-process COM DLL है। Extension में crash या देरी पूरे Explorer (और shell इस्तेमाल करने वाले अन्य apps) तक फैलती है; 64-bit environment को 64-bit DLL चाहिए; managed-code implementation unsupported है।⁴⁵
• Windows 11 पर context menu दो भागों में बँट गया। नए menu पर वही commands दिखती हैं जो IExplorerCommand प्लस package identity से registered हैं; क्लासिक IContextMenu extensions «Show more options» (Shift+F10) वाले पुराने menu पर चले जाते हैं।⁶⁷
• नए menu पर custom command रखने का official मार्ग IExplorerCommand लागू करने वाले native DLL को MSIX manifest (desktop4:FileExplorerContextMenus) में register करना है। जो ऐप MSIX नहीं बन सकता उसे अकेले identity sparse package (external location वाला MSIX) से दी जा सकती है।⁷⁸
• अगर बस «इस ऐप से खोलें» चाहिए, तो association और static verb अभी भी काफ़ी हैं। Shell-extension DLL की ज़रूरत नहीं, और Microsoft स्वयं साफ़ कहती है «आवश्यकता पूरी करने वाला सबसे सरल तरीका चुनें (static verb)»।⁹
• Registration या बदलाव के बाद SHChangeNotify(SHCNE_ASSOCCHANGED) से सूचित करें; uninstall पर ProgID हटाएँ पर extension key का default मान न हटाएँ — यही official guidance है। Shell integration में cleanup का डिज़ाइन भी शामिल है।¹¹⁰

एक वाक्य में: Association और verb की दुनिया नहीं बदली; केवल menu कैसे दिखता है, Windows 11 पर दो भागों में बँट गया। नीचे हम नींव से ऊपर चलते हैं।

2. File association कैसे काम करता है ── तीन-परत structure extension key → ProgID → verb

2.1. एक उदाहरण से तीन-परत structure पढ़ना

किसी दिए extension की फ़ाइल पर double-click करने पर क्या होता है, तीन परतों की registry keys तय करती हैं।¹

HKEY_CLASSES_ROOT
   .kmrpt                                  ← (1) एक्सटेंशन कुंजी
      (Default) = KomuraSoft.Report.1      ←     केवल ProgID नाम देने वाला पॉइंटर
      OpenWithProgids
         KomuraSoft.Report.1               ←     «इससे खोलें» का उम्मीदवार
   KomuraSoft.Report.1                     ← (2) ProgID (असोसिएशन का सार)
      (Default) = Komura Report document
      DefaultIcon
         (Default) = "C:\Program Files\KomuraSoft\Report.exe",0
      shell                                ← (3) verb की सूची
         open
            command
               (Default) = "C:\Program Files\KomuraSoft\Report.exe" "%1"

• (1) Extension key (.kmrpt) केवल default मान के रूप में ProgID नाम की ओर इशारा करती है। यहाँ सीधे command लिखना गलती है।
• (2) ProgID (KomuraSoft.Report.1) association का सार है; इसमें display name, icon और verb सूची रहती है।
• (3) Verb «Open» या «Print» जैसी क्रिया है, और shell\open\command का default मान वास्तव में launch होने वाली command line है।

इसी अलगाव के कारण आप कई extensions (उदाहरण .kmrpt और .kmrpt-file) एक ही ProgID की ओर रख सकते हैं, या ऐप upgrade पर ProgID बदल सकते हैं।

flowchart TB
    accTitle: File association की तीन-परत structure
    accDescr: Extension key एक pointer है जिसका default मान ProgID नाम देता है; ProgID सार है जो display name, icon और verb सूची रखता है; और verb के नीचे command का default मान वास्तव में launch होने वाली command line है
    ext["Extension key .kmrpt"] -->|Default में ProgID नाम| pid["ProgID KomuraSoft.Report.1"]
    pid --> vb["verb (shell के नीचे open आदि)"]
    vb --> cmd["command का default मान"]
    cmd --> exe["Report.exe launch होता है"]
    pid -.-> attr["Display name और DefaultIcon भी रखता है"]

चित्र 1: Extension key pointer है, ProgID सार है, और verb की command वास्तव में launch होने वाली command line है।

2.2. HKCR «merged view» है ── कहाँ लिखें, अर्थ बदल जाता है

ऊपर का उदाहरण HKEY_CLASSES_ROOT (HKCR) के नीचे दिखाया गया है, पर HKCR भौतिक संग्रह स्थान नहीं है; यह HKLM\Software\Classes और HKCU\Software\Classes का merged view है। दोनों में एक ही key हो तो HKCU पक्ष जीतता है।²

flowchart TB
    accTitle: HKCR merged view है
    accDescr: HKCR HKLM और HKCU Classes एक के ऊपर एक हैं; दोनों में एक ही key हो तो HKCU जीतता है; registration HKLM या HKCU पर स्पष्ट लिखें और HKCR को read-only मानें
    hklm["HKLM\\Software\\Classes (सभी users)"] --> hkcr["HKCR (merged view)"]
    hkcu["HKCU\\Software\\Classes (per user)"] --> hkcr
    hkcu -.-> win["एक ही key हो तो HKCU जीतता है"]
    hkcr -.-> ro["Read-only मानें (पुष्टि के लिए)"]

चित्र 2: HKCR HKLM और HKCU Classes के साथ रखने का रूप है; लिखने का गंतव्य हमेशा एक पक्ष नामें।

व्यवहार में सुरक्षित विभाजन है registration हमेशा HKLM या HKCU पर स्पष्ट लिखें, और HKCR को पुष्टि के लिए read-only मानें। WOW64 registry redirection से संबंध भी सुलझाना चाहिए। HKLM\Software\Classes के ठीक नीचे extension keys और ProgID जैसे association data Windows 7 से 32-bit और 64-bit registry views के बीच shared हैं, इसलिए 32-bit installer लिखने पर Wow6432Node की ओर नहीं भागता। दूसरी ओर Classes\CLSID जैसी कुछ COM-registration subkeys redirect होती हैं, और shell extensions (in-process COM) register करते समय 32-bit / 64-bit लेखन विभाजन मायने रखता है। विवरण «Registry 32-bit/64-bit Redirection and Virtualization Pitfalls — Wow6432Node and the "The Value I Wrote Isn’t There" Problem» में है।

2.3. ऐप पक्ष पर registration ── App Paths, Applications, RegisteredApplications

फ़ाइल पक्ष (extension और ProgID) के साथ जोड़कर ऐप पक्ष पर भी तीन तरह के registration हैं।¹¹

• App Paths (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths): Registration जिससे ShellExecuteEx केवल executable फ़ाइल नाम से launch कर सके। Microsoft इसकी recommendation करती है क्योंकि PATH environment variable को गंदा नहीं करना पड़ता।
• Applications (HKCR\Applications\<app.exe>): «Open with» के तहत कोई भी फ़ाइल सौंपे जाने पर default खोलने का तरीका, और ऐप का display name (FriendlyAppName) परिभाषित करता है।
• RegisteredApplications + Capabilities: ऐप जिन extensions और MIME types सँभाल सकता है उन्हें घोषित करता है, और वही registration Windows Default apps settings page पर उम्मीदवार बनाता है।

«हमारा ऐप Default apps सूची में नहीं दिखता» जैसी अधिकांश सलाह वे मामले हैं जहाँ ProgID registered हुआ और यह Capabilities registration छूट गया।

flowchart TB
    accTitle: ऐप पक्ष पर तीन तरह के registration
    accDescr: ऐप-पक्ष registration तीन तरह का है ── App Paths, Applications और RegisteredApplications ── क्रमशः केवल फ़ाइल नाम से launch, Open with के तहत default तरीका, और Default apps page पर दिखना
    app["ऐप-पक्ष registration"] --> ap["App Paths"]
    app --> apps["Applications"]
    app --> ra["RegisteredApplications"]
    ap --> r1["केवल फ़ाइल नाम से launch"]
    apps --> r2["Open with का default"]
    ra --> r3["Default apps page पर दिखता है"]
    r3 -.-> cap["Capabilities घोषणा चाहिए"]

चित्र 3: ऐप-पक्ष registration तीन तरह का है, और Default apps उम्मीदवार बनने के लिए Capabilities registration चाहिए।

2.4. Default app user का है ── UserChoice सुरक्षा

Extension key के default मान के रूप में ProgID लिखना अकेले उसे default app नहीं बनाता। User द्वारा «Open with» आदि के तहत स्पष्ट चुनाव का परिणाम HKCU\...\Explorer\FileExts\<extension>\UserChoice में रहता है, और association resolution उस पक्ष को प्राथमिकता देता है।

और महत्वपूर्ण बात यह है कि Windows programmatically default app बदलने का support नहीं करता। Default-app settings user द्वारा system Settings UI से करने के लिए डिज़ाइन हैं; UserChoice data obfuscated है, और filter driver (UCPD.sys) apps से लेखन रोकता है। Managed environment में Group Policy / MDM policy official साधन है।³

SetUserFTA जैसे tools, जो «hash की नकल करके फिर लिखते हैं», इस्तेमाल हुए हैं — यही सुरक्षा का दूसरा पहलू है। In-house ऐप के installer में default चुराना नहीं, बल्कि ये तीन रखने चाहिए: (क) ProgID और verb का सही registration, (ख) खुद को OpenWithProgIds में जोड़ना, और (ग) ज़रूरत हो तो Settings page पर ले जाना।

flowchart TB
    accTitle: Default-app resolution और UserChoice सुरक्षा
    accDescr: User के स्पष्ट चुनाव का परिणाम UserChoice में रहता है और association resolution में प्राथमिकता पाता है; UCPD.sys apps से फिर-लेखन रोकता है, इसलिए installer उम्मीदवार के रूप में register कर Settings page पर ले जा सकता है
    uc["UserChoice (user की पसंद)"] -->|प्राथमिक| res["Association resolution"]
    ext["Extension-key default मान"] --> res
    wr["ऐप से फिर लिखना"] -.->|UCPD.sys रोकता है| uc
    res ~~~ inst["Installer का काम"]
    inst --> a1["ProgID और verb register करें"]
    inst --> a2["OpenWithProgIds में जोड़ें"]
    inst --> a3["Settings page पर ले जाएँ"]

चित्र 4: Association resolution user की पसंद (UserChoice) को प्राथमिकता देता है, और OS उसे apps के फिर-लेखन से बचाता है।

3. «Open» के अलावा verb ── print, edit, runas, custom verb

Verb केवल open नहीं है। जिन standard verbs का अर्थ OS जानता है उनमें open के अलावा edit, print, play और preview भी हैं, और standard verbs को OS locale के अनुसार display name अपने आप मिलता है। Double-click पर प्रयुक्त default verb इस क्रम में तय होता है: shell key का default मान → registry में पहला verb → open → openwith।¹²

flowchart TB
    accTitle: Default verb तय होने का क्रम
    accDescr: Double-click पर प्रयुक्त default verb वह पहला है जो shell-key default मान, registry में पहला verb, open, openwith के क्रम में मिलता है
    s1["shell-key default मान"] -->|न हो तो| s2["Registry में पहला verb"]
    s2 -->|न हो तो| s3["open"]
    s3 -->|न हो तो| s4["openwith"]

चित्र 5: Double-click का default verb इसी क्रम में मिला पहला है।

अपनी क्रिया जोड़नी हो तो custom verb register करें।

KomuraSoft.Report.1
   shell
      open
         command
            (Default) = "C:\Program Files\KomuraSoft\Report.exe" "%1"
      print
         command
            (Default) = "C:\Program Files\KomuraSoft\Report.exe" /print "%1"
      verify                          ← कस्टम verb
         (Default) = Verify report (&V)   ← मेनू प्रदर्शन नाम
         command
            (Default) = "C:\Program Files\KomuraSoft\Report.exe" /verify "%1"

तीन छोटी बातें जानना उपयोगी है।

• runas नाम का verb register करें तो «Run as administrator» के बराबर elevation launch परिभाषित होता है, और ShellExecute-परिवार API जब runas specify करे तब भी यही लगता है।
• Verb key पर Extended नाम का खाली मान रखें तो वह केवल Shift+right-click पर दिखने वाला extended verb बन जाता है। कम इस्तेमाल होने वाली खतरनाक क्रिया छिपाने के लिए सुविधाजनक।¹²
• पुराने ऐप के कुछ associations अभी भी DDE (ddeexec key) से document मौजूदा process में भेजते हैं, पर DDE से verb launch करना पहले से Deprecated विरासत है। नया लिखने का कोई कारण नहीं।¹²

एक और दुर्घटना अक्सर होती है command line पर quotes। Command string का कोई तत्व space रख सकता हो तो उसे quotes में लपेटना होगा। यह C:\Program Files\... जैसे EXE path पर तो लागू है ही, और %1 (चयनित फ़ाइल का path) हमेशा "%1" लिखा जाना चाहिए। User के फ़ाइल path में space न होने की गारंटी नहीं। बिना quotes वाला My Program.exe «My को command-line argument Program.exe के साथ launch करो» समझा जाता है।¹³

flowchart TB
    accTitle: Command line पर quotes दुर्घटना
    accDescr: बिना quotes वाली command space पर टूटती है और My को Program.exe argument के साथ launch करने के रूप में गलत समझी जाती है, इसलिए space रख सकने वाला EXE path और चयनित फ़ाइल path दर्शाने वाला %1 हमेशा quotes में लपेटें
    c1["बिना quotes command"] -->|Space पर टूटे| bad["दूसरा EXE launch समझने की गलती"]
    c2["Quoted command"] --> good["इरादे के अनुसार launch"]
    c2 -.-> q1["EXE path quotes में लपेटें"]
    q1 -.-> q2["%1 भी हमेशा quotes में लपेटें"]

चित्र 6: बिना quotes command space पर गलत टूटती है, इसलिए EXE path और %1 हमेशा quotes में लपेटें।

अब तक की केवल-registry machinery (static verb) बिना कोई DLL लिखे पूरी हो सकती है, और Explorer को अस्थिर करने का जोखिम नहीं। Microsoft स्वयं बार-बार कहती है «shell extension लिखने से पहले सोचें कि आवश्यकता पूरी करने वाला सबसे सरल static verb काफ़ी है या नहीं»।⁹

4. क्लासिक shell extension ── Explorer के अंदर चलने वाला DLL

4.1. Shell extension के प्रकार

Static verb जो आवश्यकताएँ नहीं पूरी कर सकता — «चयन के अनुसार menu dynamically बदलें», «icon या property sheet बदलें» — shell-extension handlers इस्तेमाल करती हैं। प्रतिनिधि प्रकार निम्न हैं।⁴

ये सभी COM class के रूप में लागू होते हैं और CLSID से registry में registered होते हैं। COM का विचार स्वयं «What Are COM / ActiveX / OCX? - The Differences and Relationships Explained» में है।

4.2. In-process COM server होने का अर्थ

क्लासिक shell extension का सार यह है कि यह Explorer (या common file dialog खोलने वाले किसी भी ऐप) में load होने वाला in-process COM server (DLL) है। हर सावधानी इसी से निकलती है।⁴

• Extension crash करे तो Explorer साथ गिरता है। अटक जाए तो right-click कई seconds जम जाता है। नुकसान केवल Explorer तक सीमित नहीं; file-open dialog दिखाने वाला हर ऐप पहुँच में आता है।
• Menu निर्माण UI thread पर होता है, इसलिए menu दिखाने के समय network access या file I/O जैसा धीमा काम नहीं करना चाहिए।
• Threading model नियमतः Apartment register करें।

flowchart TB
    accTitle: In-process extension की collateral-damage structure
    accDescr: Shell-extension DLL न केवल Explorer में बल्कि file dialog खोलने वाले किसी भी ऐप की process में load होता है, इसलिए extension का crash या hang पूरे host process तक फैलता है
    dll["Shell-extension DLL"] -->|In-process load| exp["Explorer"]
    dll -->|In-process load| any["Dialog खोलने वाला कोई भी ऐप"]
    exp --> dmg["Crash या hang फैलता है"]
    any --> dmg
    dmg -.-> rule["दिखाने के समय धीमा काम न करें"]

चित्र 7: Extension DLL host process के अंदर चलता है, इसलिए crash या hang पूरे host तक फैलता है।

«विशेष folder खोलने पर Explorer जम जाता है» या «right-click पाँच seconds लेता है» जैसी सलाह जाँचें तो कारण in-house ऐप नहीं, third-party का shell extension होना असामान्य नहीं। Isolation विधियाँ अध्याय 8 में हैं।

4.3. Bitness मिलाना ── 64-bit environment को 64-bit DLL चाहिए

In-process DLL को load करने वाली process की bitness से मेल खाना चाहिए। 64-bit Windows पर Explorer 64-bit process है, इसलिए केवल 32-bit बना shell-extension DLL कभी load नहीं होता और menu पर बिल्कुल नहीं दिखता। कोई error भी नहीं, इसलिए «registered किया पर नहीं दिखता» का आम कारण है। 32-bit ऐप बॉडी के साथ 64-bit shell-extension DLL वैध विन्यास है, पर COM registration bitness से बँटता है (Wow6432Node) — यह देखना होगा। Verb की command से launch अलग-process EXE है, इसलिए इस बाधा के अधीन नहीं (32-bit EXE छोड़ना ठीक है)।

flowchart TB
    accTitle: Shell-extension DLL की bitness मिलान
    accDescr: 64-bit Explorer केवल 64-bit shell-extension DLL load कर सकता है; केवल-32-bit DLL menu पर नहीं दिखता और कोई error नहीं देता; verb command से launch EXE अलग process है और बाधा के अधीन नहीं
    exp["64-bit Explorer"] -->|Load कर सकता है| d64["64-bit shell-extension DLL"]
    exp -.->|Load नहीं कर सकता| d32["केवल-32-bit DLL"]
    d32 -.-> sym["Menu पर नहीं, बिना error"]
    exe["Verb से launch EXE"] -->|अलग process| ok32["32-bit छोड़ना ठीक"]

चित्र 8: 64-bit Explorer में load होने वाला केवल 64-bit DLL है; verb से launch EXE इस बाधा के अधीन नहीं।

4.4. Managed code में क्यों नहीं लिखना

अक्सर पूछा जाता है «क्या C# में shell extension लिख सकता हूँ», पर Microsoft ने साफ़ कहा है कि managed code (.NET) में in-process shell extension लिखना recommended नहीं है और support से बाहर है।⁵

कारण यह है कि extension किसी भी process में load होता है। CLR version collision (खासकर .NET Framework 4 से नीचे), lock की प्रतीक्षा करते CLR का message loop में फिर घुसना, और garbage collection से uncertain object lifetime का COM reference-count अनुबंध से टकराव — ये संरचनात्मक कारण host ऐप अस्थिर बनाते हैं। कुछ बिंदु .NET Framework 4 और बाद तथा आधुनिक .NET पर नरम हुए, पर official स्थिति नहीं बदली।

Practical दिशा सरल है। In-process extensions native C++ में लिखें। Managed code चाहिए तो verb की command से launch सामान्य EXE बनाएँ, या अलग process में चलने वाला out-of-process extension (preview handler आदि)।⁵

flowchart TB
    accTitle: Managed code allow का निर्णय
    accDescr: Explorer के अंदर चलने वाला in-process extension नियमतः native C++ में लिखा जाता है; managed code चाहिए तो verb command से launch सामान्य EXE या अलग process में चलने वाला out-of-process extension बनाएँ
    q1{"In-process चलता है?"} -->|हाँ| cpp["Native C++ में लिखें"]
    q1 -->|नहीं| mg["Managed code ठीक है"]
    cpp -.-> why["CLR / reentrancy जोखिम से host अस्थिर होता है"]
    mg --> e1["Verb-launch EXE"]
    mg --> e2["Out-of-process preview"]

चित्र 9: In-process extension नियमतः native C++ है; managed code अलग process में चलने वाले विन्यास तक सीमित है।

5. Windows 11 का नया context menu ── दो भागों में बँटा menu

5.1. क्या हुआ

Windows 11 ने File Explorer का context menu नया किया। Cut, Copy आदि ऊपर icons की पंक्ति बन गए; «Open» और «Open with» ऊपर एकत्र हुए; और ऐप द्वारा जोड़ी गई commands shell की standard commands के नीचे एकत्र होती हैं। एक ऐप कई commands जोड़े तो वे ऐप-नाम वाले flyout (submenu) में इकट्ठा होती हैं।⁶

और निर्णायक बात यह है। क्लासिक IContextMenu-based shell extensions मिटाए नहीं गए; उन्हें «Show more options» (Shift+F10) से खुलने वाले पुराने-menu पक्ष पर ले जाया गया, जो Windows 10 menu ज्यों का त्यों load करता है।⁶ शुरुआती सलाह «menu छिप गया» की पहचान यही विभाजन है।

flowchart TB
    accTitle: Windows 11 द्वारा दो भागों में बाँटा context menu
    accDescr: Right-click पर पहले खुलने वाला नया menu है; वहाँ वही commands दिखती हैं जो IExplorerCommand और package identity से registered हैं; क्लासिक IContextMenu extensions Show more options से खुलने वाले पुराने menu पर चले जाते हैं
    rc["फ़ाइल पर right-click"] --> newm["नया menu (Windows 11)"]
    newm --> newi["IExplorerCommand + identity commands"]
    newm -->|Show more options Shift+F10| oldm["पुराना menu (Windows 10 menu)"]
    oldm --> oldi["क्लासिक IContextMenu extensions"]
    newi -.-> fly["कई commands flyout में इकट्ठा"]

चित्र 10: नए menu पर वही commands दिखती हैं जो IExplorerCommand + identity हैं; क्लासिक extensions पुराने-menu पक्ष पर चले जाते हैं।

5.2. नए menu का official मार्ग ── IExplorerCommand + manifest registration

नए menu पर custom command रखने का एक ही तरीका है। IExplorerCommand interface लागू करने वाला native DLL तैयार करें, और MSIX package manifest में COM server तथा context-menu extension घोषित करें।⁷

<!-- Package manifest (excerpt) -->
<com:Extension Category="windows.comServer">
  <com:ComServer>
    <com:SurrogateServer DisplayName="Komura commands">
      <com:Class Id="01234567-89AB-CDEF-0123-456789ABCDEF"
                 Path="KomuraCommand.dll" ThreadingModel="STA" />
    </com:SurrogateServer>
  </com:ComServer>
</com:Extension>
<desktop4:Extension Category="windows.fileExplorerContextMenus">
  <desktop4:FileExplorerContextMenus>
    <desktop5:ItemType Type=".kmrpt">
      <desktop5:Verb Id="VerifyReport"
                     Clsid="01234567-89AB-CDEF-0123-456789ABCDEF" />
    </desktop5:ItemType>
  </desktop4:FileExplorerContextMenus>
</desktop4:Extension>

ItemType का Type विशेष extension, या * (सभी फ़ाइलें), Directory (folder), या Directory\Background (folder background) specify कर सकता है। DLL को Explorer की architecture (64-bit / ARM64) से मिलाएँ।⁷

IExplorerCommand स्वयं Windows 7 युग से मौजूद interface है; आप title (GetTitle), icon (GetIcon), enabled / disabled / hidden स्थिति (GetState), और execution (Invoke) लागू करते हैं। Methods UI thread से बुलाई जाती हैं, इसलिए network resources तक पहुँच वर्जित है, और menu-निर्माण methods को जल्दी लौटना चाहिए। भारी काम Invoke के बाद करें।¹⁴⁷

flowchart TB
    accTitle: नए-menu registration की manifest structure
    accDescr: MSIX manifest की COM-server घोषणा CLSID को DLL से जोड़ती है, और context-menu-extension घोषणा ItemType और Verb से लक्ष्य व implementation बाँधती है, इसलिए custom command नए menu पर दिखती है
    man["MSIX manifest"] --> com["COM-server घोषणा"]
    man --> ctx["Menu-extension घोषणा"]
    com -->|CLSID को DLL से जोड़ता है| impl["IExplorerCommand implementation DLL"]
    ctx -->|ItemType और Verb से निर्दिष्ट| impl
    impl --> shown["Command नए menu पर दिखती है"]
    ctx -.-> tgt["लक्ष्य extension, सभी फ़ाइलें आदि"]

चित्र 11: Manifest की दो घोषणाएँ implementation DLL को लक्ष्य से बाँधती हैं, और command नए menu पर दिखती है।

5.3. Non-packaged ऐप का विकल्प ── sparse package से केवल identity

«हमारा ऐप MSI के अलावा बाँटा नहीं जा सकता; MSIX असंभव है» का निकास द्वार sparse package (external location वाला MSIX) है। आप केवल manifest वाला छोटा MSIX sign करते हैं, ऐप बॉडी के बिना, और मौजूदा installer के अंत में register करते हैं। ऐप तब package identity पाता है, और ऊपर का manifest registration (= नए menu पर दिखना) संभव होता है। Windows 10 version 2004 से उपलब्ध, package को target मशीन पर trusted certificate signing चाहिए।⁸

flowchart TB
    accTitle: Sparse package से identity पाने का flow
    accDescr: मौजूदा installer ऐप बॉडी रखने के बाद, केवल-manifest sparse package को external location से register करने पर ऐप package identity पाता है और नए-menu manifest registration संभव होता है
    inst["मौजूदा installer"] --> files["ऐप बॉडी रखें"]
    sp["Sparse package"] -.-> only["केवल manifest, बॉडी नहीं"]
    files --> reg["External location से register करें"]
    sp --> reg
    reg --> id["Package identity पाएँ"]
    id --> ok["नए-menu registration संभव"]
    sp -.-> sign["Trusted signing चाहिए"]

चित्र 12: बिना बॉडी वाला sparse package external location से register करें, और ऐप package identity पाता है।

सबसे बड़ा लाभ यह है कि installer बदलना नहीं पड़ता; जिसके पास पहले से MSI/EXE installer संपत्ति है, उसके लिए यही practical उत्तर है। पूर्ण MSIX स्थानांतरण से तुलना के लिए «Choosing a Windows App Distribution Method - MSI/MSIX/ClickOnce/xcopy/Custom Updater» भी देखें।

5.4. Association verbs नए menu पर कैसे दिखते हैं

गलत समझ में आसान बिंदु: अध्याय 2 और 3 के associations (ProgID और verb) नए menu पर अभी भी जीवित हैं। Double-click का default verb, «Open», और «Open with» उम्मीदवार association से हल होकर नए menu के ऊपर दिखते हैं। इसलिए अगर बस «इस ऐप से खोल सकें» चाहिए, Windows 11 पर extra काम नहीं। दूसरी ओर, Association सामान्य-उद्देश्य menu extension नहीं है, इसलिए नए menu की पहली परत पर मनमानी custom command चाहिए तो IExplorerCommand प्लस identity — यही भूमिका विभाजन है।⁷

flowchart TB
    accTitle: Association और नए menu का भूमिका विभाजन
    accDescr: ProgID-और-verb association नए menu पर अभी भी default verb, Open और Open with हल करने के लिए लगता है और ऊपर दिखता है; नए menu की पहली परत पर मनमानी custom command के लिए IExplorerCommand और identity चाहिए
    assoc["Association (ProgID + verb)"] --> sol["Default / Open हल करें"]
    sol --> top["नए menu का ऊपर"]
    assoc -.-> keep["Win11 पर extra काम नहीं"]
    cmd["Custom command"] --> need["IExplorerCommand+identity"]
    need --> first["नए menu की पहली परत"]

चित्र 13: Association नए menu पर अभी भी «Open» परिवार का समाधान करते हैं; केवल custom commands को IExplorerCommand प्लस identity चाहिए।

6. Practical निर्णय तालिका ── तीन विकल्पों में से कौन

अब तक को practical तीन-तरफ़ा चुनाव में बाँधते हैं।

दो निर्णय बिंदु। पहला, (क) पूरी करने वाली आवश्यकता के लिए (ख) या (ग) न लाएँ। Shell extension लिखते ही Explorer की स्थिरता की ज़िम्मेदारी आपके सिर। दूसरा, (ग) केवल «टूटा नहीं»; user experience में एक कदम कमज़ोर रहता है। दैनिक संचालन में जितनी बार command लगे, (ख) पर जाने का प्रतिफल उतना बड़ा।

flowchart TB
    accTitle: तीन विकल्पों में कैसे चुनें
    accDescr: अगर बस double-click या Open पर launch चाहिए तो association और static verb काफ़ी; नए menu पर custom command के लिए IExplorerCommand और MSIX manifest registration; MSIX न बन सके तो sparse package से identity; मौजूदा क्लासिक IContextMenu फिलहाल पुराने-menu पक्ष पर रखें
    q1{"Open काफ़ी है?"} -->|हाँ| pa["Association + static verb"]
    q1 -->|नहीं| q2{"नए menu पर custom?"}
    q2 -->|हाँ| q3{"MSIX बन सकते हैं?"}
    q3 -->|हाँ| pb1["IExplorerCommand+MSIX"]
    q3 -->|नहीं| pb2["Sparse-pkg identity"]
    q2 -->|नहीं| pc["फिलहाल क्लासिक रखें"]
    pc -.-> old["केवल पुराने-menu पक्ष"]
    pa -.-> dllfree["कोई DLL नहीं, कम जोखिम"]

चित्र 14: आवश्यकता के अनुसार static verb, IExplorerCommand प्लस identity, और क्लासिक बनाए रखने में चुनें।

7. व्यवहार में deployment और registration ── installer, sparse package, cleanup

7.1. HKLM या HKCU

Installer के आकार से मिलाएँ। सभी-user (Program Files के नीचे, Administrator अधिकार) HKLM\Software\Classes है; per-user install (बिना elevation) HKCU\Software\Classes। मिलाएँ तो «A खोल सकता है पर B नहीं» जैसी पूछताछ पैदा होती है। CLSID registration वाले shell extensions के लिए Reg-Free COM — जो registry registration स्वयं अनावश्यक बनाता है — in-ऐप COM उपयोग के लिए वैध विकल्प है, पर Explorer द्वारा load shell extensions पर लागू नहीं होता, इसलिए सीधा registration चाहिए («What Is Reg-Free COM - Using COM Without Registration»)।

7.2. बदलाव के बाद सूचित करें ── SHChangeNotify

Association register, बदला या हटाया हो तो SHChangeNotify से SHCNE_ASSOCCHANGED event सूचित करें। यह छोड़ें तो Explorer reboot तक बदलाव न देख सकता।¹¹⁰

// Call once after changing associations, e.g. from an installer custom action
SHChangeNotify(SHCNE_ASSOCCHANGED, SHCNF_IDLIST, nullptr, nullptr);

7.3. Sparse package register करना और हटाना

Sparse package register करना और हटाना installer का काम है। फ़ाइलें रखने के बाद register करें; फ़ाइलें हटाने से पहले हटाएँ।⁸

# At install time: after placing the files, register the install folder as the external location
Add-AppxPackage -Path "C:\Program Files\KomuraSoft\KomuraReport.identity.msix" `
                -ExternalLocation "C:\Program Files\KomuraSoft"

# At uninstall time: remove the package registration before deleting the files
Remove-AppxPackage <package full name>

देखने योग्य बिंदु: Add-AppxPackage उसे चलाने वाले user के लिए register करता है। Per-machine MSI की custom action से, LocalSystem के अधीन चलाएँ तो install करने वाले user को identity नहीं मिलती, इसलिए user impersonation के अधीन चलाएँ। तब भी impersonation के तहत registration केवल उस user का है जिसने वह install चलाया। कई users वाले PC पर अन्य users और बाद में बने users के पास package identity नहीं, और command नए menu पर नहीं दिखती। हर user को चाहिए तो पहली launch पर अपना package registration जाँचें और न हो तो register करें (per-user registration), और uninstall योजना में हर registered user से हटाना शामिल करें। Manifest registration प्रतिबिंबित करने के लिए Explorer restart (या sign-out) भी चाहिए हो सकता है।⁷

flowchart TB
    accTitle: Sparse package register और हटाने का क्रम
    accDescr: Install पर फ़ाइलें रखने के बाद sparse package register करें; uninstall पर फ़ाइलें हटाने से पहले registration हटाएँ; ध्यान दें registration केवल चलाने वाले user के लिए प्रभावी है
    i1["Install"] --> i2["फ़ाइलें रखें"]
    i2 --> i3["Sparse package register करें"]
    u1["Uninstall"] --> u2["Package registration हटाएँ"]
    u2 --> u3["फ़ाइलें हटाएँ"]
    i3 -.-> pu["Registration केवल चल रहे user पर प्रभावी"]

चित्र 15: फ़ाइलें रखने के बाद register करें, हटाने से पहले हटाएँ, और ध्यान दें registration चल रहे user के अनुसार है।

7.4. Uninstall पर cleanup ── क्या हटाएँ, क्या छोड़ें

Uninstall cleanup की स्पष्ट official-guidance रेखा है।¹

• हटाएँ: पूरा in-house ProgID key, Capabilities/RegisteredApplications registration, shell extension का CLSID registration, sparse package (Remove-AppxPackage)।
• छोड़ें: Extension key (.kmrpt) का default मान। Official recommendation है कि भले वह अभी भी in-house ProgID की ओर इशारा करे, न हटाएँ। Install के बाद तय करना कठिन है कि किसी अन्य ऐप ने default ले लिया या नहीं, और Windows unregistered default-मान ProgID को बस अनदेखा करता है, इसलिए छोड़ने से वास्तविक हानि नहीं।
• Cleanup के अंत में भी SHChangeNotify(SHCNE_ASSOCCHANGED) बुलाएँ।

ज़्यादातर «uninstall किया और menu पर अवशेष अभी भी दिखते हैं» समस्याएँ इसी cleanup डिज़ाइन की लीक हैं।

flowchart TB
    accTitle: Uninstall पर cleanup डिज़ाइन
    accDescr: Uninstall पर in-house ProgID key, CLSID registration और sparse package हटाएँ; extension-key default मान छोड़ें क्योंकि unregistered ProgID अनदेखा होता है; cleanup के अंत में SHChangeNotify से बदलाव सूचित करें
    un["Uninstall"] --> del["हटाएँ"]
    un --> keep["छोड़ें"]
    del --> d1["ProgID और CLSID registration"]
    del --> d2["Sparse package"]
    keep --> k1["Extension-key default मान"]
    k1 -.-> why["Unregistered ProgID अनदेखा होता है"]
    d1 --> fin["अंत में SHChangeNotify से सूचित करें"]
    k1 --> fin

चित्र 16: In-house registration हटाएँ, extension-key default मान छोड़ें, और cleanup के अंत में बदलाव सूचित करें।

8. Troubleshooting ── गायब, दोहरा, भारी

8.1. Menu पर नहीं दिखता

इस क्रम में अलग करें।

1. आप कौन सा menu देख रहे हैं: क्लासिक-शैली registration केवल Shift+F10 वाले पुराने-menu पक्ष पर दिखता है। पहले दोनों जाँचें।
2. Bitness: केवल-32-bit shell-extension DLL 64-bit Explorer में load नहीं होता (खंड 4.3)।
3. Registration गंतव्य: HKLM/HKCU, Wow6432Node गड़बड़। reg query से वास्तविक key पुष्टि करें।
4. Package registration: नए menu के लिए Get-AppxPackage से उपस्थिति, signing certificate का trust, और -ExternalLocation path पुष्टि करें, फिर Explorer restart करें।⁷
5. छूटी सूचना: SHChangeNotify भूल गए हों तो Explorer restart से प्रभावी होता है या नहीं, इससे पता चलता है।

flowchart TB
    accTitle: Menu पर न दिखने पर isolation क्रम
    accDescr: पहले पुष्टि करें आप कौन सा menu देख रहे हैं, फिर DLL bitness, registry registration गंतव्य, package registration और signing, तथा छूटा SHChangeNotify, इसी क्रम में अलग करें
    c1["पुष्टि करें पुराना या नया menu"] --> c2["DLL bitness पुष्टि करें"]
    c2 --> c3["HKLM और HKCU registration गंतव्य पुष्टि करें"]
    c3 --> c4["Package registration और signing पुष्टि करें"]
    c4 --> c5["Restart से छूटी सूचना पहचानें"]

चित्र 17: «नहीं दिखता» पर menu जो देख रहे हैं, bitness, registration गंतव्य, package registration, छूटी सूचना के क्रम में अलग करें।

8.2. दो बार दिखता है, या हटता नहीं

विशिष्ट कारण क्लासिक registry registration और manifest registration का साथ-साथ रहना, uninstall cleanup की लीक (खंड 7.4), या पुराने-version ProgID के अवशेष हैं। केवल पुराने menu पर दो बार दिखे तो अवशेष सोचें; पुराने और नए दोनों पर दिखे तो साथ-साथ सोचें।

flowchart TB
    accTitle: Double display अलग करना
    accDescr: केवल पुराने menu पर दो बार cleanup लीक या पुराने ProgID जैसे अवशेष की ओर इशारा करता है; पुराने और नए दोनों पर दो बार क्लासिक registry registration और manifest registration के साथ-साथ की ओर
    q{"किस पर दो बार दिखता है?"} -->|केवल पुराना menu| zan["अवशेष"]
    q -->|पुराना और नया| hei["साथ-साथ"]
    zan -.-> z1["Cleanup लीक या बचा पुराना ProgID"]
    hei -.-> h1["क्लासिक registry registration नए के साथ"]

चित्र 18: केवल पुराने menu पर दो बार अवशेष की ओर; पुराने और नए दोनों पर दो बार साथ-साथ की ओर।

8.3. Explorer भारी है या crash करता है

Right-click धीमा हो, या विशेष folder crash करे, पहले install shell extensions की सूची बनाएँ। NirSoft के ShellExView जैसे tools से गैर-Microsoft extensions सूचीबद्ध करें, संदिग्ध अस्थायी बंद करें, और binary search से दोषी DLL पहचानें। Crash पर Event Viewer का «Faulting module» भी सुराग है। In-house extension कारण हो तो menu-निर्माण path पर synchronous I/O या network access संदेह करें (खंड 4.2 और 5.2)।

flowchart TB
    accTitle: भारी या crash पर दोषी DLL पहचानना
    accDescr: ShellExView में गैर-Microsoft shell extensions सूचीबद्ध करें, संदिग्ध अस्थायी बंद करें और binary search से दोषी DLL पहचानें; crash पर Event Viewer का faulting module भी सुराग है
    s1["Shell extensions सूचीबद्ध करें"] --> s2["गैर-Microsoft सूचीबद्ध करें"]
    s2 --> s3["अस्थायी बंद करें और binary search"]
    s3 --> s4["दोषी DLL पहचानें"]
    crash["Crash पर"] -.-> ev["Faulting module जाँचें"]
    ev -.-> s4

चित्र 19: गैर-Microsoft extensions अस्थायी बंद करें और binary search करें; crash पर Event Viewer भी इस्तेमाल करें।

8.4. सत्यापन के लिए Windows Sandbox सुविधाजनक है

Shell integration का सत्यापन «स्वच्छ environment पर install → चलाएँ → uninstall → अवशेष शून्य» की पुष्टि पर आधारित है। यहाँ सुविधाजनक Windows Sandbox (Pro/Enterprise/Education) है: हर launch कुछ seconds में नया disposable Windows लाता है, इसलिए installer registration और cleanup परीक्षण जितनी बार चाहें चला सकते हैं। बंद करें तो सब गायब, इसलिए अवशेष-registry जाँच के लिए भी उपयुक्त।¹⁵

9. सारांश

• File association «extension key → ProgID → verb» की तीन-परत structure है, और HKCR HKLM/HKCU Classes का merged view है। लिखने का गंतव्य स्पष्ट नामें, और %1 हमेशा quotes में लपेटें।
• Default app user द्वारा चुने जाने के लिए डिज़ाइन है और program से नहीं बदला जा सकता। Installer का काम उम्मीदवार के रूप में सही registration है।
• क्लासिक shell extension Explorer में load in-process COM DLL है। Crash या देरी पूरे तक फैलती है; 64-bit चाहिए; managed code unsupported; नियम native C++ implementation है।
• Windows 11 पर context menu दो भागों में बँट गया। नए menu पर custom command के लिए IExplorerCommand प्लस MSIX manifest चाहिए; क्लासिक IContextMenu «Show more options» पक्ष पर चला जाता है।
• जो ऐप MSIX नहीं बन सकता, उसके लिए sparse package (external location वाला MSIX) से identity practical उत्तर है।
• अगर बस «इस ऐप से खोलें» चाहिए, association और static verb अभी भी काफ़ी हैं। सबसे सरल साधन से शुरू करना official guideline भी है।
• Registration, बदलाव या हटाने के बाद SHChangeNotify से सूचित करें; uninstall पर ProgID हटाएँ पर extension-key default मान छोड़ें। सत्यापन के लिए Windows Sandbox सुविधाजनक है।

Windows 11 PC बदलने पर «menu छिप गया» दिखे तो पहले अध्याय 6 की निर्णय तालिका में (क), (ख) और (ग) में से कौन है पुष्टि करें। काम का पैमाना वहीं आँक सकना चाहिए।

संबंधित लेख

• What Are COM / ActiveX / OCX? - The Differences and Relationships Explained
• What Is Reg-Free COM - Using COM Without Registration
• Registry 32-bit/64-bit Redirection and Virtualization Pitfalls — Wow6432Node and the “The Value I Wrote Isn’t There” Problem
• Choosing a Windows App Distribution Method - MSI/MSIX/ClickOnce/xcopy/Custom Updater
• DLL and COM Interface Backward Compatibility — A Decision Table for Which Changes Break Callers
• Windows ऐप compatibility कैसे काम करती है ── compatibility mode, shim और Compatibility Administrator से पुराने ऐप जीवित रखना

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

KomuraSoft LLC business apps के लिए file association, context menu और shell extension का डिज़ाइन व implementation; Windows 11 नए context menu को निशाना (IExplorerCommand पर जाना, sparse package लाना); मौजूदा installer के registration और cleanup की समीक्षा; तथा Explorer भारी होने या crash करने का कारण जाँच सँभालती है। «Show more options के नीचे छिपे menu के साथ क्या करें» तय करने से शुरू करना ठीक है।

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

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

Windows 11 पर हमारे ऐप का context-menu आइटम केवल "Show more options" के नीचे क्यों दिखाई देता है?

क्योंकि Windows 11 पर File Explorer का context menu दो परतों में बँट गया, पुराना और नया। नए menu पर वे ही commands आ सकती हैं जो IExplorerCommand interface लागू करती हैं और MSIX package manifest में registered हैं (= उनके पास package identity है)। क्लासिक IContextMenu-based shell extensions उस पुराने menu पर चले गए जिसे आप "Show more options" (Shift+F10) से खोलते हैं। Extension स्वयं टूटा नहीं है, इसलिए फिलहाल काम करता रहता है, लेकिन नए menu पर चाहिए तो IExplorerCommand पर migration और या तो MSIX packaging या sparse package से identity देना ज़रूरी है।

क्या installer हमारे ऐप को किसी फ़ाइल का default app (double-click पर खुलने वाला) सेट कर सकता है?

नहीं। Default app चुनना user का काम माना गया है, और Windows system Settings UI के अलावा कहीं से default app बदलने का support नहीं करता। हर user की पसंद रखने वाली UserChoice जानकारी obfuscated की गई है, और एक filter driver (UCPD.sys) apps से लिखने से भी बचाता है। Installer ProgID और verb register कर सकता है, खुद को OpenWithProgIds में जोड़कर "Open with" के उम्मीदवार के रूप में दिख सकता है, और user को Default apps settings page पर ले जा सकता है। सही implementation default चुराना नहीं, चुने जाने के लिए तैयार रहना है।

क्या मैं C# जैसी managed code में shell extension लिख सकता हूँ?

Microsoft ने साफ़ कहा है कि in-process shell extensions (context-menu handler, icon handler आदि) managed code में लिखना recommended नहीं है और unsupported है। Extension Explorer में और किसी भी ऐप की process में load होता है जो common file dialog खोलता है, इसलिए CLR version collision, reentrancy और uncertain object lifetime host ऐप को अस्थिर बनाते हैं। नियम native C++ में implementation है। Verb की command से launch होने वाला सामान्य EXE, या अलग process में चलने वाला out-of-process extension जैसे preview handler, managed code में ठीक है।

Sparse package (external location वाला MSIX) क्या है?

एक छोटा MSIX package जिसमें ऐप फ़ाइलें नहीं, केवल manifest (identity जानकारी) होती है। मौजूदा installer (MSI, Inno Setup आदि) से सामान्य तरीके से install हुए ऐप के लिए आप Add-AppxPackage -ExternalLocation से install folder की ओर इशारा करके register करते हैं, और ऐप package identity पाता है तथा Windows 11 नए context menu पर registration और toast notification जैसी identity-आवश्यक सुविधाएँ इस्तेमाल कर सकता है। Windows 10 version 2004 से उपलब्ध है, और package को target मशीन पर trusted code signing चाहिए। जब पूरा distribution तरीका MSIX पर न ले जाकर नए menu का support चाहिए, यही practical विकल्प है।

Context-menu आइटम दो बार दिखे या हटे नहीं तो क्या करें?

पहले कारण अलग करें: वह नए menu पर दिखता है या पुराने पर (Show more options)। विशिष्ट double display यह है कि क्लासिक registry registration और MSIX manifest registration साथ-साथ हैं, या uninstall पर ProgID या extension CLSID registration रह गया। Association बदलने के बाद SHChangeNotify(SHCNE_ASSOCCHANGED) छूटने का भी संदेह करें; package registration के तुरंत बाद Explorer restart छूटने का। फिर भी न सुलझे तो ShellExView में गैर-Microsoft extensions अस्थायी रूप से बंद करें और binary search से दोषी DLL पहचानें।

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

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

Go Komura

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

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