2011-01-25 9 views
8

पर 32 और 64 बिट इंटरऑपरेबिलिटी क्या कोई अच्छा गहन आधिकारिक संदर्भ है जो 32-बिट और 64-बिट प्रक्रियाओं के बीच अंतःक्रियाशीलता पर चर्चा करता है? गुगलिंग के आधार पर मैंने यह अनुमान लगाया है कि:64-बिट विंडोज

  1. एक 32-बिट डीएलएल केवल 32-बिट प्रक्रिया में रह सकता है, और केवल 64-बिट प्रक्रिया में 64-बिट डीएलएल हो सकता है।
  2. 32 और 64-बिट प्रक्रियाएं केवल नेटवर्क संचार जैसे कमजोर युग्मित संदेश सिस्टम का उपयोग करके संवाद कर सकती हैं, जिसका अर्थ है कि वे COM/DCOM का उपयोग करके संवाद कर सकते हैं।
  3. 32 और 64-बिट COM घटकों में अलग-अलग रजिस्ट्री प्रविष्टियां हैं। एक घटक आमतौर पर केवल दो में से एक में पंजीकृत होता है और आमतौर पर केवल दो दुनिया में से एक में देखा जाता है।
  4. एक 32-बिट प्रक्रिया केवल 64-बिट COM घटक के रूप में पंजीकृत कुछ बना सकती है यदि यह 64-बिट आमंत्रण ध्वज के साथ CoCreateInstance का उपयोग करती है, या (और मैं इस पर अनुमान लगा रहा हूं, क्या यह संभव है?) यदि 64 -बीबी घटक किसी भी तरह 32-बिट रजिस्ट्री में पंजीकृत है लेकिन हुड के तहत अभी भी प्रक्रिया 64-बिट प्रक्रिया के बाहर बनाया गया है, या यदि 32-बिट शेल COM घटक है जो 64-बिट घटक बनाता है और फिर रीडायरेक्ट करता है इसे बुलाओ?

यह सुझाव देता है कि: 1. 32-बिट एप्लिकेशन एक्सेल के 64-बिट संस्करण को चलाने के लिए GetObject का उपयोग नहीं कर सकता है? या यह कर सकते हैं? चल रहे ऑब्जेक्ट टेबल (आरओटी) 32-बिट 64-बिट मुद्दे के विरुद्ध 32 द्वारा कैसे प्रभावित किया जाता है? क्या 32-बिट प्रक्रिया Excel का एक उदाहरण बना सकती है यदि Office का केवल 64-बिट संस्करण स्थापित है? मुझे लगता है कि उत्तर "नहीं" होगा जब तक कि 32-बिट प्रक्रिया अपने CoCreateInstance कॉल में 64-बिट ध्वज का उपयोग नहीं करती है, या यदि Excel किसी भी तरह 32-बिट दुनिया में स्वयं पंजीकृत है?

क्या माइक्रोसॉफ्ट स्वचालित रूप से 32-बिट प्रक्रिया से CoCreateInstance रखने की तरह कुछ भी करता है 64-बिट रजिस्ट्री की जांच करता है और 32-बिट रजिस्ट्री में कोई पंजीकृत नहीं होने पर प्रक्रिया 64-बिट घटक से बाहर निकलने का प्रयास करता है? मैंने 64-बिट ऑफिस से कुछ रिलीज नोट्स देखे हैं जहां माइक्रोसॉफ्ट 32-बिट अनुप्रयोगों से 64-बिट एक्सेल तक काम करने के बारे में चेतावनी देता है, फिर भी मुझे एक उदाहरण पता है जहां यह काम करना प्रतीत होता है।

क्या इसके लिए कोई अच्छा तकनीकी तथ्यात्मक संदर्भ है?

उत्तर

5

यह CLSCTX के लिए MSDN Library docs में काफी अच्छी तरह से समझाया गया है। नियमों के बहुत सारे हैं, तो डिफ़ॉल्ट है:

न ग्राहक है और न ही सर्वर एक प्राथमिकता निर्दिष्ट करता है, तो:

  • कंप्यूटर कि सर्वर होस्ट करता चल रहा है Windows XP या विंडोज सर्वर 2003 के बिना सेवा पैक 1 (एसपी 1) या बाद में स्थापित, COM के 64-बिट संस्करण को उपलब्ध होने पर सर्वर को पसंद करेगा; अन्यथा यह सर्वर का 32-बिट संस्करण सक्रिय करेगा।

  • कंप्यूटर कि सर्वर होस्ट करता है विंडोज सर्वर SP1 के साथ 2003 या बाद में स्थापित चल रहा है, तो कॉम ग्राहक वास्तुकला के लिए सर्वर वास्तुकला बनाने का प्रयास करेगा। दूसरे शब्दों में, 32-बिट क्लाइंट के लिए, COM उपलब्ध होने पर 32-बिट सर्वर सक्रिय करेगा; अन्यथा यह सर्वर के के 64-बिट संस्करण को सक्रिय करेगा।64-बिट क्लाइंट के लिए, COM उपलब्ध होने पर 64-बिट सर्वर सक्रिय करेगा; अन्यथा यह को 32-बिट सर्वर सक्रिय करेगा।

चेक MSDN लेख यदि आप इस व्यवहार को ओवरराइड करना चाहते हैं।

+0

धन्यवाद, मैंने एमएसडीएन अनुभाग को कम करके आंका था। फिर यह आलेख क्यों http://www.dnjonline.com/article.aspx?id=jun07_access3264 एक 64-बिट COM wrapper बनाता है जो बस 32-बिट COM के साथ इंटरैक्ट करता है? यह अनावश्यक होना चाहिए, क्योंकि केवल 32-बिट COM घटक होने के कारण, 32 और 64-बिट दोनों दुनिया के समान रूप से उपयोग करने योग्य होना चाहिए जो कार्यों के उपयुक्त मार्शलिंग को मानते हैं? Http://blogs.technet.com/b/office2010/archive/2010/02/23/understanding-64-bit-office.aspx पर भी देखें, नीचे "आपको क्या पता होना चाहिए" जो असंगतताओं के बारे में चेतावनी देता है। क्यूं कर? –

+0

डीडीजे आलेख 32-बिट COM सर्वर को 64-बिट प्रक्रिया में काम करने पर केंद्रित है, रैपर 64-बिट होना चाहिए। कार्यालय आलेख * इन-प्रोसेस * COM सर्वर के लिए असंगतताओं के बारे में चेतावनी देता है। केवल आउट-ऑफ-प्रोसेस सर्वर ही अंतर को पुल कर सकते हैं। –

+2

पहली टिप्पणी में पहला लेख http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/ पर ले जाया गया है – AndrewS

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^