मुझे एक समस्या में भाग गया है, मुझे यकीन है कि मुझे जवाब पता है, लेकिन मुझे लगा कि मैं कम से कम पूछूंगा और देख सकता हूं कि कुछ "जादू बुलेट "जो मुझे एक बड़ा सिरदर्द बचा सकता है।32-बिट और 64-बिट पी/मिक्सिंग
यहां उच्च स्तरीय दृश्य है।
मेरे पास एक प्रबंधित एप्लिकेशन है। यह एप्लिकेशन विभिन्न विक्रेताओं से तीसरे पक्ष के पुस्तकालयों के माध्यम से हार्डवेयर के साथ इंटरफेस करता है। मेरा उपभोग करने वाले प्रबंधित ऐप और हार्डवेयर एपीआई पुस्तकालयों पर शून्य नियंत्रण पर पूर्ण नियंत्रण है।
विक्रेता ए केवल 32-बिट देशी एसडीके प्रदान करता है। 64-बिट सिस्टम पर इसका उपयोग करने की अनुमति देने के लिए, हमने एप्लिकेशन को 32-बिट मोड में चलाने के लिए चिह्नित किया। सब कुछ ठीक था।
अब हम विक्रेता बी के साथ एकीकृत कर रहे हैं, जो 64-बिट मशीनों पर 64-बिट-विशिष्ट देशी API पुस्तकालय प्रदान करता है। विक्रेता बी से 32-बिट देशी डीएलएल 64-बिट सिस्टम पर काम नहीं करेगा (कोशिश की गई)। यदि मैं 64-बिट या AnyCPU के रूप में चल रहे परीक्षण दोहन का निर्माण करता हूं, तो यह ठीक काम करता है। यदि मैं इसे 32-बिट के रूप में चिह्नित करता हूं, तो यह पी/आमंत्रण कॉल पर विफल रहता है।
ऐसा लगता है कि विक्रेता ए और विक्रेता बी हार्डवेयर 64-बिट पीसी पर पारस्परिक रूप से अनन्य होने जा रहे हैं, लेकिन मुझे आश्चर्य है कि अगर किसी के पास सुझाव है कि संभवतः उसके आसपास कैसे काम करना है।
हमने इसे पहले ही एनोथर ऐपडोमेन में अनुक्रमित कर दिया है, इसलिए सुरक्षा ठीक है। इसे एनोटेर प्रक्रिया में ले जाने से इंटरफेस जटिलता को जोड़ा जाता है जिसे हम टालने की उम्मीद कर रहे थे, लेकिन ऐसा लगता है कि विक्रेता ए के हार्डवेयर को छोड़ दिया गया है या छोड़ दिया गया है। – ctacke
यह अच्छा है कि आपको इसे किसी अन्य ऐपडोमेन में अनुक्रमित किया गया है। हालांकि एक ऐपडोमेन केवल प्रबंधित कोड घटकों के बीच सुरक्षा प्रदान करता है। अप्रबंधित कोड एक खराब पॉइंटर को आसानी से पकड़ सकता है और ऐपडोमेन के बावजूद पूरी प्रक्रिया मेमोरी स्पेस में कचरा फैलाना शुरू कर सकता है। आप मेमोरी मैप की गई फाइलों या इसी तरह की तकनीक के माध्यम से आईपीसी पर विचार करना चाहेंगे ताकि तीसरे पक्ष के घटक आपके ऐप पर कहर बरबाद न कर सकें। :) –