32 बिट एप्लिकेशन में 64 बिट लाइब्रेरी काम कर सकता है? उदाहरण के लिए, मेरा आवेदन जीयूआई 32 बिट क्यूटी का उपयोग करता है। और मेरा बिजनेस कोर 64 बिट लाइब्रेरी है। ओएस 64 बिट है। क्या वे एक साथ काम कर सकते हैं और कैसे? धन्यवाद।32 बिट और 64 बिट एक साथ काम कर सकते हैं?
संक्षेप में: आप 32-बिट ऐप को 64-बिट लाइब्रेरी से लिंक नहीं कर सकते हैं।
आप 64-बिट ओएस पर 32-बिट साझा पुस्तकालयों का उपयोग करके 32-बिट एप्लिकेशन चला सकते हैं (कम से कम सभी लोकप्रिय 32-/64-बिट प्रोसेसर जैसे एएमडी, इंटेल और स्पार्क)। लेकिन इसमें किसी भी पुस्तकालय शामिल नहीं है।
लंबा उत्तर: मैं x86 के लिए 64-बिट लिनक्स कर्नेल को डिज़ाइन करने वाली कुछ टीमों में शामिल था (बाहरी इलाकों में)। संक्षेप में (पूरी परियोजना की तुलना में, कुछ घंटों तक चर्चाएं हुईं) कुछ चर्चाएं कि आप तकनीकी रूप से यह काम कैसे कर सकते हैं। इसका संक्षिप्त सारांश यह है कि 64-बिट में ऐसे रजिस्ट्रार हैं जो 32-बिट में उपलब्ध नहीं हैं। स्मृति पते और रजिस्टरों में अतिरिक्त 32-बिट की समस्या भी है। इन सभी को हल किया जा सकता है पुस्तकालय खुद को "जानता है" कि यह एक 32-बिट संगत पुस्तकालय है। लेकिन फिर हमारे पास मूल रूप से एक 64-बिट लाइब्रेरी है जिसे 32-बिट लाइब्रेरी माना जाता है, और हमने इस तरह की स्थिति खो दी है।
"अधिक रजिस्ट्रार" कुछ प्रोसेसर पर लागू नहीं हो सकते हैं, लेकिन रजिस्टरों का बड़ा पता/बिट-रेंज निश्चित रूप से सभी 32- और 64-बिट संगत प्रोसेसर पर लागू होता है। और मुझे किसी एकल प्रोसेसर से अवगत नहीं है जो 32-बिट कोड को 64-बिट साझा लाइब्रेरी या स्थैतिक लाइब्रेरी को कॉल करने की अनुमति देता है। यह तब तक काम नहीं करता जब तक कोड को उस से निपटने के लिए विशेष रूप से लिखा नहीं जाता है, जो 32-बिट ऐप्स का समर्थन करने के लिए सामान्य 64-बिट लाइब्रेरी रखने के उद्देश्य को हरा देता है।
संपादित करें:
ऊपर एक निष्पादन इकाई जोड़ने चर्चा करता है, उदा एक निष्पादन योग्य फ़ाइल, एक साझा लाइब्रेरी या एक स्थिर पुस्तकालय। यह सब "एक गद्दार" होना चाहिए, या तो 32 या 64 - कोई मिश्रण नहीं।
जब एक प्रक्रिया जो किसी अन्य प्रक्रिया से बात करती है (उदाहरण के लिए एक जीयूआई ऐप जो गैर-जीयूआई प्रक्रिया से स्थिति प्रदर्शित करता है), जब तक कि दो प्रक्रियाएं उसी प्रोटोकॉल का उपयोग करती हैं [और आमतौर पर, आईपीसी गुजरने की अनुमति नहीं देता है पॉइंटर्स वैसे भी, तो 32-/64-बिट रूपांतरण एक मुद्दा जितना बड़ा नहीं है], आपके पास एक प्रक्रिया हो सकती है जो 32-बिट है और दूसरा 64-बिट है।
अमीगा सिस्टम पर कुछ मिश्रित बाइनरी कोड निष्पादन था जो 68k और पीपीसी कोड वाली वसा बाइनरी चला सकता था। एक CPU से दूसरे में निष्पादन निष्पादित होने पर स्टब्स को संदर्भ स्विचिंग करने के लिए जोड़ा गया था। हालांकि, अगर मुझे सही याद है तो दोनों 32 बी मोड में भाग गए। – Jens
-1 "संक्षेप में नहीं।" गलत है।64-बिट विंडोज़ पर सभी 32-बिट प्रोग्राम अंततः 64 बिट सेवाओं का लाभ उठाते हैं, क्योंकि वे 64 बिट ओएस में चल रहे हैं। 64-बिट लाइब्रेरी में अंतर को पुल करने के लिए आप COM सहित कई तकनीकों का उपयोग कर सकते हैं। –
@ एएलएफ: COM आरपीसी है। आरपीसी के साथ, आप 32 और 57 बिट्स के बीच के अंतर को पुल कर सकते हैं। यह विशेष नहीं है। पुस्तकालयों के रूप में, 64 बिट्स विंडोज़ अभी भी अपने पुस्तकालयों (डीएलएल) के 32 बिट संस्करणों के साथ वाहों सबस्टेम में जहाजों के साथ जहाजों को भेजता है, ठीक है क्योंकि आप एक ही प्रक्रिया में गठबंधन मिश्रण नहीं कर सकते हैं। – MSalters
यदि आप विंडोज पर चलते हैं, तो 32b के लिए संकलित आपका एप्लिकेशन विंडोज 64 बी होस्ट सिस्टम पर चलाया जा सकता है: WOW64 उपप्रणाली को देखें जो 64b विंडोज़ में बनाया गया है।
यह कहकर, आप 64b के लिए संकलित कोड के साथ 32 बी के लिए संकलित मिश्रण कोड कर सकते हैं। इसका मतलब है कि 32 बी के लिए बनाया गया एक लाइब्रेरी 64 बी कोड के खिलाफ नहीं जोड़ा जा सकता है, और इसके विपरीत। (विभिन्न कॉलिंग सम्मेलन, ढेर फ्रेम लेआउट, अनदेखा को छोड़कर, ...)
हां, लेकिन यह लाइब्रेरी से लिंक नहीं कर रहा है, यह एक सिस्टम कॉल इंटरफ़ेस है जो 32-बिट कोड से 64-बिट कर्नेल में सिस्टम कॉल को कॉल करता है। यह एक पूरी तरह से अलग बात है। (दूसरे पैराग्राफ से पहले लिखा गया था, जो मेरे बिंदु को बताता है) –
@ मैट्स पीटरसन: ओपी को "लाइब्रेरी से जोड़ने" की आवश्यकता नहीं है, ऐसे में कार्य एक्स करने की कोई आवश्यकता नहीं है जो काम नहीं करता है; इसके विपरीत, ओपी उन तरीकों से पूछता है जो काम करते हैं –
"32 बिट एप्लिकेशन में 64 बिट लाइब्रेरी काम कर सकता है?" क्या मतलब? –
हां, लेकिन यह एक बड़ा उपद्रव है।
सबसे पहले, एक कर्नेल लाइब्रेरी से अलग है। आमतौर पर, आपकी प्रक्रिया में वर्चुअल एड्रेस स्पेस में लाइब्रेरी दिखाई देती है; यह पता कोड को अपने कोड के साथ साझा करता है। लाइब्रेरी दिनचर्या को कॉल करना बस एक सबराउटिन कॉल है।
इसके विपरीत, कर्नेल से सेवाओं का अनुरोध करने के लिए, आपकी प्रक्रिया एक जाल उत्पन्न करने के लिए एक विशेष निर्देश निष्पादित करती है। यह जाल प्रोसेसर को कुछ विशेष चीजें करने का कारण बनता है जिसमें आपकी प्रक्रिया 'रजिस्टरों और अन्य राज्य को स्मृति में सहेजना शामिल है (या विशेष प्रोसेसर रजिस्टरों में जिन्हें आप सामान्य रूप से एक्सेस नहीं कर सकते), प्रोसेसर में विभिन्न मोड को कर्नेल के लिए उपयुक्त बनाने के लिए बदलते हैं, और कर्नेल के लिए निर्देशों को इंगित करने के लिए प्रोग्राम काउंटर को बदलना। फिर कर्नेल चल रहा है।इस बिंदु पर, कर्नेल 64-बिट मोड में चल रहा है जबकि आपकी प्रक्रिया 32-बिट मोड में चल रही थी। हालांकि, कर्नेल को इन मतभेदों से अवगत कराने के लिए डिज़ाइन किया गया है। जब आपका कर्नेल आपकी प्रक्रिया का निरीक्षण करता है कि आप क्या अनुरोध कर रहे हैं, तो यह जानकारी और डेटा संरचनाओं को देखता है कि यह जानकर कि आपकी प्रक्रिया 32-बिट मोड में चल रही थी। एक कर्नेल 32-बिट और 64-बिट दोनों प्रक्रियाओं का समर्थन कर सकता है, यह सिर्फ प्रत्येक प्रकार की प्रक्रिया को अलग-अलग व्यवहार करता है।
यह अनुमान लगाता है कि 64-बिट कर्नेल आप 32-बिट प्रक्रियाओं का समर्थन कर रहे हैं।
आम तौर पर, जब आप लाइब्रेरी को कॉल करते हैं, तो आप चाहते हैं कि यह आपके कोड के समान मोड हो, क्योंकि एक सामान्य लाइब्रेरी कॉल केवल एक सबराउटिन कॉल है; यह एक जाल उत्पन्न नहीं करता है और प्रोसेसर मोड नहीं बदलता है। यदि 32-बिट प्रक्रिया से 64-बिट लाइब्रेरी में दिनचर्या कॉल करने की कोई महत्वपूर्ण आवश्यकता थी, तो आप एक सहायक 64-बिट प्रक्रिया बना सकते हैं। आपकी 32-बिट प्रक्रिया लाइब्रेरी कॉल के लिए अनुरोध को पैकेज करेगी और उस अनुरोध को 64-बिट सहायक प्रक्रिया में कुछ प्रकार के इंटरप्रोसेस संचार द्वारा भेज देगा। वह सहायक प्रक्रिया लाइब्रेरी दिनचर्या को कॉल करेगी और परिणाम वापस भेज देगा।
स्वाभाविक रूप से, यह प्रत्येक लाइब्रेरी कॉल के लिए महत्वपूर्ण ओवरहेड जोड़ता है, इसलिए ऐसा कुछ है जो आप केवल तभी करना चाहते हैं जब कोई बड़ी आवश्यकता हो और कोई बेहतर विकल्प न हो।
+1 मैं upvoting कर रहा हूँ, भले ही है कि कैसे एक कर्नेल कॉल चला जाता है का वर्णन भी ठोस है (यह खासियत है लेकिन लेकिन कोई केवल संभावना तरह से) –
मैं एक ऐसे एप्लिकेशन पर काम कर रहा हूं जो वास्तव में ऐसा करता है। एप्लिकेशन कोर x64 (और क्यूटी का उपयोग करता है) है, लेकिन इसे कुछ उपकरणों के साथ संवाद करना है, जिसके लिए मेरे पास निर्माता से केवल 32 बिट लाइब्रेरी है। जिस तरह से मैंने इसे कार्यान्वित किया है, उसके पास कोर और जीयूआई के लिए दो अनुप्रयोग 64 बिट हैं, और 32 बिट्स जो उपकरण को नियंत्रित करती हैं और QSharedMemory का उपयोग करके मुख्य अनुप्रयोगों के साथ संचार करती हैं। दोनों ऐप्स Qt (64 और 32 बिट्स संगत रूप से) पर आधारित हैं।
आपका कर्नेल 32/64 बिट्स कर्नेल है। आपका कर्नेल लाइब्रेरी नहीं है। – MSalters
आप सभी तुरंत लिनक्स और ओएस कर्नेल के बारे में क्यों सोचते हैं? _ "कर्नेल" _ से उसका अर्थ हो सकता है कि वह अपनी खुद की लाइब्रेरी है जो उसके आवेदन में कोर का एक प्रकार है (हां, यह वास्तव में इसे कॉल करने के लिए थोड़ा बीमार गठित तरीका है, लेकिन कुछ लोग करते हैं)। एक साथ रखने के लिए उसके पास 32-बिट एप्लिकेशन है जिसमें कुछ तर्क के साथ केवल जीयूआई और एक अलग 64-बिट लाइब्रेरी है। –
देखें ... मैं सही था, उसने अभी शब्द का दुरुपयोग किया है ... ':)' –