विंडोज रनटाइम सिस्टम और सीएलआर इंटरेक्शन टाइप करें

विंडोज 8 की रिलीज के साथ, डेवलपर्स के पास एक नए वर्ग के पुस्तकालय तक पहुंच है - विंडोज रनटाइम। WinRT घटकों का उपयोग विंडोज स्टोर और डेस्कटॉप अनुप्रयोगों में किया जा सकता है; अनवांटेड C / C ++ कोड, जावास्क्रिप्ट में, और C # और विजुअल बेसिक में भी।

विंडोज रनटाइम मेटाडेटा

आंतरिक रूप से, WinRT घटक COM (घटक ऑब्जेक्ट मॉडल) घटक हैं, जो मेटाडेटा अब एपीआई का वर्णन करने के लिए उपयोग किया जाता है। यह मेटाडेटा * .winmd एक्सटेंशन के साथ फाइलों में संग्रहीत है और .NET मेटाडेटा के एक अद्यतन संस्करण का प्रतिनिधित्व करता है, जो ECMA-335 मानक की धारा 2 (मेटाडेटा परिभाषा और शब्दार्थ) के नियमों के अनुसार एन्कोडेड है। चूंकि सामान्य .NET फ्रेमवर्क असेंबलियों को एक ही मानक का उपयोग करके एन्कोड किया गया है, इससे यह पता चलता है कि आप इन फ़ाइलों की सामग्री को देखने के लिए परिचित टूल (जैसे ildasm.exe , ऑब्जेक्ट ब्राउज़र) का उपयोग कर सकते हैं।
अधिकांश भाग के लिए, WinMD फ़ाइल को ildasm.exe सुविधा के साथ देखना मानक प्रबंधित असेंबली को देखने के समान है। कई अंतर हैं जो दिखाई दे सकते हैं - मुख्य रूप से कि WinMD फाइलें, सामान्य रूप से, किसी भी मध्यवर्ती भाषा (IL) के निर्देश नहीं होते हैं। इसके बजाय, ये फाइलें विंडोज रनटाइम द्वारा प्रदान किए गए एपीआई का वर्णन करती हैं। इन इंटरफेस के कार्यान्वयन को उनकी परिभाषा से पूरी तरह से अलग किया जा सकता है, और वास्तव में, मशीन कोड में लिखा जा सकता है। हालांकि, प्रबंधित अनुप्रयोगों के डेवलपर्स के लिए, WinRT API का कार्यान्वयन विवरण अप्रासंगिक है, क्योंकि प्रबंधित कोड को केवल एपीआई परिभाषाएं देखनी चाहिए जो इसे कॉल करती हैं। दृश्यों के पीछे, कॉमन लैंग्वेज रनटाइम (सीएलआर) और विंडोज ऑपरेटिंग सिस्टम आपके लिए एपीआई परिभाषा और उनके कार्यान्वयन को जोड़ते हैं।

उदाहरण के लिए, Windows.Foundation.winmd मेटाडेटा फ़ाइल (% WinDir% \ System32 \ WinMetadata निर्देशिका में स्थित) में आप निम्न प्रकार की Windows.Foundation.Collections.ProperadSet पा सकते हैं, जिसके निर्माता के पास कोई निकाय नहीं है, क्योंकि यह प्रकार मूल कोड में लागू होता है।



हालांकि, मेटाडेटा जो इस प्रकार का वर्णन करता है, वह सीएलआर को एक कार्यान्वयन उदाहरण प्राप्त करने की अनुमति देता है, जब क्लास कंस्ट्रक्टर को बुलाया जाता है।
जब विंडोज रनटाइम मेटाडेटा को देखते हैं, तो आप यह भी नोटिस कर सकते हैं कि टाइप और असेंबली परिभाषाएँ नए विंडोज़रंटाइम कीवर्ड का उपयोग करती हैं।



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

WinRT कंपोनेंट्स के साथ CLR इंटरेक्शन

CRL, Runtime Callable Wrapper (RCW) और COM Callable Wrapper (CCW) रैपर के माध्यम से COM घटकों के साथ सहभागिता का समर्थन करता है। इस प्रकार, सीएलआर में, एक WinRT ऑब्जेक्ट का लिंक RCW के लिए एक लिंक है, जिसमें बदले में एक WinRT ऑब्जेक्ट का लिंक होता है। तदनुसार, प्रबंधित कोड RCW के साथ इंटरैक्ट करता है, जो अनिवार्य रूप से आपके कोड और WinRT ऑब्जेक्ट के बीच का इंटरफ़ेस है।



इसी तरह, विंडोज रनटाइम में, सीएलआर ऑब्जेक्ट का लिंक सीसीडब्ल्यू के लिए एक लिंक है, जिसमें बदले में सीएलआर ऑब्जेक्ट का लिंक होता है। Windows रनटाइम प्रबंधित इकाई की कार्यक्षमता तक पहुँचने के लिए CCW के साथ सहभागिता करता है।

WinRT प्रकार और प्रबंधित कोड

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

• मुख्य डेटा प्रकार जो मेटाडाटा में एन्कोड किए गए हैं, उसी एलांस्टिवाईपीई इन्यूमेंट का उपयोग करके प्रबंधित असेंबली में। एक अपवाद SByte प्रकार है, जो WinRT में समर्थित नहीं है।
• अनुमानित प्रकार (मैप किए गए प्रकार) , जो WinMD फ़ाइलों में एक प्रकार के रूप में एन्कोडेड हैं, लेकिन प्रबंधित कोड में उनके .NET समकक्ष के रूप में दिखाई देते हैं। उदाहरण के लिए, जब CLR Windows.Foundation.Uri को मेटाडेटा में पढ़ता है, यह इसके बजाय System.Uri प्रकार का उपयोग करता है। अर्थात्, CLR WinRT प्रकार को छुपाता है और दूसरे प्रकार के माध्यम से उस तक पहुँच प्रदान करता है। इसके अलावा, CLR प्रबंधित और अनवांटेड कोड के बीच का प्रकार बताता है, जो आपको Windows.oundation.Uri के रूप में System.Uri ऑब्जेक्ट को Windows रनटाइम में स्थानांतरित करने की अनुमति देता है। WinRT प्रकारों की एक पूरी सूची जो FCL प्रकारों पर CLR परियोजनाओं को मिल सकती है ।
• अन्य सभी प्रकार । WinRT एपीआई प्रकार के विशाल बहुमत के रूप में .NET डेवलपर्स को प्रदान किए जाते हैं। उदाहरण के लिए, यदि आप Windows.UI.Xaml.Controls.Button वर्ग का उपयोग करते हैं, तो CLR इस प्रकार का एक विशेष दृश्य या मार्शलिंग प्रदान नहीं करता है। जिस प्रकार के लिए सीएलआर विस्तार के तरीके प्रदान करता है उसे भी इस श्रेणी में शामिल किया गया है। उदाहरण के लिए, .NET फ्रेमवर्क वर्ग के साथ Windows.Storage.IInputStream के WinRT इंटरफ़ेस को लागू करने वाली एक वस्तु का उपयोग करने के लिए, जिसे System.IO.Stream से प्राप्त एक प्रकार की आवश्यकता होती है, आपको सिस्टम विधानसभा में परिभाषित एक्सटेंशन विधियों का उपयोग करना होगा। Runtime.WindowsRuntime.dll।

दिलचस्प है, अभी भी प्रकारों की एक छोटी श्रेणी है जो कि विंडोज मेटाडेटा एन्कोडिंग में गैर-आवश्यक स्थानों पर दिखाई देती है। ये .NET फ्रेमवर्क प्रकार हैं जिनका उपयोग केवल WinRT प्रकारों का वर्णन करने के लिए किया जाता है। उदाहरण के लिए, विंडोज रनटाइम प्रतिनिधियों को आधार प्रकार System.MulticastDelegate के साथ एन्कोड किया गया है, लेकिन इसका मतलब यह नहीं है कि सभी विंडोज रनटाइम प्रतिनिधियों को प्रबंधित कोड से लिया गया है। इसके बजाय, आधार प्रकार केवल एक मेटाडेटा टोकन के रूप में उपयोग किया जाता है ताकि यह इंगित किया जा सके कि प्रकार एक प्रतिनिधि प्रकार है।

प्रकार प्रक्षेपण

जब CLR प्रोजेक्ट (प्रदर्शित) WinRT टाइप करता है, तो यह दो ऑपरेशन करता है:

• सीएलआर निजी के रूप में विंडोज रनटाइम प्रकार को परिभाषित करता है, सार्वजनिक नहीं। यह स्रोत प्रकार को प्रबंधित कोड के लिए दृश्यमान होने से रोकता है। यानी प्रबंधित कोड के संदर्भ में, मौजूद एकमात्र प्रकार .NET फ्रेमवर्क प्रकार है, जो मैपिंग का लक्ष्य है।
• स्रोत प्रकार के सभी संदर्भ लक्ष्य .NET फ्रेमवर्क प्रकार के संदर्भ में बदल दिए जाते हैं।

तो, सीएलआर आईवीएस <टी> के रूप में आईवीकेटर <टी> इंटरफेस का प्रतिनिधित्व करता है, आईवीएस <टी> सीएलआर की प्रकार परिभाषा को निजी दायरे के साथ एक प्रकार की परिभाषा के रूप में माना जाता है, लेकिन जनता के साथ नहीं। इसी प्रकार, आईवीआरएक्सएक्सएलएल.कंट्रोलs.यूइमेंटमेंटकॉलक्शन प्रकार, जो आईवीएक्टर <UIElement> को लागू करता है, सीएलआर द्वारा अद्यतन किया जाता है। IVector <T> इंटरफ़ेस के कार्यान्वयन को IList <T> पर पुनर्निर्देशित किया गया है ताकि प्रबंधित कोड में UIElementCollection IList <UIElement> इंटरफ़ेस को लागू करे।
आमतौर पर, ildasm.exe किसी भी रीडायरेक्ट को शामिल किए बिना WinMD फ़ाइल का एक कच्चा प्रतिनिधित्व प्रदर्शित करता है। पुनर्निर्देशित सक्षम के साथ एक WinMD फ़ाइल की सामग्री को देखने के लिए, आपको / प्रोजेक्ट विकल्प को निर्दिष्ट करना होगा। यह विकल्प आपको यह देखने की अनुमति देता है कि सीएलआर डिस्क पर मेटाडेटा कैसे प्रदर्शित करता है।

आधार प्रकार

WinRT घटकों में एक सामान्य आधार वर्ग नहीं है, हालांकि, सभी विंडोज रनटाइम वर्गों को IInspectable इंटरफ़ेस को लागू करना चाहिए, जो बदले में IUnogn इंटरफ़ेस (जो आश्चर्य की बात नहीं है) से विरासत में मिला है। हालाँकि, .NET डेवलपर्स के लिए, सभी WinRT प्रकार System.Object से प्राप्त किए गए प्रकारों के अनुसार दिखते हैं और तदनुसार विरासत, GetHashCode , इत्यादि जैसे विरासत के तरीके। यह संभव है क्योंकि CLR मार्शल्स WinRT और .NET विचारों के बीच प्रकार परिवर्तित करने के लिए रन टाइम पर ऑब्जेक्ट करता है।

संरचना

WinRT संरचना, महत्वपूर्ण CLR प्रकारों के विपरीत, इसमें मूल प्रकारों में से केवल एक के खुले क्षेत्र हो सकते हैं या किसी अन्य WinRT संरचना हो सकते हैं। इस प्रकार, निम्नलिखित कोड संकलन चरण में एक त्रुटि फेंक देगा:

public struct MyStruct { // 'MyStruct' contains non-public field 'MyStruct.i'. // Windows Runtime structures can contain only public fields. private Int32 i; //Windows Runtime structures can contain only fields. public MyStruct(Int32 i) { this.i = i; } //Windows Runtime structures can contain only fields. public void MyFunc() { } } 

इसके अलावा, WinRT संरचनाएं कंस्ट्रक्टर को परिभाषित नहीं कर सकती हैं या सहायक तरीके नहीं रख सकती हैं। हालांकि, सुविधा के लिए, कुछ सीएलआर संरचनाओं को अपने दम पर पेश किया जाता है, जिससे डेवलपर्स को सहायक तरीके और निर्माणकर्ता प्रदान करते हैं। इनमें शामिल हैं, उदाहरण के लिए, Windows.Foundation.Point की संरचना, Windows.Foundation.Size, और Windows.Foundation.Rect ।

पंक्तियां

WinRT में System.String प्रकार को HSTRING के रूप में दर्शाया गया है । जब आप विंडोज रनटाइम विधि कहते हैं, तो CLR विधि को कॉल करने से पहले किसी भी .NET फ्रेमवर्क स्ट्रिंग को HSTRING में परिवर्तित करता है। इसी तरह, CLR रनटाइम विधि से लौटी किसी भी पंक्तियों को System.String प्रकार में परिवर्तित करता है। एक और विशेषता है - WinRT प्रकार प्रणाली तारों को शून्य होने की अनुमति नहीं देती है। अशक्त के बजाय, String.Empty का उपयोग एक रिक्त स्ट्रिंग को पारित करने के लिए किया जाना चाहिए। जब WinRT फ़ंक्शन को स्ट्रिंग के रूप में नल पास करने की कोशिश कर रहा है, तो CLR एक ArgumentNullException को फेंक देगा। इसी तरह, आप कभी नहीं देखेंगे कि एक WinRT फ़ंक्शन एक नल स्ट्रिंग वापस कर सकता है, यह केवल एक खाली स्ट्रिंग हो सकता है।

अशक्त संगत प्रकार

WinRT API एक अशक्त-महत्वपूर्ण महत्वपूर्ण प्रकार को परिभाषित करने के लिए Windows.Foundation.IReference <T> इंटरफ़ेस का उपयोग करता है, जो CLR अपने सिस्टम पर प्रोजेक्ट करता है। Nullable <T> । उदाहरण के लिए, अगर WinMD फ़ाइल में विधि में निम्नलिखित हस्ताक्षर हैं:

 IReference<bool> Method(IReference<int> i); 

तब प्रबंधित कोड में यह विधि इस तरह दिखाई देगी:

 Nullable<bool> Method(Nullable<int> i); 

प्रतिनिधियों

केवल WinRT- संगत प्रकार पैरामीटर प्रकार या प्रतिनिधि के वापसी मान के रूप में WinRT का उपयोग कर सकते हैं। साथ ही, एक वैश्विक (सार्वजनिक) गुंजाइश वाले प्रतिनिधियों को नेस्टेड के रूप में घोषित नहीं किया जा सकता है (वास्तव में, ये विंडोज रनटाइम के लिए सामान्य नियम हैं)। जब आप Windows रनटाइम घटक के लिए एक प्रतिनिधि ऑब्जेक्ट पास करते हैं, तो यह ऑब्जेक्ट CCW आवरण में लपेटी जाती है जो तब तक कचरा संग्रहकर्ता द्वारा नष्ट नहीं किया जाता है जब तक कि इसका उपयोग करने वाले घटक द्वारा मुक्त नहीं किया जाता है। एक और दिलचस्प तथ्य यह है कि WinRT प्रतिनिधियों के पास BeginInvoke और EndInvoke तरीके नहीं हैं।

घटनाओं

WinRT घटक केवल WinRT प्रतिनिधि प्रकार का उपयोग करके घटनाओं को परिभाषित कर सकते हैं। एक Windows.Foundation.EventHandler <T> प्रतिनिधि प्रकार है जो CLR .NET .NET फ्रेमवर्क सिस्टम के लिए मैप करता है। EventHandler <TEventArgs> प्रतिनिधि प्रकार। जब आप एक घटना के सदस्य को परिभाषित करते हैं:

 public event EventHandler<RoutedEventArgs> MyEvent; 

फिर जब कोड की इस लाइन को कंपाइल करते हैं, तो कंपाइलर इसे निम्न निर्देशों में बदल देता है:

 private EventRegistrationTokenTable<EventHandler<RoutedEventArgs>> MyEvent; public EventRegistrationToken add_MyEvent(EventHandler<RoutedEventArgs> handler) { return EventRegistrationTokenTable<EventHandler<RoutedEventArgs>> .GetOrCreateEventRegistrationTokenTable(ref MyEvent) .AddEventHandler(handler); } public void remove_MyEvent(EventRegistrationToken token) { EventRegistrationTokenTable<EventHandler<RoutedEventArgs>> .GetOrCreateEventRegistrationTokenTable(ref MyEvent) .RemoveEventHandler(token); } 

पहले की तरह, कंपाइलर एक निजी क्षेत्र और घटना से पंजीकरण और सदस्यता समाप्त करने के लिए दो एक्सेसर विधि बनाता है। हालाँकि, इन विधियों के क्षेत्र और सामग्री का प्रकार हम ( Delegate.Combine और Delegate.Remove ) के लिए उपयोग किए जाने वाले से अलग है। सामान्यीकृत श्रेणी EventRegistrationTokenTable <T> का उपयोग फ़ील्ड प्रकार के रूप में किया जाता है, जिसका प्रकार तर्क संगत प्रतिनिधि प्रकार है। यह वर्ग उन प्रतिनिधियों की श्रृंखला को संग्रहीत करने के लिए जिम्मेदार है जो घटना संचालकों का प्रतिनिधित्व करते हैं। नया हैंडलर जोड़ने पर, EventRegistrationToken टोकन वापस आ जाता है , जिसे बाद में इवेंट हैंडलर को निकालने के लिए उपयोग किया जा सकता है।

 public void RaiseEvent() { var list = EventRegistrationTokenTable<EventHandler<RoutedEventArgs>> .GetOrCreateEventRegistrationTokenTable(ref MyEvent) .InvocationList; if (list != null) list(this, new RoutedEventArgs()); } public void Main() { var myClass = new MyClass(); var token = myClass.add_MyEvent(Handler); myClass.RaiseEvent(); myClass.remove_MyEvent(token); myClass.RaiseEvent(); } private void Handler(object sender, RoutedEventArgs args) { Debug.WriteLine("event handling"); } 

किसी ईवेंट को बढ़ाने के लिए, InvocationList प्रॉपर्टी का उपयोग करें, जो एक प्रतिनिधि को लौटाता है जिसकी कॉल सूची में ईवेंट हैंडलर के रूप में जोड़े गए सभी प्रतिनिधि शामिल हैं।

समय और तारीख

WinRT में, Windows.Foundation.DateTime संरचना द्वारा UTC में समय और दिनांक का प्रतिनिधित्व किया जाता है। CLR इस प्रकार को System.DateTimeOffset स्ट्रक्चर में मैप करता है, System.DateTime को नहीं। यह ध्यान देने योग्य है कि DateTime में समय क्षेत्र की जानकारी नहीं है। इसलिए, UTC प्रारूप में WinRT फ़ंक्शन द्वारा दी गई तारीख और समय CLR द्वारा स्थानीय समय में परिवर्तित किया जाता है। इसके विपरीत, WinRT फ़ंक्शन के लिए DateTimeOffset संरचना को पास करते समय , दिनांक और समय को UTC प्रारूप में बदल दिया जाता है।

सरणियों

WinRT एपीआई केवल एक आयामी सरणियों का समर्थन करता है। तदनुसार, निम्नलिखित कोड एक संकलन-समय त्रुटि का कारण होगा:

 // Arrays in Windows Runtime method signatures must be one dimensional. public int[,] MyFunc() { return new int[5, 5]; } 

प्रबंधित कोड में, सरणियों को संदर्भ द्वारा पारित किया जाता है, और सरणी के तत्वों में परिवर्तन किसी भी कोड को दिखाई देगा, जिसका इस सरणी के उदाहरण से लिंक है। हालाँकि, WinRT के लिए यह हमेशा ऐसा नहीं होता है, क्योंकि सरणी की सामग्री को केवल उसी दिशा में मार्श किया जाता है, जिसमें API System.Runtime.InteropServices.InAttribute और System.Runtime.InteropServices.OutAttribute का उपयोग करके अपने हस्ताक्षर में परिभाषित करता है। दोनों विशेषताएँ विधि मापदंडों या रिटर्न मानों पर लागू होती हैं और रन समय पर प्रबंधित और अप्रबंधित मेमोरी के बीच मार्शलों की दिशा निर्धारित करती हैं। विंडोज रनटाइम में, पैरामीटर या तो केवल [InAttribute] या केवल-लिखित [OutAttribute] और पढ़ने और लिखने के लिए चिह्नित नहीं किए जा सकते हैं [InAttribute], [OutAttribute]। इसका मतलब यह है कि सरणी की सामग्री विधि के साथ-साथ सरणी के लिए ही पारित की गई है, इसे अवश्य पढ़ा या लिखा जाना चाहिए। इसलिए, सरणी की सामग्री, जिसे [InAttribute] विशेषता के साथ चिह्नित किया गया है, उसे तथाकथित विधि में कॉपी किया जाता है, इसलिए सरणी पर लागू होने वाले सभी परिवर्तन कॉलिंग ऑब्जेक्ट के लिए दृश्यमान नहीं हैं। इसी प्रकार, एक सरणी की सामग्री जिसे [आउटऑटवर्ट] विशेषता के रूप में चिह्नित किया जाता है, उसे तथाकथित विधि द्वारा सेट किया जाता है और कॉलिंग ऑब्जेक्ट में कॉपी किया जाता है, इसलिए इस विधि को मूल सरणी की सामग्री के बारे में कोई धारणा नहीं बनाना चाहिए।

संग्रह

एक संग्रह को स्थानांतरित करते समय, CLR संग्रह वस्तु को CCW आवरण में पैक करता है और WinRT API में लिंक को पास करता है। उसी समय, आवरण के माध्यम से कॉल बातचीत की सीमा को पार करते हैं, जो उत्पादकता को नकारात्मक रूप से प्रभावित करता है। हालांकि, सरणियों के विपरीत, तत्वों की नकल के बिना संचालन किया जा सकता है।

निष्कर्ष

सारांशित करते हुए, मैं ध्यान देता हूं कि सीएलआर में बदलाव के लिए धन्यवाद, प्रबंधित कोड डेवलपर्स आसानी से परिचित तकनीकों का उपयोग करके नए विंडोज रनटाइम एपीआई के लिए अनुकूलित कर सकते हैं। इस लेख में, मैंने WinRT और CLR की बातचीत के सभी विवरणों से दूर का वर्णन किया है। हालांकि, यह आगे के अध्ययन के लिए आधार और विंडोज रनटाइम की गहरी समझ प्रदान कर सकता है।