फैट बाइनरी

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

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

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

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

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

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

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

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

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

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

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

पूर्व से उपस्तिथ प्राचीन पावरपीसी अनुप्रयोगों के फॉरवर्ड माइग्रेशन के लिए यूनिवर्सल बाइनरी प्रारूप आवश्यक नहीं था | 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-बिट ईएफआई बायनेरिज़ दोनों सम्मिलित थे।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह भी देखें

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