फैट बाइनरी

From Vigyanwiki
Not to be confused with पोर्टेबल एक्सेक्यूटेबले or पोर्टेबल एप्लिकेशन.

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


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

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

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

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

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


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

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

इंटेल 8080 (और Z80) प्रोसेसर वर्गों के लिए सीपी/एम-80, एमपी/एम-80, समवर्ती सीपी/एम, सीपी/एम प्लस, व्यक्तिगत सीपी/एम-80, एससीपी (ऑपरेटिंग सिस्टम) और एमएसएक्स-डॉस एक्सेक्यूटेबले इंटेल 8086 बायनेरिज़ के लिए डॉस-संगत ऑपरेटिंग सिस्टम के जेन.कॉम फाइल एक्सटेंशन का उपयोग करते हैं। [nb 1] यह दोनों ही स्तिथियों में प्रोग्राम होता हैं | यह ऑफसेट +100एच पर लोड किया गया और फ़ाइल में पहले बाइट पर जाकर निष्पादित किया गया हैं।[14][15] चूंकि दो प्रोसेसर वर्गों के ऑपकोड संगत नहीं हैं, इसलिए गलत ऑपरेटिंग सिस्टम के अनुसार प्रोग्राम प्रारंभ करने का प्रयास गलत और अप्रत्याशित व्यवहार की ओर ले जाता है।

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

सीपी/एम-80 और एमएसएक्स-डीओएस मशीनों के लिए .कॉम प्रोग्रामों को ग़लत रूप से निष्पादित करने से डॉस-संगत ऑपरेटिंग सिस्टम को रखने की दूसरा विधि हैं[15] इसमें 8080 कोड C3h, 03h, 01h को प्रारंभ करना है, जिसे x86 प्रोसेसर द्वारा आरईटी निर्देश के रूप में डिकोड किया जाता है, जिससे प्रोग्राम से यह उत्कृष्ट रूप से बाहर निकल जाता है,[nb 2] जबकि इसे 8080 प्रोसेसर द्वारा जीपी 103h अनुदेश के रूप में डिकोड किया जाएगा और बीयूएस प्रोग्राम में अगले अनुदेश पर पहुंच जाएगा। इसी प्रकार, एसएलआर सिस्टम्स द्वारा सीपी/एम असेंबलर Z80एएसएम+ डॉस पर गलती से चलने पर त्रुटि संदेश प्रदर्शित करता हैं। [17]

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

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

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







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

सीपी/एम-86 और डॉस निष्पादन योग्यों के लिए सामान्य फ़ाइल एक्सटेंशन साझा नहीं करते हैं।[nb 1] इस प्रकार, निष्पादन योग्यों को भ्रमित करना सामान्यतः संभव नहीं है। चूँकि, डीओएस के प्रारंभिक संस्करणों में इसकी वास्तुकला के संदर्भ में सीपी/एम के साथ इतनी समानता थी जिससे कि एक्सेक्यूटेबले कोड वाले बायनेरिज़ को साझा करने के लिए कुछ प्रारंभिक डीओएस प्रोग्राम विकसित किए गए थे। ऐसा करने के लिए ज्ञात प्रोग्राम वर्डस्टार 3.20 और वर्डस्टार 3.2x था, जो सीपी/एम-86 और एमएस-डॉस के लिए अपने पोर्ट में समान ओवरले फ़ाइलों का उपयोग करता था,[27] और रनटाइम (प्रोग्राम) में इन ऑपरेटिंग सिस्टम की भिन्न-भिन्न कॉलिंग कन्वेंशनों को अनुकूलित करने के लिए गतिशील रूप से फिक्स्ड-अप कोड का उपयोग किया जाता है।[27]

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






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

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

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

डॉस के अनुसार, कन्वेंशन के अनुसार, कुछ फाइलों में फ़ाइल एक्सटेंशन होते हैं जो उनके वास्तविक फ़ाइल प्रकार को प्रतिबिंबित नहीं करते हैं।[nb 4] उदाहरण के लिए, कंट्री.एसवाईएस [31] डीओएस डिवाइस ड्राइवर नहीं है,[nb 5] किन्तु कॉन्फ़िग.एसवाईएस कंट्री (कॉन्फ़िग.एसवाईएस निर्देश) और एनएलएसएफयूएनसी (डीओएस कमांड) ड्राइवर के साथ उपयोग के लिए बाइनरी नेशनल लैंग्वेज समर्थन डेटाबेस फ़ाइल हैं।[31] पीसीडीओएस और डीआर-डीओएस सिस्टम फ़ाइलें आईबीएमबीओ.कॉम और आईबीएमडॉस.कॉम बूटस्ट्रैप लोडर द्वारा लोड की गई विशेष बाइनरी छवियां हैं, यह कॉम-शैली प्रोग्राम नहीं हैं। [nb 5] डिवाइस स्टेटमेंट के साथ कंट्री.एसवाईएस को लोड करने का प्रयास करने या कमांड प्रॉम्प्ट पर आईबीएमबीओ.कॉम या आईबीएमडॉस.कॉम को निष्पादित करने के अप्रत्याशित परिणाम होते हैं। [nb 4][nb 6]

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

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

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






लिनक्स

फैटईएलएफ: लिनक्स के लिए यूनिवर्सल बायनेरिज़

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

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

डेवलपर्स के अनुसार फैटईएलएफ के अनेक उपयोगी-स्तिथियां होती हैं [43]

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

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


विंडोज़

फ़ैटपैक

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


एआरएम64एक्स

विंडोज 11 एआरएम64 विकसित करते समय, माइक्रोसॉफ्ट ने एआरएम64एक्स नामक पोर्टेबल एक्सेक्यूटेबले प्रारूप का विस्तार करने की नई विधि को प्रस्तुत किया हैं।[51] एआरएम64एक्स बाइनरी में वह सभी सामग्री सम्मिलित होती है जो भिन्न-भिन्न x64/एआरएम64EC और एआरएम64 बायनेरिज़ में होती है, किन्तु डिस्क पर यह और अधिक कुशल फ़ाइल में विलय हो जाती है। ऐसे बायनेरिज़ के निर्माण में सहायता के लिए विज़ुअल C++ टूलसेट को अपग्रेड किया गया है। और जब एआरएम64X बायनेरिज़ का निर्माण तकनीकी रूप से कठिन हो, तब डेवलपर्स इसके अतिरिक्त एआरएम64एक्स शुद्ध फ़ॉरवर्डर डीएलएल का निर्माण कर सकते हैं।[52]


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

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

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

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

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

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


फैट ऑब्जेक्ट्स

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


फ़ंक्शन मल्टी-वर्जन्स

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

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

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

यह भी देखें

टिप्पणियाँ

  1. ↑ 1.0 1.1 This isn't a problem for CP/M-86 style executables under CP/M-86, CP/M-86 Plus, Personal CP/M-86, S5-DOS, Concurrent CP/M-86, Concurrent DOS, Concurrent DOS 286, FlexOS, Concurrent DOS 386, DOS Plus, Multiuser DOS, System Manager and REAL/32 because they use the file extension .CMD rather than .COM for these files. (The .CMD extension, however, is conflictive with the file extension for batchjobs written for the command line processor CMD.EXE under the OS/2 and Windows NT operating system families.)
  2. ↑ 2.0 2.1 2.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.
  3. ↑ 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.
  4. ↑ 4.0 4.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.
  5. ↑ 5.0 5.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.
  6. ↑ 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.
  7. ↑ 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]


संदर्भ

  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)
  2. ↑ Pero, Nicola (2008-12-18). "gnustep/tools-make: README.Packaging". GitHub. Archived from the original on 2022-05-25. Retrieved 2022-05-26.
  3. ↑ "PackagingDrafts/GNUstep". Fedora Project Wiki. 2009-02-25. Archived from the original on 2022-05-25. Retrieved 2022-05-26.
  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)
  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.
  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.
  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.
  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]
  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.
  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)
  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.
  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.
  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.)
  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]
  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.)
  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.)
  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. […]
  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.)
  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.)
  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. […]
  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.)
  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.)
  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]
  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. […]
  26. ↑ 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. ↑ 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. […]
  28. ↑ Lineback, Nathan. "GSX Screen Shots". Toastytech.com. Archived from the original on 2020-01-15. Retrieved 2020-01-15.
  29. ↑ 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. ↑ 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. ↑ 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. ↑ 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]
  33. ↑ 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]
  34. ↑ 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. ↑ 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. ↑ 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. ↑ 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]
  38. ↑ "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)
  39. ↑ "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)
  40. ↑ "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)
  41. ↑ 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.
  42. ↑ "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. ↑ 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.
  44. ↑ Hogan, Thom (1982). "3. CP/M Transient Commands". Osborne CP/M User Guide - For All CP/M Users (2 ed.). Berkeley, California, USA: A. Osborne/McGraw-Hill. p. 74. ISBN 0-931988-82-9. Retrieved 2020-02-28. […] CP/M marks the end of an ASCII file by placing a CONTROL-z character in the file after the last data character. If the file contains an exact multiple of 128 characters, in which case adding the CONTROL-Z would waste 127 characters, CP/M does not do so. Use of the CONTROL-Z character as the end-of-file marker is possible because CONTROL-z is seldom used as data in ASCII files. In a non-ASCII file, however, CONTROL-Z is just as likely to occur as any other character. Therefore, it cannot be used as the end-of-file marker. CP/M uses a different method to mark the end of a non-ASCII file. CP/M assumes it has reached the end of the file when it has read the last record (basic unit of disk space) allocated to the file. The disk directory entry for each file contains a list of the disk records allocated to that file. This method relies on the size of the file, rather than its content, to locate the end of the file. […] [17][18]
  45. ↑ Gordon, Ryan C. (November 2009). "FatELF specification, version 1". icculus.org. Archived from the original on 2020-08-27. Retrieved 2010-07-25.
  46. ↑ 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.
  47. ↑ 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.)
  48. ↑ 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.
  49. ↑ 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.
  50. ↑ 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.
  51. ↑ "Arm64X PE files". learn.microsoft.com. Microsoft. 2023-03-31 [2022-08-12]. Retrieved 2023-03-31.{{cite web}}: CS1 maint: url-status (link)
  52. ↑ "Build Arm64X binaries". learn.microsoft.com. Microsoft. 2023-03-31 [2023-03-09]. Retrieved 2023-03-31.{{cite web}}: CS1 maint: url-status (link)
  53. ↑ 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)
  54. ↑ 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)
  55. ↑ "cudaFatFormat.h / ptxomp.c". 1.13. Nvidia Corporation. 2004-11-15. Archived from the original on 2022-05-26. Retrieved 2022-05-26.
  56. ↑ 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.
  57. ↑ "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.
  58. ↑ "fatbinary - help". helpmanual.io. 8.0. 2016. Archived from the original on 2022-05-25. Retrieved 2022-05-25.
  59. ↑ "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.
  60. ↑ 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.
  61. ↑ 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)
  62. ↑ 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. [19]
  63. ↑ 63.0 63.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)
  64. ↑ 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)
  65. ↑ "LTO Overview (GNU Compiler Collection (GCC) Internals)". gcc.gnu.org. Archived from the original on 2021-09-12. Retrieved 2021-09-12.
  66. ↑ Wennborg, Hans (2018). "Attributes in Clang". Clang 7 documentation. Archived from the original on 2022-04-07. Retrieved 2022-05-26.
  67. ↑ 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)
  68. ↑ Paul, Matthias R.; Frinke, Axel C. (1997-10-13) [first published 1991], FreeKEYB - Enhanced DOS keyboard and console driver (User Manual) (v6.5 ed.) [20] (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.)
  69. ↑ 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 […]
  70. ↑ 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. […]
  71. ↑ 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). […]


अग्रिम पठन

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=फैट_बाइनरी&oldid=245450’