फैट बाइनरी: Difference between revisions

Revision as of 01:08, 7 August 2023

फैट बाइनरी (या मल्टीआर्किटेक्चर बाइनरी) कंप्यूटर एक्सेक्यूटेबले प्रोग्राम या लाइब्रेरी (कंप्यूटिंग) है जिसे अनेक निर्देश सेटों के मूल कोड के साथ विस्तारित (या फैट किया गया) किया गया है, जिसके परिणामस्वरूप यह अनेक प्रोसेसर प्रकारों पर चलाया जा सकता है।^[1] इसके परिणामस्वरूप फ़ाइल सामान्य यह-आर्किटेक्चर बाइनरी फ़ाइल से बड़ी हो जाती है, इस प्रकार नाम हैं।

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

ऑपरेटिंग सिस्टम सॉफ़्टवेयर में फैट बायनेरिज़ का उपयोग सामान्य नहीं है ऐसी ही समस्या का समाधान करने के लिए अनेक विकल्प हैं, जैसे इंस्टालर प्रोग्राम का उपयोग इंस्टॉल समय पर आर्किटेक्चर-विशिष्ट बाइनरी चुनने के लिए होता हैं और (जैसे एंड्रॉइड (ऑपरेटिंग सिस्टम) एकाधिक एंड्रॉइड पैकेज के साथ), रनटाइम पर आर्किटेक्चर-विशिष्ट बाइनरी का चयन करता हैं इस प्रकार (जैसे कि बेल लैब्स की संघ निर्देशिका (योजना 9) के साथ (प्लान 9) और जीएनयूस्टेप के वसा बंडल) होता हैं, ^[2]^[3] सॉफ़्टवेयर को सोर्स कोड के रूप में वितरित करना और उसे उसी स्थान पर संकलित करना हैं, इस आभासी मशीन का उपयोग (जैसे कि जावा वर्चुअल मशीन के साथ) और समय-समय पर संकलन करना होता हैं।

अपोलो

अपोलो के यौगिक निष्पादनयोग्य

1988 में, अपोलो कंप्यूटर के डोमेन/ओएस SR10.1 ने नया फ़ाइल प्रकार, सीएमपेक्स (यौगिक एक्सेक्यूटेबले ) प्रस्तुत किया, जिसमें मोटोरोला 680x0 श्रृंखला और अपोलो प्रिज्म एक्सेक्यूटेबले के लिए बायनेरिज़ को बंडल किया गया था। ^[4]

एप्पल

एप्पल की फैट बाइनरी

फैट-बाइनरी योजना ने 1994 में 68k माइक्रोप्रोसेसरों से पावरपीसी माइक्रोप्रोसेसरों तक एप्पल मैकिंटोश के संक्रमण को सुचारू किया हैं। पूर्व प्लेटफ़ॉर्म के लिए अनेक एप्लिकेशन विकसित एमुलेटर के अनुसार नए प्लेटफ़ॉर्म पर क्रोसदर्शी रूप से चलते हैं, किन्तु एम्युलेटेड कोड सामान्यतः मूल कोड की तुलना में धीमी गति से चलता है। फैट बायनेरिज़ के रूप में प्रचलित किए गए एप्लिकेशन ने अधिक संग्रहण स्थान ले लिया हैं, किन्तु वह किसी भी प्लेटफ़ॉर्म पर पूर्ण गति से चले। यह मोटोरोला 68k-संकलित संस्करण और ऐसे ही प्रोग्राम के पावरपीसी-संकलित संस्करण दोनों को उनकी एक्सेक्यूटेबले फ़ाइलों में पैकेजिंग करके प्राप्त किया गया था।^[5]^[6] पूर्व 68K कोड (सीएफएम-68K या क्लासिक 68K) को संसाधन फ़ोर्क में संग्रहीत किया जाना प्रचलित रखा गया हैं, जबकि नया पावरपीसी कोड डेटा फोर्क में, फेवरेट एक्सेक्यूटेबले फार्मेट प्रारूप में समाहित किया गया था।^[7]^[8]^[9]

फैट बायनेरिज़ केवल पावरपीसी या 68k का समर्थन करने वाले प्रोग्रामों से बड़े थे, जिसके कारण इनमे अनेक उपयोगिताओं का निर्माण हुआ जो अनावश्यक संस्करण को हटा देते हैं। ^[5]^[6] लघु हार्ड ड्राइव के युग में, जब 80 एमबी हार्ड ड्राइव सामान्य आकार के थे, यह उपयोगिताएँ कभी-कभी उपयोगी होती थीं, क्योंकि प्रोग्राम कोड सामान्यतः समग्र ड्राइव उपयोग का बड़ा भाग होता था, और फैट बाइनरी के अनावश्यक सदस्यों को अलग करने से हार्ड ड्राइव पर महत्वपूर्ण मात्रा में जगह रिक्त हो जाती थी।

नेक्स्ट/एप्पल की मल्टी-आर्किटेक्चर बायनेरिज़

नेक्स्ट स्टेप मल्टी-आर्किटेक्चर बायनेरिज़

फैट बायनेरिज़ नेक्स्ट के नेक्स्ट स्टेप /ओपेन स्टेप ऑपरेटिंग सिस्टम की विशेषता थी, जिसकी प्रारंभ नेक्स्ट स्टेप 3.1 से हुई थी। नेक्स्ट स्टेप में, उन्हें मल्टी-आर्किटेक्चर बायनेरिज़ कहा जाता था। मल्टी-आर्किटेक्चर बायनेरिज़ का उद्देश्य मूल रूप से सॉफ़्टवेयर को नेक्स्ट के मोटोरोला 68k-आधारित हार्डवेयर और नेक्स्ट स्टेप पर चलने वाले इंटेल आईए-32-आधारित आईबीएम पीसी कॉम ्पैटिबल्स पर चलाने के लिए संकलित करने की अनुमति देना था, दोनों प्लेटफार्मों के लिए बाइनरी फ़ाइल के साथ होता था। ^[10] इसके पश्चात् इसका उपयोग ओपेन स्टेप अनुप्रयोगों को पीसी पर चलने की अनुमति देने के लिए किया गया और इसमें विभिन्न आरआईएससी प्लेटफ़ॉर्म ओपेन स्टेप समर्थित थे। मल्टी-आर्किटेक्चर बाइनरी फ़ाइलें विशेष संग्रह प्रारूप में होती हैं, जिसमें एकल फ़ाइल मल्टी-आर्किटेक्चर बाइनरी द्वारा समर्थित प्रत्येक आर्किटेक्चर के लिए या अधिक मच-ओ सबफ़ाइलें संग्रहीत करती है। प्रत्येक मल्टी-आर्किटेक्चर बाइनरी संरचना से प्रारंभ होती है इसमें (struct fat_header) होते हैं जिसमें दो अहस्ताक्षरित पूर्णांक हैं। इस फ़ाइल को फैट बाइनरी के रूप में पहचानने के लिए पहले पूर्णांक (मैजिक) का उपयोग किया जाता हैं इस प्रकार फ़ाइल प्रारूप या मैजिक नंबर के रूप में इसका प्रयोग किया जाता है। दूसरा पूर्णांक (nfat_arch) परिभाषित करता है कि संग्रह में कितनी मैक-ओ फ़ाइलें हैं (विभिन्न आर्किटेक्चर के लिए ही प्रोग्राम के कितने उदाहरण हैं)। इस हेडर के पश्चात्, nfat_arch फैट_आर्क संरचनाओं की संख्या (struct fat_arch) होती हैं. यह संरचना ऑफसेट (फ़ाइल प्रारंभ से) इसको परिभाषित करती है जिस पर फ़ाइल, एलाइनमेंट, साइज और सीपीयू टाइप और सबटाइप को ढूंढना है जिस पर मैक-ओ बाइनरी (संग्रह के अंदर) लक्षित होता है।

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

विभिन्न लक्षित ऑब्जेक्ट फ़ाइलों के साथ लाइब्रेरी बनाना (उदाहरण के लिए नेक्स्ट स्टेप के llibtool का उपयोग करना) भी संभव था।

मैक-ओ और मैक ओएस एक्स

एप्पल कंप्यूटर ने 1996 में नेक्स्टम का अधिग्रहण किया और ओपेन स्टेप कोड के साथ काम करना प्रचलित रखा था। मैक-ओ एप्पल के मुफ्त डार्विन (ऑपरेटिंग सिस्टम) (2000) और एप्पल के मैक ओएस एक्स (2001) में मूल ऑब्जेक्ट फ़ाइल स्वरूप बन गया था, और नेक्स्ट के मल्टी-आर्किटेक्चर बायनेरिज़ को ऑपरेटिंग सिस्टम द्वारा समर्थित किया जाना प्रचलित रहा था। मैक ओएस में इसका उपयोग अनेक आर्किटेक्चर का समर्थन करने के लिए भी किया जा सकता है, जैसे कि 32-बिट और 64-बिट पावरपीसी, या पावरपीसी और x86, या x86-64 और AArch64 हैं। ^[11]

एप्पल की यूनिवर्सल बाइनरी

एप्पल यूनिवर्सल बाइनरी लोगो

2005 में, एप्पल ने पावरपीसी प्रोसेसर से इंटेल x86 प्रोसेसर तक, इंटेल प्रोसेसर में और मैक परिवर्तन की घोषणा की थी। एप्पल ने मल्टी-आर्किटेक्चर बाइनरी प्रारूप में एक्सेक्यूटेबले फ़ाइलों का उपयोग करके नए अनुप्रयोगों के वितरण को बढ़ावा दिया जो मूल रूप से पावरपीसी और x86 दोनों का समर्थन करते हैं।^[12] एप्पल ऐसे प्रोग्रामों को सार्वभौमिक अनुप्रयोग कहता है और फ़ाइल प्रारूप को यूनिवर्सल बाइनरी कहता है, जो संभवतः इस नए संक्रमण को पिछले संक्रमण, या मल्टी-आर्किटेक्चर बाइनरी प्रारूप के अन्य उपयोगों से भिन्न करने का विधि है।

पूर्व से उपस्तिथ प्राचीन पावरपीसी अनुप्रयोगों के फॉरवर्ड माइग्रेशन के लिए यूनिवर्सल बाइनरी प्रारूप आवश्यक नहीं था | 2006 से 2011 तक, एप्पल ने इस भूमिका को निभाने के लिए रोसेटा (सॉफ़्टवेयर), पावरपीसी (पीपीसी)-टू-x86 डायनेमिक बाइनरी अनुवाद की आपूर्ति की हैं। चूँकि, रोसेटा का प्रदर्शन अधिक अच्छा था, इसलिए डेवलपर्स को यूनिवर्सल बायनेरिज़ का उपयोग करके पीपीसी और इंटेल बायनेरिज़ दोनों की प्रस्तुति करने के लिए प्रोत्साहित किया गया। यूनिवर्सल बाइनरी का स्पष्ट निवेश यह है कि प्रत्येक स्थापित एक्सेक्यूटेबले फ़ाइल बड़ी होती है, किन्तु पीपीसी के प्रचलित होने के पश्चात् इसके वर्षों में, हार्ड-ड्राइव स्थान एक्सेक्यूटेबले आकार से अधिक आगे निकल गया है | जबकि यूनिवर्सल बाइनरी ही एप्लिकेशन के एकल-प्लेटफ़ॉर्म संस्करण के आकार से दोगुना हो सकता है, फ्री-स्पेस संसाधन सामान्यतः कोड आकार को लघु कर देते हैं, जो छोटी सी समस्या बन जाती है। वास्तव में, प्रायः यूनिवर्सल-बाइनरी एप्लिकेशन दो एकल-आर्किटेक्चर अनुप्रयोगों से छोटा होगा क्योंकि प्रोग्राम संसाधनों को इसके डुप्लिकेट के अतिरिक्त साझा किया जा सकता है। यदि सभी आर्किटेक्चर की आवश्यकता नहीं है, तब lipo और ditto मल्टी-आर्किटेक्चर बाइनरी छवि से संस्करणों को हटाने के लिए कमांड-लाइन अनुप्रयोगों का उपयोग किया जा सकता है, जिससे कभी-कभी थिन बाइनरी कहा जाता है।

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

एक्सकोड विकास परिवेश के 2.1 से 3.2 (मैक ओएस सार्वभौमिक बायनेरिज़ में अंततः एक्सेक्यूटेबले कोड के अधिकतम चार संस्करण सम्मिलित हो सकते हैं | इसमें (32-बिट पावरपीसी, 32-बिट x86, 64-बिट पावरपीसी, और एक्स86-64|64-बिट x86) होते है। चूँकि, पावरपीसी समर्थन को एक्सकोड 4.0 से हटा दिया गया था और इसलिए यह मैक ओएस एक्स 10.7 या इससे अधिक संस्करण चलाने वाले डेवलपर्स के लिए उपलब्ध नहीं होता है।

2020 में, एप्पल ने एप्पल सिलिकॉन में और मैक परिवर्तन की घोषणा की थी, इस बार इंटेल x86 प्रोसेसर से एप्पल सिलिकॉन (ARM64 आर्किटेक्चर) में दिया। संक्रमण को सुचारू करने के लिए एप्पल ने यूनिवर्सल 2 बाइनरी प्रारूप के लिए समर्थन जोड़ा था | यूनिवर्सल 2 में बाइनरी फ़ाइलें मल्टी-आर्किटेक्चर बाइनरी फ़ाइलें हैं जिनमें x86-64 और ARM64 एक्सेक्यूटेबले कोड दोनों होते हैं, जो बाइनरी को 64-बिट इंटेल और 64-बिट एप्पल सिलिकॉन दोनों पर मूल रूप से चलाने की अनुमति देते हैं। इसके अतिरिक्त, एप्पल ने उपयोगकर्ताओं को ऐसे एप्लिकेशन चलाने की अनुमति देने के लिए x86 से Arm64 निर्देश सेट के लिए रोसेटा 2 डायनेमिक बाइनरी अनुवाद प्रस्तुत किया, जिसमें यूनिवर्सल बाइनरी वेरिएंट नहीं है।

एप्पल फैट ईएफआई बाइनरी

2006 में, एप्पल ने पावरपीसी से इंटेल सीपीयू पर स्विच किया और फ़र्मवेयर खोलें इसको एक्स्टेंसिबल फ़र्मवेयर इंटरफ़ेस से परिवर्तित कर दिया। चूँकि, 2008 तक, उनके कुछ मैक 32-बिट ईएफआई और कुछ 64-बिट ईएफआई का उपयोग करते थे। इस कारण से, एप्पल ने ईएफआई विनिर्देश को फैट बायनेरिज़ के साथ बढ़ाया जिसमें 32-बिट और 64-बिट ईएफआई बायनेरिज़ दोनों सम्मिलित थे।^[13]

सीपी/एम और डॉस

सीपी/एम-80 और डॉस के लिए संयुक्त कॉम -शैली बायनेरिज़

इंटेल 8080 (और Z80) प्रोसेसर परिवारों के लिए सीपी/एम-80, एमपी/एम-80, समवर्ती सीपी/एम, सीपी/एम प्लस, व्यक्तिगत सीपी/एम-80, एससीपी (ऑपरेटिंग सिस्टम) और एमएसएक्स-डॉस एक्सेक्यूटेबले इंटेल 8086 बायनेरिज़ के लिए डॉस-संगत ऑपरेटिंग सिस्टम के समान .कॉम फाइल एक्सटेंशन का उपयोग करते हैं। Cite error: The opening <ref> tag is malformed or has a bad name दोनों ही मामलों में प्रोग्राम हैं ऑफसेट +100एच पर लोड किया गया और फ़ाइल में पहले बाइट पर जाकर निष्पादित किया गया।^[14]^[15]चूंकि दो प्रोसेसर परिवारों के opcode संगत नहीं हैं, इसलिए गलत ऑपरेटिंग सिस्टम के अनुसार प्रोग्राम प्रारंभ करने का प्रयास गलत और अप्रत्याशित व्यवहार की ओर ले जाता है।

इससे बचने के लिए, फैट बायनेरिज़ बनाने के लिए कुछ तरीके तैयार किए गए हैं जिनमें सीपी/एम-80 और डॉस प्रोग्राम दोनों सम्मिलित हैं, जिसके पहले प्रारंभिक कोड होता है जिसे दोनों प्लेटफार्मों पर सही ढंग से व्याख्या किया जाता है।^[15]विधियाँ या तब अपने संबंधित वातावरण के लिए बनाए गए दो पूर्ण तरह कार्यात्मक प्रोग्रामों को जोड़ती हैं, या कोड स्टब्स जोड़ती हैं जो गलत प्रोसेसर पर प्रारंभ होने पर प्रोग्राम को शानदार ढंग से बाहर निकलने का कारण बनती हैं। इसे काम करने के लिए, पहले कुछ निर्देश (कभी-कभी या गैजेट्स भी कहा जाता है^[16] .कॉम फ़ाइल में 8086 और 8080 दोनों प्रोसेसर के लिए वैध कोड होना चाहिए, जिससे प्रोसेसर कोड के अंदर विभिन्न स्थानों में शाखाबद्ध हो जाएंगे।^[16]उदाहरण के लिए, शिमोन क्रैन के एमुलेटर MyZ80 में उपयोगिताएँ ऑपकोड अनुक्रम से प्रारंभ होती हैं EBh, 52h, EBh.^[17]^[18]8086 इसे जम्प के रूप में देखता है और अपने अगले निर्देश को ऑफसेट +154h से पढ़ता है जबकि 8080 या संगत प्रोसेसर सीधे जाता है और अपने अगले निर्देश को +103h से पढ़ता है। इस प्रयोजन के लिए इसी प्रकार का अनुक्रम प्रयोग किया जाता है EBh, 03h, C3h.^[19]^[20] जॉन सी. इलियट का FATBIN^[21]^[22]^[23]CP/M-80 और डीओएस .कॉम फ़ाइल को एक्सेक्यूटेबले में संयोजित करने की उपयोगिता है।^[17]^[24]मूल PMsfx का उनका व्युत्पन्न योशीहिको मिनो के PMarc द्वारा बनाए गए अभिलेखों को स्व-निकालने योग्य संग्रह के रूप में संशोधित करता है|CP/M-80 और DOS, दोनों के अनुसार स्व-निकालने योग्य, से प्रारंभ होता है EBh, 18h, 2Dh, 70h, 6Dh, 73h, 2Dh स्वयं-निकालने वाले PMarc अभिलेखागार के लिए -pms- हस्ताक्षर भी सम्मिलित करें,^[25]^[17]^[24]^[18]इस प्रकार यह एक्सेक्यूटेबले ASCII कोड के रूप का भी प्रतिनिधित्व करता है।

CP/M-80 और MSX-डीओएस मशीनों के लिए .कॉम प्रोग्रामों को ग़लत ढंग से निष्पादित करने से DOS-संगत ऑपरेटिंग सिस्टम को रखने का दूसरा विधि^[15]8080 कोड को प्रारंभ करना है C3h, 03h, 01h, जिसे x86 प्रोसेसर द्वारा RET निर्देश के रूप में डिकोड किया जाता है, जिससे प्रोग्राम से शानदार ढंग से बाहर निकल जाता है,^{[nb 1]}जबकि इसे 8080 प्रोसेसर द्वारा JP 103h अनुदेश के रूप में डिकोड किया जाएगा और बस प्रोग्राम में अगले अनुदेश पर पहुंच जाएगा। इसी तरह, एसएलआर सिस्टम्स द्वारा सीपी/एम असेंबलर Z80ASM+ डॉस पर गलती से चलने पर त्रुटि संदेश प्रदर्शित करेगा।^[17]

कुछ CP/M-80 3.0 .कॉम फ़ाइलों में GENकॉम (CP/M कमांड) द्वारा या अधिक RSX (कंप्यूटिंग) ओवरले जुड़े हो सकते हैं।^[26]यदि ऐसा है, तब वह अतिरिक्त 256 बाइट सीमा|256-बाइट हेडर (एक पृष्ठ (कंप्यूटिंग)) के साथ प्रारंभ करते हैं। इसे इंगित करने के लिए, हेडर में पहला बाइट जादुई बाइट पर सेट किया गया है C9h, जो CP/M 3.0 एक्सेक्यूटेबले लोडर के लिए इस प्रकार की कॉम फ़ाइल की पहचान करने वाले हस्ताक्षर के रूप में काम करता है, साथ ही 8080-संगत प्रोसेसर के लिए RET निर्देश के रूप में काम करता है, जो फ़ाइल को CP/M-80 के पूर्व संस्करणों के अनुसार निष्पादित करने पर शानदार निकास की ओर ले जाता है।^{[nb 1]}

C9h किसी भी x86 प्रोसेसर के लिए प्रोग्राम के पहले बाइट के रूप में कभी भी उपयुक्त नहीं है (विभिन्न पीढ़ियों के लिए इसके भिन्न-भिन्न अर्थ हैं,^{[nb 2]}किन्तु यह कभी भी सार्थक पहली बाइट नहीं होती); डीओएस के कुछ संस्करणों में एक्सेक्यूटेबले लोडर प्रारंभ होने वाली कॉम फ़ाइलों को अस्वीकार कर देता है C9h, गलत संचालन से बचना।

संयुक्त Z80/6502 के लिए समान ऑपकोड ओवरलैपिंग कोड अनुक्रम भी तैयार किए गए हैं,^[17]8086/68000^[17]या x86/MIPS आर्किटेक्चर/ARM आर्किटेक्चर बायनेरिज़।^[16]

सीपी/एम-86 और डॉस के लिए संयुक्त बायनेरिज़

सीपी/एम-86 और डॉस निष्पादन योग्यों के लिए सामान्य फ़ाइल एक्सटेंशन साझा नहीं करते हैं।Cite error: The opening <ref> tag is malformed or has a bad name इस प्रकार, निष्पादनयोग्यों को भ्रमित करना सामान्यतः संभव नहीं है। चूँकि, डीओएस के प्रारंभिक संस्करणों में इसकी वास्तुकला के संदर्भ में CP/M के साथ इतनी समानता थी कि एक्सेक्यूटेबले कोड वाले बायनेरिज़ को साझा करने के लिए कुछ प्रारंभिक डीओएस प्रोग्राम विकसित किए गए थे। ऐसा करने के लिए ज्ञात प्रोग्राम WordStar 3.20|WordStar 3.2x था, जो सीपी/एम-86 और एमएस-डॉस के लिए अपने पोर्ट में समान ओवरले फ़ाइलों का उपयोग करता था,^[27]और रनटाइम (प्रोग्राम जीवनचक्र चरण) में इन ऑपरेटिंग सिस्टम की भिन्न-भिन्न कॉलिंग परंपराओं को अनुकूलित करने के लिए गतिशील रूप से फिक्स्ड-अप कोड का उपयोग किया जाता है।^[27]

सीपी/एम-86 और डॉस के लिए डिजिटल अनुसंधान का ग्राफ़िक्स सिस्टम एक्सटेंशन भी बाइनरी समान 16-बिट ड्राइवर साझा करता है।^[28]

संयुक्त कॉम और SYS फ़ाइलें

डीओएस डिवाइस ड्राइवर (सामान्यतः फ़ाइल एक्सटेंशन .SYS के साथ) फ़ाइल हेडर से प्रारंभ होते हैं जिनके पहले चार बाइट्स परंपरा के अनुसार हेक्साडेसिमल होते हैं, हालांकि यह कोई आवश्यकता नहीं है।^[29]इसे ऑपरेटिंग सिस्टम द्वारा गतिशील रूप से ठीक किया जाता है जब ड्राइवर लोडर (कंप्यूटिंग) करता है (सामान्यतः डीओएस BIOS में जब यह CONFIG.SYS में डिवाइस (CONFIG.SYS निर्देश) कथन निष्पादित करता है)। चूँकि डीओएस प्रति डिवाइस लोड होने वाली .कॉम एक्सटेंशन वाली फ़ाइलों को अस्वीकार नहीं करता है और FFFFFFFFh के लिए परीक्षण नहीं करता है, इसलिए कॉम प्रोग्राम और डिवाइस ड्राइवर को ही फ़ाइल में संयोजित करना संभव है^[30]^[29]फ़ाइल के पहले चार बाइट्स के अंदर एम्बेडेड कॉम प्रोग्राम के प्रवेश बिंदु पर जंप निर्देश रखकर (तीन बाइट्स सामान्यतः पर्याप्त होते हैं)।^[29]यदि एम्बेडेड प्रोग्राम और डिवाइस ड्राइवर अनुभाग कोड या डेटा का सामान्य भाग साझा करते हैं, तब कोड को .कॉम स्टाइल प्रोग्राम के रूप में ऑफसेट +0100h पर और डिवाइस ड्राइवर के रूप में +0000h पर लोड होने से निपटना आवश्यक है।^[30]गलत ऑफसेट पर लोड किए गए किन्तु स्थिति-स्वतंत्र होने के लिए डिज़ाइन नहीं किए गए साझा कोड के लिए, इसके लिए आंतरिक पता फिक्स-अप की आवश्यकता होती है^[30]उसी के समान जो अन्यथा पहले से ही स्थानांतरित लोडर द्वारा किया गया होता, सिवाय इसके कि इस मामले में इसे लोड किए गए प्रोग्राम द्वारा ही किया जाना है; यह स्व-स्थानांतरित करने वाले ड्राइवरों की स्थिति के समान है, किन्तु ऑपरेटिंग सिस्टम के लोडर द्वारा प्रोग्राम पहले से ही लक्ष्य स्थान पर लोड किया गया है।

क्रैश-संरक्षित सिस्टम फ़ाइलें

डॉस के अनुसार , परंपरा के अनुसार, कुछ फाइलों में फ़ाइल एक्सटेंशन होते हैं जो उनके वास्तविक फ़ाइल प्रकार को प्रतिबिंबित नहीं करते हैं।^{[nb 3]}उदाहरण के लिए, COUNTRY.SYS^[31]डीओएस डिवाइस ड्राइवर नहीं है,^{[nb 4]}किन्तु CONFIG.SYS देश (CONFIG.SYS निर्देश) और NLSFUNC (डीओएस कमांड) ड्राइवर के साथ उपयोग के लिए बाइनरी राष्ट्रीय भाषा समर्थन डेटाबेस फ़ाइल।^[31]पीसीडीओएस और DR-डीओएस सिस्टम फ़ाइलें IBMBIO.कॉम और IBMDOS.कॉम बूटस्ट्रैप लोडर द्वारा लोड की गई विशेष बाइनरी छवियां हैं, COM-शैली प्रोग्राम नहीं।^{[nb 4]}DEVICE स्टेटमेंट के साथ COUNTRY.SYS को लोड करने का प्रयास करने या कमांड प्रॉम्प्ट पर IBMBIO.कॉम या IBMDOS.कॉम को निष्पादित करने से अप्रत्याशित परिणाम होंगे।^{[nb 3]}^{[nb 5]}

कभी-कभी ऊपर वर्णित तकनीकों का उपयोग करके इससे बचना संभव होता है। उदाहरण के लिए, DR-डीओएस 7.02 और उच्चतर में मैथियास आर. पॉल द्वारा विकसित सुरक्षा सुविधा सम्मिलित है:^[32]यदि इन फ़ाइलों को अनुचित तरीके से बुलाया जाता है, तब लघु एम्बेडेड स्टब्स बस कुछ फ़ाइल संस्करण जानकारी प्रदर्शित करेंगे और शानदार ढंग से बाहर निकल जाएंगे।^[33]^[32]^[34]^[31]इसके अतिरिक्त, संदेश विशेष रूप से कुछ जादुई संख्या (प्रोग्रामिंग) का पालन करने के लिए तैयार किया गया है बाहरी नेटवेयर और DR-डीओएस संस्करण.EXE फ़ाइल पहचान उपयोगिता द्वारा पहचाने गए जादुई पैटर्न।^[31]^[32]^{[nb 6]}

एक समान सुरक्षा सुविधा 8080 निर्देश थी C7h ( RST 0 ) जे सेज और जो राइट के जेड-प्रणाली टाइप-3 और टाइप-4 Z3ENV प्रोग्रामों की प्रारंभ में^[35]^[36]साथ ही Z3TXT भाषा ओवरले फ़ाइलें,^[37]जिसके परिणामस्वरूप अनुचित तरीके से लोड होने पर सीपी/एम-80 के अनुसार गर्म बूट (क्रैश के अतिरिक्त) हो जाएगा।^[35]^[36]^[37]^{[nb 1]}

एक समान रूप से, परंपरा के अनुसार फ़ाइल हस्ताक्षरों की अनेक (बाइनरी) सूची में सम्मिलित है 1Ah फ़ाइल की प्रारंभ के पास बाइट (ASCII ^Z)। जब किसी फ़ाइल को गैर-बाइनरी मोड में खोला जाता है, तब इस नियंत्रण चरित्र को सॉफ्ट फाइल समाप्त (ईओएफ) मार्कर के रूप में व्याख्या किया जाएगा, और इस प्रकार, अनेक ऑपरेटिंग सिस्टम (पीडीपी-6 -6 मॉनिटर सहित) के अनुसार ^[38]और आरटी-11, ओपन VMS , टॉप -10,^[39]सीपी/एम,^[40]<रेफरी नाम= होगन_1982_सीपी/एम /> डॉस,^[41]और विंडोज़^[42]), यह बाइनरी कचरा प्रदर्शित होने से रोकता है जब कोई फ़ाइल गलती से कंसोल पर मुद्रित हो जाती है।

लिनक्स

FatELF: लिनक्स के लिए यूनिवर्सल बायनेरिज़

फैटईएलएफ लोगो

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

डेवलपर्स के अनुसार, FatELF के अनेक उपयोग-मामले हैं:^[43]* वितरणों को अब विभिन्न प्लेटफार्मों के लिए भिन्न-भिन्न डाउनलोड करने की आवश्यकता नहीं है।

फाइलसिस्टम पदानुक्रम मानक में अब भिन्न /lib, /lib32 और /lib64 पेड़ों की आवश्यकता नहीं है।
सही बाइनरी और लाइब्रेरीज़ को शैल स्क्रिप्ट के अतिरिक्त सिस्टम द्वारा केंद्रीय रूप से चुना जाता है।
यदि ईएलएफ एबीआई किसी दिन परिवर्तितता है, तब विरासती उपयोगकर्ताओं को अभी भी समर्थन दिया जा सकता है।
वेब ब्राउज़र प्लग इन का वितरण जो अनेक प्लेटफार्मों के साथ बॉक्स से बाहर काम करता है।
एक एप्लिकेशन फ़ाइल का वितरण जो लिनक्स और बर्कले सॉफ़्टवेयर वितरण वेरिएंट पर काम करता है, उन पर प्लेटफ़ॉर्म संगतता परत के बिना।
विकास और प्रयोग के लिए हार्ड ड्राइव विभाजन को विभिन्न सीपीयू आर्किटेक्चर वाली विभिन्न मशीनों पर बूट किया जा सकता है। समान रूट फ़ाइल सिस्टम, भिन्न कर्नेल और सीपीयू आर्किटेक्चर।
नेटवर्क शेयर या यूएसबी स्टिक द्वारा प्रदान किए गए एप्लिकेशन, अनेक सिस्टम पर काम करेंगे। यह पोर्टेबल अनुप्रयोग और विषम प्रणालियों के लिए क्लाउड कम्प्यूटिंग छवियां बनाने में भी सहायक है।^[45]

एक प्रूफ़-ऑफ़-कॉन्सेप्ट उबंटू (ऑपरेटिंग सिस्टम)|उबंटू 9.04 छवि उपलब्ध है।^[46] As of 2021^[update], FatELF को मेनलाइन लिनक्स कर्नेल में एकीकृत नहीं किया गया है।^[47]^[48]

विंडोज़

फ़ैटपैक

चूँकि विंडोज़ द्वारा उपयोग किया जाने वाला पोर्टेबल एक्सेक्यूटेबले प्रारूप प्लेटफ़ॉर्म पर कोड निर्दिष्ट करने की अनुमति नहीं देता है, फिर भी लोडर प्रोग्राम बनाना संभव है जो आर्किटेक्चर के आधार पर डिस्पैच करता है। ऐसा इसलिए है क्योंकि एआरएम पर विंडोज के डेस्कटॉप संस्करणों में 32-बिट x86 इम्यूलेशन के लिए समर्थन है, जो इसे उपयोगी सार्वभौमिक मशीन कोड लक्ष्य बनाता है। फ़ैटपैक लोडर है जो अवधारणा को प्रदर्शित करता है: इसमें 32-बिट x86 प्रोग्राम सम्मिलित है जो अपने संसाधन अनुभागों में पैक किए गए एक्सेक्यूटेबले को एक-एक करके चलाने का प्रयास करता है।^[49]

आर्म64एक्स

Windows 11 ARM64 विकसित करते समय, Microsoft ने Arm64X नामक पोर्टेबल एक्सेक्यूटेबले प्रारूप का विस्तार करने का नया विधि प्रस्तुत किया।^[50]एक Arm64X बाइनरी में वह सभी सामग्री सम्मिलित होती है जो भिन्न-भिन्न x64/Arm64EC और Arm64 बायनेरिज़ में होती है, किन्तु डिस्क पर और अधिक कुशल फ़ाइल में विलय हो जाती है। ऐसे बायनेरिज़ के निर्माण में सहायता के लिए विज़ुअल C++ टूलसेट को अपग्रेड किया गया है। और जब Arm64X बायनेरिज़ का निर्माण तकनीकी रूप से कठिन हो, तब डेवलपर्स इसके अतिरिक्त Arm64X शुद्ध फ़ॉरवर्डर DLL का निर्माण कर सकते हैं।^[51]

समान अवधारणाएँ

निम्नलिखित दृष्टिकोण फैट बायनेरिज़ के समान हैं, जिसमें ही उद्देश्य के मशीन कोड के अनेक संस्करण ही फ़ाइल में प्रदान किए जाते हैं।

विषम कंप्यूटिंग

2007 के पश्चात् से, विषम कंप्यूटिंग के लिए कुछ विशेष कंपाइलर अनेक प्रकार के प्रोसेसर पर समानांतर कंप्यूटिंग के लिए कोड फाइलें तैयार करते हैं, यानी इंटेल एक्सोची (एक्सोस्केलेटन सीक्वेंसर) डेवलपमेंट सूट से सीएचआई (सी (प्रोग्रामिंग भाषा) विषम एकीकरण के लिए) कंपाइलर मल्टीथ्रेडिंग (सॉफ्टवेयर) के लिए ओपनएमपी निर्देश (प्रोग्रामिंग) अवधारणा का विस्तार करता है ताकि विभिन्न निर्देश सेट आर्किटेक्चर के लिए कोड अनुभागों वाले वसा बायनेरिज़ का उत्पादन किया जा सके। आईएसए) जिससे रनटाइम सिस्टम लोडर विषम सिस्टम वातावरण में अनेक उपलब्ध सीपीयू और जीपीयू कोर पर समानांतर निष्पादन को गतिशील रूप से प्रारंभ कर सकता है।^[52]^[53]

फरवरी 2007 में प्रस्तुत किया गया, ए NVIDIA का समानांतर कंप्यूटिंग प्लेटफॉर्म CUDA (कंप्यूट यूनिफाइड डिवाइस आर्किटेक्चर) GPU (GPGPU) पर सामान्य-उद्देश्य कंप्यूटिंग को सक्षम करने के लिए सॉफ्टवेयर है। इसका एलएलवीएम-आधारित कंपाइलर एनवीसीसी (संकलक) तथाकथित समानांतर थ्रेड निष्पादन वर्चुअल सभा की भाषा (टेक्स्ट के रूप में) युक्त एक्सेक्यूटेबले और लिंक करने योग्य प्रारूप-आधारित फैट बायनेरिज़ बना सकता है, जिसे सीयूडीए रनटाइम ड्राइवर पश्चात् में कुछ एसएएसएस (स्ट्रीमिंग असेंबलर) में जस्ट-इन-टाइम कंपाइलेशन | जस्ट-इन-टाइम कंपाइल कर सकता है।) वास्तव में उपस्तिथ लक्ष्य GPU के लिए बाइनरी एक्सेक्यूटेबले कोड। एक्सेक्यूटेबले में तथाकथित CUDA बायनेरिज़ (उर्फ क्यूबिन फ़ाइलें) भी सम्मिलित हो सकती हैं जिनमें या अधिक विशिष्ट GPU आर्किटेक्चर के लिए समर्पित एक्सेक्यूटेबले कोड अनुभाग सम्मिलित हैं जिनमें से CUDA रनटाइम लोड-टाइम पर चुन सकता है।^[54]^[55]^[56]^[57]^[58]^[59]फैट बायनेरिज़ का भी समर्थन किया जाता है GPGPU-Sim [de], GPU माइक्रोआर्किटेक्चर सिमुलेशन 2007 में भी प्रस्तुत किया गया था।^[60]^[61]

मुलतक़सम (कैंची), ओपनसीएल विषम प्रणाली सिम्युलेटर ढांचा (मूल रूप से केवल एमआईपीएस आर्किटेक्चर या x86 सीपीयू के लिए, किन्तु पश्चात् में उन्नत माइक्रो डिवाइसेस/एटीआई टेक्नोलॉजीज एएमडी सदाबहार और एएमडी दक्षिणी द्वीप समूह के साथ-साथ एनवीडिया फर्मी और एनवीडिया केपलर परिवारों जैसे एआरएम आर्किटेक्चर सीपीयू और जीपीयू का भी समर्थन करने के लिए विस्तारित किया गया)^[62]ईएलएफ-आधारित वसा बायनेरिज़ का भी समर्थन करता है।^[63]^[62]

मोटी वस्तुएं

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

फ़ंक्शन बहु-संस्करण

यहां तक कि समान निर्देश सेट आर्किटेक्चर के लिए इच्छित प्रोग्राम या लाइब्रेरी (कंप्यूटिंग) में भी, प्रोग्रामर पूर्व सीपीयू के साथ संगतता बनाए रखते हुए कुछ नए निर्देश सेट एक्सटेंशन का उपयोग करना चाह सकता है। इसे फ़ंक्शन मल्टी-वर्जनिंग (एफएमवी) के साथ प्राप्त किया जा सकता है: ही फ़ंक्शन के संस्करण प्रोग्राम में लिखे जाते हैं, और कोड का टुकड़ा सीपीयू की क्षमताओं का पता लगाकर यह तय करता है कि किसका उपयोग करना है (जैसे कि सीपीयू आईडी के माध्यम से)। इंटेल C++ कंपाइलर, जीसीसी और एलएलवीएम सभी में स्वचालित रूप से बहु-संस्करण फ़ंक्शन उत्पन्न करने की क्षमता है।^[65]यह बिना किसी अर्थ संबंधी प्रभाव के गतिशील प्रेषण का रूप है।

अनेक गणित लाइब्रेरीों में हस्तलिखित असेंबली रूटीन की सुविधा होती है जो सीपीयू क्षमता के अनुसार स्वचालित रूप से चुनी जाती हैं। उदाहरणों में glibc, इंटेल MKL और OpenBLAS सम्मिलित हैं। इसके अतिरिक्त, glibc में लाइब्रेरी लोडर विशिष्ट सीपीयू सुविधाओं के लिए वैकल्पिक पथों से लोडिंग का समर्थन करता है।^[66]

एक समान, किन्तु बाइट-लेवल ग्रैन्युलर दृष्टिकोण जो मूल रूप से मैथियस आर। पॉल और एक्सल सी। फ्रिंके द्वारा तैयार किया गया है, लघु से आत्म-विनाश, निर्देश छूट और स्थानांतरित लोडर को एक्सेक्यूटेबले फ़ाइल में एंबेडेड करने के लिए है, जो कि किसी भी तरह के कार्यक्रम के लिए विशेष रूप से प्रकार के प्रकार के प्रकार के प्रकार के लिए (या विशेष रूप से प्रकार के प्रकार के प्रकार के रूप में है। ।^[67]^[68]^[69]^[70]

यह भी देखें

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

↑ ^1.0 ^1.1 ^1.2 This works because a (suitable) return instruction can be used to exit programs under CP/M-80, CP/M-86 and DOS, although the opcodes, exact conditions and underlying mechanisms differ: Under CP/M-80, programs can terminate (that is, warm boot into the BIOS) by jumping to 0 in the zero page, either directly with RST 0 (8080/8085/Z80 opcode C7h), or by calling BDOS function 0 through the CALL 5 interface. Alternatively, as the stack is prepared to hold a 0 return address before passing control to a loaded program, they can, for as long as the stack is aligned, also be exited by issuing a RET (opcode C9h) instruction, thereby falling into the terminating code at offset 0 in the zero page. Although DOS has a dedicated INT 20h interrupt as well as INT 21h API sub-functions to terminate programs (which are preferable for more complicated programs), for machine-translated programs DOS also emulates CP/M's behaviour to some extent: A program can terminate itself by jumping to offset 0 in its PSP (the equivalent to CP/M's zero page), where the system had previously planted an INT 20h instruction. Also, a loaded program's initial stack is prepared to hold a word of 0, so that a program issuing a near return RETN (8088/8086 opcode C3h) will implicitly jump to the start of its code segment as well, thereby eventually reaching the INT 20h as well.^[a] In CP/M-86, the zero page is structured differently and there is no CALL 5 interface, but the stack return method and BDOS function 0 (but now through INT E0h) both work as well.
↑ On 8088/8086 processors, the opcode C9h is an undocumented alias for CBh ("RETF", popping CS:IP from the stack), whereas it decodes as "LEAVE" (set SP to BP and pop BP) on 80188/80186 and newer processors.
↑ ^3.0 ^3.1 This problem could have been avoided by choosing non-conflicting file extensions, but, once introduced, these particular file names were retained from very early versions of MS-DOS/PC DOS for compatibility reasons with (third-party) tools hard-wired to expect these specific file names.
↑ ^4.0 ^4.1 Other DOS files of this type are KEYBOARD.SYS, a binary keyboard layout database file for the keyboard driver KEYB under MS-DOS and PC DOS, IO.SYS containing the DOS BIOS under MS-DOS, and MSDOS.SYS, a text configuration file under Windows 95/MS-DOS 7.0 and higher, but originally a binary system file containing the MS-DOS kernel. However, MS-DOS and PC DOS do not provide crash-protected system files at all, and these file names are neither used nor needed in DR-DOS 7.02 and higher, which otherwise does provide crash-protected system files.
↑ This is the reason why these files have the hidden attribute set, so that they are not listed by default, thereby reducing the risk of being invoked accidentally.
↑ The COUNTRY.SYS file formats supported by the MS-DOS/PC DOS and the DR-DOS families of operating systems contain similar data but are organized differently and incompatible. Since the entry points into the data structures are at different offsets in the file it is possible to create "fat" COUNTRY.SYS databases, which could be used under both DOS families.^[b] However, DR-DOS 7.02 and its NLSFUNC 4.00 (and higher) include an improved parser capable of reading both types of formats (and variants), even at the same time, so that Janus-headed files are not necessary.^[c]^[d] The shipped files are nevertheless "fat" for including a tiny executable stub just displaying an embedded message when invoked inappropriately.^[d]^[b]

Cite error: <ref> tag with name "NB_CP/M-86" defined in <references> is not used in prior text.

संदर्भ

↑ Devanbu, Premkumar T.; Fong, Philip W. L.; Stubblebine, Stuart G. (19–25 April 1998). "3.3 Java and TH" (PDF). Techniques for Trusted Software Engineering. Proceedings of the 20th International Conference on Software Engineering. Proceedings - International Conference on Software Engineering. Kyoto, Japan. p. 131. doi:10.1109/ICSE.1998.671109. ISBN 0-8186-8368-6. ISSN 0270-5257. Archived from the original (PDF) on 2014-01-16. Retrieved 2021-09-29. (10 pages)
↑ Pero, Nicola (2008-12-18). "gnustep/tools-make: README.Packaging". GitHub. Archived from the original on 2022-05-25. Retrieved 2022-05-26.
↑ "PackagingDrafts/GNUstep". Fedora Project Wiki. 2009-02-25. Archived from the original on 2022-05-25. Retrieved 2022-05-26.
↑ "Domain System Software Release Notes, Software Release 10.1" (PDF) (first printing ed.). Chelmsford, Massachusetts, USA: Apollo Computer Inc. December 1988. p. 2-16. Order No. 005809-A03. Retrieved 2022-07-24. (256 pages)
↑ ^5.0 ^5.1 Engst, Adam C. (1994-08-22). "Should Fat Binaries Diet?". TidBITS. No. 240. TidBITS Publishing Inc. ISSN 1090-7017. Archived from the original on 2021-09-29. Retrieved 2021-09-29.
↑ ^6.0 ^6.1 Engst, Adam C. (1994-08-29). "Fat Binary Comments". TidBITS. No. 241. TidBITS Publishing Inc. ISSN 1090-7017. Archived from the original on 2021-09-29. Retrieved 2021-09-29.
↑ "Chapter 1 - Resource Manager / Resource Manager Reference - Resource File Format". Inside Macintosh: Mac OS Runtime Architectures. Apple Computer. 1996-07-06. Archived from the original on 2021-09-29. Retrieved 2021-09-29.
↑ "Chapter 7 - Fat Binary Programs - Creating Fat Binary Programs". Inside Macintosh: Mac OS Runtime Architectures. Apple Computer. 1997-03-11. Archived from the original on 2021-09-29. Retrieved 2011-06-20. [1]
↑ "Chapter 8 - PEF Structure". Inside Macintosh: Mac OS Runtime Architectures. Apple Computer. 1997-03-11. Archived from the original on 2021-09-29. Retrieved 2021-09-29.
↑ Tevanian, Avadis; DeMoney, Michael; Enderby, Kevin; Wiebe, Douglas; Snyder, Garth (1995-07-11) [1993-08-20]. "Method and apparatus for architecture independent executable files" (PDF). Redwood City, California, USA: NeXT Computer, Inc. US patent 5432937A. Archived (PDF) from the original on 2020-12-14. Retrieved 2022-05-26. [2] (9 pages); Tevanian, Avadis; DeMoney, Michael; Enderby, Kevin; Wiebe, Douglas; Snyder, Garth (1997-02-18) [1995-02-28]. "Method and apparatus for architecture independent executable files" (PDF). Redwood City, California, USA: NeXT Computer, Inc. US patent 5604905A. Archived (PDF) from the original on 2022-05-26. Retrieved 2022-05-26. (9 pages)
↑ "Universal Binaries and 32-bit/64-bit PowerPC Binaries". Mac OS X ABI Mach-O File Format Reference. Apple Inc. 2009-02-04 [2003]. Archived from the original on 2012-04-27.
↑ Singh, Amit (2006-06-19). "2.6.2 Fat Binaries". Mac OS X Internals - A Systems Approach. Pearson Education. p. 66. ISBN 978-0-13270226-3. Retrieved 2021-09-28.
↑ "रेफ़िट - ईएफआई फैट बायनेरिज़". refit.sourceforge.net. Retrieved 2022-10-18.
↑ Paul, Matthias R. (2002-10-07) [2000]. "Re: Run a COM file". Newsgroup: alt.msdos.programmer. Archived from the original on 2017-09-03. Retrieved 2017-09-03. [3] (NB. Has details on DOS COM program calling conventions.)
↑ ^15.0 ^15.1 ^15.2 Wilkinson, William "Bill" Albert (2005-04-02) [2003, 1999-02-16, February 1987, 1986-11-15, 1986-11-10]. Written at Heath Company, USA. "Something COMmon About MS-DOS and CP/M". REMark. Vol. 8, no. 2. St. Joseph, Michigan, USA: Heath/Zenith Users' Group (HUG). pp. 55–57. #85. P/N 885-2085. Archived from the original on 2021-12-13. [4]
↑ ^16.0 ^16.1 ^16.2 Cha, Sang Kil; Pak, Brian; Brumley, David; Lipton, Richard Jay (2010-10-08) [2010-10-04]. Platform-Independent Programs (PDF). Proceedings of the 17th ACM conference on Computer and Communications Security (CCS'10). Chicago, Illinois, USA: Carnegie Mellon University, Pittsburgh, Pennsylvania, USA / Georgia Institute of Technology, Atlanta, Georgia, USA. pp. 547–558. doi:10.1145/1866307.1866369. ISBN 978-1-4503-0244-9. Archived (PDF) from the original on 2022-05-26. Retrieved 2022-05-26. [5] (12 pages) (See also: [6]) (NB. Does not address the scenario specifically for 8080 vs. 8086 instruction set architectures (as for CP/M and DOS), but describes the general "self-identifying program" concept of platform-independent programs (PIPs) through what the authors call a gadget header (that is, chunks of program logic not to be confused with ROP gadgets) for x86, MIPS and ARM: i.e. 0Eh, B2h, 02h, A9h, 0Eh, B2h, 02h, 3Ah, 24h, 77h, 01h, 04h or 90h, EBh, 20h, 2Ah, 90h, EBh, 20h, 3Ah, 24h, 77h, 01h, 04h.)
↑ ^17.0 ^17.1 ^17.2 ^17.3 ^17.4 ^17.5 Wilkinson, William "Bill" Albert; Seligman, Cory; Drushel, Richard F.; Harston, Jonathan Graham; Elliott, John C. (1999-02-17). "MS-DOS & CP/M-Compatible Binaries". Newsgroup: comp.os.cpm. Archived from the original on 2021-12-13. Retrieved 2021-12-13. (NB. Some of the opcodes in Elliott's example code (EBh, 44h, EBh and EBh, 04h, ...) might be mixed up.)
↑ ^18.0 ^18.1 Elliott, John C. (2009-10-27). "CP/M info program". Newsgroup: comp.os.cpm. Archived from the original on 2021-12-13. Retrieved 2021-12-13. […] DOS protection feature […] The idea is based on the utilities in Simeon Cran's MYZ80 emulator; the DOS-protection header in those goes one better by not changing any Z80 registers. The magic sequence is EB 52 EB: […] XCHG […] MOV D,D […] XCHG […] but that means the DOS code ends up quite a way away from the start of the program. […] More fun can be had with self-extract PMArc archives. Start one with […] defb 0EBh, 018h, '-pms-' […] and it's treated as a valid archive by the PMA utilities, sends 8086 processors to 011Ah, and Z80 processors to 0130h. […]
↑ ChristW (2012-11-14) [2012-11-13]. Chen, Raymond (ed.). "Microsoft Money crashes during import of account transactions or when changing a payee of a downloaded transaction". The New Old Thing. Archived from the original on 5 July 2018. Retrieved 2018-05-19. […] byte sequence […] EB 03 C3 yy xx […] If you create a .COM file with those 5 bytes as the first ones […] you'll see 'JMP SHORT 3', followed by 3 garbage bytes. […] If you look at a Z80 disassembly […] that translates to 'EX DE,HL; INC BC;' […] The 3rd byte is 'JUMP' followed by the 16-bit address specified as yy xx […] you'll have a .COM file that runs on MS-DOS and […] CP/M […] (NB. While the author speaks about the Z80, this sequence also works on the 8080 and compatible processors.)
↑ Brehm, Andrew J. (2016). "CP/M and MS-DOS Fat Binary". DesertPenguin.org. Archived from the original on 2018-05-19. Retrieved 2018-05-19. (NB. While the article speaks about the Z80, the code sequence also works on the 8080 and compatible processors.)
↑ Elliott, John C. (1996-06-13). "Upload to micros.hensa.ac.uk". Newsgroup: comp.os.cpm. Archived from the original on 2021-12-13. Retrieved 2021-12-13. […] FATBIN 1.00 - combine a CP/M .COM file and a DOS .COM file to create one which runs on both platforms. […] It was used to create: […] MSODBALL 2.05 - convert floppy discs between Amstrad 706k format and a DOS 706k format. […] Both the programs run under CP/M-80 and DOS. […]
↑ Elliott, John C. (1998-06-28) [1997-04-01]. "FATBIN v1.01". Archived from the original on 1998-06-28. (NB. FATBN101.COM 22k 1997-04-01 FATBIN v1.01. Creates fat binary files which will run under both CP/M and DOS. Distributed in a self-extracting archive for CP/M-80 and DOS.)
↑ Elliott, John C. (2002-03-11). "DSKWRITE v1.00". Fossies - the Fresh Open Source Software Archive. Archived from the original on 2021-12-12. Retrieved 2021-12-12. […] DSKWRITE.Z80 contains source for the CP/M version. […] DSKWRITE.ASM contains source for the DOS version. […] To get the single .COM file, you need to use FBMAKE: […] [7] (NB. Mentions FBMAKE from the FATBNSEA.COM package.)
↑ ^24.0 ^24.1 Elliott, John C. (2012-06-20) [2005-01-05]. "Generic CP/M". Seasip.info. Archived from the original on 2021-11-17. Retrieved 2021-12-12. […] Self-extracting archives are .COM files containing a number of smaller files. When you run one, it will create its smaller files […] The self-extract archive programs will run under DOS (2 or later) or CP/M, with identical effects. To extract them under Unix, you can use ZXCC […] FATBNSEA.COM […] FATBIN combines a CP/M-80 .COM file and a DOS .COM file to produce one that will work on both systems. […] M3C4SEA.COM […] M3CONV version 4 - converts Spectrum snapshots in the .Z80 or .SNA format to or from Multiface 3 format (Multiface 3 -> Z80 only on a PC). […] PMSFX21X.COM […] PMSFX is the program that was used to generate these self-unpacking archives. This version (2.11) can generate archives which unpack themselves under CP/M or DOS. You will need PMARC to use PMSFX. New: Under DOS, it supports exact file sizes. […] SP2BMSEA.COM […] Converts a Stop Press Canvas file to a Windows .BMP […] [8]
↑ Elliott, John C. (1997-01-18) [1997-01-11]. "PMSFX 2". Newsgroup: comp.os.cpm. Archived from the original on 2021-12-13. Retrieved 2021-12-13. […] I've written a version of PMSFX that produces .COM files unpackable under DOS and CP/M (the first three bytes are both legal Z80 code, legal 8086 code and legal PMA header) […] as a self-extracting archive. […]
↑ Elliott, John C.; Lopushinsky, Jim (2002) [1998-04-11]. "CP/M 3 COM file header". Seasip.info. Archived from the original on 2016-08-30. Retrieved 2016-08-29.
↑ ^27.0 ^27.1 Necasek, Michal (2018-01-30) [2018-01-28, 2018-01-26]. "WordStar Again". OS/2 Museum. Archived from the original on 2019-07-28. Retrieved 2019-07-28. […] The reason to suspect such difference is that version 3.2x also supported CP/M-86 (the overlays are identical between DOS and CP/M-86, only the main executable is different) […] the .OVR files are 100% identical between DOS and CP/M-86, with a flag (clearly shown in the WordStar 3.20 manual) switching between them at runtime […] the OS interface in WordStar is quite narrow and well abstracted […] the WordStar 3.2x overlays are 100% identical between the DOS and CP/M-86 versions. There is a runtime switch which chooses between calling INT 21h (DOS) and INT E0h (CP/M-86). WS.COM is not the same between DOS and CP/M-86, although it's probably not very different either. […]
↑ Lineback, Nathan. "GSX Screen Shots". Toastytech.com. Archived from the original on 2020-01-15. Retrieved 2020-01-15.
↑ ^29.0 ^29.1 ^29.2 Paul, Matthias R. (2002-04-11). "Re: [fd-dev] ANNOUNCE: CuteMouse 2.0 alpha 1". freedos-dev. Archived from the original on 2020-02-21. Retrieved 2020-02-21. […] FreeKEYB is […] a true .COM and .SYS driver (tiny model) in one. You can safely overwrite the first JMP, that's part of what I meant by "tricky header". […] you can replace the FFFFh:FFFFh by a 3-byte jump and a pending DB FFh. It works with MS-DOS, PC DOS, DR-DOS, and most probably any other DOS issue as well. […]
↑ ^30.0 ^30.1 ^30.2 Paul, Matthias R. (2002-04-06). "Re: [fd-dev] ANNOUNCE: CuteMouse 2.0 alpha 1". freedos-dev. Archived from the original on 2020-02-07. Retrieved 2020-02-07. […] Add a SYS device driver header to the driver, so that CTMOUSE could be both in one, a normal TSR and a device driver - similar to our FreeKEYB advanced keyboard driver. […] This is not really needed under DR DOS because INSTALL= is supported since DR DOS 3.41+ and DR DOS preserves the order of [D]CONFIG.SYS directives […] but it would […] improve the […] flexibility on MS-DOS/PC DOS systems, which […] always execute DEVICE= directives prior to any INSTALL= statements, regardless of their order in the file. […] software may require the mouse driver to be present as a device driver, as mouse drivers have always been device drivers back in the old times. These mouse drivers have had specific device driver names depending on which protocol they used ("PC$MOUSE" for Mouse Systems Mode for example), and some software may search for these drivers in order to find out the correct type of mouse to be used. […] Another advantage would be that device drivers usually consume less memory (no environment, no PSP) […] It's basically a tricky file header, a different code to parse the command line, a different entry point and exit line, and some segment magics to overcome the ORG 0 / ORG 100h difference. Self-loadhighing a device driver is a bit more tricky as you have to leave the driver header where it is and only relocate the remainder of the driver […]
↑ ^31.0 ^31.1 ^31.2 ^31.3 Paul, Matthias R. (2001-06-10) [1995]. "DOS COUNTRY.SYS file format" (COUNTRY.LST file) (1.44 ed.). Archived from the original on 2016-04-20. Retrieved 2016-08-20.
↑ ^32.0 ^32.1 ^32.2 Paul, Matthias R. (1997-07-30) [1994-05-01]. "Chapter II.4. Undokumentierte Eigenschaften externer Kommandos - SYS.COM". NWDOS-TIPs — Tips & Tricks rund um Novell DOS 7, mit Blick auf undokumentierte Details, Bugs und Workarounds. Archived from the original on 2017-09-10. Retrieved 2014-08-06. Für ein zukünftiges Update für Calderas OpenDOS 7.01 habe ich den Startcode von IBMBIO.COM so modifiziert, daß er - falls fälschlicherweise als normales Programm gestartet - ohne Absturz zur Kommandozeile zurückkehrt. Wann diese Sicherheitsfunktion in die offizielle Version Einzug halten wird, ist jedoch noch nicht abzusehen. {{cite book}}: |work= ignored (help) (NB. NWDOSTIP.TXT is a comprehensive work on Novell DOS 7 and OpenDOS 7.01, including the description of many undocumented features and internals. It is part of the author's yet larger MPDOSTIP.ZIP collection maintained up to 2001 and distributed on many sites at the time. The provided link points to a HTML-converted older version of the NWDOSTIP.TXT file.) [9]
↑ Paul, Matthias R. (1997-10-02). "Caldera OpenDOS 7.01/7.02 Update Alpha 3 IBMBIO.COM README.TXT". Archived from the original on 2003-10-04. Retrieved 2009-03-29. [10]
↑ DR-DOS 7.03 WHATSNEW.TXT - Changes from DR-DOS 7.02 to DR-DOS 7.03. Caldera, Inc. 1998-12-24. Archived from the original on 8 April 2019. Retrieved 2019-04-08.
↑ ^35.0 ^35.1 Sage, Jay (May–June 1988). Carlson, Art (ed.). "ZCPR 3.4 - Type-4 Programs". The Computer Journal (TCJ) - Programming, User Support, Applications. ZCPR3 Corner. Columbia Falls, Montana, USA (32): 10–17 [16]. ISSN 0748-9331. ark:/13960/t1wd4v943. Retrieved 2021-11-29. [11][12]
↑ ^36.0 ^36.1 Sage, Jay (May–June 1992) [March–June 1992]. Carlson, Art; McEwen, Chris (eds.). "Type-3 and Type-4 Programs". The Computer Journal (TCJ) - Programming, User Support, Applications. Z-System Corner - Some New Applications of Type-4 Programs. S. Plainfield, New Jersey, USA: Socrates Press (55): 13–19 [14, 16]. ISSN 0748-9331. ark:/13960/t4dn54d22. Retrieved 2021-11-29. [13][14]
↑ ^37.0 ^37.1 Sage, Jay (November–December 1992). Carlson, Art; Kibler, Bill D. (eds.). "Regular Feature, ZCPR Support, Language Independence, part 2". The Computer Journal (TCJ) - Programming, User Support, Applications. The Z-System Corner. Lincoln, CA, USA (58): 7–10. ISSN 0748-9331. ark:/13960/t70v9g87h. Retrieved 2020-02-09. […] there was an opcode of "RST 0", which, if executed, would result in a warm boot. A file containing a Z3TXT module should never be executed, but at a cost of one byte we could protect ourself against that outside chance. The header also contained the string of characters "Z3TXT" followed by a null (0) byte. Many Z-System modules include such identifiers. In this category are resident command packages (RCPs), flow command packages (FCPs), and environment descriptor modules (Z3ENVs). Programs, such as Bridger Mitchell's […] JETLDR.COM, that load these modules from files into memory can use the ID string to validate the file, that is, to make sure that it is the kind of module that the user has stated it to be. User mistakes and damaged files can thus be detected. […] The header, thus, now stands as follows: […] rst […] db 'Z3TXT',0 ; null-terminated ID […] ; 12345678 ; must be 8 characters, […] db 'PROGNAME' ; pad with spaces […] ; 123 ; must be 3 characters […] db 'ENG' ; name of language […] dw LENGTH ; length of module […] [15][16]
↑ "Table of IO Device Characteristics - Console or Teletypewriters". PDP-6 Multiprogramming System Manual (PDF). Maynard, Massachusetts, USA: Digital Equipment Corporation (DEC). 1965. p. 43. DEC-6-0-EX-SYS-UM-IP-PRE00. Archived (PDF) from the original on 2014-07-14. Retrieved 2014-07-10. (1+84+10 pages)
↑ "5.1.1.1. Device Dependent Functions - Data Modes - Full-Duplex Software A(ASCII) and AL(ASCII Line)". PDP-10 Reference Handbook: Communicating with the Monitor - Time-Sharing Monitors (PDF). Vol. 3. Digital Equipment Corporation (DEC). 1969. pp. 5-3–5-6 [5-5 (431)]. Archived (PDF) from the original on 2011-11-15. Retrieved 2014-07-10. (207 pages)
↑ "2. Operating System Call Conventions". CP/M 2.0 Interface Guide (PDF) (1 ed.). Pacific Grove, California, USA: Digital Research. 1979. p. 5. Archived (PDF) from the original on 2020-02-28. Retrieved 2020-02-28. […] The end of an ASCII file is denoted by a control-Z character (1AH) or a real end of file, returned by the CP/M read operation. Control-Z characters embedded within machine code files (e.g., COM files) are ignored, however, and the end of file condition returned by CP/M is used to terminate read operations. […] (56 pages)
↑ BC_Programmer (2010-01-31) [2010-01-30]. "Re: Copy command which merges several files tags the word SUB at the end". Computer Hope Forum. Archived from the original on 2020-02-26. Retrieved 2020-02-26.
↑ "What are the differences between Linux and Windows .txt files (Unicode encoding)". Superuser. 2011-08-03 [2011-06-08]. Archived from the original on 2020-02-26. Retrieved 2020-02-26.
↑ ^43.0 ^43.1 Gordon, Ryan C. (October 2009). "FatELF: Universal Binaries for Linux". icculus.org. Archived from the original on 2020-08-27. Retrieved 2010-07-13.
↑ Gordon, Ryan C. (November 2009). "FatELF specification, version 1". icculus.org. Archived from the original on 2020-08-27. Retrieved 2010-07-25.
↑ Windisch, Eric (2009-11-03). "Subject: Newsgroups: gmane.linux.kernel, Re: FatELF patches..." gmane.org. Archived from the original on 2016-11-15. Retrieved 2010-07-08.
↑ Gordon, Ryan C. (2009). "FatELF: Universal Binaries for Linux. - The proof-of-concept virtual machine download page". icculus.org. Archived from the original on 2022-05-21. Retrieved 2022-05-26. (NB. VM image of Ubuntu 9.04 with Fat Binary support.)
↑ Holwerda, Thom (2009-11-05). "Ryan Gordon Halts FatELF Project". Linux. osnews.com. Archived from the original on 2022-05-26. Retrieved 2010-07-05.
↑ Brockmeier, Joe "Zonker" (2010-06-23). "SELF: Anatomy of an (alleged) failure". LWN.net. Linux Weekly News. Archived from the original on 2022-05-26. Retrieved 2011-02-06.
↑ Mulder, Sijmen J. (2021-03-06) [2018-04-25]. "sjmulder/fatpack - Build multi-architecture 'fat' binaries for Windows". GitHub. Archived from the original on 2022-05-26. Retrieved 2022-05-26.
↑ "Arm64X PE files". learn.microsoft.com. Microsoft. 2023-03-31 [2022-08-12]. Retrieved 2023-03-31.{{cite web}}: CS1 maint: url-status (link)
↑ "Build Arm64X binaries". learn.microsoft.com. Microsoft. 2023-03-31 [2023-03-09]. Retrieved 2023-03-31.{{cite web}}: CS1 maint: url-status (link)
↑ Wang, Perry H.; Collins, Jamison D.; Chinya, Gautham N.; Jiang, Hong; Tian, Xinmin; Girkar, Milind; Yang, Nick Y.; Lueh, Guei-Yuan; Wang, Hong (June 2007). "EXOCHI: architecture and programming environment for a heterogeneous multi-core multithreaded system". ACM SIGPLAN Notices. 42 (6): 156–166. doi:10.1145/1273442.1250753. (11 pages)
↑ Wang, Perry H.; Collins, Jamison D.; Chinya, Gautham N.; Jiang, Hong; Tian, Xinmin; Girkar, Milind; Pearce, Lisa; Lueh, Guei-Yuan; Yakoushkin, Sergey; Wang, Hong (2007-08-22). "Accelerator Exoskeleton" (PDF). Intel Technology Journal. Intel Corporation. 11: Tera-scale Computing (3): 185–196. doi:10.1535/itj.1103. ISSN 1535-864X. Archived (PDF) from the original on 2022-05-26. Retrieved 2022-05-26. (12 of 1+vii+90+1 pages)
↑ "cudaFatFormat.h / ptxomp.c". 1.13. Nvidia Corporation. 2004-11-15. Archived from the original on 2022-05-26. Retrieved 2022-05-26.
↑ Harris, Mark J. (2014-05-08) [2013-06-05]. "Technical Walkthrough: CUDA Pro Tip: Understand Fat Binaries and JIT Caching". Nvidia Developer. Nvidia. Archived from the original on 2022-03-23. Retrieved 2022-05-26.
↑ "CUDA Binary Utilities" (PDF) (Application Note). 6.0. Nvidia. February 2014. DA-06762-001_v6.0. Archived (PDF) from the original on 2022-05-25. Retrieved 2022-05-25.
↑ "fatbinary - help". helpmanual.io. 8.0. 2016. Archived from the original on 2022-05-25. Retrieved 2022-05-25.
↑ "CUDA Compiler Driver NVCC - Reference Guide" (PDF). 11.7. Nvidia. May 2022. TRM-06721-001_v11.7. Archived (PDF) from the original on 2022-05-25. Retrieved 2022-05-25.
↑ Braun, Lorenz; Fröning, Holger (2019-11-18). CUDA Flux: A Lightweight Instruction Profiler for CUDA Applications (PDF). IEEE/ACM Performance Modeling, Benchmarking and Simulation of High Performance Computer Systems (PMBS). Denver, Colorado, USA: IEEE. doi:10.1109/PMBS49563.2019.00014. ISBN 978-1-7281-5977-5. Archived (PDF) from the original on 2022-03-21. Retrieved 2022-05-26.
↑ Fung, Wilson W. L.; Sham, Ivan; Yuan, George; Aamodt, Tor M. (2007). "Dynamic Warp Formation and Scheduling for Efficient GPU Control Flow" (PDF). Vancouver, British Columbia, Canada. Archived (PDF) from the original on 2022-05-26. Retrieved 2022-05-26. (12 pages)
↑ Bakhoda, Ali; Yuan, George L.; Fung, Wilson W. L.; Wong, Henry; Aamodt, Tor M. (2009-04-28) [2009-04-26]. Analyzing CUDA Workloads Using a Detailed GPU Simulator (PDF). Proceedings of the IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS). Boston, Massachusetts, USA. pp. 163–174. doi:10.1109/ISPASS.2009.4919648. Archived (PDF) from the original on 2022-05-26. Retrieved 2022-05-06. [17]
↑ ^62.0 ^62.1 "13.4 The AMD Compiler Wrapper: Fat binaries". The Multi2Sim Simulation Framework - A CPU-GPU Model for Heterogeneous Computing (PDF). 2013. pp. 173–176 [176]. Archived (PDF) from the original on 2022-05-25. Retrieved 2022-05-25. {{cite book}}: |website= ignored (help) (4 of 210 pages)
↑ Ubal, Rafael; Jang, Byunghyun; Mistry, Perhaad; Schaa, Dana; Kaeli, David R. (2012-09-23) [2012-09-19]. "Multi2Sim: A Simulation Framework for CPU-GPU Computing" (PDF). 21st International Conference on Parallel Architectures and Compilation Techniques (PACT). Minneapolis, Minnesota, USA: IEEE. ISBN 978-1-4503-1182-3. Archived (PDF) from the original on 2022-05-25. Retrieved 2022-05-25. (10 pages)
↑ "LTO Overview (GNU Compiler Collection (GCC) Internals)". gcc.gnu.org. Archived from the original on 2021-09-12. Retrieved 2021-09-12.
↑ Wennborg, Hans (2018). "Attributes in Clang". Clang 7 documentation. Archived from the original on 2022-04-07. Retrieved 2022-05-26.
↑ Bahena, Victor Rodriguez (2018-04-03). "Transparent use of library packages optimized for Intel architecture". Power and Performance. Clear Linux Project. Intel Corporation. Archived from the original on 2022-04-26. Retrieved 2022-05-26. {{cite web}}: |archive-date= / |archive-url= timestamp mismatch (help)
↑ Paul, Matthias R.; Frinke, Axel C. (1997-10-13) [first published 1991], FreeKEYB - Enhanced DOS keyboard and console driver (User Manual) (v6.5 ed.) [18] (NB. FreeKEYB is a Unicode-based dynamically configurable successor of K3PLUS supporting most keyboard layouts, code pages, and country codes. Utilizing an off-the-shelf macro assembler as well as a framework of automatic pre- and post-processing analysis tools to generate dependency and code morphing meta data to be embedded into the executable file alongside the binary code and a self-discarding, relaxing and relocating loader, the driver implements byte-level granular dynamic dead code elimination and relocation techniques at load-time as well as self-modifying code and reconfigurability at run-time to minimize its memory footprint downto close the canonical form depending on the underlying hardware, operating system, and driver configuration as well as the selected feature set and locale (about sixty configuration switches with hundreds of options for an almost unlimited number of possible combinations). This complexity and the dynamics are hidden from users, who deal with a single executable file just like they would do with a conventional driver.)
↑ Paul, Matthias R. (2002-04-06). "[fd-dev] Ctrl+Alt+Del". freedos-dev. Archived from the original on 2019-04-27. Retrieved 2019-04-27. […] FreeKEYB builds the driver's runtime image at initialization time depending on the type of machine it is being loaded on, the type of keyboard, layout, country and code page used, the type of mouse and video adapter(s) installed, the other drivers loaded on that system, the operating system and the load and relocation method(s) used, the individual features included, and the configuration options specified in the command line. Due to the large number of command line switches and options supported […] (around fifty switches […] with multiple possible settings) there is a high number of feature combinations with uncountable dependencies […] resulting in […] endless number of […] different target images. FreeKEYB's Dynamic Dead Code Elimination technique manages to resolve […] these […] dependencies and […] remove dead code and data […] is not restricted to […] include or exclude a somewhat limited number of modules or whole sub-routines and fix up some dispatch tables as in classical TSR programming, but […] works […] at […] byte level […] able to remove […] individual instructions in the middle of larger routines […] distributed all over the code to handle a particular case or support a specific feature […] special tools are used to analyze the code […] and create […] fixup tables […] automated […] using conditional defines […] to declare the various cases […] not only optional at assembly time but at initialization time […] without the […] overhead of having at least some amount of dead code left in the runtime image […] to keep track of all the dependencies between […] these conditionals, dynamically build and relocate the runtime image, fix up all the references between these small, changing, and moving binary parts […] still allowing to use the tiny .COM/.SYS style […] model […] is done at initialization time […]
↑ Paul, Matthias R. (2001-08-21). "[fd-dev] Changing codepages in FreeDOS". freedos-dev. Archived from the original on 2019-04-19. Retrieved 2019-04-20. […] a […] unique feature […] we call dynamic dead code elimination, so you can at installation time […] specify which components of the driver you want and which you don't. This goes to an extent of dynamic loadable modularization and late linkage I have not seen under DOS so far. If you do not like the screen saver, macros, the calculator, or mouse support, or <almost anything else>, you can specify this at the command line, and FreeKEYB, while taking all the dependencies between the routines into account, will completely remove all the code fragments, which deal with that feature and are not necessary to provide the requested functionality, before the driver relocates the image into the target location and makes itself resident. […]
↑ Paul, Matthias R. (2001-04-10). "[ANN] FreeDOS beta 6 released" (in Deutsch). Newsgroup: de.comp.os.msdos. Archived from the original on 2017-09-09. Retrieved 2017-07-02. […] brandneue[s] Feature, der dynamischen Dead-Code-Elimination, die die jeweils notwendigen Bestandteile des Treibers erst zum Installationszeitpunkt zusammenbastelt und reloziert, so daß keine ungenutzten Code- oder Datenbereiche mehr resident bleiben (z.B. wenn jemand ein bestimmtes FreeKEYB-Feature nicht benötigt). […]

Cite error: <ref> tag with name "Hogan_1982_CP/M" defined in <references> is not used in prior text.

अग्रिम पठन

Tunney, Justine Alexandra Roberts (2021-02-11). "How Fat Does a Fat Binary Need to Be?". cosmopolitan libc - your build-once run-anywhere c library / Cosmopolitan Communiqué. Archived from the original on 2021-09-12. Retrieved 2021-09-12.; Tunney, Justine Alexandra Roberts (2021-02-11). "How Fat Does a Fat Binary Need to Be?". Hacker News. Archived from the original on 2021-06-01. Retrieved 2021-09-12.
Tunney, Justine Alexandra Roberts (2020-08-24). "αcτµαlly pδrταblε εxεcµταblε (Ape)". Archived from the original on 2021-09-12. Retrieved 2021-09-12.
Gotham, Frederick (2020-10-22). "Making a Fat Binary for Linux and Mac". Narkive. Archived from the original on 2021-09-12. Retrieved 2021-09-12.
Gotham, Frederick (2020-10-24). "Fat Binary - MS-Windows and four Linux". Narkive. Archived from the original on 2021-09-12. Retrieved 2021-09-12.
Gotham, Frederick (2020-11-02). "Fat Binary - DOS Windows Linux". Narkive. Archived from the original on 2021-09-12. Retrieved 2021-09-12.
"We develop to WarpUP the Amiga - StormC for PowerPC and p-OS". Haage & Partner GmbH. September 1996. Archived from the original on 2017-12-06. Retrieved 2021-09-29.
Münch, Matthias (2006) [2005]. "AmigaOS 3.9 - Features". AmigaOS: multimedia, multi-threaded, multi-tasking. Archived from the original on 2019-09-29. Retrieved 2021-09-29. {{cite web}}: |archive-date= / |archive-url= timestamp mismatch (help)

[NB_RET-26] 1.0 ^1.1 ^1.2 This works because a (suitable) return instruction can be used to exit programs under CP/M-80, CP/M-86 and DOS, although the opcodes, exact conditions and underlying mechanisms differ: Under CP/M-80, programs can terminate (that is, warm boot into the BIOS) by jumping to 0 in the zero page, either directly with RST 0 (8080/8085/Z80 opcode C7h), or by calling BDOS function 0 through the CALL 5 interface. Alternatively, as the stack is prepared to hold a 0 return address before passing control to a loaded program, they can, for as long as the stack is aligned, also be exited by issuing a RET (opcode C9h) instruction, thereby falling into the terminating code at offset 0 in the zero page. Although DOS has a dedicated INT 20h interrupt as well as INT 21h API sub-functions to terminate programs (which are preferable for more complicated programs), for machine-translated programs DOS also emulates CP/M's behaviour to some extent: A program can terminate itself by jumping to offset 0 in its PSP (the equivalent to CP/M's zero page), where the system had previously planted an INT 20h instruction. Also, a loaded program's initial stack is prepared to hold a word of 0, so that a program issuing a near return RETN (8088/8086 opcode C3h) will implicitly jump to the start of its code segment as well, thereby eventually reaching the INT 20h as well.^[a] In CP/M-86, the zero page is structured differently and there is no CALL 5 interface, but the stack return method and BDOS function 0 (but now through INT E0h) both work as well.

[NB_C9-28] On 8088/8086 processors, the opcode C9h is an undocumented alias for CBh ("RETF", popping CS:IP from the stack), whereas it decodes as "LEAVE" (set SP to BP and pop BP) on 80188/80186 and newer processors.

[NB_NAMES-33] 3.0 ^3.1 This problem could have been avoided by choosing non-conflicting file extensions, but, once introduced, these particular file names were retained from very early versions of MS-DOS/PC DOS for compatibility reasons with (third-party) tools hard-wired to expect these specific file names.

[NB_KEYBOARD.SYS-35] 4.0 ^4.1 Other DOS files of this type are KEYBOARD.SYS, a binary keyboard layout database file for the keyboard driver KEYB under MS-DOS and PC DOS, IO.SYS containing the DOS BIOS under MS-DOS, and MSDOS.SYS, a text configuration file under Windows 95/MS-DOS 7.0 and higher, but originally a binary system file containing the MS-DOS kernel. However, MS-DOS and PC DOS do not provide crash-protected system files at all, and these file names are neither used nor needed in DR-DOS 7.02 and higher, which otherwise does provide crash-protected system files.

[NB_HIDDEN-36] This is the reason why these files have the hidden attribute set, so that they are not listed by default, thereby reducing the risk of being invoked accidentally.

[NB_COUNTRY.SYS-40] The COUNTRY.SYS file formats supported by the MS-DOS/PC DOS and the DR-DOS families of operating systems contain similar data but are organized differently and incompatible. Since the entry points into the data structures are at different offsets in the file it is possible to create "fat" COUNTRY.SYS databases, which could be used under both DOS families.^[b] However, DR-DOS 7.02 and its NLSFUNC 4.00 (and higher) include an improved parser capable of reading both types of formats (and variants), even at the same time, so that Janus-headed files are not necessary.^[c]^[d] The shipped files are nevertheless "fat" for including a tiny executable stub just displaying an embedded message when invoked inappropriately.^[d]^[b]

[Devanbu-Fong-Stubblebine_1998-1] Devanbu, Premkumar T.; Fong, Philip W. L.; Stubblebine, Stuart G. (19–25 April 1998). "3.3 Java and TH" (PDF). Techniques for Trusted Software Engineering. Proceedings of the 20th International Conference on Software Engineering. Proceedings - International Conference on Software Engineering. Kyoto, Japan. p. 131. doi:10.1109/ICSE.1998.671109. ISBN 0-8186-8368-6. ISSN 0270-5257. Archived from the original (PDF) on 2014-01-16. Retrieved 2021-09-29. (10 pages)

[Pero_2008-2] Pero, Nicola (2008-12-18). "gnustep/tools-make: README.Packaging". GitHub. Archived from the original on 2022-05-25. Retrieved 2022-05-26.

[GNUstep_2009-3] "PackagingDrafts/GNUstep". Fedora Project Wiki. 2009-02-25. Archived from the original on 2022-05-25. Retrieved 2022-05-26.

[Apollo_1988-4] "Domain System Software Release Notes, Software Release 10.1" (PDF) (first printing ed.). Chelmsford, Massachusetts, USA: Apollo Computer Inc. December 1988. p. 2-16. Order No. 005809-A03. Retrieved 2022-07-24. (256 pages)

[Engst_1994_1-5] 5.0 ^5.1 Engst, Adam C. (1994-08-22). "Should Fat Binaries Diet?". TidBITS. No. 240. TidBITS Publishing Inc. ISSN 1090-7017. Archived from the original on 2021-09-29. Retrieved 2021-09-29.

[Engst_1994_2-6] 6.0 ^6.1 Engst, Adam C. (1994-08-29). "Fat Binary Comments". TidBITS. No. 241. TidBITS Publishing Inc. ISSN 1090-7017. Archived from the original on 2021-09-29. Retrieved 2021-09-29.

[Apple_1996_ResourceManager-7] "Chapter 1 - Resource Manager / Resource Manager Reference - Resource File Format". Inside Macintosh: Mac OS Runtime Architectures. Apple Computer. 1996-07-06. Archived from the original on 2021-09-29. Retrieved 2021-09-29.

[Apple_1997_Fat-8] "Chapter 7 - Fat Binary Programs - Creating Fat Binary Programs". Inside Macintosh: Mac OS Runtime Architectures. Apple Computer. 1997-03-11. Archived from the original on 2021-09-29. Retrieved 2011-06-20. [1]

[Apple_1997_PEF-9] "Chapter 8 - PEF Structure". Inside Macintosh: Mac OS Runtime Architectures. Apple Computer. 1997-03-11. Archived from the original on 2021-09-29. Retrieved 2021-09-29.

[Tevanian-DeMoney-Enderby_Wiebe_Snyder_1995-10] Tevanian, Avadis; DeMoney, Michael; Enderby, Kevin; Wiebe, Douglas; Snyder, Garth (1995-07-11) [1993-08-20]. "Method and apparatus for architecture independent executable files" (PDF). Redwood City, California, USA: NeXT Computer, Inc. US patent 5432937A. Archived (PDF) from the original on 2020-12-14. Retrieved 2022-05-26. [2] (9 pages); Tevanian, Avadis; DeMoney, Michael; Enderby, Kevin; Wiebe, Douglas; Snyder, Garth (1997-02-18) [1995-02-28]. "Method and apparatus for architecture independent executable files" (PDF). Redwood City, California, USA: NeXT Computer, Inc. US patent 5604905A. Archived (PDF) from the original on 2022-05-26. Retrieved 2022-05-26. (9 pages)

[Universal_Binary-11] "Universal Binaries and 32-bit/64-bit PowerPC Binaries". Mac OS X ABI Mach-O File Format Reference. Apple Inc. 2009-02-04 [2003]. Archived from the original on 2012-04-27.

[Singh_2006-12] Singh, Amit (2006-06-19). "2.6.2 Fat Binaries". Mac OS X Internals - A Systems Approach. Pearson Education. p. 66. ISBN 978-0-13270226-3. Retrieved 2021-09-28.

[13] "रेफ़िट - ईएफआई फैट बायनेरिज़". refit.sourceforge.net. Retrieved 2022-10-18.

[Paul_2002_COM-14] Paul, Matthias R. (2002-10-07) [2000]. "Re: Run a COM file". Newsgroup: alt.msdos.programmer. Archived from the original on 2017-09-03. Retrieved 2017-09-03. [3] (NB. Has details on DOS COM program calling conventions.)

[Wilkinson_2005-15] 15.0 ^15.1 ^15.2 Wilkinson, William "Bill" Albert (2005-04-02) [2003, 1999-02-16, February 1987, 1986-11-15, 1986-11-10]. Written at Heath Company, USA. "Something COMmon About MS-DOS and CP/M". REMark. Vol. 8, no. 2. St. Joseph, Michigan, USA: Heath/Zenith Users' Group (HUG). pp. 55–57. #85. P/N 885-2085. Archived from the original on 2021-12-13. [4]

[Cha-Pak-Brumley-Lipton_2010-16] 16.0 ^16.1 ^16.2 Cha, Sang Kil; Pak, Brian; Brumley, David; Lipton, Richard Jay (2010-10-08) [2010-10-04]. Platform-Independent Programs (PDF). Proceedings of the 17th ACM conference on Computer and Communications Security (CCS'10). Chicago, Illinois, USA: Carnegie Mellon University, Pittsburgh, Pennsylvania, USA / Georgia Institute of Technology, Atlanta, Georgia, USA. pp. 547–558. doi:10.1145/1866307.1866369. ISBN 978-1-4503-0244-9. Archived (PDF) from the original on 2022-05-26. Retrieved 2022-05-26. [5] (12 pages) (See also: [6]) (NB. Does not address the scenario specifically for 8080 vs. 8086 instruction set architectures (as for CP/M and DOS), but describes the general "self-identifying program" concept of platform-independent programs (PIPs) through what the authors call a gadget header (that is, chunks of program logic not to be confused with ROP gadgets) for x86, MIPS and ARM: i.e. 0Eh, B2h, 02h, A9h, 0Eh, B2h, 02h, 3Ah, 24h, 77h, 01h, 04h or 90h, EBh, 20h, 2Ah, 90h, EBh, 20h, 3Ah, 24h, 77h, 01h, 04h.)

[Wilkinson-Seligman-Drushel-Elliott-Harston_1999-17] 17.0 ^17.1 ^17.2 ^17.3 ^17.4 ^17.5 Wilkinson, William "Bill" Albert; Seligman, Cory; Drushel, Richard F.; Harston, Jonathan Graham; Elliott, John C. (1999-02-17). "MS-DOS & CP/M-Compatible Binaries". Newsgroup: comp.os.cpm. Archived from the original on 2021-12-13. Retrieved 2021-12-13. (NB. Some of the opcodes in Elliott's example code (EBh, 44h, EBh and EBh, 04h, ...) might be mixed up.)

[Elliott_2009_PMARC-18] 18.0 ^18.1 Elliott, John C. (2009-10-27). "CP/M info program". Newsgroup: comp.os.cpm. Archived from the original on 2021-12-13. Retrieved 2021-12-13. […] DOS protection feature […] The idea is based on the utilities in Simeon Cran's MYZ80 emulator; the DOS-protection header in those goes one better by not changing any Z80 registers. The magic sequence is EB 52 EB: […] XCHG […] MOV D,D […] XCHG […] but that means the DOS code ends up quite a way away from the start of the program. […] More fun can be had with self-extract PMArc archives. Start one with […] defb 0EBh, 018h, '-pms-' […] and it's treated as a valid archive by the PMA utilities, sends 8086 processors to 011Ah, and Z80 processors to 0130h. […]

[Christ_2012-19] ChristW (2012-11-14) [2012-11-13]. Chen, Raymond (ed.). "Microsoft Money crashes during import of account transactions or when changing a payee of a downloaded transaction". The New Old Thing. Archived from the original on 5 July 2018. Retrieved 2018-05-19. […] byte sequence […] EB 03 C3 yy xx […] If you create a .COM file with those 5 bytes as the first ones […] you'll see 'JMP SHORT 3', followed by 3 garbage bytes. […] If you look at a Z80 disassembly […] that translates to 'EX DE,HL; INC BC;' […] The 3rd byte is 'JUMP' followed by the 16-bit address specified as yy xx […] you'll have a .COM file that runs on MS-DOS and […] CP/M […] (NB. While the author speaks about the Z80, this sequence also works on the 8080 and compatible processors.)

[Brehm_2016-20] Brehm, Andrew J. (2016). "CP/M and MS-DOS Fat Binary". DesertPenguin.org. Archived from the original on 2018-05-19. Retrieved 2018-05-19. (NB. While the article speaks about the Z80, the code sequence also works on the 8080 and compatible processors.)

[Elliott_1996_FATBIN-21] Elliott, John C. (1996-06-13). "Upload to micros.hensa.ac.uk". Newsgroup: comp.os.cpm. Archived from the original on 2021-12-13. Retrieved 2021-12-13. […] FATBIN 1.00 - combine a CP/M .COM file and a DOS .COM file to create one which runs on both platforms. […] It was used to create: […] MSODBALL 2.05 - convert floppy discs between Amstrad 706k format and a DOS 706k format. […] Both the programs run under CP/M-80 and DOS. […]

[Elliott_1998_FATBIN-22] Elliott, John C. (1998-06-28) [1997-04-01]. "FATBIN v1.01". Archived from the original on 1998-06-28. (NB. FATBN101.COM 22k 1997-04-01 FATBIN v1.01. Creates fat binary files which will run under both CP/M and DOS. Distributed in a self-extracting archive for CP/M-80 and DOS.)

[Elliott_2002_FBMAKE-23] Elliott, John C. (2002-03-11). "DSKWRITE v1.00". Fossies - the Fresh Open Source Software Archive. Archived from the original on 2021-12-12. Retrieved 2021-12-12. […] DSKWRITE.Z80 contains source for the CP/M version. […] DSKWRITE.ASM contains source for the DOS version. […] To get the single .COM file, you need to use FBMAKE: […] [7] (NB. Mentions FBMAKE from the FATBNSEA.COM package.)

[Elliott_2005_FATBIN-PMSFX-24] 24.0 ^24.1 Elliott, John C. (2012-06-20) [2005-01-05]. "Generic CP/M". Seasip.info. Archived from the original on 2021-11-17. Retrieved 2021-12-12. […] Self-extracting archives are .COM files containing a number of smaller files. When you run one, it will create its smaller files […] The self-extract archive programs will run under DOS (2 or later) or CP/M, with identical effects. To extract them under Unix, you can use ZXCC […] FATBNSEA.COM […] FATBIN combines a CP/M-80 .COM file and a DOS .COM file to produce one that will work on both systems. […] M3C4SEA.COM […] M3CONV version 4 - converts Spectrum snapshots in the .Z80 or .SNA format to or from Multiface 3 format (Multiface 3 -> Z80 only on a PC). […] PMSFX21X.COM […] PMSFX is the program that was used to generate these self-unpacking archives. This version (2.11) can generate archives which unpack themselves under CP/M or DOS. You will need PMARC to use PMSFX. New: Under DOS, it supports exact file sizes. […] SP2BMSEA.COM […] Converts a Stop Press Canvas file to a Windows .BMP […] [8]

[Elliott_1997_PMSFX2-25] Elliott, John C. (1997-01-18) [1997-01-11]. "PMSFX 2". Newsgroup: comp.os.cpm. Archived from the original on 2021-12-13. Retrieved 2021-12-13. […] I've written a version of PMSFX that produces .COM files unpackable under DOS and CP/M (the first three bytes are both legal Z80 code, legal 8086 code and legal PMA header) […] as a self-extracting archive. […]

[Elliott_CPM3_COM-27] Elliott, John C.; Lopushinsky, Jim (2002) [1998-04-11]. "CP/M 3 COM file header". Seasip.info. Archived from the original on 2016-08-30. Retrieved 2016-08-29.

[Necasek_2018_WordStar-29] 27.0 ^27.1 Necasek, Michal (2018-01-30) [2018-01-28, 2018-01-26]. "WordStar Again". OS/2 Museum. Archived from the original on 2019-07-28. Retrieved 2019-07-28. […] The reason to suspect such difference is that version 3.2x also supported CP/M-86 (the overlays are identical between DOS and CP/M-86, only the main executable is different) […] the .OVR files are 100% identical between DOS and CP/M-86, with a flag (clearly shown in the WordStar 3.20 manual) switching between them at runtime […] the OS interface in WordStar is quite narrow and well abstracted […] the WordStar 3.2x overlays are 100% identical between the DOS and CP/M-86 versions. There is a runtime switch which chooses between calling INT 21h (DOS) and INT E0h (CP/M-86). WS.COM is not the same between DOS and CP/M-86, although it's probably not very different either. […]

[Lineback_GSX-30] Lineback, Nathan. "GSX Screen Shots". Toastytech.com. Archived from the original on 2020-01-15. Retrieved 2020-01-15.

[Paul_2002_COMSYS-31] 29.0 ^29.1 ^29.2 Paul, Matthias R. (2002-04-11). "Re: [fd-dev] ANNOUNCE: CuteMouse 2.0 alpha 1". freedos-dev. Archived from the original on 2020-02-21. Retrieved 2020-02-21. […] FreeKEYB is […] a true .COM and .SYS driver (tiny model) in one. You can safely overwrite the first JMP, that's part of what I meant by "tricky header". […] you can replace the FFFFh:FFFFh by a 3-byte jump and a pending DB FFh. It works with MS-DOS, PC DOS, DR-DOS, and most probably any other DOS issue as well. […]

[Paul_2002_CTMOUSE-32] 30.0 ^30.1 ^30.2 Paul, Matthias R. (2002-04-06). "Re: [fd-dev] ANNOUNCE: CuteMouse 2.0 alpha 1". freedos-dev. Archived from the original on 2020-02-07. Retrieved 2020-02-07. […] Add a SYS device driver header to the driver, so that CTMOUSE could be both in one, a normal TSR and a device driver - similar to our FreeKEYB advanced keyboard driver. […] This is not really needed under DR DOS because INSTALL= is supported since DR DOS 3.41+ and DR DOS preserves the order of [D]CONFIG.SYS directives […] but it would […] improve the […] flexibility on MS-DOS/PC DOS systems, which […] always execute DEVICE= directives prior to any INSTALL= statements, regardless of their order in the file. […] software may require the mouse driver to be present as a device driver, as mouse drivers have always been device drivers back in the old times. These mouse drivers have had specific device driver names depending on which protocol they used ("PC$MOUSE" for Mouse Systems Mode for example), and some software may search for these drivers in order to find out the correct type of mouse to be used. […] Another advantage would be that device drivers usually consume less memory (no environment, no PSP) […] It's basically a tricky file header, a different code to parse the command line, a different entry point and exit line, and some segment magics to overcome the ORG 0 / ORG 100h difference. Self-loadhighing a device driver is a bit more tricky as you have to leave the driver header where it is and only relocate the remainder of the driver […]

[Paul_2001_COUNTRY-34] 31.0 ^31.1 ^31.2 ^31.3 Paul, Matthias R. (2001-06-10) [1995]. "DOS COUNTRY.SYS file format" (COUNTRY.LST file) (1.44 ed.). Archived from the original on 2016-04-20. Retrieved 2016-08-20.

[Paul_1997_NWDOSTIP-37] 32.0 ^32.1 ^32.2 Paul, Matthias R. (1997-07-30) [1994-05-01]. "Chapter II.4. Undokumentierte Eigenschaften externer Kommandos - SYS.COM". NWDOS-TIPs — Tips & Tricks rund um Novell DOS 7, mit Blick auf undokumentierte Details, Bugs und Workarounds. Archived from the original on 2017-09-10. Retrieved 2014-08-06. Für ein zukünftiges Update für Calderas OpenDOS 7.01 habe ich den Startcode von IBMBIO.COM so modifiziert, daß er - falls fälschlicherweise als normales Programm gestartet - ohne Absturz zur Kommandozeile zurückkehrt. Wann diese Sicherheitsfunktion in die offizielle Version Einzug halten wird, ist jedoch noch nicht abzusehen. {{cite book}}: |work= ignored (help) (NB. NWDOSTIP.TXT is a comprehensive work on Novell DOS 7 and OpenDOS 7.01, including the description of many undocumented features and internals. It is part of the author's yet larger MPDOSTIP.ZIP collection maintained up to 2001 and distributed on many sites at the time. The provided link points to a HTML-converted older version of the NWDOSTIP.TXT file.) [9]

[Paul_1997_OD-A3-38] Paul, Matthias R. (1997-10-02). "Caldera OpenDOS 7.01/7.02 Update Alpha 3 IBMBIO.COM README.TXT". Archived from the original on 2003-10-04. Retrieved 2009-03-29. [10]

[Caldera_1998_NEW703-39] DR-DOS 7.03 WHATSNEW.TXT - Changes from DR-DOS 7.02 to DR-DOS 7.03. Caldera, Inc. 1998-12-24. Archived from the original on 8 April 2019. Retrieved 2019-04-08.

[Sage_1988_ZSystem-41] 35.0 ^35.1 Sage, Jay (May–June 1988). Carlson, Art (ed.). "ZCPR 3.4 - Type-4 Programs". The Computer Journal (TCJ) - Programming, User Support, Applications. ZCPR3 Corner. Columbia Falls, Montana, USA (32): 10–17 [16]. ISSN 0748-9331. ark:/13960/t1wd4v943. Retrieved 2021-11-29. [11][12]

[Sage_1992_ZSystem_1-42] 36.0 ^36.1 Sage, Jay (May–June 1992) [March–June 1992]. Carlson, Art; McEwen, Chris (eds.). "Type-3 and Type-4 Programs". The Computer Journal (TCJ) - Programming, User Support, Applications. Z-System Corner - Some New Applications of Type-4 Programs. S. Plainfield, New Jersey, USA: Socrates Press (55): 13–19 [14, 16]. ISSN 0748-9331. ark:/13960/t4dn54d22. Retrieved 2021-11-29. [13][14]

[Sage_1992_ZSystem_2-43] 37.0 ^37.1 Sage, Jay (November–December 1992). Carlson, Art; Kibler, Bill D. (eds.). "Regular Feature, ZCPR Support, Language Independence, part 2". The Computer Journal (TCJ) - Programming, User Support, Applications. The Z-System Corner. Lincoln, CA, USA (58): 7–10. ISSN 0748-9331. ark:/13960/t70v9g87h. Retrieved 2020-02-09. […] there was an opcode of "RST 0", which, if executed, would result in a warm boot. A file containing a Z3TXT module should never be executed, but at a cost of one byte we could protect ourself against that outside chance. The header also contained the string of characters "Z3TXT" followed by a null (0) byte. Many Z-System modules include such identifiers. In this category are resident command packages (RCPs), flow command packages (FCPs), and environment descriptor modules (Z3ENVs). Programs, such as Bridger Mitchell's […] JETLDR.COM, that load these modules from files into memory can use the ID string to validate the file, that is, to make sure that it is the kind of module that the user has stated it to be. User mistakes and damaged files can thus be detected. […] The header, thus, now stands as follows: […] rst […] db 'Z3TXT',0 ; null-terminated ID […] ; 12345678 ; must be 8 characters, […] db 'PROGNAME' ; pad with spaces […] ; 123 ; must be 3 characters […] db 'ENG' ; name of language […] dw LENGTH ; length of module […] [15][16]

[DEC_1965_PDP-6-44] "Table of IO Device Characteristics - Console or Teletypewriters". PDP-6 Multiprogramming System Manual (PDF). Maynard, Massachusetts, USA: Digital Equipment Corporation (DEC). 1965. p. 43. DEC-6-0-EX-SYS-UM-IP-PRE00. Archived (PDF) from the original on 2014-07-14. Retrieved 2014-07-10. (1+84+10 pages)

[DEC_1969_PDP-10-45] "5.1.1.1. Device Dependent Functions - Data Modes - Full-Duplex Software A(ASCII) and AL(ASCII Line)". PDP-10 Reference Handbook: Communicating with the Monitor - Time-Sharing Monitors (PDF). Vol. 3. Digital Equipment Corporation (DEC). 1969. pp. 5-3–5-6 [5-5 (431)]. Archived (PDF) from the original on 2011-11-15. Retrieved 2014-07-10. (207 pages)

[DRI_1979_CPM20-IG-46] "2. Operating System Call Conventions". CP/M 2.0 Interface Guide (PDF) (1 ed.). Pacific Grove, California, USA: Digital Research. 1979. p. 5. Archived (PDF) from the original on 2020-02-28. Retrieved 2020-02-28. […] The end of an ASCII file is denoted by a control-Z character (1AH) or a real end of file, returned by the CP/M read operation. Control-Z characters embedded within machine code files (e.g., COM files) are ignored, however, and the end of file condition returned by CP/M is used to terminate read operations. […] (56 pages)

[CHF_2010_DOS-1A-47] BC_Programmer (2010-01-31) [2010-01-30]. "Re: Copy command which merges several files tags the word SUB at the end". Computer Hope Forum. Archived from the original on 2020-02-26. Retrieved 2020-02-26.

[Superuser_2011_TXT-48] "What are the differences between Linux and Windows .txt files (Unicode encoding)". Superuser. 2011-08-03 [2011-06-08]. Archived from the original on 2020-02-26. Retrieved 2020-02-26.

[Gordon_2009_FatELF-49] 43.0 ^43.1 Gordon, Ryan C. (October 2009). "FatELF: Universal Binaries for Linux". icculus.org. Archived from the original on 2020-08-27. Retrieved 2010-07-13.

[Gordon_2009_Spec-50] Gordon, Ryan C. (November 2009). "FatELF specification, version 1". icculus.org. Archived from the original on 2020-08-27. Retrieved 2010-07-25.

[Windisch_2009-51] Windisch, Eric (2009-11-03). "Subject: Newsgroups: gmane.linux.kernel, Re: FatELF patches..." gmane.org. Archived from the original on 2016-11-15. Retrieved 2010-07-08.

[Gordon_2009_VM-52] Gordon, Ryan C. (2009). "FatELF: Universal Binaries for Linux. - The proof-of-concept virtual machine download page". icculus.org. Archived from the original on 2022-05-21. Retrieved 2022-05-26. (NB. VM image of Ubuntu 9.04 with Fat Binary support.)

[Holwerda_2009-53] Holwerda, Thom (2009-11-05). "Ryan Gordon Halts FatELF Project". Linux. osnews.com. Archived from the original on 2022-05-26. Retrieved 2010-07-05.

[Brockmeier_2010-54] Brockmeier, Joe "Zonker" (2010-06-23). "SELF: Anatomy of an (alleged) failure". LWN.net. Linux Weekly News. Archived from the original on 2022-05-26. Retrieved 2011-02-06.

[Mulder_2018-55] Mulder, Sijmen J. (2021-03-06) [2018-04-25]. "sjmulder/fatpack - Build multi-architecture 'fat' binaries for Windows". GitHub. Archived from the original on 2022-05-26. Retrieved 2022-05-26.

[Microsoft_2022-56] "Arm64X PE files". learn.microsoft.com. Microsoft. 2023-03-31 [2022-08-12]. Retrieved 2023-03-31.{{cite web}}: CS1 maint: url-status (link)

[Microsoft_2023-57] "Build Arm64X binaries". learn.microsoft.com. Microsoft. 2023-03-31 [2023-03-09]. Retrieved 2023-03-31.{{cite web}}: CS1 maint: url-status (link)

[Collins-Chinya-Jiang-Tian-Girkar-Yang-Lueh-Wang_2007-58] Wang, Perry H.; Collins, Jamison D.; Chinya, Gautham N.; Jiang, Hong; Tian, Xinmin; Girkar, Milind; Yang, Nick Y.; Lueh, Guei-Yuan; Wang, Hong (June 2007). "EXOCHI: architecture and programming environment for a heterogeneous multi-core multithreaded system". ACM SIGPLAN Notices. 42 (6): 156–166. doi:10.1145/1273442.1250753. (11 pages)

[Wang-Collins-Chinya-Jiang-Tian-Girkar-Pearce-Lueh-Yakoushkin-Wang_2007-59] Wang, Perry H.; Collins, Jamison D.; Chinya, Gautham N.; Jiang, Hong; Tian, Xinmin; Girkar, Milind; Pearce, Lisa; Lueh, Guei-Yuan; Yakoushkin, Sergey; Wang, Hong (2007-08-22). "Accelerator Exoskeleton" (PDF). Intel Technology Journal. Intel Corporation. 11: Tera-scale Computing (3): 185–196. doi:10.1535/itj.1103. ISSN 1535-864X. Archived (PDF) from the original on 2022-05-26. Retrieved 2022-05-26. (12 of 1+vii+90+1 pages)

[Nvidia_2004-60] "cudaFatFormat.h / ptxomp.c". 1.13. Nvidia Corporation. 2004-11-15. Archived from the original on 2022-05-26. Retrieved 2022-05-26.

[Harris_2014-61] Harris, Mark J. (2014-05-08) [2013-06-05]. "Technical Walkthrough: CUDA Pro Tip: Understand Fat Binaries and JIT Caching". Nvidia Developer. Nvidia. Archived from the original on 2022-03-23. Retrieved 2022-05-26.

[CUDA_2014-62] "CUDA Binary Utilities" (PDF) (Application Note). 6.0. Nvidia. February 2014. DA-06762-001_v6.0. Archived (PDF) from the original on 2022-05-25. Retrieved 2022-05-25.

[CUDA_2016-63] "fatbinary - help". helpmanual.io. 8.0. 2016. Archived from the original on 2022-05-25. Retrieved 2022-05-25.

[CUDA_2022-64] "CUDA Compiler Driver NVCC - Reference Guide" (PDF). 11.7. Nvidia. May 2022. TRM-06721-001_v11.7. Archived (PDF) from the original on 2022-05-25. Retrieved 2022-05-25.

[Braun-Fröning_2019-65] Braun, Lorenz; Fröning, Holger (2019-11-18). CUDA Flux: A Lightweight Instruction Profiler for CUDA Applications (PDF). IEEE/ACM Performance Modeling, Benchmarking and Simulation of High Performance Computer Systems (PMBS). Denver, Colorado, USA: IEEE. doi:10.1109/PMBS49563.2019.00014. ISBN 978-1-7281-5977-5. Archived (PDF) from the original on 2022-03-21. Retrieved 2022-05-26.

[Fung-Sham-Yuan-Aamodt_2007-66] Fung, Wilson W. L.; Sham, Ivan; Yuan, George; Aamodt, Tor M. (2007). "Dynamic Warp Formation and Scheduling for Efficient GPU Control Flow" (PDF). Vancouver, British Columbia, Canada. Archived (PDF) from the original on 2022-05-26. Retrieved 2022-05-26. (12 pages)

[Bakhoda-Yuan-Fung-Wong-Aamodt_2009-67] Bakhoda, Ali; Yuan, George L.; Fung, Wilson W. L.; Wong, Henry; Aamodt, Tor M. (2009-04-28) [2009-04-26]. Analyzing CUDA Workloads Using a Detailed GPU Simulator (PDF). Proceedings of the IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS). Boston, Massachusetts, USA. pp. 163–174. doi:10.1109/ISPASS.2009.4919648. Archived (PDF) from the original on 2022-05-26. Retrieved 2022-05-06. [17]

[Multi2Sim_2013-68] 62.0 ^62.1 "13.4 The AMD Compiler Wrapper: Fat binaries". The Multi2Sim Simulation Framework - A CPU-GPU Model for Heterogeneous Computing (PDF). 2013. pp. 173–176 [176]. Archived (PDF) from the original on 2022-05-25. Retrieved 2022-05-25. {{cite book}}: |website= ignored (help) (4 of 210 pages)

[Ubal-Jang_Mistry_Schaa_Kaeli_2012-69] Ubal, Rafael; Jang, Byunghyun; Mistry, Perhaad; Schaa, Dana; Kaeli, David R. (2012-09-23) [2012-09-19]. "Multi2Sim: A Simulation Framework for CPU-GPU Computing" (PDF). 21st International Conference on Parallel Architectures and Compilation Techniques (PACT). Minneapolis, Minnesota, USA: IEEE. ISBN 978-1-4503-1182-3. Archived (PDF) from the original on 2022-05-25. Retrieved 2022-05-25. (10 pages)

[LTO-70] "LTO Overview (GNU Compiler Collection (GCC) Internals)". gcc.gnu.org. Archived from the original on 2021-09-12. Retrieved 2021-09-12.

[Wennborg_2018-71] Wennborg, Hans (2018). "Attributes in Clang". Clang 7 documentation. Archived from the original on 2022-04-07. Retrieved 2022-05-26.

[Bahena_2018-72] Bahena, Victor Rodriguez (2018-04-03). "Transparent use of library packages optimized for Intel architecture". Power and Performance. Clear Linux Project. Intel Corporation. Archived from the original on 2022-04-26. Retrieved 2022-05-26. {{cite web}}: |archive-date= / |archive-url= timestamp mismatch (help)

[Paul_1997_FreeKEYB-73] Paul, Matthias R.; Frinke, Axel C. (1997-10-13) [first published 1991], FreeKEYB - Enhanced DOS keyboard and console driver (User Manual) (v6.5 ed.) [18] (NB. FreeKEYB is a Unicode-based dynamically configurable successor of K3PLUS supporting most keyboard layouts, code pages, and country codes. Utilizing an off-the-shelf macro assembler as well as a framework of automatic pre- and post-processing analysis tools to generate dependency and code morphing meta data to be embedded into the executable file alongside the binary code and a self-discarding, relaxing and relocating loader, the driver implements byte-level granular dynamic dead code elimination and relocation techniques at load-time as well as self-modifying code and reconfigurability at run-time to minimize its memory footprint downto close the canonical form depending on the underlying hardware, operating system, and driver configuration as well as the selected feature set and locale (about sixty configuration switches with hundreds of options for an almost unlimited number of possible combinations). This complexity and the dynamics are hidden from users, who deal with a single executable file just like they would do with a conventional driver.)

[Paul_2002_DDCE2-74] Paul, Matthias R. (2002-04-06). "[fd-dev] Ctrl+Alt+Del". freedos-dev. Archived from the original on 2019-04-27. Retrieved 2019-04-27. […] FreeKEYB builds the driver's runtime image at initialization time depending on the type of machine it is being loaded on, the type of keyboard, layout, country and code page used, the type of mouse and video adapter(s) installed, the other drivers loaded on that system, the operating system and the load and relocation method(s) used, the individual features included, and the configuration options specified in the command line. Due to the large number of command line switches and options supported […] (around fifty switches […] with multiple possible settings) there is a high number of feature combinations with uncountable dependencies […] resulting in […] endless number of […] different target images. FreeKEYB's Dynamic Dead Code Elimination technique manages to resolve […] these […] dependencies and […] remove dead code and data […] is not restricted to […] include or exclude a somewhat limited number of modules or whole sub-routines and fix up some dispatch tables as in classical TSR programming, but […] works […] at […] byte level […] able to remove […] individual instructions in the middle of larger routines […] distributed all over the code to handle a particular case or support a specific feature […] special tools are used to analyze the code […] and create […] fixup tables […] automated […] using conditional defines […] to declare the various cases […] not only optional at assembly time but at initialization time […] without the […] overhead of having at least some amount of dead code left in the runtime image […] to keep track of all the dependencies between […] these conditionals, dynamically build and relocate the runtime image, fix up all the references between these small, changing, and moving binary parts […] still allowing to use the tiny .COM/.SYS style […] model […] is done at initialization time […]

[Paul_2001_FK-75] Paul, Matthias R. (2001-08-21). "[fd-dev] Changing codepages in FreeDOS". freedos-dev. Archived from the original on 2019-04-19. Retrieved 2019-04-20. […] a […] unique feature […] we call dynamic dead code elimination, so you can at installation time […] specify which components of the driver you want and which you don't. This goes to an extent of dynamic loadable modularization and late linkage I have not seen under DOS so far. If you do not like the screen saver, macros, the calculator, or mouse support, or <almost anything else>, you can specify this at the command line, and FreeKEYB, while taking all the dependencies between the routines into account, will completely remove all the code fragments, which deal with that feature and are not necessary to provide the requested functionality, before the driver relocates the image into the target location and makes itself resident. […]

[Paul_2001_DDCE-76] Paul, Matthias R. (2001-04-10). "[ANN] FreeDOS beta 6 released" (in Deutsch). Newsgroup: de.comp.os.msdos. Archived from the original on 2017-09-09. Retrieved 2017-07-02. […] brandneue[s] Feature, der dynamischen Dead-Code-Elimination, die die jeweils notwendigen Bestandteile des Treibers erst zum Installationszeitpunkt zusammenbastelt und reloziert, so daß keine ungenutzten Code- oder Datenbereiche mehr resident bleiben (z.B. wenn jemand ein bestimmtes FreeKEYB-Feature nicht benötigt). […]

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[nb 1]

[26]

[nb 2]

[27]

[28]

[29]

[30]

[nb 3]

[31]

[nb 4]

[nb 5]

[32]

[33]

[34]

[nb 6]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[57]

[58]

[59]

[60]

[61]

[62]

[63]

[64]

[65]

[66]

[67]

[68]

[69]

[70]

@@ Line 1: / Line 1: @@
 {{Short description|Combined executable file for multiple processor types or operating systems}}
-{{Distinguish|Portable executable|Portable application}}
+{{Distinguish|पोर्टेबल एक्सेक्यूटेबले |पोर्टेबल एप्लिकेशन}}
-एक फैट बाइनरी (या मल्टीआर्किटेक्चर बाइनरी) कंप्यूटर [[निष्पादन योग्य प्रोग्राम]] या [[ पुस्तकालय (कंप्यूटिंग) |पुस्तकालय (कंप्यूटिंग)]] है जिसे कई निर्देश सेटों के मूल कोड के साथ विस्तारित (या फैट किया गया) किया गया है, जिसके परिणामस्वरूप कई प्रोसेसर प्रकारों पर चलाया जा सकता है।<ref name="Devanbu-Fong-Stubblebine_1998"/>इसके परिणामस्वरूप फ़ाइल सामान्य एक-आर्किटेक्चर बाइनरी फ़ाइल से बड़ी हो जाती है, इस प्रकार नाम।
-कार्यान्वयन की सामान्य विधि प्रत्येक निर्देश सेट के लिए [[मशीन कोड]] का संस्करण शामिल करना है, जिसके पहले सभी [[ऑपरेटिंग सिस्टम]] के साथ संगत कोड के साथ एकल प्रविष्टि बिंदु होता है, जो उपयुक्त अनुभाग पर छलांग निष्पादित करता है। वैकल्पिक कार्यान्वयन अलग-अलग निष्पादनयोग्यों को अलग-अलग फोर्क (फ़ाइल सिस्टम) में संग्रहीत करते हैं, प्रत्येक का अपना [[प्रवेश बिंदु]] होता है जो सीधे ऑपरेटिंग सिस्टम द्वारा उपयोग किया जाता है।
-ऑपरेटिंग सिस्टम सॉफ़्टवेयर में फैट बायनेरिज़ का उपयोग आम नहीं है; ही समस्या को हल करने के लिए कई विकल्प हैं, जैसे [[ इंस्टालर |इंस्टालर]] प्रोग्राम का उपयोग इंस्टॉल समय पर आर्किटेक्चर-विशिष्ट बाइनरी चुनने के लिए (जैसे [[एंड्रॉइड (ऑपरेटिंग सिस्टम)]] एकाधिक [[एंड्रॉइड पैकेज]] के साथ), रनटाइम पर आर्किटेक्चर-विशिष्ट बाइनरी का चयन करना (जैसे कि बेल लैब्स की [[संघ निर्देशिका (योजना 9)]] 9 के साथ (प्लान 9) और [[जीएनयूस्टेप]] के वसा बंडल),<ref name="Pero_2008"/><ref name="GNUstep_2009"/>सॉफ़्टवेयर को स्रोत कोड के रूप में वितरित करना और उसे उसी स्थान पर संकलित करना, या [[ आभासी मशीन |आभासी मशीन]] का उपयोग (जैसे कि [[जावा वर्चुअल मशीन]] के साथ) और समय-समय पर संकलन करना।
+फैट बाइनरी (या मल्टीआर्किटेक्चर बाइनरी) कंप्यूटर [[निष्पादन योग्य प्रोग्राम|एक्सेक्यूटेबले प्रोग्राम]] या [[ पुस्तकालय (कंप्यूटिंग) |लाइब्रेरी (कंप्यूटिंग)]] है जिसे अनेक निर्देश सेटों के मूल कोड के साथ विस्तारित (या फैट किया गया) किया गया है, जिसके परिणामस्वरूप यह अनेक प्रोसेसर प्रकारों पर चलाया जा सकता है।<ref name="Devanbu-Fong-Stubblebine_1998"/> इसके परिणामस्वरूप फ़ाइल सामान्य यह-आर्किटेक्चर बाइनरी फ़ाइल से बड़ी हो जाती है, इस प्रकार नाम हैं।
+कार्यान्वयन की सामान्य विधि प्रत्येक निर्देश सेट के लिए [[मशीन कोड]] का संस्करण सम्मिलित करना है, जिसके पहले सभी [[ऑपरेटिंग सिस्टम]] के साथ संगत कोड के साथ एकल प्रविष्टि बिंदु होता है, जो उपयुक्त अनुभाग पर जम्प निष्पादित करता है। वैकल्पिक कार्यान्वयन भिन्न-भिन्न निष्पादन योग्यों को भिन्न-भिन्न फोर्क (फ़ाइल सिस्टम) में संग्रहीत करते हैं, प्रत्येक का अपना [[प्रवेश बिंदु]] होता है जो सीधे ऑपरेटिंग सिस्टम द्वारा उपयोग किया जाता है।
+ऑपरेटिंग सिस्टम सॉफ़्टवेयर में फैट बायनेरिज़ का उपयोग सामान्य नहीं है ऐसी ही समस्या का समाधान करने के लिए अनेक विकल्प हैं, जैसे [[ इंस्टालर |इंस्टालर]] प्रोग्राम का उपयोग इंस्टॉल समय पर आर्किटेक्चर-विशिष्ट बाइनरी चुनने के लिए होता हैं और (जैसे [[एंड्रॉइड (ऑपरेटिंग सिस्टम)]] एकाधिक [[एंड्रॉइड पैकेज]] के साथ), रनटाइम पर आर्किटेक्चर-विशिष्ट बाइनरी का चयन करता हैं इस प्रकार (जैसे कि बेल लैब्स की [[संघ निर्देशिका (योजना 9)]] के साथ (प्लान 9) और [[जीएनयूस्टेप]] के वसा बंडल) होता हैं, <ref name="Pero_2008"/><ref name="GNUstep_2009"/> सॉफ़्टवेयर को सोर्स कोड के रूप में वितरित करना और उसे उसी स्थान पर संकलित करना हैं, इस [[ आभासी मशीन |आभासी मशीन]] का उपयोग (जैसे कि [[जावा वर्चुअल मशीन]] के साथ) और समय-समय पर संकलन करना होता हैं।
 ==अपोलो==
 ===अपोलो के यौगिक निष्पादनयोग्य===
-में, [[अपोलो कंप्यूटर]] के डोमेन/ओएस SR10.1 ने नया फ़ाइल प्रकार, सीएमपेक्स (यौगिक निष्पादन योग्य) पेश किया, जिसमें [[मोटोरोला 68000 श्रृंखला]] और अपोलो PRISM निष्पादन योग्य के लिए बायनेरिज़ को बंडल किया गया था।<ref name="Apollo_1988"/>
+में, [[अपोलो कंप्यूटर]] के डोमेन/ओएस SR10.1 ने नया फ़ाइल प्रकार, सीएमपेक्स (यौगिक एक्सेक्यूटेबले ) प्रस्तुत किया, जिसमें [[मोटोरोला 68000 श्रृंखला|मोटोरोला 680x0 श्रृंखला]] और अपोलो प्रिज्म एक्सेक्यूटेबले के लिए बायनेरिज़ को बंडल किया गया था। <ref name="Apollo_1988"/>
+==एप्पल ==
-==सेब==
-===सेब की वसा बाइनरी===
+===एप्पल की फैट बाइनरी===
-एक फैट-बाइनरी योजना ने 1994 में [[68k]] माइक्रोप्रोसेसरों से [[पावरपीसी]] माइक्रोप्रोसेसरों तक [[एप्पल मैकिंटोश]] के संक्रमण को सुचारू किया। पुराने प्लेटफ़ॉर्म के लिए कई एप्लिकेशन विकसित एमुलेटर के तहत नए प्लेटफ़ॉर्म पर पारदर्शी रूप से चलते हैं, लेकिन एम्युलेटेड कोड आम तौर पर मूल कोड की तुलना में धीमी गति से चलता है। फैट बायनेरिज़ के रूप में जारी किए गए एप्लिकेशन ने अधिक संग्रहण स्थान ले लिया, लेकिन वे किसी भी प्लेटफ़ॉर्म पर पूरी गति से चले। यह [[मोटोरोला 68k]]-संकलित संस्करण और ही प्रोग्राम के पावरपीसी-संकलित संस्करण दोनों को उनकी निष्पादन योग्य फ़ाइलों में पैकेजिंग करके हासिल किया गया था।<ref name="Engst_1994_1"/><ref name="Engst_1994_2"/>पुराने 68K कोड (CFM-68K या क्लासिक 68K) को संसाधन फ़ोर्क में संग्रहीत किया जाना जारी रखा गया, जबकि नया PowerPC कोड [[डेटा कांटा]] में, [[पसंदीदा निष्पादन योग्य प्रारूप]] प्रारूप में समाहित किया गया था।<ref name="Apple_1996_ResourceManager"/><ref name="Apple_1997_Fat"/><ref name="Apple_1997_PEF"/>
+फैट-बाइनरी योजना ने 1994 में [[68k]] माइक्रोप्रोसेसरों से [[पावरपीसी]] माइक्रोप्रोसेसरों तक [[एप्पल मैकिंटोश]] के संक्रमण को सुचारू किया हैं। पूर्व प्लेटफ़ॉर्म के लिए अनेक एप्लिकेशन विकसित एमुलेटर के अनुसार नए प्लेटफ़ॉर्म पर क्रोसदर्शी रूप से चलते हैं, किन्तु एम्युलेटेड कोड सामान्यतः मूल कोड की तुलना में धीमी गति से चलता है। फैट बायनेरिज़ के रूप में प्रचलित किए गए एप्लिकेशन ने अधिक संग्रहण स्थान ले लिया हैं, किन्तु वह किसी भी प्लेटफ़ॉर्म पर पूर्ण गति से चले। यह [[मोटोरोला 68k]]-संकलित संस्करण और ऐसे ही प्रोग्राम के पावरपीसी-संकलित संस्करण दोनों को उनकी एक्सेक्यूटेबले फ़ाइलों में पैकेजिंग करके प्राप्त किया गया था।<ref name="Engst_1994_1"/><ref name="Engst_1994_2"/> पूर्व 68K कोड (सीएफएम-68K या क्लासिक 68K) को संसाधन फ़ोर्क में संग्रहीत किया जाना प्रचलित रखा गया हैं, जबकि नया पावरपीसी कोड [[डेटा कांटा|डेटा फोर्क]] में, [[पसंदीदा निष्पादन योग्य प्रारूप|फेवरेट एक्सेक्यूटेबले फार्मेट]] '''प्रारूप''' में समाहित किया गया था।<ref name="Apple_1996_ResourceManager"/><ref name="Apple_1997_Fat"/><ref name="Apple_1997_PEF"/>
-फैट बायनेरिज़ केवल पावरपीसी या 68k का समर्थन करने वाले कार्यक्रमों से बड़े थे, जिसके कारण कई उपयोगिताओं का निर्माण हुआ जो अनावश्यक संस्करण को हटा देंगे।<ref name="Engst_1994_1"/><ref name="Engst_1994_2"/>छोटे [[हार्ड ड्राइव]] के युग में, जब 80 एमबी हार्ड ड्राइव सामान्य आकार थे, ये उपयोगिताएँ कभी-कभी उपयोगी होती थीं, क्योंकि प्रोग्राम कोड आम तौर पर समग्र ड्राइव उपयोग का बड़ा प्रतिशत होता था, और वसा बाइनरी के अनावश्यक सदस्यों को अलग करने से हार्ड ड्राइव पर महत्वपूर्ण मात्रा में जगह खाली हो जाती थी।
+फैट बायनेरिज़ केवल पावरपीसी या 68k का समर्थन करने वाले प्रोग्रामों से बड़े थे, जिसके कारण इनमे अनेक उपयोगिताओं का निर्माण हुआ जो अनावश्यक संस्करण को हटा देते हैं। <ref name="Engst_1994_1"/><ref name="Engst_1994_2"/> लघु [[हार्ड ड्राइव]] के युग में, जब 80 एमबी हार्ड ड्राइव सामान्य आकार के थे, यह उपयोगिताएँ कभी-कभी उपयोगी होती थीं, क्योंकि प्रोग्राम कोड सामान्यतः समग्र ड्राइव उपयोग का बड़ा भाग होता था, और फैट बाइनरी के अनावश्यक सदस्यों को अलग करने से हार्ड ड्राइव पर महत्वपूर्ण मात्रा में जगह रिक्त हो जाती थी।
 ===नेक्स्ट/एप्पल की मल्टी-आर्किटेक्चर बायनेरिज़===
-====[[ [[अगला]] कदम ]] मल्टी-आर्किटेक्चर बायनेरिज़====
+====[[अगला|नेक्स्ट]] स्टेप मल्टी-आर्किटेक्चर बायनेरिज़====
-फैट बायनेरिज़ NeXT के NeXTSTEP/OPENSTEP ऑपरेटिंग सिस्टम की विशेषता थी, जिसकी शुरुआत NeXTSTEP 3.1 से हुई थी। NeXTSTEP में, उन्हें मल्टी-आर्किटेक्चर बायनेरिज़ कहा जाता था। मल्टी-आर्किटेक्चर बायनेरिज़ का उद्देश्य मूल रूप से सॉफ़्टवेयर को NeXT के मोटोरोला 68k-आधारित हार्डवेयर और NeXTSTEP पर चलने वाले Intel [[IA-32]]-आधारित IBM PC कॉम्पैटिबल्स पर चलाने के लिए संकलित करने की अनुमति देना था, दोनों प्लेटफार्मों के लिए बाइनरी फ़ाइल के साथ।<ref name="Tevanian-DeMoney-Enderby_Wiebe_Snyder_1995"/>बाद में इसका उपयोग OPENSTEP अनुप्रयोगों को पीसी पर चलने की अनुमति देने के लिए किया गया और विभिन्न [[RISC]] प्लेटफ़ॉर्म OPENSTEP समर्थित थे। मल्टी-आर्किटेक्चर बाइनरी फ़ाइलें विशेष संग्रह प्रारूप में होती हैं, जिसमें एकल फ़ाइल मल्टी-आर्किटेक्चर बाइनरी द्वारा समर्थित प्रत्येक आर्किटेक्चर के लिए या अधिक [[मच-ओ]] सबफ़ाइलें संग्रहीत करती है। प्रत्येक मल्टी-आर्किटेक्चर बाइनरी संरचना से शुरू होती है ({{code|struct fat_header}}) जिसमें दो अहस्ताक्षरित पूर्णांक हैं। इस फ़ाइल को फैट बाइनरी के रूप में पहचानने के लिए पहले पूर्णांक (मैजिक) का उपयोग फ़ाइल प्रारूप#मैजिक नंबर के रूप में किया जाता है। दूसरा पूर्णांक ({{mono|nfat_arch}}) परिभाषित करता है कि संग्रह में कितनी मैक-ओ फ़ाइलें हैं (विभिन्न आर्किटेक्चर के लिए ही प्रोग्राम के कितने उदाहरण हैं)। इस हेडर के बाद, हैं{{mono|nfat_arch}} फैट_आर्क संरचनाओं की संख्या ({{code|struct fat_arch}}). यह संरचना ऑफसेट (फ़ाइल की शुरुआत से) को परिभाषित करती है जिस पर फ़ाइल, संरेखण, आकार और सीपीयू प्रकार और उपप्रकार को ढूंढना है जिस पर मैक-ओ बाइनरी (संग्रह के भीतर) लक्षित है।
+फैट बायनेरिज़ नेक्स्ट के नेक्स्ट स्टेप /ओपेन स्टेप ऑपरेटिंग सिस्टम की विशेषता थी, जिसकी प्रारंभ नेक्स्ट स्टेप 3.1 से हुई थी। नेक्स्ट स्टेप में, उन्हें मल्टी-आर्किटेक्चर बायनेरिज़ कहा जाता था। मल्टी-आर्किटेक्चर बायनेरिज़ का उद्देश्य मूल रूप से सॉफ़्टवेयर को नेक्स्ट के मोटोरोला 68k-आधारित हार्डवेयर और नेक्स्ट स्टेप पर चलने वाले इंटेल [[IA-32|आईए-32]]-आधारित आईबीएम पीसी कॉम ्पैटिबल्स पर चलाने के लिए संकलित करने की अनुमति देना था, दोनों प्लेटफार्मों के लिए बाइनरी फ़ाइल के साथ होता था। <ref name="Tevanian-DeMoney-Enderby_Wiebe_Snyder_1995"/> इसके पश्चात् इसका उपयोग ओपेन स्टेप अनुप्रयोगों को पीसी पर चलने की अनुमति देने के लिए किया गया और इसमें विभिन्न [[RISC|आरआईएससी]] प्लेटफ़ॉर्म ओपेन स्टेप समर्थित थे। मल्टी-आर्किटेक्चर बाइनरी फ़ाइलें विशेष संग्रह प्रारूप में होती हैं, जिसमें एकल फ़ाइल मल्टी-आर्किटेक्चर बाइनरी द्वारा समर्थित प्रत्येक आर्किटेक्चर के लिए या अधिक [[मच-ओ]] सबफ़ाइलें संग्रहीत करती है। प्रत्येक मल्टी-आर्किटेक्चर बाइनरी संरचना से प्रारंभ होती है इसमें ({{code|struct fat_header}}) होते हैं जिसमें दो अहस्ताक्षरित पूर्णांक हैं। इस फ़ाइल को फैट बाइनरी के रूप में पहचानने के लिए पहले पूर्णांक (मैजिक) का उपयोग किया जाता हैं इस प्रकार  फ़ाइल प्रारूप या मैजिक नंबर के रूप में इसका प्रयोग किया जाता है। दूसरा पूर्णांक ({{mono|nfat_arch}}) परिभाषित करता है कि संग्रह में कितनी मैक-ओ फ़ाइलें हैं (विभिन्न आर्किटेक्चर के लिए ही प्रोग्राम के कितने उदाहरण हैं)। इस हेडर के पश्चात्, {{mono|nfat_arch}} फैट_आर्क संरचनाओं की संख्या ({{code|struct fat_arch}}) होती हैं. यह संरचना ऑफसेट (फ़ाइल प्रारंभ से) इसको परिभाषित करती है जिस पर फ़ाइल, एलाइनमेंट, साइज और सीपीयू टाइप और सबटाइप को ढूंढना है जिस पर मैक-ओ बाइनरी (संग्रह के अंदर) लक्षित होता है।
-डेवलपर टूल्स के साथ भेजा गया [[जीएनयू कंपाइलर संग्रह]] का संस्करण विभिन्न आर्किटेक्चर के लिए [[ पार संकलन |पार संकलन]] स्रोत कोड को क्रॉस-कंपाइल करने में सक्षम था, जिस पर [[NeXTStep]] चलने में सक्षम था। उदाहरण के लिए, कई '-आर्क' विकल्पों (तर्क के रूप में आर्किटेक्चर के साथ) के साथ लक्ष्य आर्किटेक्चर को चुनना संभव था। यह विभिन्न आर्किटेक्चर पर चलने वाले NeXTStep के लिए प्रोग्राम वितरित करने का सुविधाजनक तरीका था।
+डेवलपर टूल्स के साथ भेजा गया [[जीएनयू कंपाइलर संग्रह]] का संस्करण विभिन्न आर्किटेक्चर के लिए [[ पार संकलन |क्रोस कंपिल]] स्रोत कोड को क्रॉस-कंपाइल करने में सक्षम था, जिस पर [[NeXTStep|नेक्स्ट स्टेप]] चलने में सक्षम था। उदाहरण के लिए, अनेक '-आर्क' विकल्पों (तर्क के रूप में आर्किटेक्चर के साथ) '''के साथ''' लक्ष्य आर्किटेक्चर को चुनना संभव था। यह विभिन्न आर्किटेक्चर पर चलने वाले नेक्स्ट स्टेप के लिए प्रोग्राम वितरित करने की सरल विधि थी।
-पुस्तकालय बनाना भी संभव था (उदाहरण के लिए NeXTStep का उपयोग करना)। {{mono|libtool}}) विभिन्न लक्षित ऑब्जेक्ट फ़ाइलों के साथ।
+विभिन्न लक्षित ऑब्जेक्ट फ़ाइलों के साथ लाइब्रेरी बनाना (उदाहरण के लिए नेक्स्ट स्टेप के l{{mono|libtool}} का उपयोग करना) भी संभव था।
-====मैक-ओ और [[ Mac OS X |Mac OS X]]====
+====मैक-ओ और [[ Mac OS X |मैक ओएस एक्स]]====
-Apple कंप्यूटर ने 1996 में NeXT का अधिग्रहण किया और OPENSTEP कोड के साथ काम करना जारी रखा। मैक-ओ एप्पल के मुफ्त [[डार्विन (ऑपरेटिंग सिस्टम)]] (2000) और एप्पल के मैक ओएस एक्स (2001) में मूल ऑब्जेक्ट फ़ाइल स्वरूप बन गया, और नेक्स्ट के मल्टी-आर्किटेक्चर बायनेरिज़ को ऑपरेटिंग सिस्टम द्वारा समर्थित किया जाना जारी रहा। Mac OS इसका उपयोग कई आर्किटेक्चर का समर्थन करने के लिए भी किया जा सकता है, जैसे कि [[32-बिट]] और [[64-बिट]] पावरपीसी, या पावरपीसी और x[[86]], या [[x86-64]] और [[AArch64]]।<ref name="Universal Binary"/>
+एप्पल कंप्यूटर ने 1996 में नेक्स्टम का अधिग्रहण किया और ओपेन स्टेप कोड के साथ काम करना प्रचलित रखा था। मैक-ओ एप्पल के मुफ्त [[डार्विन (ऑपरेटिंग सिस्टम)]] (2000) और एप्पल के मैक ओएस एक्स (2001) में मूल ऑब्जेक्ट फ़ाइल स्वरूप बन गया था, और नेक्स्ट के मल्टी-आर्किटेक्चर बायनेरिज़ को ऑपरेटिंग सिस्टम द्वारा समर्थित किया जाना प्रचलित रहा था। मैक ओएस में इसका उपयोग अनेक आर्किटेक्चर का समर्थन करने के लिए भी किया जा सकता है, जैसे कि [[32-बिट]] और [[64-बिट]] पावरपीसी, या पावरपीसी और x[[86]], या [[x86-64]] और [[AArch64]] हैं। <ref name="Universal Binary"/>
 ====एप्पल की यूनिवर्सल बाइनरी====
-{{Main|Universal binary}}
+{{Main|यूनिवर्सल बाइनरी}}
-[[File:Apple-Universal-binary-logo.png|thumb|एप्पल यूनिवर्सल बाइनरी लोगो]]2005 में, Apple ने PowerPC प्रोसेसर से Intel x86 प्रोसेसर तक, Intel प्रोसेसर में और Mac परिवर्तन की घोषणा की। Apple ने मल्टी-आर्किटेक्चर बाइनरी प्रारूप में निष्पादन योग्य फ़ाइलों का उपयोग करके नए अनुप्रयोगों के वितरण को बढ़ावा दिया जो मूल रूप से PowerPC और x86 दोनों का समर्थन करते हैं।<ref name="Singh_2006"/>ऐप्पल ऐसे कार्यक्रमों को [[सार्वभौमिक अनुप्रयोग]] कहता है और फ़ाइल प्रारूप को [[यूनिवर्सल बाइनरी]] कहता है, जो शायद इस नए संक्रमण को पिछले संक्रमण, या मल्टी-आर्किटेक्चर बाइनरी प्रारूप के अन्य उपयोगों से अलग करने का तरीका है।
+[[File:Apple-Universal-binary-logo.png|thumb|एप्पल यूनिवर्सल बाइनरी लोगो]]2005 में, एप्पल ने पावरपीसी प्रोसेसर से इंटेल x86 प्रोसेसर तक, इंटेल प्रोसेसर में और मैक परिवर्तन की घोषणा की थी। एप्पल ने मल्टी-आर्किटेक्चर बाइनरी प्रारूप में एक्सेक्यूटेबले फ़ाइलों का उपयोग करके नए अनुप्रयोगों के वितरण को बढ़ावा दिया जो मूल रूप से पावरपीसी और x86 दोनों का समर्थन करते हैं।<ref name="Singh_2006"/> एप्पल ऐसे प्रोग्रामों को [[सार्वभौमिक अनुप्रयोग]] कहता है और फ़ाइल प्रारूप को [[यूनिवर्सल बाइनरी]] कहता है, जो संभवतः इस नए संक्रमण को पिछले संक्रमण, या मल्टी-आर्किटेक्चर बाइनरी प्रारूप के अन्य उपयोगों से भिन्न करने का विधि है।
-पहले से मौजूद देशी पावरपीसी अनुप्रयोगों के फॉरवर्ड माइग्रेशन के लिए यूनिवर्सल बाइनरी प्रारूप आवश्यक नहीं था; 2006 से 2011 तक, Apple ने इस भूमिका को निभाने के लिए रोसेटा (सॉफ़्टवेयर), PowerPC (PPC)-टू-x86 डायनेमिक बाइनरी अनुवाद की आपूर्ति की। हालाँकि, रोसेटा का प्रदर्शन काफी अच्छा था, इसलिए डेवलपर्स को यूनिवर्सल बायनेरिज़ का उपयोग करके पीपीसी और इंटेल बायनेरिज़ दोनों की पेशकश करने के लिए प्रोत्साहित किया गया। यूनिवर्सल बाइनरी की स्पष्ट लागत यह है कि प्रत्येक स्थापित निष्पादन योग्य फ़ाइल बड़ी होती है, लेकिन पीपीसी के जारी होने के बाद के वर्षों में, हार्ड-ड्राइव स्थान निष्पादन योग्य आकार से काफी आगे निकल गया है; जबकि यूनिवर्सल बाइनरी ही एप्लिकेशन के एकल-प्लेटफ़ॉर्म संस्करण के आकार से दोगुना हो सकता है, फ्री-स्पेस संसाधन आम तौर पर कोड आकार को बौना कर देते हैं, जो छोटी सी समस्या बन जाती है। वास्तव में, अक्सर यूनिवर्सल-बाइनरी एप्लिकेशन दो एकल-आर्किटेक्चर अनुप्रयोगों से छोटा होगा क्योंकि प्रोग्राम संसाधनों को डुप्लिकेट के बजाय साझा किया जा सकता है। यदि सभी आर्किटेक्चर की आवश्यकता नहीं है, तो {{mono|lipo}} और {{mono|ditto}} मल्टी-आर्किटेक्चर बाइनरी छवि से संस्करणों को हटाने के लिए कमांड-लाइन अनुप्रयोगों का उपयोग किया जा सकता है, जिससे कभी-कभी पतली बाइनरी कहा जाता है।
+पूर्व से उपस्तिथ प्राचीन पावरपीसी अनुप्रयोगों के फॉरवर्ड माइग्रेशन के लिए यूनिवर्सल बाइनरी प्रारूप आवश्यक नहीं था | 2006 से 2011 तक, एप्पल ने इस भूमिका को निभाने के लिए रोसेटा (सॉफ़्टवेयर), पावरपीसी (पीपीसी)-टू-x86 डायनेमिक बाइनरी अनुवाद की आपूर्ति की हैं। चूँकि, रोसेटा का प्रदर्शन अधिक अच्छा था, इसलिए डेवलपर्स को यूनिवर्सल बायनेरिज़ का उपयोग करके पीपीसी और इंटेल बायनेरिज़ दोनों की प्रस्तुति करने के लिए प्रोत्साहित किया गया। यूनिवर्सल बाइनरी का स्पष्ट निवेश यह है कि प्रत्येक स्थापित एक्सेक्यूटेबले फ़ाइल बड़ी होती है, किन्तु पीपीसी के प्रचलित होने के पश्चात् इसके वर्षों में, हार्ड-ड्राइव स्थान एक्सेक्यूटेबले आकार से अधिक आगे निकल गया है | जबकि यूनिवर्सल बाइनरी ही एप्लिकेशन के एकल-प्लेटफ़ॉर्म संस्करण के आकार से दोगुना हो सकता है, फ्री-स्पेस संसाधन सामान्यतः कोड आकार को लघु कर देते हैं, जो छोटी सी समस्या बन जाती है। वास्तव में, प्रायः यूनिवर्सल-बाइनरी एप्लिकेशन दो एकल-आर्किटेक्चर अनुप्रयोगों से छोटा होगा क्योंकि प्रोग्राम संसाधनों को इसके डुप्लिकेट के अतिरिक्त साझा किया जा सकता है। यदि सभी आर्किटेक्चर की आवश्यकता नहीं है, तब {{mono|lipo}} और {{mono|ditto}} मल्टी-आर्किटेक्चर बाइनरी छवि से संस्करणों को हटाने के लिए कमांड-लाइन अनुप्रयोगों का उपयोग किया जा सकता है, जिससे कभी-कभी थिन बाइनरी कहा जाता है।
-इसके अलावा, मल्टी-आर्किटेक्चर बाइनरी निष्पादन योग्य में पावरपीसी और x86 के 32-बिट और 64-बिट दोनों संस्करणों के लिए कोड हो सकते हैं, जिससे एप्लिकेशन को ऐसे फॉर्म में भेजा जा सकता है जो 32-बिट प्रोसेसर का समर्थन करता है लेकिन 64-बिट प्रोसेसर पर चलने पर बड़े एड्रेस स्पेस और व्यापक डेटा पथ का उपयोग करता है।
+इसके अतिरिक्त, मल्टी-आर्किटेक्चर बाइनरी एक्सेक्यूटेबले में पावरपीसी और x86 के 32-बिट और 64-बिट दोनों संस्करणों के लिए कोड हो सकते हैं, जिससे एप्लिकेशन को ऐसे फॉर्म में भेजा जा सकता है जो 32-बिट प्रोसेसर का समर्थन करता है किन्तु 64-बिट प्रोसेसर पर चलने पर बड़े एड्रेस स्पेस और व्यापक डेटा पथ का उपयोग करता है।
-[[Xcode]] विकास परिवेश के 2.1 से 3.2 (Mac OS सार्वभौमिक बायनेरिज़ में अंततः निष्पादन योग्य कोड के अधिकतम चार संस्करण शामिल हो सकते हैं (32-बिट पावरपीसी, 32-बिट x86, 64-बिट पावरपीसी, और एक्स86-64|64-बिट x86)। हालाँकि, PowerPC समर्थन को Xcode 4.0 से हटा दिया गया था और इसलिए यह Mac OS X 10.7 या इससे अधिक संस्करण चलाने वाले डेवलपर्स के लिए उपलब्ध नहीं है।
+[[Xcode|एक्सकोड]] विकास परिवेश के 2.1 से 3.2 (मैक ओएस सार्वभौमिक बायनेरिज़ में अंततः एक्सेक्यूटेबले कोड के अधिकतम चार संस्करण सम्मिलित हो सकते हैं | इसमें (32-बिट पावरपीसी, 32-बिट x86, 64-बिट पावरपीसी, और एक्स86-64|64-बिट x86) होते है। चूँकि, पावरपीसी समर्थन को एक्सकोड 4.0 से हटा दिया गया था और इसलिए यह मैक ओएस एक्स 10.7 या इससे अधिक संस्करण चलाने वाले डेवलपर्स के लिए उपलब्ध नहीं होता है।
-में, Apple ने Apple सिलिकॉन में और Mac परिवर्तन की घोषणा की, इस बार Intel x86 प्रोसेसर से Apple सिलिकॉन (ARM64 आर्किटेक्चर) में। संक्रमण को सुचारू करने के लिए Apple ने [[यूनिवर्सल 2 बाइनरी]] प्रारूप के लिए समर्थन जोड़ा; यूनिवर्सल 2 बाइनरी फ़ाइलें मल्टी-आर्किटेक्चर बाइनरी फ़ाइलें हैं जिनमें x86-64 और ARM64 निष्पादन योग्य कोड दोनों होते हैं, जो बाइनरी को 64-बिट इंटेल और 64-बिट [[सेब सिलिकॉन]] दोनों पर मूल रूप से चलाने की अनुमति देते हैं। इसके अतिरिक्त, Apple ने उपयोगकर्ताओं को ऐसे एप्लिकेशन चलाने की अनुमति देने के लिए x86 से Arm64 निर्देश सेट के लिए [[रोसेटा 2]] डायनेमिक बाइनरी अनुवाद पेश किया, जिसमें यूनिवर्सल बाइनरी वेरिएंट नहीं है।
+में, एप्पल ने एप्पल सिलिकॉन में और मैक परिवर्तन की घोषणा की थी, इस बार इंटेल x86 प्रोसेसर से एप्पल सिलिकॉन (ARM64 आर्किटेक्चर) में दिया। संक्रमण को सुचारू करने के लिए एप्पल ने [[यूनिवर्सल 2 बाइनरी]] प्रारूप के लिए समर्थन जोड़ा था | यूनिवर्सल 2 में बाइनरी फ़ाइलें मल्टी-आर्किटेक्चर बाइनरी फ़ाइलें हैं जिनमें x86-64 और ARM64 एक्सेक्यूटेबले कोड दोनों होते हैं, जो बाइनरी को 64-बिट इंटेल और 64-बिट [[सेब सिलिकॉन|एप्पल सिलिकॉन]] दोनों पर मूल रूप से चलाने की अनुमति देते हैं। इसके अतिरिक्त, एप्पल ने उपयोगकर्ताओं को ऐसे एप्लिकेशन चलाने की अनुमति देने के लिए x86 से Arm64 निर्देश सेट के लिए [[रोसेटा 2]] डायनेमिक बाइनरी अनुवाद प्रस्तुत किया, जिसमें यूनिवर्सल बाइनरी वेरिएंट नहीं है।
 ==== एप्पल फैट ईएफआई बाइनरी ====
-में, Apple ने PowerPC से [[Intel]] CPU पर स्विच किया और [[फ़र्मवेयर खोलें]] को [[एक्स्टेंसिबल फ़र्मवेयर इंटरफ़ेस]] से बदल दिया। हालाँकि, 2008 तक, उनके कुछ Mac 32-बिट EFI और कुछ 64-बिट EFI का उपयोग करते थे। इस कारण से, Apple ने EFI विनिर्देश को फैट बायनेरिज़ के साथ बढ़ाया जिसमें 32-बिट और 64-बिट EFI बायनेरिज़ दोनों शामिल थे।<ref>{{Cite web |title=रेफ़िट - ईएफआई फैट बायनेरिज़|url=https://refit.sourceforge.net/info/fat_binary.html |access-date=2022-10-18 |website=refit.sourceforge.net}}</ref>
+में, एप्पल ने पावरपीसी से इंटेल सीपीयू पर स्विच किया और [[फ़र्मवेयर खोलें]] इसको [[एक्स्टेंसिबल फ़र्मवेयर इंटरफ़ेस]] से परिवर्तित कर दिया। चूँकि, 2008 तक, उनके कुछ मैक 32-बिट ईएफआई और कुछ 64-बिट ईएफआई का उपयोग करते थे। इस कारण से, एप्पल ने ईएफआई विनिर्देश को फैट बायनेरिज़ के साथ बढ़ाया जिसमें 32-बिट और 64-बिट ईएफआई बायनेरिज़ दोनों सम्मिलित थे।<ref>{{Cite web |title=रेफ़िट - ईएफआई फैट बायनेरिज़|url=https://refit.sourceforge.net/info/fat_binary.html |access-date=2022-10-18 |website=refit.sourceforge.net}}</ref>
 ==सीपी/एम और डॉस==
-===सीपी/एम-80 और डॉस के लिए संयुक्त COM-शैली बायनेरिज़===
+===सीपी/एम-80 और डॉस के लिए संयुक्त कॉम -शैली बायनेरिज़===
-[[इंटेल 8080]] (और [[Z80]]) प्रोसेसर परिवारों के लिए सीपी/एम-80, एमपी/एम-80, समवर्ती सीपी/एम, सीपी/एम प्लस, व्यक्तिगत सीपी/एम-80, [[एससीपी (ऑपरेटिंग सिस्टम)]] और [[एमएसएक्स-डॉस]] निष्पादन योग्य [[इंटेल 8086]] बायनेरिज़ के लिए डॉस-संगत ऑपरेटिंग सिस्टम के समान .COM [[फाइल एक्सटेंशन]] का उपयोग करते हैं। <ref समूह = nb नाम = NB_CP/M-86 /> दोनों ही मामलों में प्रोग्राम हैं ऑफसेट +100एच पर लोड किया गया और फ़ाइल में पहले बाइट पर जाकर निष्पादित किया गया।<ref name="Paul_2002_COM"/><ref name="Wilkinson_2005"/>चूंकि दो प्रोसेसर परिवारों के [[opcode]] संगत नहीं हैं, इसलिए गलत ऑपरेटिंग सिस्टम के तहत प्रोग्राम शुरू करने का प्रयास गलत और अप्रत्याशित व्यवहार की ओर ले जाता है।
+[[इंटेल 8080]] (और [[Z80]]) प्रोसेसर परिवारों के लिए सीपी/एम-80, एमपी/एम-80, समवर्ती सीपी/एम, सीपी/एम प्लस, व्यक्तिगत सीपी/एम-80, [[एससीपी (ऑपरेटिंग सिस्टम)]] और [[एमएसएक्स-डॉस]] एक्सेक्यूटेबले [[इंटेल 8086]] बायनेरिज़ के लिए डॉस-संगत ऑपरेटिंग सिस्टम के समान .कॉम [[फाइल एक्सटेंशन]] का उपयोग करते हैं। <ref समूह = nb नाम = NB_CP/M-86 /> दोनों ही मामलों में प्रोग्राम हैं ऑफसेट +100एच पर लोड किया गया और फ़ाइल में पहले बाइट पर जाकर निष्पादित किया गया।<ref name="Paul_2002_COM"/><ref name="Wilkinson_2005"/>चूंकि दो प्रोसेसर परिवारों के [[opcode]] संगत नहीं हैं, इसलिए गलत ऑपरेटिंग सिस्टम के अनुसार प्रोग्राम प्रारंभ करने का प्रयास गलत और अप्रत्याशित व्यवहार की ओर ले जाता है।
-इससे बचने के लिए, फैट बायनेरिज़ बनाने के लिए कुछ तरीके तैयार किए गए हैं जिनमें सीपी/एम-80 और डॉस प्रोग्राम दोनों शामिल हैं, जिसके पहले प्रारंभिक कोड होता है जिसे दोनों प्लेटफार्मों पर सही ढंग से व्याख्या किया जाता है।<ref name="Wilkinson_2005"/>विधियाँ या तो अपने संबंधित वातावरण के लिए बनाए गए दो पूरी तरह कार्यात्मक कार्यक्रमों को जोड़ती हैं, या [[कोड स्टब]]्स जोड़ती हैं जो गलत प्रोसेसर पर शुरू होने पर प्रोग्राम को शानदार ढंग से बाहर निकलने का कारण बनती हैं। इसे काम करने के लिए, पहले कुछ निर्देश (कभी-कभी #गैजेट्स भी कहा जाता है<ref name="Cha-Pak-Brumley-Lipton_2010"/> .COM फ़ाइल में 8086 और 8080 दोनों प्रोसेसर के लिए वैध कोड होना चाहिए, जिससे प्रोसेसर कोड के भीतर विभिन्न स्थानों में शाखाबद्ध हो जाएंगे।<ref name="Cha-Pak-Brumley-Lipton_2010"/>उदाहरण के लिए, शिमोन क्रैन के एमुलेटर MyZ80 में उपयोगिताएँ ऑपकोड अनुक्रम से शुरू होती हैं {{mono|EBh, 52h, EBh}}.<ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/><ref name="Elliott_2009_PMARC"/>8086 इसे छलांग के रूप में देखता है और अपने अगले निर्देश को ऑफसेट +154h से पढ़ता है जबकि 8080 या संगत प्रोसेसर सीधे जाता है और अपने अगले निर्देश को +103h से पढ़ता है।
+इससे बचने के लिए, फैट बायनेरिज़ बनाने के लिए कुछ तरीके तैयार किए गए हैं जिनमें सीपी/एम-80 और डॉस प्रोग्राम दोनों सम्मिलित हैं, जिसके पहले प्रारंभिक कोड होता है जिसे दोनों प्लेटफार्मों पर सही ढंग से व्याख्या किया जाता है।<ref name="Wilkinson_2005"/>विधियाँ या तब अपने संबंधित वातावरण के लिए बनाए गए दो पूर्ण तरह कार्यात्मक प्रोग्रामों को जोड़ती हैं, या [[कोड स्टब]]्स जोड़ती हैं जो गलत प्रोसेसर पर प्रारंभ होने पर प्रोग्राम को शानदार ढंग से बाहर निकलने का कारण बनती हैं। इसे काम करने के लिए, पहले कुछ निर्देश (कभी-कभी या गैजेट्स भी कहा जाता है<ref name="Cha-Pak-Brumley-Lipton_2010"/> .कॉम फ़ाइल में 8086 और 8080 दोनों प्रोसेसर के लिए वैध कोड होना चाहिए, जिससे प्रोसेसर कोड के अंदर विभिन्न स्थानों में शाखाबद्ध हो जाएंगे।<ref name="Cha-Pak-Brumley-Lipton_2010"/>उदाहरण के लिए, शिमोन क्रैन के एमुलेटर MyZ80 में उपयोगिताएँ ऑपकोड अनुक्रम से प्रारंभ होती हैं {{mono|EBh, 52h, EBh}}.<ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/><ref name="Elliott_2009_PMARC"/>8086 इसे जम्प के रूप में देखता है और अपने अगले निर्देश को ऑफसेट +154h से पढ़ता है जबकि 8080 या संगत प्रोसेसर सीधे जाता है और अपने अगले निर्देश को +103h से पढ़ता है।
 इस प्रयोजन के लिए इसी प्रकार का अनुक्रम प्रयोग किया जाता है {{mono|EBh, 03h, C3h}}.<ref name="Christ_2012"/><ref name="Brehm_2016"/>
-जॉन सी. इलियट का FATBIN<ref name="Elliott_1996_FATBIN"/><ref name="Elliott_1998_FATBIN"/><ref name="Elliott_2002_FBMAKE"/>CP/M-80 और DOS .COM फ़ाइल को निष्पादन योग्य में संयोजित करने की उपयोगिता है।<ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/><ref name="Elliott_2005_FATBIN-PMSFX"/>मूल [[PMsfx]] का उनका व्युत्पन्न योशीहिको मिनो के [[PMarc]] द्वारा बनाए गए अभिलेखों को [[स्व-निकालने योग्य संग्रह]] के रूप में संशोधित करता है|CP/M-80 और DOS, दोनों के तहत स्व-निकालने योग्य, से शुरू होता है {{mono|EBh, 18h, 2Dh, 70h, 6Dh, 73h, 2Dh}} स्वयं-निकालने वाले [[PMarc]] अभिलेखागार के लिए -pms- हस्ताक्षर भी शामिल करें,<ref name="Elliott_1997_PMSFX2"/><ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/><ref name="Elliott_2005_FATBIN-PMSFX"/><ref name="Elliott_2009_PMARC"/>इस प्रकार यह [[निष्पादन योग्य ASCII कोड]] के रूप का भी प्रतिनिधित्व करता है।
+जॉन सी. इलियट का FATBIN<ref name="Elliott_1996_FATBIN"/><ref name="Elliott_1998_FATBIN"/><ref name="Elliott_2002_FBMAKE"/>CP/M-80 और डीओएस .कॉम फ़ाइल को एक्सेक्यूटेबले में संयोजित करने की उपयोगिता है।<ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/><ref name="Elliott_2005_FATBIN-PMSFX"/>मूल [[PMsfx]] का उनका व्युत्पन्न योशीहिको मिनो के [[PMarc]] द्वारा बनाए गए अभिलेखों को [[स्व-निकालने योग्य संग्रह]] के रूप में संशोधित करता है|CP/M-80 और DOS, दोनों के अनुसार स्व-निकालने योग्य, से प्रारंभ होता है {{mono|EBh, 18h, 2Dh, 70h, 6Dh, 73h, 2Dh}} स्वयं-निकालने वाले [[PMarc]] अभिलेखागार के लिए -pms- हस्ताक्षर भी सम्मिलित करें,<ref name="Elliott_1997_PMSFX2"/><ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/><ref name="Elliott_2005_FATBIN-PMSFX"/><ref name="Elliott_2009_PMARC"/>इस प्रकार यह [[निष्पादन योग्य ASCII कोड|एक्सेक्यूटेबले ASCII कोड]] के रूप का भी प्रतिनिधित्व करता है।
-CP/M-80 और MSX-DOS मशीनों के लिए .COM प्रोग्रामों को ग़लत ढंग से निष्पादित करने से DOS-संगत ऑपरेटिंग सिस्टम को रखने का दूसरा तरीका<ref name="Wilkinson_2005"/>8080 कोड को प्रारंभ करना है {{mono|C3h, 03h, 01h}}, जिसे x86 प्रोसेसर द्वारा RET निर्देश के रूप में डिकोड किया जाता है, जिससे प्रोग्राम से शानदार ढंग से बाहर निकल जाता है,<ref group="nb" name="NB_RET"/>जबकि इसे 8080 प्रोसेसर द्वारा JP 103h अनुदेश के रूप में डिकोड किया जाएगा और बस प्रोग्राम में अगले अनुदेश पर पहुंच जाएगा। इसी तरह, एसएलआर सिस्टम्स द्वारा सीपी/एम असेंबलर Z80ASM+ डॉस पर गलती से चलने पर त्रुटि संदेश प्रदर्शित करेगा।<ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/>
+CP/M-80 और MSX-डीओएस मशीनों के लिए .कॉम प्रोग्रामों को ग़लत ढंग से निष्पादित करने से DOS-संगत ऑपरेटिंग सिस्टम को रखने का दूसरा विधि<ref name="Wilkinson_2005"/>8080 कोड को प्रारंभ करना है {{mono|C3h, 03h, 01h}}, जिसे x86 प्रोसेसर द्वारा RET निर्देश के रूप में डिकोड किया जाता है, जिससे प्रोग्राम से शानदार ढंग से बाहर निकल जाता है,<ref group="nb" name="NB_RET"/>जबकि इसे 8080 प्रोसेसर द्वारा JP 103h अनुदेश के रूप में डिकोड किया जाएगा और बस प्रोग्राम में अगले अनुदेश पर पहुंच जाएगा। इसी तरह, एसएलआर सिस्टम्स द्वारा सीपी/एम असेंबलर Z80ASM+ डॉस पर गलती से चलने पर त्रुटि संदेश प्रदर्शित करेगा।<ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/>
-कुछ CP/M-80 3.0 .COM फ़ाइलों में GENCOM (CP/M कमांड) द्वारा या अधिक RSX (कंप्यूटिंग) ओवरले जुड़े हो सकते हैं।<ref name="Elliott_CPM3_COM"/>यदि ऐसा है, तो वे अतिरिक्त [[256 बाइट सीमा]]|256-बाइट हेडर (एक पृष्ठ (कंप्यूटिंग)) के साथ शुरू करते हैं। इसे इंगित करने के लिए, हेडर में पहला बाइट [[ जादुई बाइट |जादुई बाइट]] पर सेट किया गया है {{mono|C9h}}, जो CP/M 3.0 [[निष्पादन योग्य लोडर]] के लिए इस प्रकार की COM फ़ाइल की पहचान करने वाले हस्ताक्षर के रूप में काम करता है, साथ ही 8080-संगत प्रोसेसर के लिए RET निर्देश के रूप में काम करता है, जो फ़ाइल को CP/M-80 के पुराने संस्करणों के तहत निष्पादित करने पर शानदार निकास की ओर ले जाता है।<ref group="nb" name="NB_RET"/>
+कुछ CP/M-80 3.0 .कॉम फ़ाइलों में GENकॉम (CP/M कमांड) द्वारा या अधिक RSX (कंप्यूटिंग) ओवरले जुड़े हो सकते हैं।<ref name="Elliott_CPM3_COM"/>यदि ऐसा है, तब वह अतिरिक्त [[256 बाइट सीमा]]|256-बाइट हेडर (एक पृष्ठ (कंप्यूटिंग)) के साथ प्रारंभ करते हैं। इसे इंगित करने के लिए, हेडर में पहला बाइट [[ जादुई बाइट |जादुई बाइट]] पर सेट किया गया है {{mono|C9h}}, जो CP/M 3.0 [[निष्पादन योग्य लोडर|एक्सेक्यूटेबले लोडर]] के लिए इस प्रकार की कॉम फ़ाइल की पहचान करने वाले हस्ताक्षर के रूप में काम करता है, साथ ही 8080-संगत प्रोसेसर के लिए RET निर्देश के रूप में काम करता है, जो फ़ाइल को CP/M-80 के पूर्व संस्करणों के अनुसार निष्पादित करने पर शानदार निकास की ओर ले जाता है।<ref group="nb" name="NB_RET"/>
-{{mono|C9h}} किसी भी x86 प्रोसेसर के लिए प्रोग्राम के पहले बाइट के रूप में कभी भी उपयुक्त नहीं है (विभिन्न पीढ़ियों के लिए इसके अलग-अलग अर्थ हैं,<ref group="nb" name="NB_C9"/>लेकिन यह कभी भी सार्थक पहली बाइट नहीं होती); DOS के कुछ संस्करणों में निष्पादन योग्य लोडर प्रारंभ होने वाली COM फ़ाइलों को अस्वीकार कर देता है {{mono|C9h}}, गलत संचालन से बचना।
+{{mono|C9h}} किसी भी x86 प्रोसेसर के लिए प्रोग्राम के पहले बाइट के रूप में कभी भी उपयुक्त नहीं है (विभिन्न पीढ़ियों के लिए इसके भिन्न-भिन्न अर्थ हैं,<ref group="nb" name="NB_C9"/>किन्तु यह कभी भी सार्थक पहली बाइट नहीं होती); डीओएस के कुछ संस्करणों में एक्सेक्यूटेबले लोडर प्रारंभ होने वाली कॉम फ़ाइलों को अस्वीकार कर देता है {{mono|C9h}}, गलत संचालन से बचना।
 संयुक्त Z80/[[6502]] के लिए समान [[ऑपकोड ओवरलैपिंग]] कोड अनुक्रम भी तैयार किए गए हैं,<ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/>8086/[[68000]]<ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/>या x86/MIPS आर्किटेक्चर/ARM आर्किटेक्चर बायनेरिज़।<ref name="Cha-Pak-Brumley-Lipton_2010"/>
@@ Line 70: / Line 67: @@
 ===सीपी/एम-86 और डॉस के लिए संयुक्त बायनेरिज़===
-सीपी/एम-86 और डॉस निष्पादनयोग्यों के लिए सामान्य फ़ाइल एक्सटेंशन साझा नहीं करते हैं।<ref समूह=एनबी नाम=एनबी_सीपी/एम-86 /> इस प्रकार, निष्पादनयोग्यों को भ्रमित करना आम तौर पर संभव नहीं है। हालाँकि, DOS के शुरुआती संस्करणों में इसकी वास्तुकला के संदर्भ में CP/M के साथ इतनी समानता थी कि निष्पादन योग्य कोड वाले बायनेरिज़ को साझा करने के लिए कुछ शुरुआती DOS प्रोग्राम विकसित किए गए थे। ऐसा करने के लिए ज्ञात प्रोग्राम WordStar 3.20|WordStar 3.2x था, जो सीपी/एम-86 और [[एमएस-डॉस]] के लिए अपने पोर्ट में समान [[ओवरले फ़ाइल]]ों का उपयोग करता था,<ref name="Necasek_2018_WordStar"/>और [[रनटाइम (प्रोग्राम जीवनचक्र चरण)]] में इन ऑपरेटिंग सिस्टम की अलग-अलग कॉलिंग परंपराओं को अनुकूलित करने के लिए गतिशील रूप से फिक्स्ड-अप कोड का उपयोग किया जाता है।<ref name="Necasek_2018_WordStar"/>
+सीपी/एम-86 और डॉस निष्पादन योग्यों के लिए सामान्य फ़ाइल एक्सटेंशन साझा नहीं करते हैं।<ref समूह=एनबी नाम=एनबी_सीपी/एम-86 /> इस प्रकार, निष्पादनयोग्यों को भ्रमित करना सामान्यतः संभव नहीं है। चूँकि, डीओएस के प्रारंभिक संस्करणों में इसकी वास्तुकला के संदर्भ में CP/M के साथ इतनी समानता थी कि एक्सेक्यूटेबले कोड वाले बायनेरिज़ को साझा करने के लिए कुछ प्रारंभिक डीओएस प्रोग्राम विकसित किए गए थे। ऐसा करने के लिए ज्ञात प्रोग्राम WordStar 3.20|WordStar 3.2x था, जो सीपी/एम-86 और [[एमएस-डॉस]] के लिए अपने पोर्ट में समान [[ओवरले फ़ाइल]]ों का उपयोग करता था,<ref name="Necasek_2018_WordStar"/>और [[रनटाइम (प्रोग्राम जीवनचक्र चरण)]] में इन ऑपरेटिंग सिस्टम की भिन्न-भिन्न कॉलिंग परंपराओं को अनुकूलित करने के लिए गतिशील रूप से फिक्स्ड-अप कोड का उपयोग किया जाता है।<ref name="Necasek_2018_WordStar"/>
 सीपी/एम-86 और डॉस के लिए [[ डिजिटल अनुसंधान |डिजिटल अनुसंधान]] का [[ ग्राफ़िक्स सिस्टम एक्सटेंशन |ग्राफ़िक्स सिस्टम एक्सटेंशन]] भी बाइनरी समान 16-बिट ड्राइवर साझा करता है।<ref name="Lineback_GSX"/>
-===संयुक्त COM और SYS फ़ाइलें===
+===संयुक्त कॉम और SYS फ़ाइलें===
-DOS [[डिवाइस ड्राइवर]] (आमतौर पर फ़ाइल एक्सटेंशन .SYS के साथ) फ़ाइल हेडर से शुरू होते हैं जिनके पहले चार बाइट्स परंपरा के अनुसार [[हेक्साडेसिमल]] होते हैं, हालांकि यह कोई आवश्यकता नहीं है।<ref name="Paul_2002_COMSYS"/>इसे ऑपरेटिंग सिस्टम द्वारा गतिशील रूप से ठीक किया जाता है जब ड्राइवर [[लोडर (कंप्यूटिंग)]] करता है (आमतौर पर [[DOS BIOS]] में जब यह CONFIG.SYS में डिवाइस (CONFIG.SYS निर्देश) कथन निष्पादित करता है)। चूँकि DOS प्रति डिवाइस लोड होने वाली .COM एक्सटेंशन वाली फ़ाइलों को अस्वीकार नहीं करता है और FFFFFFFFh के लिए परीक्षण नहीं करता है, इसलिए COM प्रोग्राम और डिवाइस ड्राइवर को ही फ़ाइल में संयोजित करना संभव है<ref name="Paul_2002_CTMOUSE"/><ref name="Paul_2002_COMSYS"/>फ़ाइल के पहले चार बाइट्स के भीतर एम्बेडेड COM प्रोग्राम के प्रवेश बिंदु पर जंप निर्देश रखकर (तीन बाइट्स आमतौर पर पर्याप्त होते हैं)।<ref name="Paul_2002_COMSYS"/>यदि एम्बेडेड प्रोग्राम और डिवाइस ड्राइवर अनुभाग कोड या डेटा का सामान्य भाग साझा करते हैं, तो कोड को .COM स्टाइल प्रोग्राम के रूप में ऑफसेट +0100h पर और डिवाइस ड्राइवर के रूप में +0000h पर लोड होने से निपटना आवश्यक है।<ref name="Paul_2002_CTMOUSE"/>गलत ऑफसेट पर लोड किए गए लेकिन स्थिति-स्वतंत्र होने के लिए डिज़ाइन नहीं किए गए साझा कोड के लिए, इसके लिए आंतरिक पता फिक्स-अप की आवश्यकता होती है<ref name="Paul_2002_CTMOUSE"/>उसी के समान जो अन्यथा पहले से ही स्थानांतरित लोडर द्वारा किया गया होता, सिवाय इसके कि इस मामले में इसे लोड किए गए प्रोग्राम द्वारा ही किया जाना है; यह स्व-स्थानांतरित करने वाले ड्राइवरों की स्थिति के समान है, लेकिन ऑपरेटिंग सिस्टम के लोडर द्वारा प्रोग्राम पहले से ही लक्ष्य स्थान पर लोड किया गया है।
+डीओएस [[डिवाइस ड्राइवर]] (सामान्यतः फ़ाइल एक्सटेंशन .SYS के साथ) फ़ाइल हेडर से प्रारंभ होते हैं जिनके पहले चार बाइट्स परंपरा के अनुसार [[हेक्साडेसिमल]] होते हैं, हालांकि यह कोई आवश्यकता नहीं है।<ref name="Paul_2002_COMSYS"/>इसे ऑपरेटिंग सिस्टम द्वारा गतिशील रूप से ठीक किया जाता है जब ड्राइवर [[लोडर (कंप्यूटिंग)]] करता है (सामान्यतः [[DOS BIOS|डीओएस BIOS]] में जब यह CONFIG.SYS में डिवाइस (CONFIG.SYS निर्देश) कथन निष्पादित करता है)। चूँकि डीओएस प्रति डिवाइस लोड होने वाली .कॉम एक्सटेंशन वाली फ़ाइलों को अस्वीकार नहीं करता है और FFFFFFFFh के लिए परीक्षण नहीं करता है, इसलिए कॉम प्रोग्राम और डिवाइस ड्राइवर को ही फ़ाइल में संयोजित करना संभव है<ref name="Paul_2002_CTMOUSE"/><ref name="Paul_2002_COMSYS"/>फ़ाइल के पहले चार बाइट्स के अंदर एम्बेडेड कॉम प्रोग्राम के प्रवेश बिंदु पर जंप निर्देश रखकर (तीन बाइट्स सामान्यतः पर्याप्त होते हैं)।<ref name="Paul_2002_COMSYS"/>यदि एम्बेडेड प्रोग्राम और डिवाइस ड्राइवर अनुभाग कोड या डेटा का सामान्य भाग साझा करते हैं, तब कोड को .कॉम स्टाइल प्रोग्राम के रूप में ऑफसेट +0100h पर और डिवाइस ड्राइवर के रूप में +0000h पर लोड होने से निपटना आवश्यक है।<ref name="Paul_2002_CTMOUSE"/>गलत ऑफसेट पर लोड किए गए किन्तु स्थिति-स्वतंत्र होने के लिए डिज़ाइन नहीं किए गए साझा कोड के लिए, इसके लिए आंतरिक पता फिक्स-अप की आवश्यकता होती है<ref name="Paul_2002_CTMOUSE"/>उसी के समान जो अन्यथा पहले से ही स्थानांतरित लोडर द्वारा किया गया होता, सिवाय इसके कि इस मामले में इसे लोड किए गए प्रोग्राम द्वारा ही किया जाना है; यह स्व-स्थानांतरित करने वाले ड्राइवरों की स्थिति के समान है, किन्तु ऑपरेटिंग सिस्टम के लोडर द्वारा प्रोग्राम पहले से ही लक्ष्य स्थान पर लोड किया गया है।
 ===क्रैश-संरक्षित सिस्टम फ़ाइलें===
-डॉस के तहत, परंपरा के अनुसार, कुछ फाइलों में फ़ाइल एक्सटेंशन होते हैं जो उनके वास्तविक फ़ाइल प्रकार को प्रतिबिंबित नहीं करते हैं।<ref group="nb" name="NB_NAMES"/>उदाहरण के लिए, COUNTRY.SYS<ref name="Paul_2001_COUNTRY"/>DOS डिवाइस ड्राइवर नहीं है,<ref group="nb" name="NB_KEYBOARD.SYS"/>लेकिन CONFIG.SYS देश (CONFIG.SYS निर्देश) और NLSFUNC (DOS कमांड) ड्राइवर के साथ उपयोग के लिए बाइनरी राष्ट्रीय भाषा समर्थन डेटाबेस फ़ाइल।<ref name="Paul_2001_COUNTRY"/>PC DOS और [[DR-DOS]] सिस्टम फ़ाइलें IBMBIO.COM और IBMDOS.COM [[बूटस्ट्रैप लोडर]] द्वारा लोड की गई विशेष बाइनरी छवियां हैं, COM-शैली प्रोग्राम नहीं।<ref group="nb" name="NB_KEYBOARD.SYS"/>DEVICE स्टेटमेंट के साथ COUNTRY.SYS को लोड करने का प्रयास करने या कमांड प्रॉम्प्ट पर IBMBIO.COM या IBMDOS.COM को निष्पादित करने से अप्रत्याशित परिणाम होंगे।<ref group="nb" name="NB_NAMES"/><ref group="nb" name="NB_HIDDEN"/>
+डॉस के अनुसार , परंपरा के अनुसार, कुछ फाइलों में फ़ाइल एक्सटेंशन होते हैं जो उनके वास्तविक फ़ाइल प्रकार को प्रतिबिंबित नहीं करते हैं।<ref group="nb" name="NB_NAMES"/>उदाहरण के लिए, COUNTRY.SYS<ref name="Paul_2001_COUNTRY"/>डीओएस डिवाइस ड्राइवर नहीं है,<ref group="nb" name="NB_KEYBOARD.SYS"/>किन्तु CONFIG.SYS देश (CONFIG.SYS निर्देश) और NLSFUNC (डीओएस कमांड) ड्राइवर के साथ उपयोग के लिए बाइनरी राष्ट्रीय भाषा समर्थन डेटाबेस फ़ाइल।<ref name="Paul_2001_COUNTRY"/>पीसीडीओएस और [[DR-DOS|DR-]]डीओएस सिस्टम फ़ाइलें IBMBIO.कॉम और IBMDOS.कॉम [[बूटस्ट्रैप लोडर]] द्वारा लोड की गई विशेष बाइनरी छवियां हैं, COM-शैली प्रोग्राम नहीं।<ref group="nb" name="NB_KEYBOARD.SYS"/>DEVICE स्टेटमेंट के साथ COUNTRY.SYS को लोड करने का प्रयास करने या कमांड प्रॉम्प्ट पर IBMBIO.कॉम या IBMDOS.कॉम को निष्पादित करने से अप्रत्याशित परिणाम होंगे।<ref group="nb" name="NB_NAMES"/><ref group="nb" name="NB_HIDDEN"/>
-कभी-कभी ऊपर वर्णित तकनीकों का उपयोग करके इससे बचना संभव होता है। उदाहरण के लिए, DR-DOS 7.02 और उच्चतर में मैथियास आर. पॉल द्वारा विकसित सुरक्षा सुविधा शामिल है:<ref name="Paul_1997_NWDOSTIP"/>यदि इन फ़ाइलों को अनुचित तरीके से बुलाया जाता है, तो छोटे एम्बेडेड स्टब्स बस कुछ फ़ाइल संस्करण जानकारी प्रदर्शित करेंगे और शानदार ढंग से बाहर निकल जाएंगे।<ref name="Paul_1997_OD-A3"/><ref name="Paul_1997_NWDOSTIP"/><ref name="Caldera_1998_NEW703"/><ref name="Paul_2001_COUNTRY"/>इसके अतिरिक्त, संदेश विशेष रूप से कुछ जादुई संख्या (प्रोग्रामिंग) का पालन करने के लिए तैयार किया गया है बाहरी [[नेटवेयर]] और DR-DOS संस्करण.EXE फ़ाइल पहचान उपयोगिता द्वारा पहचाने गए जादुई पैटर्न।<ref name="Paul_2001_COUNTRY"/><ref name="Paul_1997_NWDOSTIP"/><ref group="nb" name="NB_COUNTRY.SYS"/>
+कभी-कभी ऊपर वर्णित तकनीकों का उपयोग करके इससे बचना संभव होता है। उदाहरण के लिए, DR-डीओएस 7.02 और उच्चतर में मैथियास आर. पॉल द्वारा विकसित सुरक्षा सुविधा सम्मिलित है:<ref name="Paul_1997_NWDOSTIP"/>यदि इन फ़ाइलों को अनुचित तरीके से बुलाया जाता है, तब लघु एम्बेडेड स्टब्स बस कुछ फ़ाइल संस्करण जानकारी प्रदर्शित करेंगे और शानदार ढंग से बाहर निकल जाएंगे।<ref name="Paul_1997_OD-A3"/><ref name="Paul_1997_NWDOSTIP"/><ref name="Caldera_1998_NEW703"/><ref name="Paul_2001_COUNTRY"/>इसके अतिरिक्त, संदेश विशेष रूप से कुछ जादुई संख्या (प्रोग्रामिंग) का पालन करने के लिए तैयार किया गया है बाहरी [[नेटवेयर]] और DR-डीओएस संस्करण.EXE फ़ाइल पहचान उपयोगिता द्वारा पहचाने गए जादुई पैटर्न।<ref name="Paul_2001_COUNTRY"/><ref name="Paul_1997_NWDOSTIP"/><ref group="nb" name="NB_COUNTRY.SYS"/>
-एक समान सुरक्षा सुविधा 8080 निर्देश थी {{mono|C7h}} ( RST 0 ) जे सेज और जो राइट के [[जेड-प्रणाली]] टाइप-3 और टाइप-4 Z3ENV कार्यक्रमों की शुरुआत में<ref name="Sage_1988_ZSystem"/><ref name="Sage_1992_ZSystem_1"/>साथ ही Z3TXT भाषा ओवरले फ़ाइलें,<ref name="Sage_1992_ZSystem_2"/>जिसके परिणामस्वरूप अनुचित तरीके से लोड होने पर सीपी/एम-80 के तहत [[ गर्म बूट |गर्म बूट]] (क्रैश के बजाय) हो जाएगा।<ref name="Sage_1988_ZSystem"/><ref name="Sage_1992_ZSystem_1"/><ref name="Sage_1992_ZSystem_2"/><ref group="nb" name="NB_RET"/>
+एक समान सुरक्षा सुविधा 8080 निर्देश थी {{mono|C7h}} ( RST 0 ) जे सेज और जो राइट के [[जेड-प्रणाली]] टाइप-3 और टाइप-4 Z3ENV प्रोग्रामों की प्रारंभ में<ref name="Sage_1988_ZSystem"/><ref name="Sage_1992_ZSystem_1"/>साथ ही Z3TXT भाषा ओवरले फ़ाइलें,<ref name="Sage_1992_ZSystem_2"/>जिसके परिणामस्वरूप अनुचित तरीके से लोड होने पर सीपी/एम-80 के अनुसार [[ गर्म बूट |गर्म बूट]] (क्रैश के अतिरिक्त) हो जाएगा।<ref name="Sage_1988_ZSystem"/><ref name="Sage_1992_ZSystem_1"/><ref name="Sage_1992_ZSystem_2"/><ref group="nb" name="NB_RET"/>
-एक समान रूप से, परंपरा के अनुसार फ़ाइल हस्ताक्षरों की कई (बाइनरी) सूची में शामिल है {{mono|1Ah}} फ़ाइल की शुरुआत के पास बाइट ([[ASCII]] ^Z)। जब किसी फ़ाइल को गैर-बाइनरी मोड में खोला जाता है, तो इस [[नियंत्रण चरित्र]] को सॉफ्ट [[फाइल समाप्त]] (ईओएफ) मार्कर के रूप में व्याख्या किया जाएगा, और इस प्रकार, कई ऑपरेटिंग सिस्टम ([[पीडीपी-6]] -6 मॉनिटर सहित) के तहत<ref name="DEC_1965_PDP-6"/>और आरटी-11, [[ ओपन VMS |ओपन VMS]] , [[टॉप -10]],<ref name="DEC_1969_PDP-10"/>सीपी/एम,<ref name="DRI_1979_CPM20-IG"/><रेफरी नाम= होगन_1982_सीपी/एम /> डॉस,<ref name="CHF_2010_DOS-1A"/>और विंडोज़<ref name="Superuser_2011_TXT"/>), यह बाइनरी कचरा प्रदर्शित होने से रोकता है जब कोई फ़ाइल गलती से कंसोल पर मुद्रित हो जाती है।
+एक समान रूप से, परंपरा के अनुसार फ़ाइल हस्ताक्षरों की अनेक (बाइनरी) सूची में सम्मिलित है {{mono|1Ah}} फ़ाइल की प्रारंभ के पास बाइट ([[ASCII]] ^Z)। जब किसी फ़ाइल को गैर-बाइनरी मोड में खोला जाता है, तब इस [[नियंत्रण चरित्र]] को सॉफ्ट [[फाइल समाप्त]] (ईओएफ) मार्कर के रूप में व्याख्या किया जाएगा, और इस प्रकार, अनेक ऑपरेटिंग सिस्टम ([[पीडीपी-6]] -6 मॉनिटर सहित) के अनुसार <ref name="DEC_1965_PDP-6"/>और आरटी-11, [[ ओपन VMS |ओपन VMS]] , [[टॉप -10]],<ref name="DEC_1969_PDP-10"/>सीपी/एम,<ref name="DRI_1979_CPM20-IG"/><रेफरी नाम= होगन_1982_सीपी/एम /> डॉस,<ref name="CHF_2010_DOS-1A"/>और विंडोज़<ref name="Superuser_2011_TXT"/>), यह बाइनरी कचरा प्रदर्शित होने से रोकता है जब कोई फ़ाइल गलती से कंसोल पर मुद्रित हो जाती है।
 ==लिनक्स==
 ===FatELF: लिनक्स के लिए यूनिवर्सल बायनेरिज़===
-[[File:FatELF-logo.png|thumb|फैटईएलएफ लोगो]][[FatELF]]<ref name="Gordon_2009_FatELF"/>[[लिनक्स]] और अन्य यूनिक्स जैसे ऑपरेटिंग सिस्टम के लिए मोटा बाइनरी कार्यान्वयन था। तकनीकी रूप से, FatELF बाइनरी कुछ मेटा डेटा के साथ [[निष्पादन योग्य और लिंकिंग प्रारूप]] बायनेरिज़ का संयोजन था जो दर्शाता है कि किस आर्किटेक्चर पर किस बाइनरी का उपयोग करना है।<ref name="Gordon_2009_Spec"/>[[ CPU | CPU]] आर्किटेक्चर एब्स्ट्रैक्शन ([[ बाइट क्रम ]], शब्द आकार, सीपीयू निर्देश सेट इत्यादि) के अतिरिक्त, एकाधिक कर्नेल [[एप्लिकेशन बाइनरी इंटरफ़ेस]] और संस्करणों के समर्थन के साथ बायनेरिज़ का लाभ है।
+[[File:FatELF-logo.png|thumb|फैटईएलएफ लोगो]][[FatELF]]<ref name="Gordon_2009_FatELF"/>[[लिनक्स]] और अन्य यूनिक्स जैसे ऑपरेटिंग सिस्टम के लिए मोटा बाइनरी कार्यान्वयन था। तकनीकी रूप से, FatELF बाइनरी कुछ मेटा डेटा के साथ [[निष्पादन योग्य और लिंकिंग प्रारूप|एक्सेक्यूटेबले और लिंकिंग प्रारूप]] बायनेरिज़ का संयोजन था जो दर्शाता है कि किस आर्किटेक्चर पर किस बाइनरी का उपयोग करना है।<ref name="Gordon_2009_Spec"/> सीपीयू आर्किटेक्चर एब्स्ट्रैक्शन ([[ बाइट क्रम ]], शब्द आकार, सीपीयू निर्देश सेट इत्यादि) के अतिरिक्त, एकाधिक कर्नेल [[एप्लिकेशन बाइनरी इंटरफ़ेस]] और संस्करणों के समर्थन के साथ बायनेरिज़ का लाभ है।
-डेवलपर्स के अनुसार, FatELF के कई उपयोग-मामले हैं:<ref name="Gordon_2009_FatELF"/>* वितरणों को अब विभिन्न प्लेटफार्मों के लिए अलग-अलग डाउनलोड करने की आवश्यकता नहीं है।
+डेवलपर्स के अनुसार, FatELF के अनेक उपयोग-मामले हैं:<ref name="Gordon_2009_FatELF"/>* वितरणों को अब विभिन्न प्लेटफार्मों के लिए भिन्न-भिन्न डाउनलोड करने की आवश्यकता नहीं है।
-* [[फाइलसिस्टम पदानुक्रम मानक]] में अब अलग /lib, /lib32 और /lib64 पेड़ों की आवश्यकता नहीं है।
+* [[फाइलसिस्टम पदानुक्रम मानक]] में अब भिन्न /lib, /lib32 और /lib64 पेड़ों की आवश्यकता नहीं है।
-* सही बाइनरी और लाइब्रेरीज़ को [[ शैल स्क्रिप्ट |शैल स्क्रिप्ट]] के बजाय सिस्टम द्वारा केंद्रीय रूप से चुना जाता है।
+* सही बाइनरी और लाइब्रेरीज़ को [[ शैल स्क्रिप्ट |शैल स्क्रिप्ट]] के अतिरिक्त सिस्टम द्वारा केंद्रीय रूप से चुना जाता है।
-* यदि ईएलएफ एबीआई किसी दिन बदलता है, तो विरासती उपयोगकर्ताओं को अभी भी समर्थन दिया जा सकता है।
+* यदि ईएलएफ एबीआई किसी दिन परिवर्तितता है, तब विरासती उपयोगकर्ताओं को अभी भी समर्थन दिया जा सकता है।
-* वेब ब्राउज़र प्लग इन का वितरण जो कई प्लेटफार्मों के साथ बॉक्स से बाहर काम करता है।
+* वेब ब्राउज़र प्लग इन का वितरण जो अनेक प्लेटफार्मों के साथ बॉक्स से बाहर काम करता है।
 * एक एप्लिकेशन फ़ाइल का वितरण जो लिनक्स और बर्कले सॉफ़्टवेयर वितरण वेरिएंट पर काम करता है, उन पर प्लेटफ़ॉर्म संगतता परत के बिना।
 * विकास और प्रयोग के लिए हार्ड ड्राइव विभाजन को विभिन्न सीपीयू आर्किटेक्चर वाली विभिन्न मशीनों पर बूट किया जा सकता है। समान रूट फ़ाइल सिस्टम, भिन्न कर्नेल और सीपीयू आर्किटेक्चर।
-* नेटवर्क शेयर या यूएसबी स्टिक द्वारा प्रदान किए गए एप्लिकेशन, कई सिस्टम पर काम करेंगे। यह [[पोर्टेबल अनुप्रयोग]] और विषम प्रणालियों के लिए [[ क्लाउड कम्प्यूटिंग |क्लाउड कम्प्यूटिंग]] छवियां बनाने में भी सहायक है।<ref name="Windisch_2009"/>
+* नेटवर्क शेयर या यूएसबी स्टिक द्वारा प्रदान किए गए एप्लिकेशन, अनेक सिस्टम पर काम करेंगे। यह [[पोर्टेबल अनुप्रयोग]] और विषम प्रणालियों के लिए [[ क्लाउड कम्प्यूटिंग |क्लाउड कम्प्यूटिंग]] छवियां बनाने में भी सहायक है।<ref name="Windisch_2009"/>
 एक प्रूफ़-ऑफ़-कॉन्सेप्ट उबंटू (ऑपरेटिंग सिस्टम)|उबंटू 9.04 छवि उपलब्ध है।<ref name="Gordon_2009_VM"/> {{as of|2021}}, FatELF को मेनलाइन लिनक्स कर्नेल में एकीकृत नहीं किया गया है।<ref name="Holwerda_2009"/><ref name="Brockmeier_2010"/>
@@ Line 107: / Line 104: @@
 ===फ़ैटपैक===
-हालाँकि विंडोज़ द्वारा उपयोग किया जाने वाला [[पोर्टेबल निष्पादन योग्य]] प्रारूप प्लेटफ़ॉर्म पर कोड निर्दिष्ट करने की अनुमति नहीं देता है, फिर भी लोडर प्रोग्राम बनाना संभव है जो आर्किटेक्चर के आधार पर डिस्पैच करता है। ऐसा इसलिए है क्योंकि एआरएम पर विंडोज के डेस्कटॉप संस्करणों में 32-बिट x86 इम्यूलेशन के लिए समर्थन है, जो इसे उपयोगी सार्वभौमिक मशीन कोड लक्ष्य बनाता है। फ़ैटपैक लोडर है जो अवधारणा को प्रदर्शित करता है: इसमें 32-बिट x86 प्रोग्राम शामिल है जो अपने संसाधन अनुभागों में पैक किए गए निष्पादन योग्य को एक-एक करके चलाने का प्रयास करता है।<ref name="Mulder_2018"/>
+चूँकि विंडोज़ द्वारा उपयोग किया जाने वाला [[पोर्टेबल निष्पादन योग्य|पोर्टेबल एक्सेक्यूटेबले]] प्रारूप प्लेटफ़ॉर्म पर कोड निर्दिष्ट करने की अनुमति नहीं देता है, फिर भी लोडर प्रोग्राम बनाना संभव है जो आर्किटेक्चर के आधार पर डिस्पैच करता है। ऐसा इसलिए है क्योंकि एआरएम पर विंडोज के डेस्कटॉप संस्करणों में 32-बिट x86 इम्यूलेशन के लिए समर्थन है, जो इसे उपयोगी सार्वभौमिक मशीन कोड लक्ष्य बनाता है। फ़ैटपैक लोडर है जो अवधारणा को प्रदर्शित करता है: इसमें 32-बिट x86 प्रोग्राम सम्मिलित है जो अपने संसाधन अनुभागों में पैक किए गए एक्सेक्यूटेबले को एक-एक करके चलाने का प्रयास करता है।<ref name="Mulder_2018"/>
 ===आर्म64एक्स===
-Windows 11 ARM64 विकसित करते समय, Microsoft ने Arm64X नामक [[पोर्टेबल निष्पादन योग्य]] प्रारूप का विस्तार करने का नया तरीका पेश किया।<ref name="Microsoft_2022"/>एक Arm64X बाइनरी में वह सभी सामग्री शामिल होती है जो अलग-अलग x64/Arm64EC और Arm64 बायनेरिज़ में होती है, लेकिन डिस्क पर और अधिक कुशल फ़ाइल में विलय हो जाती है। ऐसे बायनेरिज़ के निर्माण में सहायता के लिए विज़ुअल C++ टूलसेट को अपग्रेड किया गया है। और जब Arm64X बायनेरिज़ का निर्माण तकनीकी रूप से कठिन हो, तो डेवलपर्स इसके बजाय Arm64X शुद्ध फ़ॉरवर्डर DLL का निर्माण कर सकते हैं।<ref name="Microsoft_2023"/>
+Windows 11 ARM64 विकसित करते समय, Microsoft ने Arm64X नामक [[पोर्टेबल निष्पादन योग्य|पोर्टेबल एक्सेक्यूटेबले]] प्रारूप का विस्तार करने का नया विधि प्रस्तुत किया।<ref name="Microsoft_2022"/>एक Arm64X बाइनरी में वह सभी सामग्री सम्मिलित होती है जो भिन्न-भिन्न x64/Arm64EC और Arm64 बायनेरिज़ में होती है, किन्तु डिस्क पर और अधिक कुशल फ़ाइल में विलय हो जाती है। ऐसे बायनेरिज़ के निर्माण में सहायता के लिए विज़ुअल C++ टूलसेट को अपग्रेड किया गया है। और जब Arm64X बायनेरिज़ का निर्माण तकनीकी रूप से कठिन हो, तब डेवलपर्स इसके अतिरिक्त Arm64X शुद्ध फ़ॉरवर्डर DLL का निर्माण कर सकते हैं।<ref name="Microsoft_2023"/>
 ==समान अवधारणाएँ==
-निम्नलिखित दृष्टिकोण फैट बायनेरिज़ के समान हैं, जिसमें ही उद्देश्य के मशीन कोड के कई संस्करण ही फ़ाइल में प्रदान किए जाते हैं।
+निम्नलिखित दृष्टिकोण फैट बायनेरिज़ के समान हैं, जिसमें ही उद्देश्य के मशीन कोड के अनेक संस्करण ही फ़ाइल में प्रदान किए जाते हैं।
 ===विषम कंप्यूटिंग===
-के बाद से, [[विषम कंप्यूटिंग]] के लिए कुछ विशेष कंपाइलर कई प्रकार के प्रोसेसर पर [[समानांतर कंप्यूटिंग]] के लिए कोड फाइलें तैयार करते हैं, यानी इंटेल एक्सोची (एक्सोस्केलेटन सीक्वेंसर) डेवलपमेंट सूट से सीएचआई ([[सी (प्रोग्रामिंग भाषा)]] विषम एकीकरण के लिए) कंपाइलर [[मल्टीथ्रेडिंग (सॉफ्टवेयर)]] के लिए [[ओपनएमपी]] [[निर्देश (प्रोग्रामिंग)]] अवधारणा का विस्तार करता है ताकि विभिन्न निर्देश सेट आर्किटेक्चर के लिए कोड अनुभागों वाले वसा बायनेरिज़ का उत्पादन किया जा सके। आईएसए) जिससे [[रनटाइम सिस्टम]] लोडर विषम सिस्टम वातावरण में कई उपलब्ध सीपीयू और [[जीपीयू]] कोर पर समानांतर निष्पादन को गतिशील रूप से शुरू कर सकता है।<ref name="Collins-Chinya-Jiang-Tian-Girkar-Yang-Lueh-Wang_2007"/><ref name="Wang-Collins-Chinya-Jiang-Tian-Girkar-Pearce-Lueh-Yakoushkin-Wang_2007"/>
+के पश्चात् से, [[विषम कंप्यूटिंग]] के लिए कुछ विशेष कंपाइलर अनेक प्रकार के प्रोसेसर पर [[समानांतर कंप्यूटिंग]] के लिए कोड फाइलें तैयार करते हैं, यानी इंटेल एक्सोची (एक्सोस्केलेटन सीक्वेंसर) डेवलपमेंट सूट से सीएचआई ([[सी (प्रोग्रामिंग भाषा)]] विषम एकीकरण के लिए) कंपाइलर [[मल्टीथ्रेडिंग (सॉफ्टवेयर)]] के लिए [[ओपनएमपी]] [[निर्देश (प्रोग्रामिंग)]] अवधारणा का विस्तार करता है ताकि विभिन्न निर्देश सेट आर्किटेक्चर के लिए कोड अनुभागों वाले वसा बायनेरिज़ का उत्पादन किया जा सके। आईएसए) जिससे [[रनटाइम सिस्टम]] लोडर विषम सिस्टम वातावरण में अनेक उपलब्ध सीपीयू और [[जीपीयू]] कोर पर समानांतर निष्पादन को गतिशील रूप से प्रारंभ कर सकता है।<ref name="Collins-Chinya-Jiang-Tian-Girkar-Yang-Lueh-Wang_2007"/><ref name="Wang-Collins-Chinya-Jiang-Tian-Girkar-Pearce-Lueh-Yakoushkin-Wang_2007"/>
-फरवरी 2007 में पेश किया गया, ए[[ NVIDIA | NVIDIA]] का समानांतर कंप्यूटिंग प्लेटफॉर्म [[CUDA]] (कंप्यूट यूनिफाइड डिवाइस आर्किटेक्चर) GPU ([[GPGPU]]) पर सामान्य-उद्देश्य कंप्यूटिंग को सक्षम करने के लिए सॉफ्टवेयर है। इसका [[एलएलवीएम]]-आधारित कंपाइलर [[ एनवीसीसी (संकलक) |एनवीसीसी (संकलक)]] तथाकथित [[समानांतर थ्रेड निष्पादन]] वर्चुअल [[ सभा की भाषा |सभा की भाषा]] (टेक्स्ट के रूप में) युक्त [[निष्पादन योग्य और लिंक करने योग्य प्रारूप]]-आधारित फैट बायनेरिज़ बना सकता है, जिसे सीयूडीए रनटाइम ड्राइवर बाद में कुछ एसएएसएस (स्ट्रीमिंग असेंबलर) में जस्ट-इन-टाइम कंपाइलेशन | जस्ट-इन-टाइम कंपाइल कर सकता है।) वास्तव में मौजूद लक्ष्य GPU के लिए बाइनरी निष्पादन योग्य कोड। निष्पादन योग्य में तथाकथित CUDA बायनेरिज़ (उर्फ क्यूबिन फ़ाइलें) भी शामिल हो सकती हैं जिनमें या अधिक विशिष्ट GPU आर्किटेक्चर के लिए समर्पित निष्पादन योग्य कोड अनुभाग शामिल हैं जिनमें से CUDA रनटाइम लोड-टाइम पर चुन सकता है।<ref name="Nvidia_2004"/><ref name="Harris_2014"/><ref name="CUDA_2014"/><ref name="CUDA_2016"/><ref name="CUDA_2022"/><ref name="Braun-Fröning_2019"/>फैट बायनेरिज़ का भी समर्थन किया जाता है {{ill|GPGPU-Sim|de}}, GPU [[माइक्रोआर्किटेक्चर सिमुलेशन]] 2007 में भी पेश किया गया था।<ref name="Fung-Sham-Yuan-Aamodt_2007"/><ref name="Bakhoda-Yuan-Fung-Wong-Aamodt_2009"/>
+फरवरी 2007 में प्रस्तुत किया गया, ए[[ NVIDIA | NVIDIA]] का समानांतर कंप्यूटिंग प्लेटफॉर्म [[CUDA]] (कंप्यूट यूनिफाइड डिवाइस आर्किटेक्चर) GPU ([[GPGPU]]) पर सामान्य-उद्देश्य कंप्यूटिंग को सक्षम करने के लिए सॉफ्टवेयर है। इसका [[एलएलवीएम]]-आधारित कंपाइलर [[ एनवीसीसी (संकलक) |एनवीसीसी (संकलक)]] तथाकथित [[समानांतर थ्रेड निष्पादन]] वर्चुअल [[ सभा की भाषा |सभा की भाषा]] (टेक्स्ट के रूप में) युक्त [[निष्पादन योग्य और लिंक करने योग्य प्रारूप|एक्सेक्यूटेबले और लिंक करने योग्य प्रारूप]]-आधारित फैट बायनेरिज़ बना सकता है, जिसे सीयूडीए रनटाइम ड्राइवर पश्चात् में कुछ एसएएसएस (स्ट्रीमिंग असेंबलर) में जस्ट-इन-टाइम कंपाइलेशन | जस्ट-इन-टाइम कंपाइल कर सकता है।) वास्तव में उपस्तिथ लक्ष्य GPU के लिए बाइनरी एक्सेक्यूटेबले कोड। एक्सेक्यूटेबले में तथाकथित CUDA बायनेरिज़ (उर्फ क्यूबिन फ़ाइलें) भी सम्मिलित हो सकती हैं जिनमें या अधिक विशिष्ट GPU आर्किटेक्चर के लिए समर्पित एक्सेक्यूटेबले कोड अनुभाग सम्मिलित हैं जिनमें से CUDA रनटाइम लोड-टाइम पर चुन सकता है।<ref name="Nvidia_2004"/><ref name="Harris_2014"/><ref name="CUDA_2014"/><ref name="CUDA_2016"/><ref name="CUDA_2022"/><ref name="Braun-Fröning_2019"/>फैट बायनेरिज़ का भी समर्थन किया जाता है {{ill|GPGPU-Sim|de}}, GPU [[माइक्रोआर्किटेक्चर सिमुलेशन]] 2007 में भी प्रस्तुत किया गया था।<ref name="Fung-Sham-Yuan-Aamodt_2007"/><ref name="Bakhoda-Yuan-Fung-Wong-Aamodt_2009"/>
-मुलतक़सम (कैंची), [[ओपनसीएल]] विषम प्रणाली सिम्युलेटर ढांचा (मूल रूप से केवल एमआईपीएस आर्किटेक्चर या x86 सीपीयू के लिए, लेकिन बाद में उन्नत माइक्रो डिवाइसेस/एटीआई टेक्नोलॉजीज [[ एएमडी सदाबहार |एएमडी सदाबहार]] और [[एएमडी दक्षिणी द्वीप समूह]] के साथ-साथ [[एनवीडिया फर्मी]] और [[एनवीडिया केपलर]] परिवारों जैसे एआरएम आर्किटेक्चर सीपीयू और जीपीयू का भी समर्थन करने के लिए विस्तारित किया गया)<ref name="Multi2Sim_2013"/>ईएलएफ-आधारित वसा बायनेरिज़ का भी समर्थन करता है।<ref name="Ubal-Jang_Mistry_Schaa_Kaeli_2012"/><ref name="Multi2Sim_2013"/>
+मुलतक़सम (कैंची), [[ओपनसीएल]] विषम प्रणाली सिम्युलेटर ढांचा (मूल रूप से केवल एमआईपीएस आर्किटेक्चर या x86 सीपीयू के लिए, किन्तु पश्चात् में उन्नत माइक्रो डिवाइसेस/एटीआई टेक्नोलॉजीज [[ एएमडी सदाबहार |एएमडी सदाबहार]] और [[एएमडी दक्षिणी द्वीप समूह]] के साथ-साथ [[एनवीडिया फर्मी]] और [[एनवीडिया केपलर]] परिवारों जैसे एआरएम आर्किटेक्चर सीपीयू और जीपीयू का भी समर्थन करने के लिए विस्तारित किया गया)<ref name="Multi2Sim_2013"/>ईएलएफ-आधारित वसा बायनेरिज़ का भी समर्थन करता है।<ref name="Ubal-Jang_Mistry_Schaa_Kaeli_2012"/><ref name="Multi2Sim_2013"/>
 ===मोटी वस्तुएं===
-जीएनयू कंपाइलर कलेक्शन (जीसीसी) और एलएलवीएम में फैट बाइनरी फॉर्मेट नहीं है, लेकिन उनके पास [[ लिंक-टाइम अनुकूलन |लिंक-टाइम अनुकूलन]] (एलटीओ) के लिए फैट ऑब्जेक्ट फाइलें हैं। चूंकि एलटीओ में संकलन को लिंक-टाइम तक विलंबित करना शामिल है, इसलिए [[ऑब्जेक्ट फ़ाइल]]ों को [[मध्यवर्ती प्रतिनिधित्व]] (आईआर) को संग्रहीत करना होगा, लेकिन दूसरी ओर मशीन कोड को भी संग्रहीत करने की आवश्यकता हो सकती है (गति या संगतता के लिए)। एलटीओ ऑब्जेक्ट जिसमें आईआर और मशीन कोड दोनों होते हैं उसे फैट ऑब्जेक्ट के रूप में जाना जाता है।<ref name="LTO"/>
+जीएनयू कंपाइलर कलेक्शन (जीसीसी) और एलएलवीएम में फैट बाइनरी फॉर्मेट नहीं है, किन्तु उनके पास [[ लिंक-टाइम अनुकूलन |लिंक-टाइम अनुकूलन]] (एलटीओ) के लिए फैट ऑब्जेक्ट फाइलें हैं। चूंकि एलटीओ में संकलन को लिंक-टाइम तक विलंबित करना सम्मिलित है, इसलिए [[ऑब्जेक्ट फ़ाइल|ऑब्जेक्ट फ़ाइलों]] को [[मध्यवर्ती प्रतिनिधित्व]] (आईआर) को संग्रहीत करना होगा, किन्तु दूसरी ओर मशीन कोड को भी संग्रहीत करने की आवश्यकता हो सकती है (गति या संगतता के लिए)। एलटीओ ऑब्जेक्ट जिसमें आईआर और मशीन कोड दोनों होते हैं उसे फैट ऑब्जेक्ट के रूप में जाना जाता है।<ref name="LTO"/>
 ===[[फ़ंक्शन बहु-संस्करण]]===
-यहां तक कि समान निर्देश सेट आर्किटेक्चर के लिए इच्छित प्रोग्राम या लाइब्रेरी (कंप्यूटिंग) में भी, प्रोग्रामर पुराने सीपीयू के साथ संगतता बनाए रखते हुए कुछ नए निर्देश सेट एक्सटेंशन का उपयोग करना चाह सकता है। इसे फ़ंक्शन मल्टी-वर्जनिंग (एफएमवी) के साथ हासिल किया जा सकता है: ही फ़ंक्शन के संस्करण प्रोग्राम में लिखे जाते हैं, और कोड का टुकड़ा सीपीयू की क्षमताओं का पता लगाकर यह तय करता है कि किसका उपयोग करना है (जैसे कि [[सीपीयूआईडी]] के माध्यम से)। Intel C++ कंपाइलर, GCC और LLVM सभी में स्वचालित रूप से बहु-संस्करण फ़ंक्शन उत्पन्न करने की क्षमता है।<ref name="Wennborg_2018"/>यह बिना किसी अर्थ संबंधी प्रभाव के [[गतिशील प्रेषण]] का रूप है।
+यहां तक कि समान निर्देश सेट आर्किटेक्चर के लिए इच्छित प्रोग्राम या लाइब्रेरी (कंप्यूटिंग) में भी, प्रोग्रामर पूर्व सीपीयू के साथ संगतता बनाए रखते हुए कुछ नए निर्देश सेट एक्सटेंशन का उपयोग करना चाह सकता है। इसे फ़ंक्शन मल्टी-वर्जनिंग (एफएमवी) के साथ प्राप्त किया जा सकता है: ही फ़ंक्शन के संस्करण प्रोग्राम में लिखे जाते हैं, और कोड का टुकड़ा सीपीयू की क्षमताओं का पता लगाकर यह तय करता है कि किसका उपयोग करना है (जैसे कि [[सीपीयूआईडी|सीपीयू आईडी]] के माध्यम से)। इंटेल C++ कंपाइलर, जीसीसी और एलएलवीएम सभी में स्वचालित रूप से बहु-संस्करण फ़ंक्शन उत्पन्न करने की क्षमता है।<ref name="Wennborg_2018"/>यह बिना किसी अर्थ संबंधी प्रभाव के [[गतिशील प्रेषण]] का रूप है।
-कई गणित पुस्तकालयों में हस्तलिखित असेंबली रूटीन की सुविधा होती है जो सीपीयू क्षमता के अनुसार स्वचालित रूप से चुनी जाती हैं। उदाहरणों में [[glibc]], [[Intel MKL]] और [[OpenBLAS]] शामिल हैं। इसके अलावा, glibc में लाइब्रेरी लोडर विशिष्ट CPU सुविधाओं के लिए वैकल्पिक पथों से लोडिंग का समर्थन करता है।<ref name="Bahena_2018"/>
+अनेक गणित लाइब्रेरीों में हस्तलिखित असेंबली रूटीन की सुविधा होती है जो सीपीयू क्षमता के अनुसार स्वचालित रूप से चुनी जाती हैं। उदाहरणों में [[glibc]], [[Intel MKL|इंटेल MKL]] और [[OpenBLAS]] सम्मिलित हैं। इसके अतिरिक्त, glibc में लाइब्रेरी लोडर विशिष्ट सीपीयू सुविधाओं के लिए वैकल्पिक पथों से लोडिंग का समर्थन करता है।<ref name="Bahena_2018"/>
-एक समान, लेकिन बाइट-लेवल ग्रैन्युलर दृष्टिकोण जो मूल रूप से मैथियस आर। पॉल और एक्सल सी। फ्रिंके द्वारा तैयार किया गया है, छोटे से आत्म-विनाश, निर्देश छूट और स्थानांतरित लोडर को निष्पादन योग्य फ़ाइल में एंबेडेड करने के लिए है, जो कि किसी भी तरह के कार्यक्रम के लिए विशेष रूप से प्रकार के प्रकार के प्रकार के प्रकार के लिए (या विशेष रूप से प्रकार के प्रकार के प्रकार के रूप में है। ।<ref name="Paul_1997_FreeKEYB"/><ref name="Paul_2002_DDCE2"/><ref name="Paul_2001_FK"/><ref name="Paul_2001_DDCE"/>
+एक समान, किन्तु बाइट-लेवल ग्रैन्युलर दृष्टिकोण जो मूल रूप से मैथियस आर। पॉल और एक्सल सी। फ्रिंके द्वारा तैयार किया गया है, लघु से आत्म-विनाश, निर्देश छूट और स्थानांतरित लोडर को एक्सेक्यूटेबले फ़ाइल में एंबेडेड करने के लिए है, जो कि किसी भी तरह के कार्यक्रम के लिए विशेष रूप से प्रकार के प्रकार के प्रकार के प्रकार के लिए (या विशेष रूप से प्रकार के प्रकार के प्रकार के रूप में है। ।<ref name="Paul_1997_FreeKEYB"/><ref name="Paul_2002_DDCE2"/><ref name="Paul_2001_FK"/><ref name="Paul_2001_DDCE"/>
@@ Line 141: / Line 138: @@
 * [[डॉस स्टब]]
 * [[मोटा सूचक]]
-* [[रैखिक निष्पादन योग्य]] (LX)
+* [[रैखिक निष्पादन योग्य|रैखिक एक्सेक्यूटेबले]] (LX)
-* [[नया निष्पादन योग्य]] (एनई)
+* [[नया निष्पादन योग्य|नया एक्सेक्यूटेबले]] (एनई)
-* पोर्टेबल निष्पादन योग्य (पीई)
+* पोर्टेबल एक्सेक्यूटेबले (पीई)
 * [[स्थिति-स्वतंत्र कोड]] (पीआईसी)
 * [[दुष्प्रभाव (कंप्यूटर विज्ञान)]]
-* [[यूनिवर्सल हेक्स प्रारूप]], कई प्लेटफार्मों को लक्षित करने वाला मोटा हेक्स फ़ाइल प्रारूप
+* [[यूनिवर्सल हेक्स प्रारूप]], अनेक प्लेटफार्मों को लक्षित करने वाला मोटा हेक्स फ़ाइल प्रारूप
-* [[अल्फ़ान्यूमेरिक निष्पादन योग्य]], निष्पादन योग्य कोड (कभी-कभी पढ़ने योग्य भी) पाठ के रूप में छिपा हुआ
+* [[अल्फ़ान्यूमेरिक निष्पादन योग्य|अल्फ़ान्यूमेरिक एक्सेक्यूटेबले]] , एक्सेक्यूटेबले कोड (कभी-कभी पढ़ने योग्य भी) पाठ के रूप में छिपा हुआ
-* [[मल्टी-आर्किटेक्चर शेलकोड]], कई प्लेटफार्मों को लक्षित करने वाला शेलकोड (और कभी-कभी अल्फ़ान्यूमेरिक टेक्स्ट के रूप में भी छिपा हुआ)
+* [[मल्टी-आर्किटेक्चर शेलकोड]], अनेक प्लेटफार्मों को लक्षित करने वाला शेलकोड (और कभी-कभी अल्फ़ान्यूमेरिक टेक्स्ट के रूप में भी छिपा हुआ)
 ==टिप्पणियाँ==

Anonymous

Search

फैट बाइनरी: Difference between revisions

Namespaces

More

Page actions

Revision as of 01:08, 7 August 2023

Contents

अपोलो

अपोलो के यौगिक निष्पादनयोग्य

एप्पल

एप्पल की फैट बाइनरी

नेक्स्ट/एप्पल की मल्टी-आर्किटेक्चर बायनेरिज़

नेक्स्ट स्टेप मल्टी-आर्किटेक्चर बायनेरिज़

मैक-ओ और मैक ओएस एक्स

एप्पल की यूनिवर्सल बाइनरी

एप्पल फैट ईएफआई बाइनरी

सीपी/एम और डॉस

सीपी/एम-80 और डॉस के लिए संयुक्त कॉम -शैली बायनेरिज़

सीपी/एम-86 और डॉस के लिए संयुक्त बायनेरिज़

संयुक्त कॉम और SYS फ़ाइलें

क्रैश-संरक्षित सिस्टम फ़ाइलें

लिनक्स

FatELF: लिनक्स के लिए यूनिवर्सल बायनेरिज़

विंडोज़

फ़ैटपैक

आर्म64एक्स

समान अवधारणाएँ

विषम कंप्यूटिंग

मोटी वस्तुएं

फ़ंक्शन बहु-संस्करण

यह भी देखें

टिप्पणियाँ

संदर्भ

अग्रिम पठन

Navigation

Navigation

Wiki tools

Wiki tools

Anonymous

Search

फैट बाइनरी: Difference between revisions

Revision as of 01:08, 7 August 2023

अपोलो

अपोलो के यौगिक निष्पादनयोग्य

एप्पल

एप्पल की फैट बाइनरी

नेक्स्ट/एप्पल की मल्टी-आर्किटेक्चर बायनेरिज़

नेक्स्ट स्टेप मल्टी-आर्किटेक्चर बायनेरिज़

मैक-ओ और मैक ओएस एक्स

एप्पल की यूनिवर्सल बाइनरी

एप्पल फैट ईएफआई बाइनरी

सीपी/एम और डॉस

सीपी/एम-80 और डॉस के लिए संयुक्त कॉम -शैली बायनेरिज़

सीपी/एम-86 और डॉस के लिए संयुक्त बायनेरिज़

संयुक्त कॉम और SYS फ़ाइलें

क्रैश-संरक्षित सिस्टम फ़ाइलें

लिनक्स

FatELF: लिनक्स के लिए यूनिवर्सल बायनेरिज़

विंडोज़

फ़ैटपैक

आर्म64एक्स

समान अवधारणाएँ

विषम कंप्यूटिंग

मोटी वस्तुएं

फ़ंक्शन बहु-संस्करण

यह भी देखें

टिप्पणियाँ

संदर्भ

अग्रिम पठन

Navigation

Wiki tools

Page tools

Other projects

Categories