Windows native ऐप डेवलपमेंट इतना बिखरा हुआ क्यों है

 (domenic.me)
14 पॉइंट द्वारा GN⁺ 2026-03-23 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • Windows native ऐप डेवलपमेंट ecosystem दशकों से चले आ रहे framework fragmentation और बार-बार redesign की वजह से 2025 में भी वास्तविक developer productivity नहीं दे पा रहा है
  • Win32 से MFC, WinForms, WPF, WinRT, UWP और WinUI 3 तक UI framework के 7 चरणों के बदलाव के बावजूद, केवल latest API से बुनियादी features तक implement करना कई मामलों में संभव नहीं है
  • Tray icon, global shortcut intercept जैसे रोज़मर्रा के features अभी भी P/Invoke के जरिए Win32 call पर निर्भर हैं, जिससे modern framework अपनाने का मतलब फीका पड़ जाता है
  • .NET AOT compilation से साधारण utility app build करने पर भी 9MiB से बड़ा binary बनता है, और MSIX distribution के लिए code signing certificate की सालाना लागत $200–300 जैसी व्यावहारिक बाधा मौजूद है
  • Microsoft के अपने बड़े apps (VS Code, Outlook, Start Menu) वेब तकनीकों से बने हैं — यह इस बात का संकेत है कि Windows native development अब Microsoft के भीतर भी प्राथमिकता नहीं रहा

पृष्ठभूमि: क्या बनाया गया

  • Windows-only utility app ‘Display Blackout’ बनाते समय मौजूदा native app development environment की समस्याएँ सामने आईं
    • यह app multi-monitor environment में गेम खेलते समय बाएँ-दाएँ स्क्रीन को काले overlay से बंद करने वाला feature देता है
    • ज़रूरी features में display enumeration, boundary calculation, global shortcut handling, tray icon दिखाना, startup पर auto-run, settings save आदि शामिल थे
  • पहले से AutoHotkey script और Microsoft Store app मौजूद थे, लेकिन सीखने और UI सुधारने के उद्देश्य से इसे खुद बनाने की कोशिश की गई
  • नतीजे में यह साफ़ हुआ कि Windows native app development environment बेहद जटिल और अक्षम है

Windows programming का इतिहास

  • शुरुआत में C-आधारित Win32 API ही एकमात्र विकल्प था, और यह API आज भी प्रभावी है
  • C++-आधारित MFC ने Win32 के ऊपर class, template जैसी object-oriented abstraction जोड़ी
  • .NET 1.0(2002) के आने से C# भाषा, JIT bytecode VM, automatic memory management आए, और Windows Forms Win32 window/control API का wrapper था
  • .NET 3.0(2006) का WPF XAML markup language लाया और GPU-आधारित control rendering के जरिए Win32 निर्भरता से निकलने की पहली कोशिश थी
  • Windows 8(2012) का WinRT sandbox app model लेकर आया, जिसका लक्ष्य desktop, tablet और phone को unify करना था, लेकिन इसका XAML ढाँचा WPF से हल्का अलग था और इससे भ्रम पैदा हुआ
  • Windows 10(2015) का UWP ने sandbox की कुछ सीमाएँ कम कीं, लेकिन यह WPF-स्तर के desktop privileges तक नहीं पहुँचा; कुछ OS features (push notifications, live tiles, Microsoft Store distribution) केवल WinRT/UWP तक सीमित रहे
    • इसी कारण Chrome और Microsoft Office जैसे existing apps ने WinRT/UWP bridge apps को IPC से जोड़ने वाली असहज architecture अपनाई
  • Windows 11(2021) का Windows App SDK ने WinRT/UWP-only features को standard C++ और .NET apps दोनों के लिए खोला, और WinUI 3 नाम की नई XAML-आधारित control library शामिल की
  • UI framework evolution summary:
    > Win32 C APIs → MFC → WinForms → WPF → WinRT XAML → UWP XAML → WinUI 3

development approach चुनने की दुविधा

  • WinUI 3 app development के लिए तीन रास्ते हैं:
    • C++: lean binary, Win32 C API के साथ आसान interop — लेकिन memory safety नहीं
    • C#/XAML + framework-dependent distribution: modern Windows 11 में भी केवल .NET 4.8.1 preinstalled है, इसलिए पहली install पर .NET library download dialog दिखता है, जो खराब user experience देता है
    • C#/XAML + .NET AOT: पूरा .NET runtime (VM, GC, standard library) binary में शामिल — साधारण app भी 9MiB से बड़ा binary बना देता है
  • Rust bindings को बनाए रखने की कोशिश (windows-app-rs) archived हो चुकी है
  • distribution का तरीका चुनना भी मुश्किल है:
    • MSIX format के लिए code signing certificate चाहिए, जिसकी लागत अमेरिका के बाहर रहने वालों के लिए सालाना $200–300 है
    • unsigned sideload के लिए admin terminal में ही चलने वाला जटिल PowerShell command चाहिए
    • Microsoft Store registration को “मौलिक और निरंतर value” न देने के कारण reject कर दिया गया

वे features जो latest SDK में भी संभव नहीं

सुविधा Windows App SDK समर्थन स्थिति
display enumeration आंशिक रूप से संभव (foreach loop नहीं, बदलाव detect करने के लिए P/Invoke चाहिए)
inactive black window placement आंशिक रूप से संभव (non-activating के लिए P/Invoke चाहिए)
global keyboard shortcut intercept असंभव — P/Invoke चाहिए
startup पर auto-run संभव (system settings integration API उपलब्ध)
settings persistence संभव
tray icon + menu असंभव — P/Invoke चाहिए, menu style standard नहीं
  • Tray icon menu style हर app में अलग-अलग है; पूरे OS में कोई एकसमान standard नहीं
  • WPF से WinUI 3 तक आते-आते window size auto-adjustment जैसी बुनियादी सुविधा भी गायब हो गई

C# और Win32 interop की संरचनात्मक सीमाएँ

  • modern P/Invoke tool CsWin32 में bug है, जिसकी वजह से यह struct के अंदर की strings को सही तरह wrap नहीं कर पाता
  • CsWin32 documentation साफ़ कहता है कि Win32 API के मूल parameter type [optional, out] को C# में idiomatic तरीके से व्यक्त करने का तरीका नहीं है, इसलिए वही method दो versions में generate किया जाता है
  • WPF release(2006) के 20 साल बाद भी UI binding के लिए class लिखने वाला boilerplate लगभग वैसा ही है
    • हर property को getter/setter pair में बदलना, same-value guard लगाना, event trigger call लिखना जैसी दोहराव वाली code अभी भी चाहिए
    • JavaScript के decorators/proxies जैसा language-level समाधान 20 साल में भी C# में नहीं आया
  • CsWin32 का changelog कमज़ोर है और यह अब भी 1.0 से पहले के version पर अटका है, इसलिए कुछ वर्षों में project छोड़े जाने की आशंका दिखती है

निष्कर्ष: Electron ही जवाब क्यों है

  • अभी Microsoft native app development को प्राथमिकता नहीं दे रहा
    • संबंधित issue trackers bugs और reports से भरे हैं, लेकिन Microsoft engineers की प्रतिक्रिया लगभग नहीं के बराबर है
    • Windows App SDK का changelog machine learning APIs जोड़ने पर केंद्रित है
  • VS Code, Outlook, Start Menu जैसे Microsoft के प्रमुख apps का web technologies पर बना होना इस बात का सबूत है
  • community Avalonia, Uno Platform जैसे third-party UI frameworks की ओर जा रही है
    • ये WPF की philosophy को आगे बढ़ाते हैं और cross-platform support को मज़बूत करते हैं
  • फिलहाल Electron या Tauri जैसे web-based frameworks ज़्यादा व्यावहारिक विकल्प हैं
    • TypeScript/React/CSS का संयोजन C#/XAML से अधिक productive है
    • Win32 API access भी संभव है

    • Tauriमें system WebView का उपयोग होता है, इसलिए Chromium bundle की ज़रूरत नहीं पड़ती

      • WebView2 runtime हर 4 हफ्ते में update होता है, जबकि system .NET 4.8.1 पर अटका हुआ है
      • अगर Microsoft Windows App SDK में सुधार और distribution system को सरल बनाता है तो वापसी की संभावना हो सकती है
      • लेकिन फिलहाल ज़्यादातर developers ऐसी उम्मीद नहीं रखते
      • निष्कर्ष अंततः “मैं web stack चुनूँगा” पर पहुँचता है
  • Microsoft की हाल की Windows quality पर केंद्रित घोषणा में पूरे OS में WinUI 3 का अधिक उपयोग करने की बात शामिल है, लेकिन इससे वास्तविक सुधार होगा या नहीं, यह अभी भी स्पष्ट नहीं है

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.