डेवलपर्स के लिए विंडोज 8: एक सपने को पुनर्जीवित करना? (1/2)

इस महीने की शुरुआत में, Microsoft ने विंडोज़ डेवलपर्स को थोड़ा झटका दिया: .NET प्लेटफ़ॉर्म, जिसे कंपनी पिछले एक दशक से डेवलपर्स के लिए प्राथमिक के रूप में प्रचारित कर रही है, का उपयोग नए विंडोज 8 इंटरफ़ेस के लिए एप्लिकेशन बनाने के लिए नहीं किया जाएगा। इसके बजाय, डेवलपर्स को एचटीएमएल 5 और जावास्क्रिप्ट का उपयोग करना चाहिए।

उनमें से कई ने, स्वाभाविक रूप से, एक सवाल पूछा, जिसका जवाब अभी तक नहीं मिला है: "मैं नए अनुप्रयोगों को विकसित करने के लिए अपने अनुभव का उपयोग कैसे कर सकता हूं?" माइक्रोसॉफ्ट चुप है और सितंबर में बीयूआईएलडी सम्मेलन (पूर्व पीडीसी) तक कुछ भी रिपोर्ट करने की योजना नहीं है।

लेकिन शायद सब कुछ उतना ही निराशाजनक नहीं है जितना कि कई लोग सोचते हैं। विंडोज 8 के शुरुआती बिल्ड इंटरनेट पर लीक हो गए, और यह समझने का काफी प्रयास किया गया कि वे कैसे काम करते हैं। ठीक है, सब कुछ ऐसा दिखता है जैसे कि विंडोज 8 के लिए एप्लिकेशन डेवलपमेंट न केवल भयानक है, बल्कि अंत में डेवलपर्स को उनके रास्ते में कई कष्टप्रद बाधाओं से बचाने में सक्षम होगा। यदि Microsoft नियोजित सब कुछ को लागू करने में सफल होता है, तो विंडोज का अगला संस्करण उतना ही महत्वपूर्ण होगा जितना कि विंडोज लॉन्गहॉर्न का रिलीज होना चाहिए था।

थोड़ा इतिहास

यह समझने के लिए कि क्या है, कुछ ऐतिहासिक भ्रमण किया जाना चाहिए।
.NET प्लेटफ़ॉर्म पेश किए जाने से पहले, विंडोज एप्लिकेशन दो तरह से विकसित किए गए थे। Win32 API और C ++ का उपयोग करके बड़े एप्लिकेशन, जैसे ऑफिस, फ़ोटोशॉप, या नेटस्केप नेविगेटर को लिखा गया था। Win32 एपीआई फ़ंक्शंस का एक बड़ा सेट है जो ग्राफिक्स और उपयोगकर्ता इंटरफ़ेस प्रदर्शित करने, नेटवर्क पर डेटा स्थानांतरित करने, फ़ाइल सिस्टम तक पहुंच, साथ ही कई अन्य कम स्पष्ट लोगों जैसे सुरक्षा प्रबंधन जैसे कम-स्तर तक पहुंच प्रदान करता है।

Win32 API ने बहुत सारे कार्य हल किए, लेकिन उनमें से कई सबसे अच्छे तरीके से नहीं थे, और उनमें से कुछ भी बिल्कुल नहीं थे। इसलिए, डेटाबेस तक पहुंचने के लिए कार्यों की उपलब्धता के बावजूद, एक एप्लिकेशन विकसित करना जो सक्रिय रूप से उनका उपयोग करता है, बहुत असुविधाजनक था। लेकिन एक बहुत अधिक जरूरी समस्या यह थी कि Win32 API में यूजर इंटरफेस बनाने के लिए केवल एक बुनियादी उपकरण था, और इसमें लेआउट को नियंत्रित करने के लिए कोई साधन नहीं था। प्रत्येक बटन, प्रत्येक क्षेत्र और टूलबार को मैन्युअल रूप से डेवलपर द्वारा तैनात किया जाना था। अगर डेवलपर चाहता था कि तत्वों की स्थिति खिड़की के आकार बदलने के साथ हो, तो बिना किसी समस्या के - उसे बस हर बदलाव के साथ उन्हें फिर से व्यवस्थित करना था। बेशक, समय के साथ, कई पुस्तकालय दिखाई दिए, जो प्रोग्रामर और ऑपरेटिंग सिस्टम के बीच एक परत के रूप में कार्य करते थे, इंटरफेस के प्रतिपादन को सरल करते हुए (माइक्रोसॉफ्ट एमएफसी लाइब्रेरी सहित), लेकिन Win32 जंगल में गोता लगाने की जरूरत है सब कुछ जिस तरह से आप की जरूरत है काम करने के लिए, गायब नहीं हुआ ।

विंडोज के लिए एप्लिकेशन विकसित करने का एक और तरीका विजुअल बेसिक था। उसके लिए धन्यवाद, कुछ कार्यों को वास्तव में बस हल किया गया था - विशेष रूप से, डेटाबेस तक पहुंच और उपयोगकर्ता इंटरफेस बनाना - जिसने विज़ुअल बेसिक को उद्यम अनुप्रयोगों की दुनिया में राजा बना दिया, जिसे डेटाबेस से जानकारी लेने, उपयोगकर्ता को दिखाने और प्रवेश करने के लिए फ़ॉर्म प्रदर्शित करने की तुलना में थोड़ी अधिक आवश्यकता थी। डेटाबेस में नया डेटा। विजुअल बेसिक ने यह सब निर्दोष तरीके से संभाला। विजुअल बेसिक कई Win32 सुविधाओं का उपयोग नहीं कर सकता था, क्योंकि उसे बाकी सब समस्याओं की समस्या थी। इसके अलावा, विज़ुअल बेसिक ने लोकप्रिय ओओपी प्रतिमान का समर्थन नहीं किया।

और फिर .NET प्लेटफ़ॉर्म दिखाई दिया और सब कुछ बदल गया। .NET ने डेवलपर्स को विजुअल बेसिक का उपयोग करने में आसानी दी, लेकिन इसके अप्रिय कमियों के बिना। विज़ुअल बेसिक की तरह, .NET ने उपयोगकर्ता इंटरफेस बनाने और डेटाबेस के साथ बातचीत करने के लिए सुविधाजनक उपकरण प्रदान किए, अर्थात, यह एंटरप्राइज़ अनुप्रयोगों को विकसित करने के लिए अत्यधिक उपयुक्त था। लेकिन, Visual Basic के विपरीत, .NET ने भी Win32 को सरल, अजीब, इसके कार्यों में से एक बना दिया। प्लेटफॉर्म ने कॉर्पोरेट वातावरण में तेजी से गति प्राप्त की, और कई नई वाणिज्यिक परियोजनाएं इस पर आधारित थीं।

लोंगहॉर्न नाम का एक सपना

.NET के आगमन से एक साल पहले जारी किए गए Windows XP ने, निश्चित रूप से इस तकनीक का उपयोग नहीं किया। लेकिन, अक्टूबर 2003 में पीडीसी में, माइक्रोसॉफ्ट ने विंडोज लॉन्गहॉर्न को जारी करके इसे ठीक करने का वादा किया। ऑपरेटिंग सिस्टम के कर्नेल के हिस्से के रूप में विंडोज के इस संस्करण में .NET FX (जैसा कि .NET को कंपनी के अंदर कहा जाता था) होना चाहिए था, और .NET FX ने नए WinFX प्लेटफॉर्म - विंडोज फ्रेमवर्क के लिए रास्ता दिया। अन्य बातों के अलावा, WinFX ने अवलॉन नामक वेक्टर स्केलेबल हार्डवेयर-त्वरित उपयोगकर्ता इंटरफ़ेस विकसित करने का एक बिल्कुल नया तरीका शामिल किया। विंडोज को स्वयं अपने अनुप्रयोगों में WinFX का उपयोग करके लिखा जाना चाहिए, जैसे कि एक्सप्लोरर, कैलकुलेटर, और इसी तरह, और .NET को विंडोज के लिए एप्लिकेशन बनाने का मुख्य साधन बनना था। Win32 को पिछड़े संगतता के लिए छोड़ दिया जाएगा, लेकिन जमे हुए और भूल गए।

लोंगहार्न को कार्यक्रमों के पुराने तरीकों को दफनाने और आधुनिक विकास के एक नए युग की शुरुआत करना था, न कि दस से पंद्रह साल पहले के वास्तुशिल्प फैसलों पर बोझ।
जैसा कि हम सभी जानते हैं कि लोंगहॉर्न ने कभी दिन की रोशनी नहीं देखी। परियोजना कुछ विशाल और बेकाबू हो गई है। उसी समय, विंडोज एक्सपी, जिस पर लॉन्गहॉर्न आधारित था, हमलावरों द्वारा हमला करना शुरू कर दिया, और माइक्रोसॉफ्ट ने विंडोज एक्सपी और विंडोज सर्वर 2003 की सुरक्षा को मजबूत करने का लक्ष्य रखा, जिसके परिणामस्वरूप विंडोज एक्सपी सर्विस पैक 2 और विंडोज सेवर 2003 सर्विस पैक 1 और फिर पुराने सिद्धांतों पर आधारित और अब विंडोज विस्टा के नाम से जाना जाने वाला अगला ऑपरेटिंग सिस्टम विकसित करना शुरू कर दिया है।

विंडोज डेवलपमेंट के दौरान बदलाव का एक मुख्य शिकार .NET था। विंडोज विस्टा, हालांकि इसमें कुछ मौलिक परिवर्तन थे, पूरे WinFX अवधारणा को पीछे छोड़ दिया। एवलॉन (जिसे विंडोज प्रेजेंटेशन फ्रेमवर्क - डब्ल्यूपीएफ कहा जाता है) सिस्टम में शामिल था, लेकिन कर्नेल का हिस्सा नहीं था। विंडोज विस्टा और विंडोज 7 में केवल महत्वपूर्ण .NET कोड वाहक मीडिया सेंटर है (और यहां तक ​​कि यह WPF का उपयोग नहीं करता है)। बाकी सब कुछ अच्छा पुराने Win32, इसके अलावा, अद्यतन और विस्तारित है। इसमें कई निम्न-स्तरीय फ़ंक्शंस जोड़े गए, साथ ही ग्राफिक्स सिस्टम में बदलाव के लिए समर्थन, जैसे टास्कबार या एयरो ग्लास थीम पर रनिंग एप्लिकेशन के थंबनेल। इनमें से किसी भी बदलाव ने WPF के साथ काम नहीं किया।
इसके कई कारण थे, उदाहरण के लिए, .NET का उपयोग करके सब कुछ फिर से लिखने के लिए आवश्यक मात्रा में समय की कमी। लेकिन शायद अधिक महत्वपूर्ण कारण समूहों में माइक्रोसॉफ्ट का आंतरिक विभाजन था।

विंडोज को विंडोज डिवीजन (WinDiv) समूह में विकसित किया गया था, और .NET डेवलपर डिवीजन (DevDiv) समूह में विकसित किया गया था, जो बदले में सर्वर और टूल्स बिजनेस ग्रुप का हिस्सा था। और यद्यपि यह मानना ​​तर्कसंगत है कि इन दो समूहों ने संगीत कार्यक्रम में अभिनय किया, ऐसा नहीं था। किसी की दुर्भावना से नहीं - उनकी बस अलग प्राथमिकताएँ थीं।

वोल्टेज बिंदु

इन प्राथमिकताओं में से कुछ ने उस समय कुछ समझ बनाई। तो, WPF का उपयोग केवल C # या Visual Basic.NET में लिखे .NET प्रोग्राम द्वारा किया जा सकता है। इसकी संपूर्ण एपीआई C ++ में लिखे गए कार्यक्रमों के लिए दुर्गम थी, जो मौजूदा अनुप्रयोगों को WPF में पोर्ट करने के लिए एक महत्वपूर्ण बाधा थी। यह समझ में आया कि यदि .NET प्लेटफॉर्म का उपयोग करके सभी नए प्रोग्राम विकसित किए जाने थे, लेकिन जब योजनाएं बदल गईं और Win32 ने मुख्य विकास उपकरण का शीर्षक वापस हासिल कर लिया, तो यह एक बड़ी समस्या बन गई। Microsoft अपने मुख्य अनुप्रयोगों में सुरुचिपूर्ण वेक्टर स्केलेबल हार्डवेयर-त्वरित इंटरफेस बनाने के लिए WPF का उपयोग नहीं कर सका।

अन्य प्राथमिकताएं WinDiv और DevDiv की गतिविधि के क्षेत्रों के बीच एक भोज विसंगति का परिणाम थीं। DevDiv का लक्ष्य नई कार्यक्षमता को जोड़कर और सिल्वरलाइट जैसे पुस्तकालयों और उपकरणों को बनाकर डेवलपर्स के लिए .NET को सबसे सुविधाजनक मंच बनाना था। WinDiv के लिए, उपरोक्त पिछड़ी अनुकूलता, विश्वसनीयता, साथ ही साथ मौजूदा तकनीकी विफलताओं को बनाए रखना महत्वपूर्ण था। दोनों, और एक अन्य, निश्चित रूप से, महत्वपूर्ण था, लेकिन देवदिव ने विनडिव को प्रस्तुत नहीं किया और इस पर ध्यान नहीं दिया। नतीजतन, WinDiv .NET के साथ काम करने में सहज नहीं था, और इसके बिना काम करना सुविधाजनक था।

बाद में .NET अद्यतन ने स्थिति में सुधार किया, लेकिन नुकसान पहले ही हो चुका था। WinDiv, DevDiv के काम से असंतुष्ट, उनके काम को नजरअंदाज कर दिया, और विंडोज 7, अपने पूर्ववर्ती की तरह, केवल मीडिया सेंटर के लिए .NET का उपयोग करता है। सभी नए विंडोज 7 एपीआई क्लासिक Win32 एपीआई हैं और .NET प्रोग्रामों तक सीधी पहुंच नहीं है, और नियमित रूप से Win32 अनुप्रयोगों को उपयोगकर्ता इंटरफेस के निर्माण के लिए एक अद्भुत ढांचा नहीं मिला है।

विंडोज 8 यह सब खत्म कर देगा।

पुनश्च। यह अनुवाद का पहला भाग था, और andrewpey के अनुरोध पर प्रकाशित हुआ। आमंत्रित करने के लिए टूटूफा का धन्यवाद।

अद्यतन।
अनुवाद का दूसरा भाग यहाँ है

अनुवादक से: यह समझा जाना चाहिए कि उपरोक्त सभी जानकारी केवल लेखक द्वारा Microsoft से असंबंधित होने की अटकलें हैं, और यहां केवल विंडोज के सामने आने वाली समस्याओं को समझने के लिए प्रस्तुत किया गया है।