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

(domenic.me)

14 पॉइंट द्वारा GN⁺ 2026-03-23 | 3 टिप्पणियां | 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 का अधिक उपयोग करने की बात शामिल है, लेकिन इससे वास्तविक सुधार होगा या नहीं, यह अभी भी स्पष्ट नहीं है

3 टिप्पणियां

vndk2234 2026-03-24

Electron के जरिए इसे सामान्य बना देने के लिए धन्यवाद...

carnoxen 2026-03-23

बस यही चाहत है कि Winui 3 का WYSIWYG कब आएगा।

GN⁺ 2026-03-23

Hacker News की राय

मुझे भी लगता है कि दूसरों की तरह Win32 पर टिके रहना सही है
लंबे समय से Win32 में डेवलपमेंट करने के अनुभव से कहूँ तो, ज़रूरी फीचर 8KB से छोटे standalone executable में भी पर्याप्त रूप से लागू किए जा सकते हैं
display enumeration, window creation, shortcut hooking, startup program registration, settings save करना, tray icon दिखाना—ये सब कुछ सौ bytes के API calls से किया जा सकता है
लेकिन 2026 में नया project memory-safe नहीं होने वाली language (C++) में लिखना समय के खिलाफ चलने जैसा है
फिर भी, अगर app में untrusted input लगभग नहीं है, तो बेवजह प्रचार (Propaganda) से प्रभावित होने की ज़रूरत नहीं है
- अगर memory safety और _UNICODE जैसी समस्याओं से बचना है, तो .NET Framework के साथ आधे समय में वही चीज़ बनाई जा सकती है
- पहले Delphi या MFC जैसी पतली layers इस समस्या को हल कर देती थीं, लेकिन अब उनका दौर निकल चुका है और कोई ठोस विकल्प नहीं है
  मेरा मानना है कि “NoFramework” आंदोलन फिर से आना चाहिए ताकि हम RAD युग में लौट सकें
- Win32 के पास अब भी भरपूर documentation और tools हैं, और यह आगे भी लंबे समय तक बना रहेगा
  लेकिन नए project में C++ चुनते समय सावधानी ज़रूरी है
  memory-safe languages से भी Win32 इस्तेमाल किया जा सकता है — उदाहरण के लिए windows-rs
- मुझे जिज्ञासा है कि आम उपयोगकर्ता की नज़र में Win32 app को सुंदर कैसे बनाया जाए
- यह भी सोचने वाली बात है कि Winamp developers ने इतने शानदार Win32 apps कैसे बनाए
  उस समय Borland Delphi सबसे लोकप्रिय tool था
अगर बात पुराने WinRT, UAP, UWP apps की नहीं है, तो WinUI 3.0 या WinAppSDK से बचना चाहिए
Win32, MFC, WinForms, WPF जैसी proven technologies का इस्तेमाल जारी रखना बेहतर है,
और Microsoft के बाहर के ecosystem में Qt, VCL, Firemonkey, Avalonia, Uno, ImGUI आदि पर विचार किया जा सकता है
WinUI 3.0 इतना बिखरा हुआ है कि Microsoft खुद भी इसे community को open source के रूप में सौंपने की कोशिश कर रहा है
- मैंने पहले WinJS से Windows 8 app बनाकर Windows Store में डाला था
  बाद में WinJS open source web framework में बदल गया और official support खत्म हो गया
- हाल की एक blog post में “Windows core experience को WinUI3 में migrate किया जा रहा है” जैसी घोषणा थी; कहा तो गया कि यह quality improvement के लिए है, लेकिन यह चिंता बढ़ाती है
  संबंधित blog post
मैं embedded developer हूँ, और device से communicate करने वाला Win32 GUI program बनाना अब भी आसान है
XP ज़माने का code Windows 11 पर भी वैसे का वैसा चला, और VC6 project को Visual Studio 2022 में खोलकर भी बिना दिक्कत build किया गया
ऐसी backward compatibility दूसरे platforms पर कम ही देखने को मिलती है
- मुझे तो भद्दा Win32 code ही इस्तेमाल करते रहना बेहतर लगता है
  Apple का Cocoa structure में “elegant” लगता है, लेकिन व्यवहार में जटिल है और documentation भी खास मददगार नहीं है
- आजकल developers हर हफ्ते बदलने वाले ecosystem के आदी हो गए हैं, इसलिए पुरानी चीज़ों को वे अक्सर “maintain नहीं हो रही” मान लेते हैं
- हालांकि high-DPI या input handling जैसी समस्याएँ अब भी मुश्किल हैं
- 32-bit से 64-bit पर पूरी तरह migrate करना सबसे बड़ी चुनौती थी
- string define करने के बहुत ज़्यादा तरीके हैं, इसलिए भ्रम होता है
शुद्ध Win32 API अब भी एक व्यावहारिक विकल्प है
अगर C++ में MFC जैसी wrapper खुद बना ली जाए, तो 2–3 हफ्तों में तैयार की जा सकती है, और उसके बाद पूरा control अपने हाथ में रहता है
Microsoft की मज़बूत backward compatibility की वजह से Win32 आधारित apps लंबे समय में स्थिर रहते हैं
10 साल से ज़्यादा समय तक update किए गए उदाहरण यहाँ देखे जा सकते हैं
- dark mode support सबसे बड़ी समस्या है
  system colors और controls hard-coded हैं, इसलिए वे dark theme से टकराते हैं
  menu, message box, file dialog जैसे कुछ UI ही dark mode support करते हैं, इसलिए consistency टूट जाती है
- इस approach से Windows 11 style UI नहीं बनाया जा सकता
  संबंधित चर्चा के लिए यह लेख देखें
- मैंने पहले WTL 3.0 इस्तेमाल किया था; यह MFC से बहुत हल्का था और Win32 के सभी features तक पहुँच देता था
  अभी यह open source के रूप में maintain हो रहा है और version 10 तक आ चुका है
- अगर MFC-style wrapper की API design अच्छी हो, तो AI implementation भी लिख सकता है
- कुछ लोगों की राय है कि C++ Builder या Delphi इस्तेमाल करना शायद बेहतर होगा
Windows apps कई बार बनाने के अनुभव से,
(1) Win32 API पुराना है लेकिन बहुत स्थिर है, और
(2) Microsoft-owned UI toolkits से बचना चाहिए — आखिरकार Win32 level control की ज़रूरत पड़ती ही है
- हालांकि WPF और WinForms अपवाद हैं और अपेक्षाकृत स्थिर हैं
  पिछले 20 सालों में Microsoft की अधिकांश UI technologies किसी न किसी रूप में WPF की ही variations थीं
  अगर WPF को लगातार आगे बढ़ाया गया होता, तो आज तक यह UI development का standard बन चुका होता
उपयोगकर्ता के नज़रिए से native apps तेज़ और अच्छे लगते हैं, लेकिन development वाकई जटिल अव्यवस्था है
Outlook और Teams जैसे apps के लगातार खराब होने की एक वजह यह भी है
- विडंबना यह है कि Outlook और Teams ये समस्याएँ इसलिए झेलते हैं क्योंकि वे web app आधारित (Electron) हैं
  focus, keyboard navigation जैसी चीज़ों में native feel की नकल करना मुश्किल है
- मैं भी अपने निजी tools बनाते समय TypeScript + Bun + Electrobun का संयोजन इस्तेमाल करता हूँ
  Electrobun project देखें
- जब Microsoft खुद Electron से apps बना रहा है, तो दूसरे developers से क्या उम्मीद की जाए
“C++ में नया project बनाना अपराध है” इस बात से मैं सहमत नहीं हूँ
GUI में safety से ज़्यादा performance और control मायने रखते हैं, और C++ अब भी एक proven language है
Qt 2026 में भी बेहतरीन GUI frameworks में से एक है, और इसमें memory safety features built-in हैं
- लेकिन Qt सच में native सिर्फ कुछ Linux distributions पर ही व्यवहार करता है
- Qt apps को runtime चाहिए, इसलिए इन्हें पूरी तरह native कहना मुश्किल है
- बेशक managed environments की तुलना में यह असुविधाजनक हो सकता है, लेकिन embedded माहौल में यह अब भी उपयोगी है
यह सवाल उठता है कि आधुनिक .NET runtime Windows 11 में default रूप से शामिल क्यों नहीं है
यह Microsoft द्वारा consistent user experience छोड़ देने का एक और उदाहरण लगता है
- .NET versions बहुत ज़्यादा हैं और वे पूरी तरह backward compatible भी नहीं हैं,
  इसलिए Windows Update के जरिए सबको distribute करना व्यावहारिक नहीं है
  इसके बजाय AOT-compiled standalone executable के रूप में distribute किया जा सकता है (लगभग 9MiB)
  यह Electron से कहीं छोटा और अधिक efficient है
- पहले Windows Update के जरिए distribute किया जाता था, लेकिन updates apps को तोड़ देते थे या बहुत बड़े होते थे, इसलिए यह inefficient था
  अब DLLs को साथ package करना बेहतर है
- .NET 5 के बाद security model और namespace में बड़े बदलाव हुए,
  इसलिए इसे OS में embed करना मुश्किल हो गया
  तेज़ release cycle बनाए रखने के लिए इसे OS updates से अलग किया गया
- अभी legacy .NET Framework OS में शामिल है,
  जबकि .NET Core अलग से install करना पड़ता है
काफी समय बाद मैंने Tauri से Windows और Mac के लिए app बनाया,
development और build आसान थे, लेकिन code signing की समस्या के कारण सहकर्मी इसे install नहीं कर सके
Mac पर इसे terminal command से हल किया गया, लेकिन Windows में Smart App Control बंद करना पड़ा
और इस feature को reinstall किए बिना फिर से चालू नहीं किया जा सकता
सुरक्षा का उद्देश्य समझ में आता है, लेकिन install process इतनी कठिन होगी, यह उम्मीद नहीं थी
“Electron क्यों नहीं इस्तेमाल करते?” इसका जवाब सरल है —
Electron apps का user experience खराब होता है
development आसान होता है, लेकिन performance और quality की कीमत चुकानी पड़ती है
अगर अच्छा product बनाना है, तो मुश्किल होने पर भी native रास्ता चुनना चाहिए
व्यक्तिगत रूप से मुझे C# TypeScript से कहीं बेहतर लगता है