- 1980 के दशक के अंत तक Windows app development Win16/Win32 API पर केंद्रित एकल मॉडल के कारण स्पष्ट था, लेकिन उसके बाद कई दशकों तक असंगत platform transitions दोहराए जाते रहे
- Windows GUI रणनीति का पतन किसी एक खास तकनीक की विफलता नहीं था, बल्कि टीमों के बीच की राजनीति, developer conference-केंद्रित घोषणा संस्कृति, और बिना पूर्व सूचना के रणनीतिक बदलाव—इन तीन संगठनात्मक कारणों से पैदा हुआ
- 1988 में Charles Petzold की Programming Windows ने Win32 नामक एकल API और एकल mental model के साथ “Windows app कैसे बनाया जाए” इसका स्पष्ट उत्तर दिया था, लेकिन उसके बाद 30 वर्षों तक Microsoft इस स्पष्टता को वापस नहीं ला सका
- MFC, OLE, COM, ActiveX, WPF, Silverlight, WinRT, UWP, WinUI 3, MAUI तक पहुँचते-पहुँचते दशकों तक GUI frameworks का बिखराव जारी रहा, और हर असफल initiative में तकनीकी खामियों से अधिक संगठन के भीतर निर्णय-प्रक्रिया की विफलता मुख्य कारण बनी
- आज Windows पर वास्तव में इस्तेमाल होने वाली GUI technologies 17 से अधिक हैं, और उनमें सबसे व्यापक रूप से deploy की गई desktop GUI technology Electron है, जिसे Microsoft ने नहीं बल्कि बाहरी दुनिया ने बनाया
- “अगर कोई platform ‘UI कैसे बनाना चाहिए?’ इस सवाल का 10 सेकंड में जवाब नहीं दे सकता, तो वह platform developers को विफल कर चुका है” — यह केंद्रीय निदान 2026 में भी Microsoft पर जस का तस लागू होता है
एकसमान GUI रणनीति के गायब होने के बाद का Microsoft
- 30 साल से अधिक समय से Windows GUI रणनीति की अव्यवस्था जारी है, और “नया Windows desktop app बनाते समय कौन-सा framework इस्तेमाल किया जाए?” इस सवाल का कोई स्पष्ट उत्तर नहीं है
- 1988 में Win16/Win32 API का एकल मॉडल मौजूद था, इसलिए developers एक ही तरीके से apps लिख सकते थे
- उसके बाद कई दशकों तक Microsoft आंतरिक राजनीति, demo-केंद्रित निर्णय-प्रक्रिया, और business strategy shifts के कारण एकसमान platform बनाए नहीं रख सका
- नतीजतन Win32 से MAUI तक 17 GUI technologies साथ-साथ मौजूद हैं, और developers रणनीति-विहीन platform में भ्रम झेल रहे हैं
- मूल कारण तकनीकी विफलता नहीं बल्कि संगठनात्मक विफलता है
Petzold युग: आखिरी बार जब चीजें स्पष्ट थीं
- 1988 में Charles Petzold की Programming Windows (852 पेज) C में Win16 API को समझाने वाला एकमात्र प्रामाणिक उत्तर थी, और वही वास्तव में Windows development की रणनीति थी
- Win32 बड़ा ज़रूर हुआ, लेकिन message loop, window procedure, और GDI वाला एक mental model बना रहा; Petzold ने इसे समझाया और developers इसे सीखकर तुरंत इस्तेमाल कर सकते थे
- “एक OS, एक API, एक language, एक किताब” — यही स्पष्टता platform की विश्वसनीयता का संकेत थी
object-oriented लहर (1992–2000): जटिलता की शुरुआत
- 1992 में MFC ने Win32 को C++ में wrap किया, लेकिन उसके बाद OLE, COM, और ActiveX आ गए, और GUI framework के बजाय component architectures ने Windows development पर कब्ज़ा करना शुरू कर दिया
- Microsoft ने एकसमान कहानी देने के बजाय सिर्फ तकनीकी primitives दिए और developers से कहा कि वे खुद उन्हें जोड़ें; इसकी वजह conference keynote-केंद्रित घोषणा संस्कृति थी, जहाँ developer success से अधिक executives पर प्रभाव डालना प्राथमिकता थी
PDC 2003 Longhorn: जब vision ने खुद को निगल लिया
- 2003 PDC में दिखाया गया Longhorn WinFS (relational file system), Indigo (unified communication), Avalon (GPU-accelerated XAML-based UI) इन तीन स्तंभों पर आधारित एक प्रभावशाली vision था
- जनवरी 2004 में Jim Allchin के आंतरिक memo ने इसे “pig” कहा, और उसी साल अगस्त में पूरी development reset की घोषणा हुई — Server 2003 codebase पर वापसी
- reset के बाद leadership ने निर्देश दिया कि “Windows में managed code निषिद्ध, सभी नया code C++ में” और WPF Vista के साथ रिलीज़ हुआ, लेकिन shell ने खुद WPF का इस्तेमाल नहीं किया
- इस फैसले के कारण Windows team और .NET team के बीच 13 साल तक चलने वाला संगठनात्मक गृहयुद्ध शुरू हुआ, जिसका परिणाम WPF के अनाथ हो जाने, Silverlight के खत्म होने, और UWP की विफलता के रूप में निकला
Silverlight: दोहराए जाने वाले पैटर्न की स्थापना (2007–2010)
- WPF 2006 के अंत में रिलीज़ हुआ, लेकिन 2007 में Silverlight Flash के जवाब में browser plugin के रूप में आया और development investment बँट गया
- 2010 MIX conference में Microsoft के एक executive ने Q&A के दौरान कहा कि “Silverlight cross-platform strategy नहीं, Windows Phone strategy है” — Silverlight team को इसकी पहले से सूचना नहीं थी, और जिन developers ने अपने LOB apps के लिए Silverlight में निवेश किया था उन्हें भी यह पहली बार conference Q&A से पता चला
- Silverlight का अंत तकनीकी विफलता नहीं बल्कि business strategy change का परिणाम था, और यहीं वह ढाँचा स्थापित हुआ जिसमें developers को हमेशा सबसे अंत में बताया जाता है
Metro और दो टीमों का युद्ध (2012)
- Apple के 20 करोड़ iPhone बिकने और iPad के PC बाज़ार को काटने के जवाब में Windows 8 और Metro लाए गए, लेकिन WinRT को जानबूझकर .NET आधारित नहीं बल्कि native C++ runtime के रूप में डिज़ाइन किया गया — यह Windows team की .NET के प्रति नाराज़गी का सीधा प्रतिबिंब था
- //Build 2012 में developers ने एक साथ विरोधाभासी संदेश सुने: “भविष्य WinRT है, HTML+JS first-class citizen हैं, .NET अभी भी चलता है, C++ वापस आ गया है, Metro apps भी लिखे जा सकते हैं, और WPF code भी अभी चलता रहेगा”
- enterprise developers ने UWP की sandboxing, Store deployment requirements, और गायब Win32 APIs देखीं और तुरंत दूरी बना ली — “tablet app store अंततः कभी साकार ही नहीं हुआ”
UWP और WinUI की उलझन (2015–वर्तमान)
- Windows 10 का UWP (Universal Windows Platform) PC, phone, Xbox, और HoloLens के लिए “एक बार लिखो, हर जगह चलाओ” vision था, लेकिन Windows Phone के पतन के साथ ही जब Microsoft के अपने flagship apps (Office, Visual Studio, shell) ने UWP नहीं अपनाया, तो संकेत साफ हो गया
- आधिकारिक जवाब “it depends” तक सिमट गया — UWP, WPF को बनाए रखना, XAML Islands, WinUI 3 का इंतज़ार, WinUI 2 का साथ-साथ रहना, Project Reunion का लॉन्च, और फिर Windows App SDK नामकरण—इन सबने भ्रम और बढ़ा दिया
- Project Reunion / WinUI 3 तकनीकी प्रगति ज़रूर है, लेकिन उसका अस्तित्व ही इस संगठनात्मक समस्या का नतीजा है कि UWP controls OS से बंधे हुए थे और .NET team व developer tools team उनके मालिक नहीं थे
- 2024 में एक developer की टिप्पणी: “UAP, UWP, C++/CX को C++/WinRT से बदलना (बिना tooling support), XAML Islands, XAML Direct, Project Reunion, WinAppSDK restart, WinUI 2.0 और 3.0 के बीच उलझा हुआ transition… 14 साल, 14 pivots”
बिना रखवाले का चिड़ियाघर: आज के Windows की GUI technologies की सूची
Microsoft native frameworks:
- Win32 (1985) — अब भी उपयोग में, Petzold की किताब अब भी प्रासंगिक
- MFC (1992) — maintenance mode में, enterprise और CAD क्षेत्रों में बाकी
- WinForms (2002) — “इस्तेमाल किया जा सकता है लेकिन recommend नहीं किया जाता”, data entry forms के लिए अब भी सबसे तेज़
- WPF (2006) — XAML, DirectX rendering, open source, Microsoft का नया निवेश नहीं
- WinUI 3 / Windows App SDK (2021) — आधिकारिक “modern” उत्तर, roadmap अनिश्चित
- MAUI (2022) — Xamarin.Forms का cross-platform उत्तराधिकारी, .NET team की मौजूदा शर्त
Microsoft web hybrids:
- Blazor Hybrid — native WebView के भीतर .NET Razor components
- WebView2 — Win32/WinForms/WPF apps में embedded Chromium
Third-party:
- Electron — Chromium + Node.js, VS Code·Slack·Discord द्वारा अपनाया गया, इस समय Windows पर सबसे व्यापक रूप से deploy की गई desktop GUI technology, लेकिन Microsoft से असंबंधित
- Flutter (Google), Tauri (Rust-आधारित), Qt (C++/Python/JS), React Native for Windows (Microsoft का समर्थन, पर तकनीक Facebook की)
- Avalonia — WPF का open source वैचारिक उत्तराधिकारी, JetBrains·GitHub·Unity जैसे वे developers/companies जिन्होंने Microsoft का इंतज़ार नहीं किया, उन्होंने इसे अपनाया
- Uno Platform — WinUI के प्रति Microsoft से भी अधिक प्रतिबद्ध
- Delphi/RAD Studio, Java Swing/JavaFX — vertical markets और enterprise में अब भी जीवित
→ 17 approaches, 5 programming languages, 3 rendering philosophies — यह “platform” नहीं है
मुख्य निदान
- हर असफल GUI initiative आखिरकार तीन कारणों में से एक पर जाकर टिकता है: टीमों के बीच राजनीति (Windows vs. .NET), conference announcements के आधार पर समय से पहले platform bets (Metro, UWP), developers को बिना पूर्व सूचना business strategy shifts (Silverlight)
- तकनीकें अक्सर अच्छी थीं — WPF अच्छा था, Silverlight अच्छा था, XAML अच्छा था — संगठनात्मक विफलता ही उत्पाद की विफलता बनी
- “adoption-investment-maintenance-migration” पूरे lifecycle को कवर करने वाली Plausible Theory of Success के बिना, यह रणनीति नहीं बल्कि सिर्फ conference keynote रह जाती है
- Charles Petzold ने Microsoft की लगातार नई घोषणाओं के साथ बने रहने के लिए Programming Windows को 6th edition तक संशोधित किया, लेकिन WinRT (Windows 8) को कवर करने वाले 6th edition के बाद उन्होंने लिखना बंद कर दिया
2 टिप्पणियां
आखिरकार फिर Win32?!!
Hacker News की राय
Microsoft की बुनियादी समस्या यह है कि वह GUI में एकरूपता को सिर्फ framework layer पर हल करने की कोशिश करता है
WinForms, WPF, UWP, WinUI जैसे नए framework बार-बार लाता है और आखिर में छोड़ देता है
Apple design system को ही product की तरह देखता है, और framework को नज़र से ओझल रखता है, जबकि Microsoft हर बार इसका उल्टा करता है
Apple की तरफ के उदाहरण भी सुनना चाहोगे?
आजकल WPF, WinUI skin की नकल कर रहा है, तो कम से कम Microsoft कोशिश तो कर रहा है
latest .NET stack में भी यह अब तक official path में से एक है
WinForms अब भी आकर्षक है
WebView2 की वजह से hybrid app बनाना आसान हो गया है, और चाहें तो pure web पर भी जाया जा सकता है, लेकिन native chrome जो एहसास देता है वह बेहतर है
मेरे सभी ग्राहक Windows इस्तेमाल करते हैं, इसलिए मैं बेवजह इससे लड़ता नहीं
हाल में मैं .NET10 + WinForms + WebView2 के साथ एक AI assistant बना रहा हूँ
pure WinForms में chat history UI को बार-बार tweak करने की कल्पना भी नहीं करना चाहता
“WPF अच्छा था” इस बात से सहमत नहीं हूँ
2000 के दशक के आखिर में आम hardware पर WPF app धीमे चलते थे
उदाहरण के लिए Logos Bible Software एक साधारण text app होते हुए भी graphics performance मांगता था, इसलिए पुराने laptop पर अटकता था
बाद में पता चला कि Logos 4, WPF आधारित था, और forum post में भी ऐसी ही शिकायतें बहुत थीं
आखिर में हमें ज़्यादातर code को Direct3D/Direct2D में फिर से implement करना पड़ा
समस्या WPF architecture में ही थी
वजह धुंधला text और performance issues बताए गए थे
संबंधित लेख: edandersen.com / Reddit
संबंधित लेख: Ars Technica
आखिरकार performance debate हर दौर में दोहराई जाती है
Apple भी AppKit/UIKit से SwiftUI की ओर जाते समय ऐसे ही मसलों से गुज़र रहा है
जब ChatGPT पहली बार ज़ोर से उभरा था, तब Bing का web-accessible version integrate करना कमाल का idea था
लेकिन Microsoft ने context compression जैसी implementation details सही नहीं कीं, इसलिए बातचीत जल्दी block हो जाती थी
वहीं OpenAI, Perplexity वगैरह ने इसे अच्छी तरह implement किया, और अब यह standard बन चुका है
अगर Microsoft ने तब इसे ठीक से किया होता, तो शायद वह Google की जगह ले सकता था
आखिरकार समस्या UI/UX की अधूरी polish थी, और मुझे लगता है कि इसकी जड़ organizational culture में consistency की कमी है
Apple का UI library bundling रोकना परेशान करने वाला था, लेकिन इसी वजह से UI consistency भी बनी रही
ज़्यादातर users को इससे फ़र्क नहीं पड़ता
कोई user बार-बार Microsoft executives के साथ dinner की एक ही कहानी copy-paste करता है, और उसका सार यह है कि “Microsoft enterprise पर all-in है”
लेकिन हक़ीक़त में Windows और Azure की quality में गिरावट की वजह से enterprise ग्राहक भी दूर जा रहे हैं
हमारी company को भी Azure SLA समस्याओं से नुकसान हुआ, और कोई compensation नहीं मिला
इसलिए हम Active Directory और Windows पर अपनी dependency घटा रहे हैं
आखिर users के बिना enterprise market भी नहीं होता
Win32 के बाद Microsoft ने कभी 2 साल से ज़्यादा एक ही दिशा में लगातार push नहीं किया
WinRT ठीक-ठाक था, लेकिन Nadella के आने के बाद Azure-केंद्रित बदलाव में Windows platform को छोड़ दिया गया
Windows → Office → Azure में बदलते-बदलते उसकी पहचान धुंधली हो गई है
Office web और desktop दोनों पर है, hardware भी है और store भी
Satya Nadella की vision साफ़ तौर पर communicated नहीं होती
Store बेहद खराब था, और बस internal promotion project बनकर रह गया था
समस्या यह है कि Microsoft लगातार नए GUI framework लाता रहता है, लेकिन फिर भी Win32 app आज भी लिखे जा सकते हैं
Microsoft ने बहुत पहले से web-केंद्रित दिशा पकड़ी थी, और AJAX·Flexbox·Grid जैसी तकनीकों के विकास में भी योगदान दिया
मैं ज़्यादातर web·Java·Python आधारित cross-platform systems बनाता हूँ
Windows-only GUI बनाने की कोई खास वजह नहीं है
web app ज़्यादा flexible और accessible होते हैं
web हर जगह चलता है, और PWABuilder से app store में deployment भी संभव है
मैं इस project में शामिल हूँ, और Electron के बिना भी तेज़ और हल्के app बनाए जा सकते हैं
Active Desktop दस्तावेज़ को देखें तो उस समय यह काफ़ी experimental था
web सिर्फ एक अस्थायी उपाय है, सच में अच्छा अनुभव native में ही मिलता है
लगभग 2007 में Delphi से WPF पर गया था, लेकिन 2010 तक पूरी तरह Windows छोड़ दिया
Microsoft की internal politics और बार-बार technology को खत्म कर देने की आदत बहुत ज़्यादा थी
उस समय Rails उभर रहा था, इसलिए switch करना आसान था
शायद यह Stockholm syndrome हो, लेकिन Visual Studio भी अब तक WPF आधारित है, इसलिए ज़्यादा चिंता नहीं है
एक तरह से उसने आज की big tech समस्याओं की झलक पहले ही दिखा दी थी
Steven Sinofsky ने हाल में इसी विषय पर एक पोस्ट लिखी थी
x.com लिंक
वह WinRT दौर में DevDiv में था, लेकिन Windows team को developers की ज़रूरतें समझ नहीं आती थीं
Python/WinRT prototype भी था, लेकिन “developers सिर्फ JS चाहते हैं” यह कहकर उसे छोड़ दिया गया
Metro style थोपने के लिए Visual Studio menu को पूरी तरह uppercase में बदल दिया गया था
Windows RT ने compatibility भी तोड़ दी, इसलिए apps लगभग थे ही नहीं, और आखिर में वह विफल हो गया
यहाँ तक कि Sinofsky के कुछ technical claims भी ग़लत हैं (.NET 3.0 Vista में शामिल था)
xcancel.com अभी तक यह सुविधा support नहीं करता
जवाब साफ़ है — Qt
मज़ाक नहीं कर रहा, अगर Electron नहीं इस्तेमाल करना है तो Qt सचमुच विकल्प है
Qt के लिए यह core business है, इसलिए वह बार-बार दिशा नहीं बदलता