क्या मशीन कोड को एक अलग वास्तुकला में अनुवाद किया जा सकता है?


11

तो यह एआरएम पर विंडोज सर्वर चलाने के बारे में एक प्रश्न से संबंधित है । तो मेरे प्रश्न का आधार यह है कि क्या मशीन कोड को एक आर्किटेक्चर से दूसरे आर्किटेक्चर में अनुवादित किया जा सकता है ताकि जिस आर्किटेक्चर पर इसे चलाने के लिए संकलित किया गया था, उससे अलग किसी बाइनरी को निष्पादित करने के लिए

QEMU और अन्य एमुलेटर मक्खी पर निर्देशों का अनुवाद कर सकते हैं, और इसलिए एक कंप्यूटर पर एक निष्पादन योग्य चलाते हैं जिसे इसके लिए संकलित नहीं किया गया था। प्रक्रिया को गति देने के लिए इस अनुवाद को समय से पहले उड़ान भरने के बजाय क्यों नहीं किया जाता है? विधानसभा के अपने कुछ हद तक सीमित ज्ञान से, निर्देशों की सबसे अधिक पसंद MOV, ADDऔर दूसरों आर्किटेक्चर भर में पोर्टेबल होना चाहिए।

कुछ भी नहीं है कि एक प्रत्यक्ष मानचित्रण निर्देश के कुछ अन्य सेट करने के लिए मैप किया जा सकता है, क्योंकि सभी मशीनें ट्यूरिंग पूर्ण हैं। क्या यह करना बहुत जटिल होगा? क्या मैं किसी ऐसे कारण से काम नहीं करूँगा जिससे मैं अपरिचित हूँ? क्या यह काम करेगा, लेकिन एमुलेटर का उपयोग करने से बेहतर परिणाम नहीं मिलेगा?


तकनीक की संभावना बहुत कम हो गई है, क्योंकि (इसकी चंचलता के अलावा) इसकी ज्यादा जरूरत नहीं है। पोर्टेबिलिटी / मानकीकरण इन दिनों (यदि केवल इसलिए कि विंटेल ने दुनिया पर कब्जा कर लिया है) बेहतर है, और, जहां क्रॉस-मशीन एमुलेशन वास्तव में आवश्यक है (जैसे, ऐप डेवलपमेंट वातावरण में फोन एमुलेटर के लिए), प्रत्यक्ष एमुलेशन एक तरह से प्रदान करता है अधिक विश्वसनीय और सटीक परिणाम। इसके अलावा, प्रोसेसर तेजी से पर्याप्त हैं कि उत्सर्जन की लागत अतीत की तरह गंभीर समस्या नहीं है।
डैनियल आर हिक्स

जवाबों:


6

संक्षिप्त उत्तर : आप संकलित, लिंक किए गए निष्पादन योग्य का अनुवाद नहीं कर सकते। जबकि तकनीकी रूप से संभव है, यह पूरा करने के लिए बेहद असंभव है (नीचे देखें)। हालाँकि , यदि आपके पास असेंबली सोर्स फाइल (निर्देश और लेबल युक्त) है, तो ऐसा करना बहुत संभव है (हालाँकि यदि आप किसी तरह असेंबली सोर्स प्राप्त करते हैं, जब तक कि असेंबली में प्रोग्राम नहीं लिखा जाता है, तो आपके पास मूल प्रोग्राम सोर्स कोड होना चाहिए। ठीक है, इसलिए आप अलग-अलग आर्किटेक्चर के साथ शुरू करने के लिए इसे संकलित करना बेहतर होगा)।


लंबे उत्तर :

QEMU और अन्य एमुलेटर मक्खी पर निर्देशों का अनुवाद कर सकते हैं, और इसलिए एक कंप्यूटर पर एक निष्पादन योग्य चलाते हैं जिसे इसके लिए संकलित नहीं किया गया था। प्रक्रिया को गति देने के लिए इस अनुवाद को समय से पहले उड़ान भरने के बजाय क्यों नहीं किया जाता है?

मुझे पता है कि सिद्धांत रूप में यह आसान लग सकता है, लेकिन व्यवहार में, यह कुछ मुख्य कारणों के लिए लगभग असंभव है। शुरू करने के लिए, अलग-अलग निर्देश सेट बड़े पैमाने पर अलग-अलग एड्रेसिंग मोड, अलग-अलग ओपकोड संरचना, अलग-अलग शब्द आकार और कुछ ऐसे निर्देशों का उपयोग करते हैं जिनकी आपको जरूरत नहीं है।

मान लीजिए कि आपको निर्देश XYZको दो और निर्देशों के साथ प्रतिस्थापित करने की आवश्यकता है , ABCऔर DEF। अब आप उस बिंदु से पूरे कार्यक्रम में सभी रिश्तेदार / ऑफसेट पते को प्रभावी ढंग से स्थानांतरित कर चुके हैं, इसलिए आपको विश्लेषण करने और पूरे कार्यक्रम से गुजरने और ऑफ़सेट्स (परिवर्तन से पहले और बाद दोनों) को अपडेट करने की आवश्यकता होगी। अब, मान लें कि ऑफ़सेट्स में से एक महत्वपूर्ण रूप से बदलता है - अब आपको एड्रेसिंग मोड बदलने की ज़रूरत है, जिससे एड्रेस का आकार बदल सकता है। यह फिर से आपको पूरी फाइल को फिर से स्कैन करने और सभी पतों को फिर से गणना करने के लिए मजबूर करेगा, और इसी तरह और चौथा।

जब आप असेंबली प्रोग्राम लिखते हैं, तो आप लेबल का उपयोग कर सकते हैं, लेकिन सीपीयू - जब फ़ाइल को इकट्ठा नहीं किया जाता है, तो सभी लेबल को सापेक्ष, निरपेक्ष या ऑफसेट स्थानों की गणना की जाती है। आप देख सकते हैं कि यह जल्दी से एक गैर-तुच्छ कार्य क्यों बन जाता है, और असंभव के बगल में। किसी एकल निर्देश को बदलने से आपको आगे बढ़ने से पहले पूरे कार्यक्रम से सैकड़ों बार गुजरना पड़ सकता है।

विधानसभा के मेरे कुछ सीमित ज्ञान से, MOV, ADD और अन्य जैसे अधिकांश निर्देश आर्किटेक्चर में पोर्टेबल होने चाहिए।

हां, लेकिन उन मुद्दों को देखें जिन्हें मैंने ऊपर उल्लिखित किया था। मशीन के शब्द आकार के बारे में क्या? पता लंबाई? यह भी एक ही संबोधित मोड है? फिर से, आप निर्देशों को "ढूंढ और प्रतिस्थापित" नहीं कर सकते। कार्यक्रम के प्रत्येक खंड में एक विशेष रूप से परिभाषित पता होता है। जब किसी प्रोग्राम को असेम्बल किया जाता है तो जंपर्स को अन्य लेबलों में बदल दिया जाता है।

कुछ भी नहीं है कि एक प्रत्यक्ष मानचित्रण निर्देश के कुछ अन्य सेट करने के लिए मैप किया जा सकता है, क्योंकि सभी मशीनें ट्यूरिंग पूर्ण हैं। क्या यह करना बहुत जटिल होगा? क्या मैं किसी ऐसे कारण से काम नहीं करूँगा जिससे मैं अपरिचित हूँ? क्या यह काम करेगा, लेकिन एमुलेटर का उपयोग करने से बेहतर परिणाम नहीं मिलेगा?

आप 100% सही हैं कि यह दोनों संभव है , और बहुत तेज़ होगा । हालांकि, इसे पूरा करने के लिए एक कार्यक्रम लिखना अविश्वसनीय रूप से कठिन और अत्यधिक अनुचित है, अगर ऊपर उल्लिखित मुद्दों को छोड़कर किसी भी चीज के लिए नहीं।

यदि आपके पास वास्तविक असेंबली स्रोत कोड है, तो मशीन कोड को किसी अन्य अनुदेश सेट आर्किटेक्चर में अनुवाद करना तुच्छ होगा। मशीन कोड ही, हालांकि, इकट्ठा किया जाता है , इसलिए विधानसभा स्रोत के बिना (जिसमें मेमोरी एड्रेस की गणना करने के लिए उपयोग किए जाने वाले विभिन्न लेबल होते हैं), यह अविश्वसनीय रूप से मुश्किल हो जाता है। फिर से, एक एकल निर्देश बदलने से पूरे कार्यक्रम में मेमोरी ऑफ़सेट बदल सकते हैं, और पतों को फिर से गणना करने के लिए सैकड़ों पास की आवश्यकता होती है।

कुछ हजार निर्देशों के साथ एक कार्यक्रम के लिए ऐसा करने के लिए दसियों की आवश्यकता होगी यदि सैकड़ों हजारों पास नहीं होंगे। अपेक्षाकृत छोटे कार्यक्रमों के लिए, यह संभव हो सकता है, लेकिन याद रखें कि कार्यक्रम में मशीन निर्देशों की संख्या के साथ पास की संख्या तेजी से बढ़ेगी। एक सभ्य पर्याप्त आकार के किसी भी कार्यक्रम के लिए, यह असंभव के पास है।


अनिवार्य रूप से किसी को जो करना है, वह स्रोत ऑब्जेक्ट कोड "डिकम्पाइल" या "डिसएम्बल" है। अपेक्षाकृत सीधे-फॉरवर्ड कोड के लिए (विशेष रूप से कुछ कंपाइलर या कोड जेनरेशन पैकेज द्वारा उत्पन्न कोड जहां एक ज्ञात "शैली" है) लेबल का पुन: सम्मिलन और जैसा है वह काफी सरल है। निश्चित रूप से, हालांकि, नए उच्च-अनुकूलन वाले कंपाइलर कोड उत्पन्न करेंगे जो इस तरह से "ग्रॉक" करने के लिए बहुत कठिन थे।
डैनियल आर हिक्स

@DanH यदि आप स्रोत ऑब्जेक्ट कोड है, तो आप काफी विधानसभा स्रोत (राशि नहीं मशीन कोड)। ऑब्जेक्ट फ़ाइल में मशीन कोड के अनुक्रम (नाम: लेबल) अनुक्रम एक साथ जुड़े हुए हैं। समस्या तब आती है जब आप ऑब्जेक्ट कोड फ़ाइलों को निष्पादन योग्य में लिंक करते हैं। इन छोटे खंडों को (या रिवर्स इंजीनियर) बहुत आसानी से संभाला जा सकता है, फिर एक संपूर्ण लिंक्ड निष्पादन योग्य।
ब्रेकथ्रू

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

2

हां, आप जो सुझाव देते हैं वह किया जा सकता है और किया गया है। यह बहुत सामान्य नहीं है, और मुझे किसी भी मौजूदा सिस्टम का पता नहीं है जो तकनीक का उपयोग करते हैं, लेकिन तकनीकी व्यवहार्यता के दायरे में यह निश्चित रूप से अच्छी तरह से है।

यह एक प्रणाली से दूसरे सिस्टम में कोडिंग को सक्षम करने के लिए बहुत कुछ किया जाता था, इससे पहले कि किसी ने भी "कच्चे पोर्टेबिलिटी" को प्राप्त किया हो। इसे "स्रोत" के जटिल विश्लेषण की आवश्यकता थी और कोड संशोधन और अन्य ऑडबॉल प्रथाओं द्वारा इसे मंचित किया जा सकता था, लेकिन यह अभी भी किया गया था।

हाल ही में, IBM System / 38 - iSeries - System i जैसे सिस्टम ने असंगत निर्देश सेट आर्किटेक्चर के बीच पोर्टेबिलिटी को सक्षम करने के लिए संकलित कार्यक्रमों के साथ संकलित इंटरमीडिएट कोड (जावा बाइटकोड के समान) की पोर्टेबिलिटी का लाभ उठाया है।


सहमत हूं कि यह किया गया है, आमतौर पर बहुत पुराने (सरल) अनुदेश सेट के साथ। 1970 में पुराने 7xx बाइनरी प्रोग्राम को सिस्टम / 360 में बदलने के लिए IBM प्रोजेक्ट था।
चूरा

1

मशीन कोड ही आर्किटेक्चर विशिष्ट है।

कई आर्किटेक्चर (जावा शायद सबसे अच्छी तरह से ज्ञात है) में आसान पोर्टेबिलिटी के लिए अनुमति देने वाली भाषाएं बहुत उच्च स्तर की होती हैं, जिससे मशीन पर काम करने के लिए दुभाषियों या रूपरेखाओं को स्थापित करने की आवश्यकता होती है।

ये चौखटे या दुभाषिए प्रत्येक विशिष्ट सिस्टम आर्किटेक्चर के लिए लिखे गए हैं जो वे चलेंगे और इसलिए "सामान्य" प्रोग्राम की तुलना में अधिक पोर्टेबल नहीं हैं।


2
संकलित भाषाएं भी पोर्टेबल हैं, केवल व्याख्या की गई भाषाएं नहीं हैं, यह संकलक है जो वास्तुकला विशिष्ट है क्योंकि यह वह है जो अंततः उस कोड का अनुवाद करता है जो उस पर है जिसे वह पहचान सकता है। अंतर केवल इतना है कि संकलित भाषाओं का संकलन समय पर अनुवाद किया जाता है और व्याख्या की गई भाषाओं का अनुवाद लाइन द्वारा आवश्यकतानुसार किया जाता है।
MaQleod

1

बिल्कुल, यह संभव है। मशीन कोड क्या है? इसकी सिर्फ भाषा हैकि एक विशेष कंप्यूटर समझता है। खुद को कंप्यूटर समझें और आप जर्मन में लिखी गई किताब को समझने की कोशिश कर रहे हैं। आप ऐसा नहीं कर सकते, क्योंकि आप भाषा नहीं समझते हैं। अब यदि आप एक जर्मन शब्दकोश ले रहे थे और "कोफ़्फ़" शब्द को देख रहे थे, तो आप इसे अंग्रेज़ी शब्द "हेड" का अनुवाद करते देखेंगे। आपके द्वारा प्रयुक्त शब्दकोष को कंप्यूटर की दुनिया में एक अनुकरण परत कहा जाता है। आसान है ना? खैर, यह और मुश्किल हो जाता है। जर्मन शब्द "स्कैडनफ्र्यूड" लें और इसे अंग्रेजी में अनुवाद करें। आप देखेंगे कि अंग्रेजी भाषा में कोई शब्द नहीं है, लेकिन एक परिभाषा है। कंप्यूटर की दुनिया में एक ही समस्या मौजूद है, उन चीजों का अनुवाद करना जिनके पास एक समान शब्द नहीं है। यह प्रत्यक्ष पोर्ट को मुश्किल बनाता है क्योंकि इम्यूलेशन लेयर के डेवलपर्स को इस बात की व्याख्या करनी होती है कि उस शब्द का क्या अर्थ है और मेजबान कंप्यूटर इसे समझ सकता है। कभी-कभी यह सिर्फ उसी तरह से काम नहीं करता है जिस तरह से कोई उम्मीद करता है। हम सभी ने इंटरनेट पर पुस्तकों, वाक्यांशों आदि के मज़ेदार अनुवाद देखे हैं?


1

आपके द्वारा वर्णित प्रक्रिया को स्टेटिक रिकॉम्पिलेशन कहा जाता है, और यह किया गया है, बस आम तौर पर लागू तरीके से नहीं। मतलब यह संभव से परे है, यह कई बार किया गया है, लेकिन इसके लिए मैनुअल काम की आवश्यकता है।

शोध के लायक कई ऐतिहासिक उदाहरण हैं, लेकिन वे आधुनिक चिंताओं को प्रदर्शित करने में कम सक्षम हैं। मुझे दो उदाहरण मिले हैं जो अनिवार्य रूप से किसी भी पूर्ण संदेह पर सवाल उठाना चाहिए जो उन लोगों से सवाल करते हैं जो दावा करते हैं कि सब कुछ मुश्किल है।

पहले इस आदमी ने एक NES ROM के लिए एक पूर्ण स्टेटिक आर्किटेक्चर और प्लेटफ़ॉर्म किया। http://andrewkelley.me/post/jamulator.html

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

अब कम स्पष्ट संभावनाओं के लिए, आपके पास पहले से मौजूद प्लेटफ़ॉर्म का लाभ उठाएं ... लिनक्स एआरएम पर स्टारक्राफ्ट? हाँ, दृष्टिकोण तब काम करता है जब आप कार्य को उस गति के लिए विवश नहीं करते हैं जो आप गतिशील रूप से करते हैं। Winlib का उपयोग करके Windows प्लेटफ़ॉर्म कॉल सभी मूल हैं, हम सभी के बारे में चिंता करने की ज़रूरत है कि आर्किटेक्चर है।

http://www.geek.com/games/starcraft-has-been-reverse-engineered-to-run-on-arm-1587277/

मैं डोनट्स को डॉलर फेंक दूंगा कि मंदी लगभग नगण्य है, यह देखते हुए कि एआरएम हैंडहेल्ड पैंडोरा केवल पीआई से थोड़ा मजबूत है। इस उपकरण का उपयोग उन्होंने इस भंडार में किया है।

https://github.com/notaz/ia32rtools

उस आदमी ने बहुत मैन्युअल रूप से विघटित किया, मेरा मानना ​​है कि इस प्रक्रिया को कम काम के साथ काफी स्वचालित किया जा सकता है ... लेकिन इस समय भी प्यार का एक श्रम। किसी को यह मत बताइए कि कुछ संभव नहीं है, मुझे यह भी बताने दें कि यह व्यावहारिक नहीं है ... यह व्यावहारिक हो सकता है, जैसे ही आप इसे बनाने के लिए एक नया तरीका अपनाते हैं।


0

सैद्धांतिक रूप से, हाँ यह किया जा सकता है। खेलने में आने वाली बड़ी समस्या एक ऑपरेटिंग सिस्टम (या कर्नेल) के लिए एक एप्लिकेशन को दूसरे में अनुवाद करना है। विंडोज, लिनक्स, ओएसएक्स और आईओएस कर्नेल निम्न स्तर के संचालन के बीच महत्वपूर्ण अंतर हैं, उन उपकरणों के लिए सभी अनुप्रयोगों का उपयोग करना होगा।

एक बार फिर, सैद्धांतिक रूप से, कोई ऐसा एप्लिकेशन लिख सकता है जो किसी एप्लिकेशन के साथ-साथ ऑपरेटिंग सिस्टम से जुड़े सभी मशीन कोड को भी चला सकता है, जिसे चलाने के लिए संकलित किया गया था और फिर किसी अन्य डिवाइस के लिए उस मशीन कोड के सभी को फिर से इकट्ठा करना। हालाँकि, यह सिर्फ हर मामले में अत्यधिक अवैध होगा और लिखना बेहद कठिन होगा। यह वास्तव में, मेरे सिर में गियर इसके बारे में सोच कर जब्त करना शुरू कर रहे हैं।

अपडेट करें

नीचे दी गई टिप्पणियों में से कुछ मेरी प्रतिक्रिया से असहमत हैं, हालांकि, मुझे लगता है कि वे मेरी बात याद कर रहे हैं। मेरी जानकारी में, ऐसा कोई एप्लिकेशन नहीं है जो एक आर्किटेक्चर के लिए निष्पादन योग्य बाइट्स का एक क्रम ले सकता है, इसे बायटेकोड स्तर पर विघटित कर सकता है, जिसमें सभी आवश्यक कॉल शामिल हैं, जिसमें एक्सट्रनल लाइब्रेरी को कॉल करना शामिल है, जिसमें अंतर्निहित ओएस कर्नेल को कॉल करना और इसे किसी अन्य सिस्टम पर फिर से इकट्ठा करना और सहेजना है परिणामस्वरूप निष्पादन योग्य बायटेकोड । दूसरे शब्दों में, ऐसा कोई एप्लिकेशन नहीं है जो Notepad.exe के रूप में सरल रूप में कुछ ले सकता है, 190k की छोटी फ़ाइल को विघटित करता है जो यह है, और 100% इसे एक एप्लिकेशन में पुन: एकत्रित करता है जो लिनक्स या ओएसएक्स पर चल सकता है।

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

यदि आप आवेदन करने के लिए फिर से इकट्ठा करना चाहते हैं और इसे एक अलग वास्तुकला पर चलाने के लिए चाहते हैं, तो उस बाइट कोड के सभी को अलग किया जाना चाहिए।

वाइन जैसे एप्लिकेशन बाइट स्तर पर विंडोज बायनेरिज़ की व्याख्या करते हैं। वे कॉल को कर्नेल के रूप में पहचानते हैं और उन कॉलों को या तो संबंधित लिनक्स फ़ंक्शंस में अनुवाद करते हैं या वे विंडोज़ वातावरण का अनुकरण करते हैं। लेकिन, यह एक बाइट-फॉर-बाइट (या ओपकोड के लिए ओपोड) नहीं है। यह फंक्शन-फॉर-फंक्शन ट्रांसलेशन का अधिक है और यह काफी अलग है।


यह बिल्कुल सैद्धांतिक नहीं है। और बहुत सारे अनुप्रयोग हैं जो विभिन्न ऑपरेटिंग सिस्टम पर अन्य बायनेरिज़ चलाते हैं। क्या आपने वाइन के बारे में सुना है? यह लिनक्स, सोलारिस, मैक ओएसएक्स, बीएसडी, और अन्य जैसे विभिन्न ओएस पर विंडोज बायनेरिज़ चलाता है।
कल्टारी

कई ऑपरेटिंग सिस्टम चलाने के लिए हाइपरवाइजर का उपयोग करके (या एक "परत" को चलाने के लिए जैसे शराब एक सिस्टम पर दूसरे का अनुकरण करके) ऑपरेटिंग सिस्टम में अंतर आसानी से अधिकांश सिस्टम पर चालाकी से किया जा सकता है। AFAIK, सभी "आधुनिक" गैर-एम्बेडेड प्रोसेसर "वर्चुअलाइज़ेबल" हैं, इसलिए इसके लिए कोई अनुदेश सेट अनुकरण / अनुवाद की आवश्यकता नहीं है।
डैनियल आर हिक्स

0

लगता है कि सभी विशेषज्ञ इस बिंदु को याद कर रहे हैं: 'अनुवाद' जटिल है, लेकिन कंप्यूटर के लिए बहुत उपयुक्त है (कोई बुद्धिमान नहीं, सिर्फ प्रयोगशाला)। लेकिन अनुवाद के बाद, कार्यक्रमों को ओएस समर्थन की आवश्यकता होती है, पूर्व: GetWindowVersion लिनक्स में मौजूद नहीं है। यह सामान्य रूप से एमुलेटर द्वारा आपूर्ति की जाती है (बहुत बड़ी)। इसलिए आप एक साधारण कार्यक्रम को 'प्री-ट्रांसलेट' कर सकते थे, लेकिन आपको स्वतंत्र रूप से चलाने के लिए एक बड़े परिवाद से जुड़ना होगा। हर विंडो के प्रोग्राम का इमेजिंग अपने कर्नेल के साथ आता है ।ll + user.dll + shell.dll ...


यह सिर्फ श्रमसाध्य नहीं है, इसके लिए बुद्धि की आवश्यकता होती है। उदाहरण के लिए, मान लें कि आप कुछ संगणना देखते हैं, जिसका परिणाम आपके द्वारा छपे पते को निर्धारित करता है, जो कि किसी ऐसी चीज के बीच में हो सकता है जो एकल निर्देश प्रतीत होती है।
डेविड श्वार्ट्ज
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.