फैट बाइनरी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह भी देखें

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