फैट बाइनरी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह भी देखें

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