क्या COM मृत है?

Question

डब्ल्यूसीएफ पर घटकों के विकास के लिए COM का उपयोग करते समय गहन फायदे क्या हैं ?? क्या कुछ ऐसा है जो COM के साथ किया जा सकता है और डब्ल्यूसीएफ के साथ नहीं ??

Answer 1

नहीं, यह अभी तक मर चुका नहीं है, लेकिन यह उसकी मृत्यु-बिस्तर पर है, यह निश्चित रूप से है। आप देखते हैं कि अभी भी कई विरासत प्रणालियों के लिए है जो COM का उपयोग/आवश्यकता है, जो हमें आश्वासन देता है कि यह हमारे साथ कुछ और वर्षों तक होगा, लेकिन लंबे समय तक नहीं।

डब्ल्यूसीएफ के लिए, कॉम के कुछ किनारे के मामले हो सकते हैं, और डब्ल्यूसीएफ नहीं कर सकता है, लेकिन अधिक महत्वपूर्ण बात यह है कि, और विरासत सामग्री से संबंधित, यह है कि लगभग हर भाषा के लिए COM बाइंडिंग्स आप रख सकते हैं एक खिड़कियां ढेर, लेकिन डब्ल्यूसीएफ बाइंडिंग अभी तक सभी के लिए तैयार नहीं हैं (भाषाएं)

Answer 2

इस प्रणाली पर कितना गहराई है कि आप खोदना चाहते हैं। COM कभी भी 'मर' नहीं होगा, जैसा कि अप्रबंधित भाषाओं कभी नहीं होगा।

लंबी कहानी कम करने के लिए, यदि आप Vista + के लिए डेस्कटॉप एप्लिकेशन विकसित करते हैं, तो आपको शायद COM का उपयोग करके परेशान करने की आवश्यकता नहीं होगी।

Answer 3

यदि मुझे गलत नहीं है, तो .NET का उद्देश्य COM और WFC जैसे तकनीक को प्रतिस्थापित करना है। क्या कोई कारण है (विरासत कोड के अलावा) कि कोई COM या WFC को .NET पर चुना होगा?

Answer 4

मुझे नहीं लगता कि COM मर चुका है। यदि आप विस्टा को देखते हैं, तो यह COM आर्किटेक्चर/तकनीक का उपयोग करता है। Vista में हर चीज एक COM Dll/Exe है। मुझे लगता है कि XP ​​की तुलना में, Vista बहुत अधिक COM का उपयोग करता है।

यदि हम Vista में किसी भी चीज को विस्तारित करना चाहते हैं तो हमें COM का उपयोग करके इंटरफेस को कार्यान्वित करना होगा।

Answer 5

वहाँ कई अलग पहलू हैं:

1. अवयव उस पर चलाने के लिए और कई कंप्यूटरों के साथ बातचीत (सेवाएं)
2. अवयव कि केवल स्थानीय रूप से चलाने के लिए, और एक ABI के माध्यम से कई विक्रेताओं द्वारा कार्यान्वित घटकों के साथ बातचीत करेंगे ।
3. घटक जो एक विक्रेता द्वारा तीसरे पक्ष के घटकों के साथ बातचीत करने की आवश्यकता के बिना लिखे गए हैं।
4. स्रोत कोड में उपलब्ध कई विक्रेताओं के घटक, जिन्हें एक ही एप्लिकेशन में संकलित किया जा सकता है।

(एबीआई = आवेदन द्विआधारी इंटरफ़ेस। कॉम एक ABI का एक उदाहरण है।)

पहलू 1 के लिए, COM काफी मर चुका है।

पहलू 2 को अभी भी COM की आवश्यकता है, और जारी रहेगा। विंडोज इमेजिंग घटक इस तरह की विस्तारशीलता का एक बड़ा उदाहरण है जिससे किसी को भी नई छवि कोडेक्स लागू करने की इजाजत मिलती है। नेट इस पहलू में एक मजबूत दावेदार है।

पहलू 3 के लिए, COM अभी भी विचार करने योग्य है, लेकिन यह प्रत्येक सॉफ़्टवेयर विक्रेता के लिए निर्णय लेने का निर्णय है। इन-हाउस उपयोग के लिए घटक डेवलपर एक दिन उत्पाद के रूप में बेचा जा सकता है। नेट यहाँ भी एक अच्छा विकल्प प्रतीत होता है।

पहलू 4 के लिए, कोई भी कई ओपन-सोर्स प्रोजेक्ट्स से स्रोत कोड को अनुकूलित और संयोजित कर सकता है। COM, या किसी भी एबीआई की कोई आवश्यकता नहीं है।

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

Answer 6

COM मर चुका है, लंबे समय तक COM रहते हैं।

विंडोज 8 एक दिलचस्प वक्र का पालन करता है।

http://kennykerr.ca/2011/10/18/the-road-to-windows-8/

http://msdn.microsoft.com/en-us/library/windows/apps/hh699871.aspx