Editing Fat binary (section)

==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.