- 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 के बाद उन्होंने लिखना बंद कर दिया
अभी कोई टिप्पणी नहीं है.