Editing Fat binary

{{Short description|Combined executable file for multiple processor types or operating systems}}
{{Distinguish|Portable executable|Portable application}}
{{Use dmy dates|date=April 2019|cs1-dates=y}}
{{Use list-defined references|date=December 2021}}
A '''fat binary''' (or '''multiarchitecture binary''') is a computer [[executable program]] or [[library (computing)|library]] which has been expanded (or "fattened") with code native to multiple [[instruction set]]s which can consequently be run on multiple processor types.<ref name="Devanbu-Fong-Stubblebine_1998"/> This results in a file larger than a normal one-architecture binary file, thus the name.

The usual method of implementation is to include a version of the [[machine code]] for each instruction set, preceded by a single [[entry point]] with code compatible with all operating systems, which executes a jump to the appropriate section. Alternative implementations store different executables in different [[Fork (file system)|forks]], each with its own entry point that is directly used by the operating system.

The use of fat binaries is not common in [[operating system]] software; there are several alternatives to solve the same problem, such as the use of an [[installer]] program to choose an architecture-specific binary at install time (such as with [[Android (operating system)|Android]] multiple [[Android Package|APK]]s), selecting an architecture-specific binary at runtime (such as with [[Plan 9 from Bell Labs|Plan 9]]'s [[union directory (Plan 9)|union directories]] and {{anchor|GNUstep fat bundle}}[[GNUstep]]'s fat bundles),<ref name="Pero_2008"/><ref name="GNUstep_2009"/> distributing software in [[source code]] form and [[compiler|compiling]] it in-place, or the use of a [[virtual machine]] (such as with [[Java Virtual Machine|Java]]) and [[just-in-time compilation]].<!-- Commenting the following statement out: All of these solutions have their downsides however, notably if the user attempts to move such a program to a new machine during an upgrade. Neither a source distribution nor a virtual machine would have a problem moving to a new machine assuming a compiler or virtual machine implementation was available for the new machine. -->

==Apollo==
===Apollo's compound executables===
In 1988, [[Apollo Computer]]'s [[Domain/OS]] SR10.1 introduced a new file type, "cmpexe" (compound executable), that bundled binaries for [[Motorola 68000 series|Motorola 680x0]] and [[Apollo PRISM]] executables.<ref name="Apollo_1988"/>

==Apple==
===Apple's fat binary===
A fat-binary scheme smoothed the [[Apple Macintosh]]'s transition, beginning in 1994, from [[68k]] microprocessors to [[PowerPC]] microprocessors. Many applications for the old platform ran transparently on the new platform under an evolving [[emulator|emulation scheme]], but emulated code generally runs slower than native code. Applications released as "fat binaries" took up more storage space, but they ran at full speed on either platform. This was achieved by packaging both a [[Motorola 68k|68000]]-compiled version and a PowerPC-compiled version of the same program into their executable files.<ref name="Engst_1994_1"/><ref name="Engst_1994_2"/> The older 68K code (CFM-68K or classic 68K) continued to be stored in the [[resource fork]], while the newer PowerPC code was contained in the [[data fork]], in [[Preferred Executable Format|PEF]] format.<ref name="Apple_1996_ResourceManager"/><ref name="Apple_1997_Fat"/><ref name="Apple_1997_PEF"/>

Fat binaries were larger than programs supporting only the PowerPC or 68k, which led to the creation of a number of utilities that would strip out the unneeded version.<ref name="Engst_1994_1"/><ref name="Engst_1994_2"/> In the era of small [[hard drive]]s, when 80 MB hard drives were a common size, these utilities were sometimes useful, as program code was generally a large percentage of overall drive usage, and stripping the unneeded members of a fat binary would free up a significant amount of space on a hard drive.

===NeXT's/Apple's multi-architecture binaries===
====NeXTSTEP Multi-Architecture Binaries====
Fat binaries were a feature of [[NeXT]]'s [[NeXTSTEP]]/[[OPENSTEP]] operating system, starting with NeXTSTEP 3.1. In NeXTSTEP, they were called "Multi-Architecture Binaries". Multi-Architecture Binaries were originally intended to allow software to be compiled to run both on NeXT's Motorola 68k-based hardware and on Intel [[IA-32]]-based [[IBM PC compatible|PC]]s running NeXTSTEP, with a single binary file for both platforms.<ref name="Tevanian-DeMoney-Enderby_Wiebe_Snyder_1995"/> It was later used to allow OPENSTEP applications to run on PCs and the various [[RISC]] platforms OPENSTEP supported. Multi-Architecture Binary files are in a special archive format, in which a single file stores one or more [[Mach-O]] subfiles for each architecture supported by the Multi-Architecture Binary. Every Multi-Architecture Binary starts with a structure ({{code|struct fat_header}}) containing two unsigned integers. The first integer ("magic") is used as a [[File format#Magic number|magic number]] to identify this file as a Fat Binary. The second integer ({{mono|nfat_arch}}) defines how many Mach-O Files the archive contains (how many instances of the same program for different architectures). After this header, there are ''{{mono|nfat_arch}}'' number of fat_arch structures ({{code|struct fat_arch}}). This structure defines the offset (from the start of the file) at which to find the file, the alignment, the size and the CPU type and subtype which the Mach-O binary (within the archive) is targeted at.

The version of the [[GNU Compiler Collection]] shipped with the Developer Tools was able to [[cross-compilation|cross-compile]] source code for the different architectures on which [[NeXTStep]] was able to run. For example, it was possible to choose the target architectures with multiple '-arch' options (with the architecture as argument). This was a convenient way to distribute a program for NeXTStep running on different architectures.

It was also possible to create libraries (e.g. using NeXTStep's {{mono|libtool}}) with different targeted object files.

====Mach-O and Mac OS X====
Apple Computer acquired NeXT in 1996 and continued to work with the OPENSTEP code. Mach-O became the native object file format in Apple's free [[Darwin (operating system)|Darwin operating system]] (2000) and Apple's [[Mac OS X]] (2001), and NeXT's Multi-Architecture Binaries continued to be supported by the operating system. Under Mac OS X, Multi-Architecture Binaries can be used to support multiple variants of an architecture, for instance to have different versions of [[32-bit]] code optimized for the [[PowerPC G3]], [[PowerPC G4]], and [[PowerPC 970]] generations of processors. It can also be used to support multiple architectures, such as 32-bit and [[64-bit]] PowerPC, or PowerPC and [[x86]], or [[x86-64]] and [[AArch64|ARM64]].<ref name="Universal Binary"/>

===={{anchor|Thin binary}}Apple's Universal binary====
{{Main|Universal binary}}
[[File:Apple-Universal-binary-logo.png|thumb|Apple ''Universal binary'' logo]]
In 2005, Apple announced another [[Mac transition to Intel processors|transition, from PowerPC processors to Intel x86 processors]]. Apple promoted the distribution of new applications that support both PowerPC and x86 natively by using executable files in Multi-Architecture Binary format.<ref name="Singh_2006"/> Apple calls such programs "[[Universal application]]s" and calls the file format "[[Universal binary]]" as perhaps a way to distinguish this new transition from the previous transition, or other uses of Multi-Architecture Binary format.

Universal binary format was not necessary for forward migration of pre-existing native PowerPC applications; from 2006 to 2011, Apple supplied [[Rosetta (software)|Rosetta]], a PowerPC (PPC)-to-x86 [[dynamic binary translation|dynamic binary translator]], to play this role. However, Rosetta had a fairly steep performance overhead, so developers were encouraged to offer both PPC and Intel binaries, using Universal binaries. The obvious cost of Universal binary is that every installed executable file is larger, but in the years since the release of the PPC, hard-drive space has greatly outstripped executable size; while a Universal binary might be double the size of a single-platform version of the same application, free-space resources generally dwarf the code size, which becomes a minor issue. In fact, often a Universal-binary application will be smaller than two single-architecture applications because program resources can be shared rather than duplicated. If not all of the architectures are required, the {{mono|lipo}} and {{mono|ditto}} command-line applications can be used to remove versions from the Multi-Architecture Binary image, thereby creating what is sometimes called a ''thin binary''.

In addition, Multi-Architecture Binary executables can contain code for both 32-bit and 64-bit versions of PowerPC and x86, allowing applications to be shipped in a form that supports 32-bit processors but that makes use of the larger address space and wider data paths when run on 64-bit processors.

In versions of the [[Xcode]] development environment from 2.1 through 3.2 (running on [[Mac OS X 10.4]] through [[Mac OS X 10.6]]), Apple included utilities which allowed applications to be targeted for both Intel and PowerPC architecture; universal binaries could eventually contain up to four versions of the executable code (32-bit PowerPC, 32-bit x86, 64-bit PowerPC, and [[X86-64|64-bit x86]]). However, PowerPC support was removed from Xcode 4.0 and is therefore not available to developers running [[Mac OS X 10.7]] or greater.

In 2020, Apple announced another [[Mac transition to Apple silicon|transition]], this time from Intel x86 processors to [[Apple silicon]] (ARM64 architecture). To smooth the transition Apple added support for the [[Universal 2 binary]] format; Universal 2 binary files are Multi-Architecture Binary files containing both x86-64 and ARM64 executable code, allowing the binary to run natively on both 64-bit Intel and 64-bit Apple silicon. Additionally, Apple introduced [[Rosetta 2]] dynamic binary translation for x86 to Arm64 instruction set to allow users to run applications that do not have Universal binary variants.

==== {{Anchor|Fat EFI binary}}Apple Fat EFI binary ====
In 2006, Apple switched from [[PowerPC]] to [[Intel]] CPUs, and replaced [[Open Firmware]] with [[Extensible Firmware Interface|EFI]]. However, by 2008, some of their Macs used 32-bit EFI and some used 64-bit EFI. For this reason, Apple extended the EFI specification with "fat" binaries that contained both 32-bit and 64-bit EFI binaries.<ref>{{Cite web |title=rEFIt - EFI Fat Binaries |url=https://refit.sourceforge.net/info/fat_binary.html |access-date=2022-10-18 |website=refit.sourceforge.net}}</ref>

==CP/M and DOS==
===Combined COM-style binaries for CP/M-80 and DOS===
[[CP/M-80]], [[MP/M-80]], [[Concurrent CP/M]], [[CP/M Plus]], [[Personal CP/M-80]], [[SCP (operating system)|SCP]] and [[MSX-DOS]] executables for the [[Intel 8080]] (and [[Zilog]] [[Z80]]) processor families use the same [[.COM]] [[file extension]] as [[DOS]]-compatible operating systems for [[Intel 8086]] binaries.<ref group="nb" name="NB_CP/M-86"/> In both cases programs are loaded at offset +100h and executed by jumping to the first byte in the file.<ref name="Paul_2002_COM"/><ref name="Wilkinson_2005"/> As the [[opcode]]s of the two processor families are not compatible, attempting to start a program under the wrong operating system leads to incorrect and unpredictable behaviour.

In order to avoid this, some methods have been devised to build fat binaries which contain both a CP/M-80 and a DOS program, preceded by initial code which is interpreted correctly on both platforms.<ref name="Wilkinson_2005"/> The methods either combine two fully functional programs each built for their corresponding environment, or add [[code stub|stub]]s which cause the program to [[exit gracefully]] if started on the wrong processor. For this to work, the first few instructions (sometimes also called ''[[#Gadget|gadget header]]s''<ref name="Cha-Pak-Brumley-Lipton_2010"/>) in the .COM file have to be valid code for both 8086 and 8080 processors, which would cause the processors to branch into different locations within the code.<ref name="Cha-Pak-Brumley-Lipton_2010"/>
For example, the utilities in Simeon Cran's emulator MyZ80 start with the opcode sequence {{mono|EBh, 52h, EBh}}.<ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/><ref name="Elliott_2009_PMARC"/> An 8086 sees this as a jump and reads its next instruction from offset +154h whereas an 8080 or compatible processor goes straight through and reads its next instruction from +103h.
A similar sequence used for this purpose is {{mono|EBh, 03h, C3h}}.<ref name="Christ_2012"/><ref name="Brehm_2016"/>
<!-- Using {{mono|EBh, 04h, EBh}} as start code, -->John C. Elliott's FATBIN<ref name="Elliott_1996_FATBIN"/><ref name="Elliott_1998_FATBIN"/><ref name="Elliott_2002_FBMAKE"/> is a utility to combine a CP/M-80 and a DOS .COM file into one executable.<ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/><ref name="Elliott_2005_FATBIN-PMSFX"/> His derivative of the original [[PMsfx]] modifies archives created by Yoshihiko Mino's [[PMarc]] to be [[self-extractable archive|self-extractable]] under ''both'', CP/M-80 and DOS, starting with {{mono|EBh, 18h, 2Dh, 70h, 6Dh, 73h, 2Dh}} to also include the "-pms-" signature for self-extracting [[PMarc|PMA]] archives,<ref name="Elliott_1997_PMSFX2"/><ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/><ref name="Elliott_2005_FATBIN-PMSFX"/><ref name="Elliott_2009_PMARC"/> thereby also representing a form of [[executable ASCII code]].

Another method to keep a DOS-compatible operating system from erroneously executing .COM programs for CP/M-80 and MSX-DOS machines<ref name="Wilkinson_2005"/> is to start the 8080 code with {{mono|C3h, 03h, 01h}}, which is decoded as a "RET" instruction by x86 processors, thereby gracefully exiting the program,<ref group="nb" name="NB_RET"/> while it will be decoded as "JP 103h" instruction by 8080 processors and simply jump to the next instruction in the program. Similar, the CP/M assembler Z80ASM+ by SLR Systems would display an error message when erroneously run on DOS.<ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/>

Some [[CP/M-80 3.0]] .COM files may have one or more [[RSX (computing)|RSX]] overlays attached to them by [[GENCOM (CP/M command)|GENCOM]].<ref name="Elliott_CPM3_COM"/> If so, they start with an extra [[256 byte boundary|256-byte]] header (one [[page (computing)|page]]). In order to indicate this, the first byte in the header is set to [[magic byte]] {{mono|C9h}}, which works both as a signature identifying this type of COM file to the CP/M 3.0 [[executable loader]], as well as a "RET" instruction for 8080-compatible processors which leads to a graceful exit if the file is executed under older versions of CP/M-80.<ref group="nb" name="NB_RET"/>

{{mono|C9h}} is never appropriate as the first byte of a program for any x86 processor (it has different meanings for different generations,<ref group="nb" name="NB_C9"/> but is never a meaningful first byte); the executable loader in some versions of DOS rejects COM files that start with {{mono|C9h}}, avoiding incorrect operation.

Similar [[opcode overlapping|overlapping]] code sequences have also been devised for combined Z80/[[6502]],<ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/> 8086/[[68000]]<ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999"/> or x86/[[MIPS architecture|MIPS]]/[[ARM architecture|ARM]] binaries.<ref name="Cha-Pak-Brumley-Lipton_2010"/>

===Combined binaries for CP/M-86 and DOS===
[[CP/M-86]] and DOS do not share a common file extension for executables.<ref group="nb" name="NB_CP/M-86"/> Thus, it is not normally possible to confuse executables. However, early versions of DOS had so much in common with CP/M in terms of its architecture that some early DOS programs were developed to share binaries containing executable code. One program known to do this was [[WordStar 3.20|WordStar&nbsp;3.2x]]<!-- at least 3.20, 3.21 and 3.24 (February 1983) -->, which used identical [[overlay file]]s in their [[software port|port]]s for CP/M-86 and [[MS-DOS]],<ref name="Necasek_2018_WordStar"/> and used dynamically fixed-up code to adapt to the differing calling conventions of these operating systems at [[runtime (program lifecycle phase)|runtime]].<ref name="Necasek_2018_WordStar"/>

[[Digital Research]]'s [[Graphics System Extension|GSX]] for CP/M-86 and DOS also shares binary identical 16-bit drivers.<ref name="Lineback_GSX"/>

===Combined COM and SYS files===
DOS [[device driver]]s (typically with file extension [[.SYS]]) start with a file header whose first four bytes are [[hexadecimal|FFFFFFFFh]] by convention, although this is not a requirement.<ref name="Paul_2002_COMSYS"/> This is fixed up dynamically by the operating system when the driver [[loader (computing)|loads]] (typically in the [[DOS BIOS]] when it executes [[DEVICE (CONFIG.SYS directive)|DEVICE]] statements in [[CONFIG.SYS]]). Since DOS does not reject files with a .COM extension to be loaded per DEVICE and does not test for FFFFFFFFh, it is possible to combine a COM program and a device driver into the same file<ref name="Paul_2002_CTMOUSE"/><ref name="Paul_2002_COMSYS"/> by placing a jump instruction to the entry point of the embedded COM program within the first four bytes of the file (three bytes are usually sufficient).<ref name="Paul_2002_COMSYS"/> If the embedded program and the device driver sections share a common portion of code, or data, it is necessary for the code to deal with being loaded at offset +0100h as a .COM style program, and at +0000h as a device driver.<ref name="Paul_2002_CTMOUSE"/> For shared code loaded at the "wrong" offset but not designed to be [[position-independent]], this requires an internal address fix-up<ref name="Paul_2002_CTMOUSE"/> similar to what would otherwise already have been carried out by a [[relocating loader]], except for that in this case it has to be done by the loaded program itself; this is similar to the situation with [[self-relocating driver]]s but with the program already loaded at the target location by the operating system's loader.

===Crash-protected system files===
Under DOS, some files, by convention, have file extensions which do not reflect their actual file type.<ref group="nb" name="NB_NAMES"/> For example, [[COUNTRY.SYS]]<ref name="Paul_2001_COUNTRY"/> is not a DOS device driver,<ref group="nb" name="NB_KEYBOARD.SYS"/> but a binary [[National Language Support|NLS]] database file for use with the CONFIG.SYS [[COUNTRY (CONFIG.SYS directive)|COUNTRY directive]] and the [[NLSFUNC (DOS command)|NLSFUNC]] driver.<ref name="Paul_2001_COUNTRY"/> Likewise, the [[PC&nbsp;DOS]] and [[DR-DOS]] system files [[IBMBIO.COM]] and [[IBMDOS.COM]] are special binary images loaded by [[bootstrap loader]]s, not COM-style programs.<ref group="nb" name="NB_KEYBOARD.SYS"/> Trying to load COUNTRY.SYS with a DEVICE statement or executing IBMBIO.COM or IBMDOS.COM at the command prompt will cause unpredictable results.<ref group="nb" name="NB_NAMES"/><ref group="nb" name="NB_HIDDEN"/>

It is sometimes possible to avoid this by utilizing techniques similar to those described above. For example, [[DR-DOS&nbsp;7.02]] and higher incorporate a safety feature developed by Matthias R. Paul:<ref name="Paul_1997_NWDOSTIP"/> If these files are called inappropriately, tiny embedded stubs will just display some file version information and exit gracefully.<ref name="Paul_1997_OD-A3"/><ref name="Paul_1997_NWDOSTIP"/><ref name="Caldera_1998_NEW703"/><ref name="Paul_2001_COUNTRY"/> Additionally, the message is specifically crafted to follow certain [[magic number (programming)|"magic" pattern]]s recognized by the external [[NetWare]] & DR-DOS [[VERSION.EXE|VERSION]] file identification utility.<ref name="Paul_2001_COUNTRY"/><ref name="Paul_1997_NWDOSTIP"/><ref group="nb" name="NB_COUNTRY.SYS"/>

A similar protection feature was the 8080 instruction {{mono|C7h}} ("RST&nbsp;0") at the very start of Jay Sage's and Joe Wright's [[Z-System]] type-3 and type-4 "Z3ENV" programs<!-- introduced in 1988 --><ref name="Sage_1988_ZSystem"/><ref name="Sage_1992_ZSystem_1"/> as well as "Z3TXT" language overlay files,<ref name="Sage_1992_ZSystem_2"/> which would result in a [[warm boot]] (instead of a crash) under CP/M-80 if loaded inappropriately.<ref name="Sage_1988_ZSystem"/><ref name="Sage_1992_ZSystem_1"/><ref name="Sage_1992_ZSystem_2"/><ref group="nb" name="NB_RET"/>

In a distantly similar fashion, many (binary) [[list of file signatures|file format]]s by convention include a {{mono|1Ah}} byte ([[ASCII]] [[^Z]]) near the beginning of the file. This [[control character]] will be interpreted as "soft" [[end-of-file]] (EOF) marker when a file is opened in non-binary mode, and thus, under many operating systems (including the [[PDP-6]] monitor<ref name="DEC_1965_PDP-6"/> and [[RT-11]], [[OpenVMS|VMS]], [[TOPS-10]],<ref name="DEC_1969_PDP-10"/> CP/M,<ref name="DRI_1979_CPM20-IG"/><ref name="Hogan_1982_CP/M"/> DOS,<ref name="CHF_2010_DOS-1A"/> and Windows<ref name="Superuser_2011_TXT"/>), it prevents "binary garbage" from being displayed when a file is accidentally printed at the console.

==Linux==
===FatELF: Universal binaries for Linux===
[[File:FatELF-logo.png|thumb|''FatELF'' logo]]
[[FatELF]]<ref name="Gordon_2009_FatELF"/> was a fat binary implementation for [[Linux]] and other [[Unix-like]] operating systems. Technically, a FatELF binary was a concatenation of [[Executable and Linking Format|ELF]] binaries with some meta data indicating which binary to use on what architecture.<ref name="Gordon_2009_Spec"/> Additionally to the CPU architecture abstraction ([[byte order]], [[word size]], [[CPU]] instruction set, etc.), there is the advantage of binaries with support for multiple kernel [[Application binary interface|ABI]]s and versions.

FatELF has several use-cases, according to developers:<ref name="Gordon_2009_FatELF"/>
* Distributions no longer need to have separate downloads for various platforms.
* Separated ''/lib'', ''/lib32'' and ''/lib64'' trees are not required anymore in [[Filesystem Hierarchy Standard|OS directory structure]].
* The correct binary and libraries are centrally chosen by the system instead of [[shell script]]s.
* If the ELF ABI changes someday, legacy users can be still supported.
* Distribution of web browser plug ins that work out of the box with multiple platforms.
* Distribution of one application file that works across Linux and [[Berkeley Software Distribution|BSD OS]] variants, without a platform compatibility layer on them.
* One hard drive partition can be booted on different machines with different CPU architectures, for development and experimentation. Same root file system, different kernel and CPU architecture.
* Applications provided by network share or USB sticks, will work on multiple systems. This is also helpful for creating [[portable application]]s and also [[cloud computing]] images for heterogeneous systems.<ref name="Windisch_2009"/>

A proof-of-concept [[Ubuntu (operating system)|Ubuntu 9.04]] image is available.<ref name="Gordon_2009_VM"/> {{as of|2021}}, FatELF has not been integrated into the mainline Linux kernel.{{citation needed|date=April 2020}}<ref name="Holwerda_2009"/><ref name="Brockmeier_2010"/>

==Windows==
===Fatpack===
Although the [[Portable Executable]] format used by Windows does not allow assigning code to platforms, it is still possible to make a loader program that dispatches based on architecture. This is because desktop versions of Windows on ARM have support for 32-bit [[x86]] emulation, making it a useful "universal" machine code target. Fatpack is a loader that demonstrates the concept: it includes a 32-bit x86 program that tries to run the executables packed into its resource sections one by one.<ref name="Mulder_2018"/>

===Arm64X===
When developing Windows 11 ARM64, Microsoft introduced a new way to extend the [[Portable Executable]] format called Arm64X.<ref name="Microsoft_2022"/> An Arm64X binary contains all the content that would be in separate x64/Arm64EC and Arm64 binaries, but merged into one more efficient file on disk. Visual C++ toolset has been upgraded to support producing such binaries. And when building Arm64X binaries are technically difficult, developers can build Arm64X pure forwarder DLLs instead.<ref name="Microsoft_2023"/>

==Similar concepts==
The following approaches are similar to fat binaries in that multiple versions of machine code of the same purpose are provided in the same file.

=== Heterogeneous computing===
{{anchor|EXOCHI}}Since 2007, some specialized compilers for [[heterogeneous computing|heterogeneous platform]]s produce code files for [[parallel computing|parallel execution]] on multiple types of processors, i.e. the CHI ([[C (programming language)|C]] for Heterogeneous Integration) compiler from the [[Intel]] EXOCHI (Exoskeleton Sequencer) development suite extends the [[OpenMP]] [[directive (programming)|pragma]] concept for [[multithreading (software)|multithreading]] to produce fat binaries containing code sections for different [[instruction set architecture]]s (ISAs) from which the [[runtime system|runtime]] loader can dynamically initiate the parallel execution on multiple available CPU and [[GPU]] cores in a heterogeneous system environment.<ref name="Collins-Chinya-Jiang-Tian-Girkar-Yang-Lueh-Wang_2007"/><ref name="Wang-Collins-Chinya-Jiang-Tian-Girkar-Pearce-Lueh-Yakoushkin-Wang_2007"/>

{{anchor|cubin|SASS|GPGPU-Sim}}Introduced in 2006, [[Nvidia]]'s parallel computing platform [[CUDA]] (Compute Unified Device Architecture) is a software to enable general-purpose computing on GPUs ([[GPGPU]]). Its [[LLVM]]-based compiler [[NVCC (compiler)|NVCC]] can create [[Executable and Linkable Format|ELF]]-based fat binaries containing so called [[Parallel Thread Execution|PTX]] virtual [[assembly language|assembly]] (as text) which the CUDA runtime driver can later [[just-in-time compilation|just-in-time compile]] into some SASS (Streaming Assembler<!-- sometimes incorrectly given as: Shader Assembly -->) binary executable code for the actually present target GPU. The executables can also include so called ''CUDA binaries'' (aka ''cubin'' files) containing dedicated executable code sections for one or more specific GPU architectures from which the CUDA runtime can choose from at load-time.<ref name="Nvidia_2004"/><ref name="Harris_2014"/><ref name="CUDA_2014"/><ref name="CUDA_2016"/><ref name="CUDA_2022"/><ref name="Braun-Fröning_2019"/> Fat binaries are also supported by {{ill|GPGPU-Sim|de}}, a GPU [[microarchitecture simulation|simulator]] introduced in 2007 as well.<ref name="Fung-Sham-Yuan-Aamodt_2007"/><ref name="Bakhoda-Yuan-Fung-Wong-Aamodt_2009"/>

{{anchor|Multi2Sim}}Multi2Sim (M2S)<!-- v1 (2007) for MIPS, v2 (2008) for x86, v3 (2011) x86+Evergreen, v4 (2012) x86 + MIPS-32 + ARM, Evergreen, v5 -->, an [[OpenCL]] heterogeneous system simulator framework (originally only for either [[MIPS architecture|MIPS]] or x86 CPUs, but later extended to also support [[ARM architecture|ARM]] CPUs and GPUs like the [[Advanced Micro Devices|AMD]]/[[ATI Technologies|ATI]] [[AMD Evergreen|Evergreen]] & [[AMD Southern Islands|Southern Islands]] as well as [[Nvidia Fermi]] & [[Nvidia Kepler|Kepler]] families)<ref name="Multi2Sim_2013"/> supports ELF-based fat binaries as well.<ref name="Ubal-Jang_Mistry_Schaa_Kaeli_2012"/><ref name="Multi2Sim_2013"/>

===Fat objects===
[[GNU Compiler Collection]] (GCC) and LLVM do not have a fat binary format, but they do have fat ''object files'' for [[link-time optimization]] (LTO). Since LTO involves delaying the compilation to link-time, the [[object file]]s must store the [[intermediate representation]] (IR), but on the other hand machine code may need to be stored too (for speed or compatibility). An LTO object containing both IR and machine code is known as a ''fat object''.<ref name="LTO"/>

===Function multi-versioning===
Even in a program or [[library (computing)|library]] intended for the same [[instruction set architecture]], a programmer may wish to make use of some newer instruction set extensions while keeping compatibility with an older CPU. This can be achieved with ''function multi-versioning'' (FMV): versions of the same function are written into the program, and a piece of code decides which one to use by detecting the CPU's capabilities (such as through [[CPUID]]). [[Intel C++ Compiler]], GCC, and LLVM all have the ability to automatically generate multi-versioned functions.<ref name="Wennborg_2018"/> This is a form of [[dynamic dispatch]] without any semantic effects.

Many math libraries feature hand-written assembly routines that are automatically chosen according to CPU capability. Examples include [[glibc]], [[Intel MKL]], and [[OpenBLAS]]. In addition, the library loader in glibc supports loading from alternative paths for specific CPU features.<ref name="Bahena_2018"/>

A similar, but byte-level granular approach originally devised by Matthias R. Paul and Axel C. Frinke is to let a small self-discarding, [[instruction relaxation|relaxing]] and [[relocating loader]] embedded into the executable file alongside any number of alternative binary code snippets conditionally build a size- or speed-optimized runtime image of a program or driver necessary to perform (or not perform) a particular function in a particular target environment at [[load-time]] through a form of [[dynamic dead code elimination]] (DDCE).<ref name="Paul_1997_FreeKEYB"/><ref name="Paul_2002_DDCE2"/><ref name="Paul_2001_FK"/><ref name="Paul_2001_DDCE"/>

==See also==
* [[Cross-platform software]]
* [[DOS stub]]
* [[Fat pointer]]
* [[Linear Executable]] (LX) 
* [[New Executable]] (NE)
* [[Portable Executable]] (PE)
* [[Position-independent code]] (PIC)
* [[Side effect (computer science)|Side effect]]
* [[Universal hex format]], a "fat" hex file format targeting multiple platforms
* [[Alphanumeric executable]], executable code camouflaged as (sometimes even readable) text
* [[Multi-architecture shellcode]], shellcode targeting multiple platforms (and sometimes even camouflaged as alphanumeric text)

==Notes==
{{Reflist|group="nb"|refs=
<ref group="nb" name="NB_CP/M-86">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 (Datapac)|System Manager]] and [[REAL/32]] because they use the [[file extension]] [[CMD file (CP/M)|.CMD]] rather than [[.COM]] for these files. (The .CMD extension, however, is conflictive with the file extension for [[batchjob]]s written for the [[command line processor]] [[CMD.EXE]] under the [[OS/2]] and [[Windows NT]] operating system families.)</ref>
<ref group="nb" name="NB_C9">On [[8088]]/[[8086]] processors, the [[opcode]] {{mono|C9h}} is an undocumented alias for {{mono|CBh}} ("RETF", popping CS:IP from the [[program stack|stack]]<!-- DOS pushes 0 on the stack before starting programs (so that a "RETN" C3h works), so if DOS would have also pushed the PSP segment on the stack this would even have worked on 8088/8086 processors as the processor would then fall into the INT 20h at the start of the PSP. However, it is easier to just discard executables starting with C9h. -->), whereas it decodes as "LEAVE" (set SP to BP and pop BP) on [[80188]]/[[80186]] and newer processors.<!-- http://www.os2museum.com/wp/undocumented-8086-opcodes/ --></ref>
<ref group="nb" name="NB_NAMES">This problem could have been avoided by choosing non-conflicting [[file extension]]s, but, once introduced, these particular file names were retained from very early versions of [[MS-DOS]]/[[PC&nbsp;DOS]]<!-- 1.x/2.x --> for compatibility reasons with (third-party) tools hard-wired to expect these specific file names.</ref>
<ref group="nb" name="NB_HIDDEN">This is the reason why these files have the ''hidden'' [[file attribute|attribute]] set, so that they are not listed by default, thereby reducing the risk of being invoked accidentally.</ref>
<ref group="nb" name="NB_KEYBOARD.SYS">Other [[DOS]] files of this type are [[KEYBOARD.SYS]], a binary [[keyboard layout]] database file for the keyboard driver [[KEYB (DOS command)|KEYB]] under [[MS-DOS]] and [[PC&nbsp;DOS]], [[IO.SYS]] containing the [[DOS BIOS]] under MS-DOS, and [[MSDOS.SYS]], a text configuration file under [[Windows&nbsp;95]]/[[MS-DOS 7.0]] and higher, but originally a binary system file containing the MS-DOS [[kernel (operating system)|kernel]]. However, MS-DOS and PC&nbsp;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.<!-- The only file not protected by this scheme under DR-DOS is the text configuration file [[CONFIG.SYS]]. --></ref>
<ref group="nb" name="NB_RET">This works because a (suitable) [[return instruction]] can be used to [[program exit|exit program]]s under [[CP/M-80]], [[CP/M-86]] and [[DOS]], although the [[opcode]]s, exact conditions and underlying mechanisms differ: Under CP/M-80, programs can terminate (that is, [[warm boot]] into the [[BIOS (CP/M)|BIOS]]) by jumping to 0 in the [[zero page (CP/M)|zero page]], either directly with RST&nbsp;0 ([[8080]]/[[8085]]/[[Z80]] opcode C7h), or by calling [[BDOS (CP/M)|BDOS]] function 0 through the [[CALL 5 (CP/M)|CALL&nbsp;5]] interface. Alternatively, as the [[program stack|stack]] is prepared to hold a 0 [[return address (computing)|return address]] before passing control to a loaded program, they can, for as long as the stack is flat, 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&nbsp;20h]] interrupt as well as [[INT&nbsp;21h]] [[application program interface|API]] sub-functions to terminate programs (which are preferable for more complicated programs), for [[source-to-source translator|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 [[Program Segment Prefix|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&nbsp;20h as well.{{citeref|a|ref=CITEREF-Paul-2002-COM}} In CP/M-86, the zero page is structured differently and there is no CALL&nbsp;5 interface, but the stack return method and BDOS function 0 (but now through [[INT&nbsp;E0h]]) both work as well.</ref>
<ref group="nb" name="NB_COUNTRY.SYS">The <code>COUNTRY.SYS</code> file formats supported by the [[MS-DOS]]/[[PC&nbsp;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" <code>COUNTRY.SYS</code> databases, which could be used under both DOS families.{{citeref|b|ref=CITEREF-Paul-2001-COUNTRY}} However, [[DR-DOS 7.02]] and its [[NLSFUNC (DOS command)|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.{{citeref|c|ref=CITEREF-Paul-1997-IBMBIO}}{{citeref|d|ref=CITEREF-Caldera-1998-DRDOS}} The shipped files are nevertheless "fat" for including a tiny executable stub just displaying an embedded message when invoked inappropriately.{{citeref|d|ref=CITEREF-Caldera-1998-DRDOS}}{{citeref|b|ref=CITEREF-Paul-2001-COUNTRY}}</ref>
}}

==References==
{{Reflist|refs=
<ref name="Devanbu-Fong-Stubblebine_1998">{{cite conference |title=Techniques for Trusted Software Engineering |chapter=3.3 Java and ''TH'' |author-last1=Devanbu |author-first1=Premkumar T. |author-last2=Fong |author-first2=Philip W. L. |author-last3=Stubblebine |author-first3=Stuart G. |date=19–25 April 1998 |journal=Proceedings - International Conference on Software Engineering |location=Kyoto, Japan |doi=10.1109/ICSE.1998.671109 |issn=0270-5257 |isbn=0-8186-8368-6 |conference=Proceedings of the 20th International Conference on Software Engineering |page=131 |conference-url=https://ieeexplore.ieee.org/document/671109/;jsessionid=2A501560B9AB4D3A6FA96FD285E5E825?arnumber=671109 |chapter-url=http://ftp2.uk.postgresql.org/sites/ftp.wiretapped.net/pub/security/info/papers/secure-programming/devanbu-et-al-1998-techniques-for-trusted-software-engineering.pdf |access-date=2021-09-29 |url-status=live |archive-url=https://web.archive.org/web/20140116131407/http://ftp2.uk.postgresql.org/sites/ftp.wiretapped.net/pub/security/info/papers/secure-programming/devanbu-et-al-1998-techniques-for-trusted-software-engineering.pdf |archive-date=2014-01-16<!-- |quote=[…] [[Java (programming language)|Java]] bytecode recompilers […] (which produce "fat", multi-platform binaries that contain binary code in addition to or instead of bytecodes) can also be accommodated. […] -->}} (10 pages)</ref>
<ref name="Tevanian-DeMoney-Enderby_Wiebe_Snyder_1995">{{cite web |title=Method and apparatus for architecture independent executable files |author-first1=Avadis |author-last1=Tevanian |author-first2=Michael |author-last2=DeMoney |author-first3=Kevin |author-last3=Enderby |author-first4=Douglas |author-last4=Wiebe |author-first5=Garth |author-last5=Snyder |publisher=[[NeXT Computer, Inc.]] |publication-place=Redwood City, California, USA |date=1995-07-11 |orig-date=1993-08-20 |id=US patent 5432937A |url=https://patentimages.storage.googleapis.com/8a/87/fc/3991741ae9c814/US5432937.pdf |access-date=2022-05-26 |url-status=live |archive-url=https://web.archive.org/web/20201214153809/https://patentimages.storage.googleapis.com/8a/87/fc/3991741ae9c814/US5432937.pdf |archive-date=2020-12-14}} [https://patents.google.com/patent/US5432937] (9 pages); {{cite web |title=Method and apparatus for architecture independent executable files |author-first1=Avadis |author-last1=Tevanian |author-first2=Michael |author-last2=DeMoney |author-first3=Kevin |author-last3=Enderby |author-first4=Douglas |author-last4=Wiebe |author-first5=Garth |author-last5=Snyder |publisher=[[NeXT Computer, Inc.]] |publication-place=Redwood City, California, USA |date=1997-02-18 |orig-date=1995-02-28 |id=US patent 5604905A |url=https://patentimages.storage.googleapis.com/86/ab/58/b62a0481816568/US5604905.pdf |access-date=2022-05-26 |url-status=live |archive-url=https://web.archive.org/web/20220526193437/https://patentimages.storage.googleapis.com/86/ab/58/b62a0481816568/US5604905.pdf |archive-date=2022-05-26}} (9 pages)</ref>
<ref name="Pero_2008">{{cite web |title=gnustep/tools-make: README.Packaging |website=GitHub |date=2008-12-18 |author-first=Nicola |author-last=Pero |url=https://github.com/gnustep/tools-make/blob/master/README.Packaging#L145 |access-date=2022-05-26 |url-status=live |archive-url=https://web.archive.org/web/20220525074924/https://github.com/gnustep/tools-make/blob/master/README.Packaging#L145 |archive-date=2022-05-25}}</ref>
<ref name="GNUstep_2009">{{cite web |title=PackagingDrafts/GNUstep |website=Fedora Project Wiki |date=2009-02-25 |url=https://fedoraproject.org/wiki/PackagingDrafts/GNUstep#.22Fat.22_unflattened_layout |access-date=2022-05-26 |url-status=live |archive-url=https://web.archive.org/web/20220525075225/https://fedoraproject.org/wiki/PackagingDrafts/GNUstep#.22Fat.22_unflattened_layout |archive-date=2022-05-25}}</ref>
<ref name="Engst_1994_1">{{cite news |title=Should Fat Binaries Diet? |author-first=Adam C. |author-last=Engst |author-link=Adam C. Engst |date=1994-08-22 |newspaper=[[TidBITS]] |issn=1090-7017 |publisher=[[TidBITS Publishing Inc.]] |number=240 |url=https://tidbits.com/1994/08/22/should-fat-binaries-diet/ |access-date=2021-09-29 |url-status=live |archive-url=https://web.archive.org/web/20210929080651/https://tidbits.com/1994/08/22/should-fat-binaries-diet/ |archive-date=2021-09-29}}</ref>
<ref name="Engst_1994_2">{{cite news |title=Fat Binary Comments |author-first=Adam C. |author-last=Engst |author-link=Adam C. Engst |date=1994-08-29 |newspaper=[[TidBITS]] |issn=1090-7017 |publisher=[[TidBITS Publishing Inc.]] |number=241 |url=https://tidbits.com/1994/08/29/fat-binary-comments/ |access-date=2021-09-29 |url-status=live |archive-url=https://web.archive.org/web/20210929080636/https://tidbits.com/1994/08/29/fat-binary-comments/ |archive-date=2021-09-29}}</ref>
<ref name="Apple_1996_ResourceManager">{{cite web |title=Chapter 1 - Resource Manager / Resource Manager Reference - Resource File Format |work=Inside Macintosh: Mac OS Runtime Architectures |publisher=[[Apple Computer]] |date=1996-07-06 |url=http://developer.apple.com/legacy/mac/library/documentation/mac/MoreToolbox/MoreToolbox-99.html |access-date=2021-09-29 |url-status=live |archive-url=https://web.archive.org/web/20210929075231/https://developer.apple.com/library/archive/documentation/mac/MoreToolbox/MoreToolbox-99.html |archive-date=2021-09-29}}</ref>
<ref name="Apple_1997_Fat">{{cite web |title=Chapter 7 - Fat Binary Programs - Creating Fat Binary Programs |date=1997-03-11 |publisher=[[Apple Computer]] |work=Inside Macintosh: Mac OS Runtime Architectures |url=https://developer.apple.com/library/archive/documentation/mac/runtimehtml/RTArch-87.html |access-date=2011-06-20 |url-status=dead |archive-url=https://web.archive.org/web/20210929074105/https://developer.apple.com/library/archive/documentation/mac/runtimehtml/RTArch-87.html |archive-date=2021-09-29}} [https://web.archive.org/web/20040307080236/http://developer.apple.com/documentation/mac/runtimehtml/RTArch-87.html]</ref>
<ref name="Apple_1997_PEF">{{cite web |title=Chapter 8 - PEF Structure |work=Inside Macintosh: Mac OS Runtime Architectures |publisher=[[Apple Computer]] |date=1997-03-11 |url=https://developer.apple.com/library/archive/documentation/mac/runtimehtml/RTArch-89.html |access-date=2021-09-29 |url-status=live |archive-url=https://web.archive.org/web/20210929075218/https://developer.apple.com/library/archive/documentation/mac/runtimehtml/RTArch-89.html |archive-date=2021-09-29}}</ref>
<ref name="Universal Binary">{{cite web |work=Mac OS X ABI Mach-O File Format Reference |title=Universal Binaries and 32-bit/64-bit PowerPC Binaries |date=2009-02-04 |orig-date=2003 |publisher=[[Apple Inc.]] |url=http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html%23//apple_ref/doc/uid/20001298-154889 |url-status=dead |archive-url=https://web.archive.org/web/20120427213052/http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html%23//apple_ref/doc/uid/20001298-154889 |archive-date=2012-04-27}}</ref>
<ref name="Singh_2006">{{cite book |title=Mac OS X Internals - A Systems Approach |chapter=2.6.2 Fat Binaries |author-first=Amit |author-last=Singh |date=2006-06-19 |isbn=978-0-13270226-3 |publisher=[[Pearson Education]] |page=66 |chapter-url=https://books.google.com/books?id=K8vUkpOXhN4C&pg=PA66 |access-date=2021-09-28}}</ref>
<ref name="Elliott_CPM3_COM">{{cite web |title=CP/M 3 COM file header |author-first1=John C. |author-last1=Elliott |author-first2=Jim |author-last2=Lopushinsky |date=2002 |orig-date=1998-04-11 |work=Seasip.info |url=http://www.seasip.info/Cpm/rsxrec.html |access-date=2016-08-29 |url-status=live |archive-url=https://web.archive.org/web/20160830194033/http://www.seasip.info/Cpm/rsxrec.html |archive-date=2016-08-30}}</ref>
<ref name="Paul_2001_COUNTRY">{{cite web |ref=CITEREF-Paul-2001-COUNTRY |title=DOS COUNTRY.SYS file format |type=COUNTRY.LST file |author-first=Matthias R. |author-last=Paul |date=2001-06-10 |edition=1.44 |orig-date=1995 |url=http://www.columbia.edu/~em36/wpdos/MatthiasPaulCPI.zip<!-- not an official distribution archive, but contains an older version of COUNTRY.LST --> |access-date=2016-08-20 |url-status=live |archive-url=https://web.archive.org/web/20160420065252/http://www.columbia.edu/~em36/wpdos/MatthiasPaulCPI.zip |archive-date=2016-04-20}}</ref>
<ref name="Paul_1997_OD-A3">{{cite web |ref=CITEREF-Paul-1997-IBMBIO |author-first=Matthias R. |author-last=Paul |title=Caldera OpenDOS 7.01/7.02 Update Alpha 3 IBMBIO.COM README.TXT |url=http://www.uni-bonn.de/~uzs180/download/ibmbioa3.zip |date=1997-10-02 |access-date=2009-03-29 |url-status=dead |archive-url=https://web.archive.org/web/20031004074600/http://www-student.informatik.uni-bonn.de/~frinke/ibmbioa3.zip |archive-date=2003-10-04}} [https://web.archive.org/web/20181225154705/http://mirror.macintosharchive.org/max1zzz.co.uk/+Windows%20&%20DOS/DOS/System/Novell/Support/Bins/Op702src.zip<!-- Op702src.zip is an unofficial renamed distribution of the ibmbioa3.zip file -->]</ref>
<ref name="Caldera_1998_NEW703">{{cite book |ref=CITEREF-Caldera-1998-DRDOS |title=DR-DOS 7.03 WHATSNEW.TXT - Changes from DR-DOS 7.02 to DR-DOS 7.03 |publisher=[[Caldera, Inc.]] |date=1998-12-24 |url=http://www.lookas.net/ftp/incoming/darbui/Justas/DRDOS/WHATSNEW.TXT |access-date=2019-04-08 |url-status=dead |archive-url=https://web.archive.org/web/20190408142232/http://www.lookas.net/ftp/incoming/darbui/Justas/DRDOS/WHATSNEW.TXT |archive-date=2019-04-08}}</ref>
<ref name="Gordon_2009_FatELF">{{cite web |title=FatELF: Universal Binaries for Linux. |author-first=Ryan C. |author-last=Gordon |author-link=Ryan C. Gordon |date=October 2009 |website=icculus.org |url=http://icculus.org/fatelf/ |access-date=2010-07-13 |url-status=live |archive-url=https://web.archive.org/web/20200827163203/http://icculus.org/fatelf/ |archive-date=2020-08-27}}</ref>
<ref name="Gordon_2009_Spec">{{cite web |title=FatELF specification, version 1. |author-first=Ryan C. |author-last=Gordon |author-link=Ryan C. Gordon |website=icculus.org |date=November 2009 |url=http://hg.icculus.org/icculus/fatelf/raw-file/tip/docs/fatelf-specification.txt |access-date=2010-07-25 |url-status=live |archive-url=https://web.archive.org/web/20200827163541/http://hg.icculus.org/icculus/fatelf/raw-file/tip/docs/fatelf-specification.txt |archive-date=2020-08-27}}</ref>
<ref name="Windisch_2009">{{cite web |title=Subject: Newsgroups: gmane.linux.kernel, Re: FatELF patches... |author-last=Windisch |author-first=Eric |date=2009-11-03 |publisher=gmane.org |url=http://article.gmane.org/gmane.linux.kernel/908851 |access-date=2010-07-08  |url-status=dead |archive-url=https://web.archive.org/web/20161115002617/http://article.gmane.org/gmane.linux.kernel/908851 |archive-date=2016-11-15}}</ref>
<ref name="Holwerda_2009">{{cite web |title=Ryan Gordon Halts FatELF Project |author-last=Holwerda |author-first=Thom |author-link=Thom Holwerda |publisher=osnews.com |department=Linux |date=2009-11-05 |url=https://www.osnews.com/story/22446/ |access-date=2010-07-05 |url-status=live |archive-url=https://web.archive.org/web/20220526091019/https://www.osnews.com/story/22446/ |archive-date=2022-05-26}}</ref>
<ref name="Gordon_2009_VM">{{cite web |title=FatELF: Universal Binaries for Linux. - The proof-of-concept virtual machine download page. |author-first=Ryan C. |author-last=Gordon |author-link=Ryan C. Gordon |date=2009 |website=icculus.org |url=http://icculus.org/fatelf/vm/ |access-date=2022-05-26 |url-status=live |archive-url=https://web.archive.org/web/20220521072456/http://icculus.org/fatelf/vm/ |archive-date=2022-05-21}} (NB. VM image of Ubuntu 9.04 with Fat Binary support.)</ref>
<ref name="Christ_2012">{{cite web |editor-first=Raymond |editor-last=Chen |editor-link=Raymond Chen (Microsoft) |title=Microsoft Money crashes during import of account transactions or when changing a payee of a downloaded transaction |author=ChristW |work=The New Old Thing |date=2012-11-14 |orig-date=2012-11-13 |url=https://blogs.msdn.microsoft.com/oldnewthing/20121113-00/?p=6103#comment-1020793 |access-date=2018-05-19 |url-status=dead |archive-url=https://web.archive.org/web/20180705152154/https://blogs.msdn.microsoft.com/oldnewthing/20121113-00/?p=6103#comment-1020793 |archive-date=5 July 2018 |quote=[…] 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.)</ref>
<ref name="Brehm_2016">{{cite web |title=CP/M and MS-DOS Fat Binary |author-first=Andrew J. |author-last=Brehm |work=DesertPenguin.org |date=2016 |url=http://www.desertpenguin.org/blog/cpm-and-ms-dos-fat-binary/ |access-date=2018-05-19 |url-status=live |archive-url=https://web.archive.org/web/20180519073248/http://www.desertpenguin.org/blog/cpm-and-ms-dos-fat-binary/ |archive-date=2018-05-19}} (NB. While the article speaks about the [[Z80]], the code sequence also works on the [[8080]] and compatible processors.)</ref>
<ref name="Necasek_2018_WordStar">{{cite web |title=WordStar Again |date=2018-01-30 |orig-date=2018-01-28, 2018-01-26 |author-first=Michal |author-last=Necasek |work=OS/2 Museum |url=http://www.os2museum.com/wp/wordstar-again/comment-page-1/ |access-date=2019-07-28 |url-status=live |archive-url=https://web.archive.org/web/20190728011415/http://www.os2museum.com/wp/wordstar-again/comment-page-1/ |archive-date=2019-07-28 |quote=[…] The reason to suspect such difference is that version 3.2x also supported [[CP/M-86]] (the [[overlay (programming)|overlay]]s 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. […]}}</ref>
<ref name="Paul_1997_NWDOSTIP">{{cite book |title=NWDOS-TIPs &mdash; Tips & Tricks rund um Novell DOS 7, mit Blick auf undokumentierte Details, Bugs und Workarounds |series=MPDOSTIP |author-first=Matthias R. |author-last=Paul |date=1997-07-30 |orig-date=1994-05-01 |edition=3 |language=de |chapter=Chapter II.4. Undokumentierte Eigenschaften externer Kommandos - SYS.COM |url=http://www.antonis.de/dos/dos-tuts/mpdostip/html/nwdostip.htm |access-date=2014-08-06 |url-status=live |archive-url=https://web.archive.org/web/20170910194752/http://www.antonis.de/dos/dos-tuts/mpdostip/html/nwdostip.htm |archive-date=2017-09-10 |quote=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.}} (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 <code>MPDOSTIP.ZIP</code><!-- still named TIPS_MP.ZIP between 1991 and 1996-11 --> 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 <code>NWDOSTIP.TXT</code> file.) [https://web.archive.org/web/20190601152204/https://www.sac.sk/download/text/mpdostip.zip<!-- A yet older version 155 from 1997-05-13 of the 1997-07-15 distribution archive. -->]</ref>
<ref name="Lineback_GSX">{{cite web |author-first=Nathan |author-last=Lineback |url=http://toastytech.com/guis/gsx.html |title=GSX Screen Shots |work=Toastytech.com |access-date=2020-01-15 |url-status=live |archive-url=https://archive.today/20200115071430/http://toastytech.com/guis/gsx.html |archive-date=2020-01-15}}</ref>
<ref name="Paul_2002_CTMOUSE">{{cite web <!-- Citation bot bypass--> |title=Re: [fd-dev] ANNOUNCE: CuteMouse 2.0 alpha 1 |author-first=Matthias R. |author-last=Paul |work=freedos-dev |date=2002-04-06 |url=https://marc.info/?l=freedos-dev&m=101807226917577 |access-date=2020-02-07 |url-status=live |archive-url=https://web.archive.org/web/20200207130948/https://marc.info/?l=freedos-dev&m=101807226917577&w=2 |archive-date=2020-02-07 |quote=[…] Add a SYS device driver header to the driver, so that CTMOUSE could be both in one, a normal [[Terminate-and-stay-resident program|TSR]] and a device driver - similar to our FreeKEYB advanced keyboard driver. […] This is not really needed under [[DR&nbsp;DOS]] because [[INSTALL (CONFIG.SYS directive)|INSTALL]]= is supported since DR&nbsp;DOS 3.41+ and DR&nbsp;DOS preserves the order of [[CONFIG.SYS|&#91;D&#93;CONFIG.SYS]] directives […] but it would […] improve the […] flexibility on [[MS-DOS]]/[[PC&nbsp;DOS]] systems, which […] always execute [[DEVICE (CONFIG.SYS directive)|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 (computing)|environment]], no [[Program Segment Prefix|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-loadhigh]]ing 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 […]}}</ref>
<ref name="Paul_2002_COMSYS">{{cite web |title=Re: [fd-dev] ANNOUNCE: CuteMouse 2.0 alpha 1 |author-first=Matthias R. |author-last=Paul |work=freedos-dev |date=2002-04-11 |url=https://marc.info/?l=freedos-dev&m=101853130816682&w=2 |access-date=2020-02-21 |url-status=live |archive-url=https://web.archive.org/web/20200221130238/https://marc.info/?l=freedos-dev&m=101853130816682&w=2 |archive-date=2020-02-21 |quote=[…] 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&nbsp;DOS, DR-DOS, and most probably any other DOS issue as well. […]}}</ref>
<ref name="Sage_1988_ZSystem">{{cite journal |title=ZCPR 3.4 - Type-4 Programs |series=ZCPR3 Corner |author-first=Jay |author-last=Sage |journal=[[The Computer Journal (US journal)<!-- to be distinguished from the identically named UK journal -->|The Computer Journal]] (TCJ) - Programming, User Support, Applications |issn=0748-9331 |editor-first=Art |editor-last=Carlson |date=May–June 1988 |location=Columbia Falls, Montana, USA |issue=32 |pages=[https://archive.org/details/the-computer-journal-32/page/n10/mode/1up 10]–17 [<nowiki/>[https://archive.org/details/the-computer-journal-32/page/n16/mode/1up 16]] |id=ark:/13960/t1wd4v943 |url=https://archive.org/details/the-computer-journal-32 |access-date=2021-11-29}} [https://archive.org/stream/the-computer-journal-32/tcj_32_May-June_1988_djvu.txt][https://archive.org/download/the-computer-journal-32/tcj_32_May-June_1988_text.pdf]</ref>
<ref name="Sage_1992_ZSystem_1">{{cite journal |title=Type-3 and Type-4 Programs |series=Z-System Corner - Some New Applications of Type-4 Programs |author-first=Jay |author-last=Sage |journal=[[The Computer Journal (US journal)<!-- to be distinguished from the identically named UK journal -->|The Computer Journal]] (TCJ) - Programming, User Support, Applications |issn=0748-9331 |editor-first1=Art |editor-last1=Carlson |editor-first2=Chris |editor-last2=McEwen |date=May–June 1992 |orig-date=March–June 1992 |publisher=Socrates Press |location=S. Plainfield, New Jersey, USA |issue=55 |pages=[https://archive.org/details/the-computer-journal-55/page/n14/mode/1up 13]–19 [14, [https://archive.org/details/the-computer-journal-55/page/n16/mode/1up 16]] |id=ark:/13960/t4dn54d22 |url=https://archive.org/details/the-computer-journal-55 |access-date=2021-11-29}} [https://archive.org/stream/the-computer-journal-55/tcj_55_March-June_1992_djvu.txt][https://archive.org/download/the-computer-journal-55/tcj_55_March-June_1992_text.pdf]</ref>
<ref name="Sage_1992_ZSystem_2">{{cite journal |title=Regular Feature, ZCPR Support, Language Independence, part 2 |series=The Z-System Corner |author-first=Jay |author-last=Sage |journal=[[The Computer Journal (US journal)<!-- to be distinguished from the identically named UK journal -->|The Computer Journal]] (TCJ) - Programming, User Support, Applications |issn=0748-9331 |date=November–December 1992 |publication-place=Lincoln, CA, USA |editor-first1=Art |editor-last1=Carlson |editor-first2=Bill D. |editor-last2=Kibler |issue=58 |pages=7–10 |id=ark:/13960/t70v9g87h |url=https://archive.org/details/the-computer-journal-58 |access-date=2020-02-09 |quote=[…] 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 ([[Z3ENV]]s). 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 […]}} [https://archive.org/stream/the-computer-journal-58/tcj_58_November-December_1992_djvu.txt][https://archive.org/download/the-computer-journal-58/tcj_58_November-December_1992_text.pdf]</ref>
<ref name="CHF_2010_DOS-1A">{{cite web |title=Re: Copy command which merges several files tags the word SUB at the end |author=BC_Programmer |date=2010-01-31 |orig-date=2010-01-30 |work=Computer Hope Forum |url=https://www.computerhope.com/forum/index.php?topic=99159.0 |access-date=2020-02-26 |url-status=live |archive-url=https://web.archive.org/web/20200226141316/https://www.computerhope.com/forum/index.php?topic=99159.0 |archive-date=2020-02-26}}</ref>
<ref name="Superuser_2011_TXT">{{cite web |title=What are the differences between Linux and Windows .txt files (Unicode encoding) |work=Superuser |date=2011-08-03 |orig-date=2011-06-08 |url=https://superuser.com/questions/294219/what-are-the-differences-between-linux-and-windows-txt-files-unicode-encoding |access-date=2020-02-26 |url-status=live |archive-url=https://web.archive.org/web/20200226141750/https://superuser.com/questions/294219/what-are-the-differences-between-linux-and-windows-txt-files-unicode-encoding |archive-date=2020-02-26}}</ref>
<ref name="DRI_1979_CPM20-IG">{{cite book |title=CP/M 2.0 Interface Guide |chapter=2. Operating System Call Conventions |date=1979 |edition=1 |publisher=[[Digital Research]] |location=Pacific Grove, California, USA |page=5 |url=http://bitsavers.org/pdf/digitalResearch/cpm/2.0/CPM_2_0_Interface_Guide_1979.pdf |access-date=2020-02-28 |url-status=live |archive-url=https://web.archive.org/web/20200228175812/http://bitsavers.org/pdf/digitalResearch/cpm/2.0/CPM_2_0_Interface_Guide_1979.pdf |archive-date=2020-02-28 |quote=[…] 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 file]]s) are ignored, however, and the end of file condition returned by CP/M is used to terminate read operations. […]}} (56 pages)</ref>
<ref name="Hogan_1982_CP/M">{{cite book <!-- Citation bot bypass--> |title=Osborne CP/M User Guide - For All CP/M Users |chapter=3. CP/M Transient Commands |author-first=Thom |author-last=Hogan |publisher=[[A. Osborne/McGraw-Hill]] |date=1982 |edition=2 |location=Berkeley, California, USA <!-- |lccn=87-65432??? --> |isbn=0-931988-82-9 |page=74 |url=https://archive.org/details/osborne-cpm-users-guide_2nd-ed/OsborneCpmUsersGuideSecondEdition |access-date=2020-02-28 |quote=[…] [[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. […]}} [https://archive.org/stream/osborne-cpm-users-guide_2nd-ed/OsborneCpmUsersGuideSecondEdition_djvu.txt][https://archive.org/download/osborne-cpm-users-guide_2nd-ed/OsborneCpmUsersGuideSecondEdition.pdf]</ref>
<ref name="Brockmeier_2010">{{cite web |title=SELF: Anatomy of an (alleged) failure |publisher=Linux Weekly News |date=2010-06-23 |author-first=Joe "Zonker" |author-last=Brockmeier |website=LWN.net |url=https://lwn.net/Articles/392862/ |access-date=2011-02-06 |url-status=live |archive-url=https://web.archive.org/web/20220526090113/https://lwn.net/Articles/392862/ |archive-date=2022-05-26}}</ref>
<ref name="Mulder_2018">{{cite web |title=sjmulder/fatpack - Build multi-architecture 'fat' binaries for Windows |author-last=Mulder |author-first=Sijmen J. |website=GitHub |date=2021-03-06 |orig-date=2018-04-25 |url=https://github.com/sjmulder/fatpack |access-date=2022-05-26 |url-status=live |archive-url=https://web.archive.org/web/20220526090826/https://github.com/sjmulder/fatpack/blob/master/README.md |archive-date=2022-05-26}}</ref>
<ref name="Microsoft_2022">{{cite web |title=Arm64X PE files |publisher=[[Microsoft]] |website=learn.microsoft.com |date=2022-08-13 |url=https://learn.microsoft.com/en-us/windows/arm/arm64x-pe |access-date=2023-03-31 |url-status=live |archive-url=https://web.archive.org/web/20230820175815/https://learn.microsoft.com/en-us/windows/arm/arm64x-pe |archive-date=2023-08-20}}</ref>
<ref name="Microsoft_2023">{{cite web |title=Build Arm64X binaries |publisher=[[Microsoft]] |website=learn.microsoft.com |date=2023-03-10 |url=https://learn.microsoft.com/en-us/windows/arm/arm64x-build |access-date=2023-03-31 |url-status=live |archive-url=https://web.archive.org/web/20230820175738/https://learn.microsoft.com/en-us/windows/arm/arm64x-build |archive-date=2023-08-20}}</ref>
<ref name="LTO">{{cite web |title=LTO Overview (GNU Compiler Collection (GCC) Internals) |website=gcc.gnu.org |url=https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html |access-date=2021-09-12 |url-status=live |archive-url=https://web.archive.org/web/20210912142506/https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html |archive-date=2021-09-12}}</ref>
<ref name="Paul_2001_DDCE">{{cite newsgroup |title=[ANN] FreeDOS beta 6 released |author-first=Matthias R. |author-last=Paul |date=2001-04-10 |language=de |newsgroup=de.comp.os.msdos |url=https://groups.google.com/d/msg/de.comp.os.msdos/qCZs8p6MyPQ/Pksl0Pv6qM8J |access-date=2017-07-02 |url-status=live |archive-url=https://archive.today/20170909084250/https://groups.google.com/forum/%23!msg/de.comp.os.msdos/qCZs8p6MyPQ/Pksl0Pv6qM8J |archive-date=2017-09-09 |quote=[…] brandneue[s] Feature, der [[Dynamic dead code elimination|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). […]}}</ref>
<ref name="Paul_2001_FK">{{cite web |title=[fd-dev] Changing codepages in FreeDOS |author-first=Matthias R. |author-last=Paul |date=2001-08-21 |work=freedos-dev |url=https://marc.info/?l=freedos-dev&m=99840256128898&w=2 |access-date=2019-04-20 |url-status=live |archive-url=https://web.archive.org/web/20190419120006/https://marc.info/?l=freedos-dev&m=99840256128898&w=2 |archive-date=2019-04-19 |quote=[…] 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. […]}}</ref>
<ref name="Paul_2002_DDCE2">{{cite web |title=[fd-dev] Ctrl+Alt+Del |author-first=Matthias R. |author-last=Paul |date=2002-04-06 |work=freedos-dev |url=https://marc.info/?l=freedos-dev&m=101807225917568&w=2 |access-date=2019-04-27 |url-status=live |archive-url=https://archive.today/20190427131940/https://marc.info/?l=freedos-dev&m=101807225917568&w=2 |archive-date=2019-04-27 |quote=[…] 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 […]}}</ref>
<ref name="Paul_1997_FreeKEYB">{{citation |title=FreeKEYB - Enhanced DOS keyboard and console driver |edition=v6.5 |author-first1=Matthias R. |author-last1=Paul |author-first2=Axel C. |author-last2=Frinke |type=User Manual |date=1997-10-13 |orig-date=1991}} [https://web.archive.org/web/20190309194320/http://sta.c64.org/dosprg/fk657p1.zip<!-- FreeKEYB 6.57p1 Beta as of 2004-08-17 with outdated and incomplete documentation -->] (NB. FreeKEYB is a [[Unicode]]-based dynamically configurable successor of K3PLUS supporting most [[keyboard layout]]s, [[code page]]s, and [[List of country calling codes|country code]]s. 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, [[instruction relaxation|relaxing]] and [[relocating loader]], the driver implements byte-level granular [[dynamic dead code elimination]] and [[relocation (computing)|relocation]] techniques at [[load-time]] as well as [[self-modifying code]] and reconfigurability at [[runtime (computing)|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.)</ref>
<ref name="Wennborg_2018">{{cite web |title=Attributes in Clang |author-first=Hans |author-last=Wennborg |work=Clang 7 documentation |date=2018 |url=https://releases.llvm.org/7.0.0/tools/clang/docs/AttributeReference.html#target-gnu-target |access-date=2022-05-26 |url-status=live |archive-url=https://web.archive.org/web/20220407203122/https://releases.llvm.org/7.0.0/tools/clang/docs/AttributeReference.html#target-gnu-target |archive-date=2022-04-07}}</ref>
<ref name="Bahena_2018">{{cite web |title=Transparent use of library packages optimized for Intel architecture |department=Power and Performance |date=2018-04-03 |author-first=Victor Rodriguez |author-last=Bahena |work=[[Clear Linux Project]] |publisher=[[Intel Corporation]] |url=https://clearlinux.org/news-blogs/transparent-use-library-packages-optimized-intel-architecture |access-date=2022-05-26 |url-status=live |archive-url=https://web.archive.org/web/20220526084952/https://clearlinux.org/news-blogs/transparent-use-library-packages-optimized-intel-architecture |archive-date=2022-05-26}}</ref>
<ref name="Apollo_1988">{{cite web |title=Domain System Software Release Notes, Software Release 10.1 |id=Order No. 005809-A03 |location=Chelmsford, Massachusetts, USA |date=December 1988 |publisher=[[Apollo Computer Inc.]] |edition=first printing |page=2{{hyphen}}16 |url=http://bitsavers.org/pdf/apollo/release_notes/005809-A03_10.1_Release_Notes_Dec88.pdf |access-date=2022-07-24 |url-status=live |archive-url=https://web.archive.org/web/20230526145521/http://bitsavers.org/pdf/apollo/release_notes/005809-A03_10.1_Release_Notes_Dec88.pdf |archive-date=2023-05-26}} (256 pages)</ref>
<ref name="DEC_1965_PDP-6">{{cite book |title=PDP-6 Multiprogramming System Manual |chapter=Table of IO Device Characteristics - Console or Teletypewriters |id=DEC-6-0-EX-SYS-UM-IP-PRE00 |publisher=[[Digital Equipment Corporation]] (DEC) |publication-place=Maynard, Massachusetts, USA |date=1965 |page=43 |url=http://bitsavers.trailing-edge.com/pdf/dec/pdp6/DEC-6-0-EX-SYS-UM-IP-PRE00_Multiprogramming_System_Manual_1965.pdf |access-date=2014-07-10 |url-status=live |archive-url=https://web.archive.org/web/20140714140253/http://bitsavers.trailing-edge.com/pdf/dec/pdp6/DEC-6-0-EX-SYS-UM-IP-PRE00_Multiprogramming_System_Manual_1965.pdf |archive-date=2014-07-14}} (1+84+10 pages)</ref>
<ref name="DEC_1969_PDP-10">{{cite book |title=PDP-10 Reference Handbook: Communicating with the Monitor - Time-Sharing Monitors |volume=3 |chapter=5.1.1.1. Device Dependent Functions - Data Modes - Full-Duplex Software A(ASCII) and AL(ASCII Line) |publisher=[[Digital Equipment Corporation]] (DEC) |date=1969 |pages=5-3–5-6 [5-5 (431)] |url=http://bitsavers.org/pdf/dec/pdp10/1970_PDP-10_Ref/1970PDP10Ref_Part3.pdf |access-date=2014-07-10 |url-status=live |archive-url=https://web.archive.org/web/20111115083418/http://www.bitsavers.org/pdf/dec/pdp10/1970_PDP-10_Ref/1970PDP10Ref_Part3.pdf |archive-date=2011-11-15}} (207 pages)</ref>
<ref name="Elliott_1998_FATBIN">{{cite web |title=FATBIN v1.01 |author-first=John C. |author-last=Elliott |date=1998-06-28 |orig-date=1997-04-01 |url=http://www.seasip.demon.co.uk/Cpm/software/fatbnsea.com |url-status=dead |archive-url=https://web.archive.org/web/19980628081239/http://www.seasip.demon.co.uk/Cpm/software/fatbnsea.com |archive-date=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.)</ref>
<ref name="Elliott_2002_FBMAKE">{{cite web |title=DSKWRITE v1.00 |author-first=John C. |author-last=Elliott |work=Fossies - the Fresh Open Source Software Archive |date=2002-03-11<!-- or earlier? --> |url=https://fossies.org/linux/libdsk/dskwrite/dskwrite.txt |access-date=2021-12-12 |url-status=live |archive-url=https://web.archive.org/web/20211212211225/https://fossies.org/linux/libdsk/dskwrite/dskwrite.txt |archive-date=2021-12-12 |quote=[…] 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: […]}} [https://web.archive.org/web/20200228141706/https://www.seasip.info/Cpm/software/fatbnsea.com] (NB. Mentions FBMAKE from the FATBNSEA.COM package.)</ref>
<ref name="Elliott_2005_FATBIN-PMSFX">{{cite web |title=Generic CP/M |author-first=John C. |author-last=Elliott |date=2012-06-20 |orig-date=2005-01-05<!-- possibly earlier --> |work=Seasip.info |url=https://www.seasip.info/Cpm/software/fatbnsea.com |access-date=2021-12-12 |url-status=live |archive-url=https://web.archive.org/web/20211117090912/http://www.seasip.info/Cpm/software/gencpm.html |archive-date=2021-11-17 |quote=[…] [[Self-extracting archive]]s are [[.COM file]]s 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 [[ZX Spectrum|Spectrum]] snapshots in the .Z80 or .SNA format to or from [[Multiface 3]] format (Multiface 3 -> [[Z80]] only on a PC). […] PMSFX21X.COM<!-- an older version was named PMSFX21B.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 [[Microsoft Windows|Windows]] .BMP […]}} [https://web.archive.org/web/20210822122304/http://cd.textfiles.com/230/EMULATOR/DIVERSE/CPM/DOSTOOLS/PMAUTOAE/]</ref>
<ref name="Elliott_1996_FATBIN">{{cite newsgroup |title=Upload to micros.hensa.ac.uk |author-first=John C. |author-last=Elliott |date=1996-06-13 |newsgroup=comp.os.cpm |url=https://groups.google.com/g/comp.os.cpm/c/RNMu9TVfJ98/m/QZEasTIH3R4J |access-date=2021-12-13 |url-status=live |archive-url=https://web.archive.org/web/20211213021316/https://groups.google.com/g/comp.os.cpm/c/RNMu9TVfJ98/m/QZEasTIH3R4J |archive-date=2021-12-13 |quote=[…] 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. […]}}</ref>
<ref name="Elliott_1997_PMSFX2">{{cite newsgroup |title=PMSFX 2 |author-first=John C. |author-last=Elliott |date=1997-01-18 |orig-date=1997-01-11 |newsgroup=comp.os.cpm |url=https://groups.google.com/g/comp.os.cpm/c/tmvc1Wzz28A/m/s6GzKZKqSk0J |access-date=2021-12-13 |url-status=live |archive-url=https://web.archive.org/web/20211213022339/https://groups.google.com/g/comp.os.cpm/c/tmvc1Wzz28A/m/s6GzKZKqSk0J |archive-date=2021-12-13 |quote=[…] I've written a version of [[PMSFX]] that produces [[.COM file]]s unpackable under [[DOS]] and [[CP/M]] (the first three bytes are both legal [[Z80]] code, legal [[8086]] code and legal [[PMARC|PMA]] header) […] as a [[self-extracting archive]]. […]}}</ref>
<ref name="Elliott_2009_PMARC">{{cite newsgroup |title=CP/M info program |author-first=John C. |author-last=Elliott |date=2009-10-27 |newsgroup=comp.os.cpm |url=https://groups.google.com/g/comp.os.cpm/c/RMWG4qSdbM0/m/UGll0BzoiW0J |access-date=2021-12-13 |url-status=live |archive-url=https://web.archive.org/web/20211213154548/https://groups.google.com/g/comp.os.cpm/c/RMWG4qSdbM0/m/UGll0BzoiW0J |archive-date=2021-12-13 |quote=[…] 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|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. […]}}</ref>
<ref name="Wilkinson-Seligman-Drushel-Elliott-Harston_1999">{{cite newsgroup |title=MS-DOS & CP/M-Compatible Binaries |author-first1=William "Bill" Albert |author-last1=Wilkinson |author-first2=Cory |author-last2=Seligman |author-first3=Richard F. |author-last3=Drushel |author-first4=Jonathan Graham |author-last4=Harston |author-first5=John C. |author-last5=Elliott |date=1999-02-17 |newsgroup=comp.os.cpm |url=https://groups.google.com/g/comp.os.cpm/c/nSiKFzq1gGE/m/PzpfpSbNx34J |access-date=2021-12-13 |url-status=live |archive-url=https://web.archive.org/web/20211213055749/https://groups.google.com/g/comp.os.cpm/c/nSiKFzq1gGE/m/PzpfpSbNx34J |archive-date=2021-12-13}} (NB. Some of the opcodes in Elliott's example code ({{mono|EBh, 44h, EBh}} and {{mono|EBh, 04h, ...}}) might be mixed up.)</ref>
<ref name="Wilkinson_2005">{{cite magazine |title=Something COMmon About MS-DOS and CP/M |author-first=William "Bill" Albert |author-last=Wilkinson |location=Heath Company, USA |magazine=REMark |publisher=Heath/Zenith Users' Group (HUG) |issn= |publication-place=St. Joseph, Michigan, USA |date=2005-04-02 |volume=8 |issue=2 |id=<!-- |number=-->#85. P/N 885-2085 |orig-date=<!-- republished on new domaim -->2003, <!-- first web published http://members.aol.com/wwheco1/commscpm.htm -->1999-02-16, <!-- first published in REMark -->February 1987, <!-- originally written -->1986-11-15, 1986-11-10 |pages=55–57 |url=https://www.heco.wxwilki.com/commscpm.html |url-status=live |archive-url=https://web.archive.org/web/20211213125948/https://www.heco.wxwilki.com/commscpm.html |archive-date=2021-12-13}} [https://web.archive.org/web/20211213163457/http://www.pestingers.net/pdfs/remark-scans/1987/remark-volume8-issue2-1987.pdf]</ref>
<ref name="Paul_2002_COM">{{cite newsgroup |ref=CITEREF-Paul-2002-COM |title=Re: Run a COM file |author-first=Matthias R. |author-last=Paul |date=2002-10-07 |orig-date=2000 |newsgroup=alt.msdos.programmer |url=https://groups.google.com/d/msg/alt.msdos.programmer/d7blJjY0H5M/Qu3VeTOIGVcJ |access-date=2017-09-03 |url-status=live |archive-url=https://archive.today/20170903230312/https://groups.google.com/forum/%23!msg/alt.msdos.programmer/d7blJjY0H5M/Qu3VeTOIGVcJ |archive-date=2017-09-03}} [https://groups.google.com/d/msg/alt.lang.asm/PNOd9zfYow0/vXbab16j4XwJ] (NB. Has details on DOS COM program calling conventions.)</ref>
<ref name="Collins-Chinya-Jiang-Tian-Girkar-Yang-Lueh-Wang_2007">{{cite journal |title=EXOCHI: architecture and programming environment for a heterogeneous multi-core multithreaded system |author-first1=Perry H. |author-last1=Wang |author-first2=Jamison D. |author-last2=Collins |author-first3=Gautham N. |author-last3=Chinya |author-first4=Hong |author-last4=Jiang |author-first5=Xinmin |author-last5=Tian |author-first6=Milind |author-last6=Girkar |author-first7=Nick Y. |author-last7=Yang |author-first8=Guei-Yuan |author-last8=Lueh |author-first9=Hong |author-last9=Wang |journal=ACM SIGPLAN Notices |volume=42 |issue=6 |date=June 2007 |doi=10.1145/1273442.1250753 |pages=156–166 |url=https://doi.org/10.1145/1273442.1250753|url-access=subscription }} (11 pages)</ref>
<ref name="Wang-Collins-Chinya-Jiang-Tian-Girkar-Pearce-Lueh-Yakoushkin-Wang_2007">{{cite journal |title=Accelerator Exoskeleton |author-last1=Wang |author-first1=Perry H. |author-last2=Collins |author-first2=Jamison D. |author-last3=Chinya |author-first3=Gautham N. |author-first4=Hong |author-last4=Jiang |author-first5=Xinmin |author-last5=Tian |author-last6=Girkar |author-first6=Milind |author-last7=Pearce |author-first7=Lisa |author-first8=Guei-Yuan |author-last8=Lueh |author-last9=Yakoushkin |author-first9=Sergey |author-first10=Hong |author-last10=Wang |journal=Intel Technology Journal |publisher=[[Intel Corporation]] |volume=11: Tera-scale Computing |issue=3 |date=2007-08-22 |issn=1535-864X |doi=10.1535/itj.1103 |pages=185–196 |url=https://www.intel.com/content/dam/www/public/us/en/documents/research/2007-vol11-iss-3-intel-technology-journal.pdf |access-date=2022-05-26 |url-status=live |archive-url=https://web.archive.org/web/20220526031706/https://www.intel.com/content/dam/www/public/us/en/documents/research/2007-vol11-iss-3-intel-technology-journal.pdf |archive-date=2022-05-26}} (12 of 1+vii+90+1 pages)</ref>
<ref name="Nvidia_2004">{{cite web |title=cudaFatFormat.h / ptxomp.c |version=1.13 |date=2004-11-15 |publisher=[[Nvidia Corporation]] |url=https://pixel.ecn.purdue.edu:8443/purpl/WSJ/projects/DirectionalStippling/include/.svn/text-base/__cudaFatFormat.h.svn-base |access-date=2022-05-26 |url-status=live |archive-url=https://web.archive.org/web/20220526034030/https://pixel.ecn.purdue.edu:8443/purpl/WSJ/projects/DirectionalStippling/include/.svn/text-base/__cudaFatFormat.h.svn-base |archive-date=2022-05-26}}</ref>
<ref name="Braun-Fröning_2019">{{cite conference |title=CUDA Flux: A Lightweight Instruction Profiler for CUDA Applications |author-first1=Lorenz |author-last1=Braun |author-first2=Holger |author-last2=Fröning |conference=IEEE/ACM Performance Modeling, Benchmarking and Simulation of High Performance Computer Systems (PMBS) |date=2019-11-18 |doi=10.1109/PMBS49563.2019.00014 |publisher=[[IEEE]] |location=Denver, Colorado, USA |isbn=978-1-7281-5977-5 |url=https://sc19.supercomputing.org/proceedings/workshops/workshop_files/ws_pmbsf101s2-file1.pdf |access-date=2022-05-26 |url-status=live |archive-url=https://web.archive.org/web/20220321153526/https://sc19.supercomputing.org/proceedings/workshops/workshop_files/ws_pmbsf101s2-file1.pdf |archive-date=2022-03-21}}</ref>
<ref name="Harris_2014">{{cite web |title=Technical Walkthrough: CUDA Pro Tip: Understand Fat Binaries and JIT Caching |author-first=Mark J. |author-last=Harris |author-link=Mark Harris (programmer) |date=2014-05-08 |orig-date=2013-06-05 |work=Nvidia Developer |publisher=[[Nvidia]] |url=https://developer.nvidia.com/blog/cuda-pro-tip-understand-fat-binaries-jit-caching/ |access-date=2022-05-26 |url-status=live |archive-url=https://web.archive.org/web/20220323142917/https://developer.nvidia.com/blog/cuda-pro-tip-understand-fat-binaries-jit-caching/ |archive-date=2022-03-23}}</ref>
<ref name="CUDA_2014">{{cite web |title=CUDA Binary Utilities |id=DA-06762-001_v6.0 |date=February 2014 |publisher=[[Nvidia]] |type=Application Note |version=6.0 |url=http://194.29.175.19/cuda/6.0/doc/pdf/CUDA_Binary_Utilities.pdf |access-date=2022-05-25 |url-status=live |archive-url=https://web.archive.org/web/20220525180630/http://194.29.175.19/cuda/6.0/doc/pdf/CUDA_Binary_Utilities.pdf |archive-date=2022-05-25}}</ref>
<ref name="CUDA_2016">{{cite web |title=fatbinary - help |date=2016 |version=8.0 |url=https://helpmanual.io/help/fatbinary/ |website=helpmanual.io |access-date=2022-05-25 |url-status=live |archive-url=https://web.archive.org/web/20220525180220/https://helpmanual.io/help/fatbinary/ |archive-date=2022-05-25}}</ref>
<ref name="CUDA_2022">{{cite web |title=CUDA Compiler Driver NVCC - Reference Guide |publisher=[[Nvidia]] |date=May 2022 |id=TRM-06721-001_v11.7 |version=11.7 |url=https://docs.nvidia.com/cuda/pdf/CUDA_Compiler_Driver_NVCC.pdf |access-date=2022-05-25 |url-status=live |archive-url=https://web.archive.org/web/20220525184954/https://docs.nvidia.com/cuda/pdf/CUDA_Compiler_Driver_NVCC.pdf 
|archive-date=2022-05-25}}</ref>
<ref name="Fung-Sham-Yuan-Aamodt_2007">{{cite web |title=Dynamic Warp Formation and Scheduling for Efficient GPU Control Flow |author-first1=Wilson W. L. |author-last1=Fung |author-first2=Ivan |author-last2=Sham |author-first3=George |author-last3=Yuan |author-first4=Tor M. |author-last4=Aamodt |location=Vancouver, British Columbia, Canada |date=2007 |url=https://people.ece.ubc.ca/aamodt/papers/wwlfung.micro2007.pdf |access-date=2022-05-26 |url-status=live |archive-url=https://web.archive.org/web/20220526151255/https://people.ece.ubc.ca/aamodt/papers/wwlfung.micro2007.pdf |archive-date=2022-05-26}} (12 pages)</ref>
<ref name="Bakhoda-Yuan-Fung-Wong-Aamodt_2009">{{cite conference |title=Analyzing CUDA Workloads Using a Detailed GPU Simulator |author-first1=Ali |author-last1=Bakhoda |author-first2=George L. |author-last2=Yuan |author-first3=Wilson W. L. |author-last3=Fung |author-first4=Henry |author-last4=Wong |author-first5=Tor M. |author-last5=Aamodt |conference=Proceedings of the IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS) |doi=10.1109/ISPASS.2009.4919648 |location=Boston, Massachusetts, USA |date=2009-04-28 |orig-date=2009-04-26 |pages=163–174 |url=https://people.ece.ubc.ca/aamodt/papers/gpgpusim.ispass09.pdf |access-date=2022-05-06 |url-status=live |archive-url=https://web.archive.org/web/20220526152055/https://people.ece.ubc.ca/aamodt/papers/gpgpusim.ispass09.pdf |archive-date=2022-05-26}} [https://www.researchgate.net/profile/Ali-Bakhoda-2/publication/224445130_Analyzing_CUDA_workloads_using_a_detailed_GPU_simulator/links/00b49525edd5aa467f000000/Analyzing-CUDA-workloads-using-a-detailed-GPU-simulator.pdf]</ref>
<ref name="Ubal-Jang_Mistry_Schaa_Kaeli_2012">{{cite conference |title=Multi2Sim: A Simulation Framework for CPU-GPU Computing |author-first1=Rafael |author-last=Ubal |author-first2=Byunghyun |author-last2=Jang |author-first3=Perhaad |author-last3=Mistry |author-first4=Dana |author-last4=Schaa |author-first5=David R. |author-last5=Kaeli |author-link5=David R. Kaeli |date=2012-09-23 |orig-date=2012-09-19 |book-title=21st International Conference on Parallel Architectures and Compilation Techniques (PACT) |publisher=[[IEEE]] |location=Minneapolis, Minnesota, USA |isbn=978-1-4503-1182-3 |url=http://www.multi2sim.org/publications/pact-2012.pdf |access-date=2022-05-25 |url-status=live |archive-url=https://web.archive.org/web/20220525190239/http://www.multi2sim.org/publications/pact-2012.pdf |archive-date=2022-05-25}} (10 pages)</ref>
<ref name="Multi2Sim_2013">{{cite book |title=The Multi2Sim Simulation Framework - A CPU-GPU Model for Heterogeneous Computing |version=v4.2 |chapter=13.4 The AMD Compiler Wrapper: Fat binaries |pages=173–176 [176] |date=2013 |publisher=Multi2Sim |url=http://www.multi2sim.org/downloads/m2s-guide-4.2.pdf |access-date=2022-05-25 |url-status=live |archive-url=https://web.archive.org/web/20220525175140/http://www.multi2sim.org/downloads/m2s-guide-4.2.pdf |archive-date=2022-05-25}} (4 of 210 pages)</ref>
<ref name="Cha-Pak-Brumley-Lipton_2010">{{cite conference |title=Platform-Independent Programs |author-first1=Sang Kil |author-last1=Cha |author-first2=Brian |author-last2=Pak |author-first3=David |author-last3=Brumley |author-link3=David Brumley |author-first4=Richard Jay |author-last4=Lipton |author-link4=Richard Jay Lipton |conference=Proceedings of the 17th ACM conference on Computer and Communications Security (CCS'10) |location=Chicago, Illinois, USA |date=2010-10-08 |orig-date=2010-10-04 |isbn=978-1-4503-0244-9 |doi=10.1145/1866307.1866369 |publisher=[[Carnegie Mellon University]], Pittsburgh, Pennsylvania, USA / [[Georgia Institute of Technology]], Atlanta, Georgia, USA |pages=547–558 |url=https://softsec.kaist.ac.kr/~sangkilc/papers/cha-ccs10.pdf |access-date=2022-05-26 |url-status=live |archive-url=https://web.archive.org/web/20220526153147/https://softsec.kaist.ac.kr/~sangkilc/papers/cha-ccs10.pdf |archive-date=2022-05-26}} [https://web.archive.org/web/20220526182333/http://users.ece.cmu.edu/~sangkilc/papers/ccs10-cha.pdf] (12 pages) (See also: [https://security.ece.cmu.edu/pip/index.html]) {{anchor|Gadget}}(NB. Does not address the scenario specifically for [[8080]] vs. [[8086]] [[instruction set architecture]]s (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 gadget]]s) for [[x86]], [[MIPS architecture|MIPS]] and [[ARM architecture|ARM]]: i.e. 
{{mono|0Eh, B2h, 02h, A9h, 0Eh, B2h, 02h, 3Ah, 24h, 77h, 01h, 04h}} or {{mono|90h, EBh, 20h, 2Ah, 90h, EBh, 20h, 3Ah, 24h, 77h, 01h, 04h}}.)</ref>
}}

==Further reading==
* {{cite web |title=How Fat Does a Fat Binary Need to Be? |author-first=Justine Alexandra Roberts |author-last=Tunney |work=cosmopolitan libc - your build-once run-anywhere c library / Cosmopolitan Communiqué |date=2021-02-11 |url=https://justine.lol/cosmopolitan/howfat.html |access-date=2021-09-12 |url-status=live |archive-url=https://web.archive.org/web/20210912191536/https://justine.lol/cosmopolitan/howfat.html |archive-date=2021-09-12}}; {{cite web |title=How Fat Does a Fat Binary Need to Be? |author-first=Justine Alexandra Roberts |author-last=Tunney |date=2021-02-11 |work=Hacker News |url=https://news.ycombinator.com/item?id=26103769 |access-date=2021-09-12 |url-status=live |archive-url=https://web.archive.org/web/20210601225841/https://news.ycombinator.com/item?id=26103769 |archive-date=2021-06-01}}
* {{cite web |title=αcτµαlly pδrταblε εxεcµταblε (Ape) |author-first=Justine Alexandra Roberts |author-last=Tunney |date=2020-08-24 |url=https://justine.lol/ape.html |access-date=2021-09-12 |url-status=live |archive-url=https://web.archive.org/web/20210912190108/https://justine.lol/ape.html |archive-date=2021-09-12}}
* {{cite web |title=Making a Fat Binary for Linux and Mac |author-first=Frederick |author-last=Gotham |date=2020-10-22 |work=Narkive |url=https://comp.lang.c.narkive.com/HWx1kwqO/making-a-fat-binary-for-linux-and-mac |access-date=2021-09-12 |url-status=live |archive-url=https://web.archive.org/web/20210912190618/https://comp.lang.c.narkive.com/HWx1kwqO/making-a-fat-binary-for-linux-and-mac |archive-date=2021-09-12}}
* {{cite web |title=Fat Binary - MS-Windows and four Linux |author-first=Frederick |author-last=Gotham |date=2020-10-24 |work=Narkive |url=https://comp.lang.cpp.narkive.com/A4eaqYFD/fat-binary-ms-windows-and-four-linux |access-date=2021-09-12 |url-status=live |archive-url=https://web.archive.org/web/20210912190426/https://comp.lang.cpp.narkive.com/A4eaqYFD/fat-binary-ms-windows-and-four-linux |archive-date=2021-09-12}}
* {{cite web |title=Fat Binary - DOS Windows Linux |author-first=Frederick |author-last=Gotham |date=2020-11-02 |work=Narkive |url=https://comp.unix.programmer.narkive.com/persSes9/fat-binary-dos-windows-linux |access-date=2021-09-12 |url-status=live |archive-url=https://web.archive.org/web/20210912181058/https://comp.unix.programmer.narkive.com/persSes9/fat-binary-dos-windows-linux |archive-date=2021-09-12}}
* {{cite web |title=We develop to WarpUP the Amiga - StormC for PowerPC and p-OS |date=September 1996 |website=Haage & Partner GmbH |url=https://www.haage-partner.de/amiga/storm/sc_n1_e.htm |access-date=2021-09-29 |url-status=live |archive-url=https://web.archive.org/web/20171206172106/http://www.haage-partner.de/amiga/storm/sc_n1_e.htm |archive-date=2017-12-06}}
* {{cite web |title=AmigaOS 3.9 - Features |work=AmigaOS: multimedia, multi-threaded, multi-tasking |author-first=Matthias |author-last=Münch |date=2006 |orig-date=2005 |url=https://os.amigaworld.de/index.php?lang=en&page=7 |access-date=2021-09-29 |url-status=live |archive-url=https://web.archive.org/web/20210929081348/https://os.amigaworld.de/index.php?lang=en&page=7 |archive-date=2021-09-29}}

[[Category:Executable file formats]]