32 बिट ऐप से COM के माध्यम से x64 असेंबली को कॉल करना

Question

संक्षिप्त प्रश्न: क्या यह संभव है (निश्चित रूप से x64 ओएस पर)? यदि नहीं, तो क्यों?

मैं जब 86 में संकलित यह ठीक काम करता है एक्सेल 32.

के लिए एक सी # प्लगइन dll विकसित किया है।

जब x64 में संकलित किया गया तो COM कॉल विफल हो जाता है।

क्या मुझे एक्सेल के 64 बिट संस्करण की आवश्यकता है?

मैंने सोचा कि COM आर्किटेक्चर को संकलित करने के अज्ञेय थे और विभिन्न प्रौद्योगिकियों में विकसित डीएल के बीच संचार संभव बनाते थे और विभिन्न आर्किटेक्चर होते थे, लेकिन मुझे लगता है कि बाद वाला गलत है।

मुझे लगता है कि एक x64 बिट डीएल स्पष्ट रूप से 32-बिट ऐप से COM (या अन्य) के माध्यम से नहीं कहा जा सकता है।

Answer 1

COM दो प्रकार के सर्वर, इन-प्रोसेस और आउट-ऑफ-प्रोसेस का समर्थन करता है। कार्यालय एक्सटेंशन इन-प्रोसेस घटकों हैं, एक डीएलएल जो प्रक्रिया में लोड हो जाता है। 32-बिट प्रक्रियाओं के लिए एक कठिन नियम यह है कि वे 64-बिट डीएलएल लोड नहीं कर सकते हैं। और दूसरी तरफ। यह रजिस्ट्री द्वारा स्वयं लागू किया जाता है, 32-बिट प्रक्रिया 64-बिट COM सर्वर के लिए पंजीकरण जानकारी तक सीधे पहुंच नहीं सकती है। उन्हें एचकेएलएम/सॉफ्टवेयर/वाह 6432 नोड कुंजी पर रीडायरेक्ट किया जाता है। या दूसरे शब्दों में, वे भी गलत bitness के घटक नहीं देख सकते हैं।

आउट-ऑफ-प्रोसेस घटकों के पास उस प्रतिबंध नहीं है, वे अपनी प्रक्रिया में भाग लेते हैं। कॉम मार्शल को दो प्रक्रियाओं के बीच कॉल करता है जो आरपीसी और कागजात के अंतर के आधार पर कागजात का उपयोग करते हैं। 32-बिट होस्ट के साथ काम करने के लिए इन-प्रोसेस 64-बिट सर्वर प्राप्त करने का यह एक तरीका है, आप एक सरोगेट प्रक्रिया में घटक चला सकते हैं। यह चलना मुश्किल है और लगभग परेशानी के लायक नहीं है, प्रक्रिया कॉल से आवश्यक मार्शलिंग और संदर्भ स्विचिंग के कारण इन-प्रोसेस कॉल की तुलना में अधिक महंगा है। या तो थोड़ा महंगा नहीं, यह लगभग 10,000 गुना धीमा है, अधिकतर क्योंकि इन-प्रोसेस फ़ंक्शन कॉल बहुत तेज़ है। यह केवल 64-बिट प्रोग्राम के साथ काम कर रहे विरासत 32-बिट सर्वर को रखने के लिए उपयोग किया जाता है। COM + होस्टिंग को देखो यदि आप इसे आजमा देना चाहते हैं, तो मुझे इसके बारे में बहुत कुछ पता नहीं है।