Just Solve the File Format Problem - User contributions [en]

Floppy disk

2024-09-05T11:41:03Z

SJK:

:''See also [[Filesystem|Filesystems]], which are contained on Floppy Disks.''

{{FormatInfo
|formattype=physical
|thiscat=Floppy disk
|image=Floppy-disks.jpg
|caption=Some floppies, 5 1/4" and 3 1/2".
}}

Formats for images of floppy disk data can be found at [[Disk Image Formats]].

The main ways in which floppy disks could differ at a recording level:
* The physical dimensions and physical layout – the most common sizes were 8-inch, 5¼-inch (officially the metric 130 mm, but in common parlance referred to by its inch approximation even in countries which normally use the metric system), 3½ inch (likewise officially metric 90 mm, but commonly known by the inch approximation). Note those are the sizes of the actual magnetic disk, the jacket/cartridge is larger. However, there were many other rare sizes.
* The method of data encoding: the earliest floppies IBM 8-inch floppies used [[FM encoding]]. Capacity was doubled, without changing the disks physically, by switching to the more efficient [[MFM encoding]]. The original FM encoded disks were called "single density", and the MFM encoded "double density". IBM PC 5¼-inch and 3½ inch floppies used MFM encoding; the term "double density" was later extended to "high density" and beyond, but this time it referred to changes in the magnetic material and type of disk heads rather than an encoding change. [[GCR encoding]] was also popular, particularly with systems such as Apple IIs and Commodore 64s. Some early "double density" drives used [[M2FM encoding]] (most notably Intel ISIS-II and HP 9885) which was later replaced by the simpler MFM.
* Magnetic recording material: more expensive media could store more data
* Type of magnetic disk heads: more expensive magnets could store more data
* Speed of rotation
* Constant angular velocity (CAV) versus constant linear velocity (CLV)
* Number of sides – early disks and drives were single-sided only and could only record on one side of the disk; later disks and drives were double-sided and supported recording on both sides. There were also "flippy disks" where a single-sided drive could be used to record on both sides of a disk by the user manually flipping the disk to access the other side.
* Longitudinal magnetic recording versus perpendicular magnetic recording: traditionally floppies used longitudinal; 2.88 MB floppy drives doubled the capacity over 1.44MB by switching to perpendicular
* Sector size: the earliest floppies had 128 byte sectors; IBM PC floppies normally had 512 byte sectors. IBM PC floppy controllers could support any power of 2 from 128 to 4096. Rarely, different tracks on a floppy could be recorded with different sector sizes, or even a single track with a mix of different sector sizes.
* Gap length between sectors: reducing the gap length could squeeze more sectors on to the disk but at the risk of data loss
* Format of track and sector headers, including CRC algorithms and any per-sector flags (e.g. IBM 3740 has a flag to mark each sector as "deleted", a feature carried forward into IBM PC floppy formats, but almost never used in them.)
* Number of tracks per disk and number of sectors per track

A given combination of floppy disk controller, floppy drive, and disk, could generally support several different variations on the same basic format, but only within certain constraints – e.g. IBM PC floppies could be formatted with a non-standard sector size or number of tracks, but not with GCR or MMFM encoding (since the floppy disk controllers used in IBM PCs did not support those encodings).

The disk geometry, encoding, etc, is orthogonal to the filesystem – 1.44MB Apple Mac floppies were physically interoperable with IBM PC floppies, even though IBM PCs normally lacked software to read Apple's HFS filesystem; by contrast, the earlier 800KB and 400KB Apple Mac floppies were incompatible with IBM PC floppies, since IBM PC floppy drives could not physically read them, nor could those earlier Mac floppy drives physically read IBM PC floppies.

== 2 Inch ==
* [[LT-1]]
* [[Video Floppy]]

== 2 1/2 Inch ==
* [[Sharp 2.5-inch floppy disk]]

== 3 Inch ==
* [[CF-2 Compact Floppy Disk]]
* [[MCD-1 Micro Cassette]]

== 3 1/2 Inch ==
* Acorn
** [[Acorn double density 3 1/2" disk]]
** [[Acorn high density 3 1/2" disk]]
* [[Akai Disk Format]]
* Amiga
** [[Amiga double density disk]]
** [[Amiga high density disk]]
* Apple
** [[Apple double-density 3 1/2" disk]]
** [[Apple high-density 3 1/2" disk]]
* Brother
** [[Brother 120k]]
** [[Brother 240k]]
** [[Brother HD]]
* Commodore
** [[Commodore 1581 disk]]
* IBM PC and compatibles
** [[PC-DOS 720K format]]
** [[PC-DOS 1.44M format]]
** [[PC-DOS 2.88M format]]
* SAM Coupé
** [[SAM Coupé disk]]
* ZX Spectrum
** [[ZX Spectrum Beta Disc 3.5" floppy]] (see [[TR-DOS filesystem]])

== 4 Inch ==
* [[IBM DemiDiskette]]

== 5 1/4 Inch ==
* Acorn
** [[Acorn single density 5 1/4" disk]]
** [[Acorn double density 5 1/4" disk]]
* APF
** [[APF Imagination Machine floppy disk]]
* Apple
** [[Apple II 13 sector disk]] (Apple DOS 3.2)
** [[Apple II 16 sector disk]] (Apple DOS 3.3, ProDOS, Apple III SOS)
** [[Twiggy floppy]] (Apple Lisa)
* Atari
** [[Atari 810]]
* CalComp
** [[CalComp Vistagraphic 4500 floppy disk]]
* Commodore
** [[Commodore 2040 disk]] (and 4040; for PET computers; preceded 1541 despite higher number)
** [[Commodore 1541 disk]] (used with VIC-20 and C-64)
** [[Commodore 1571 disk]] (used with C-128)
* Compucolor
** [[Compucolor II disk]]
* IBM PC and compatible
** [[PC-DOS 160K format]]
** [[PC-DOS 180K format]]
** [[PC-DOS 320K format]]
** [[PC-DOS 360K format]]
** [[PC-DOS 1.2M format]]
* Kaypro
** [[Kaypro 2 CP/M 2.2]]
** [[Kaypro 4 CP/M 2.2]]
* North Star
** [[North Star MDS-A-D]]
* PMC
** [[PMC MicroMate floppy disk]]
* Tandy
** TRS-80 Model I, III, 4
*** [[TRS-80 single density 5.25" disk]]
*** [[TRS-80 double density 5.25" disk]]
** TRS-80 Color Computer
*** [[TRS-80 Color Computer single sided 5.25" disk]]
*** [[TRS-80 Color Computer double sided 5.25" disk]]
* Texas Instruments
** [[TI-99/4A 90K]]
** [[TI-99/4A 180K]]
** [[TI-99/4A 360K]]
* ZX Spectrum
** [[ZX Spectrum Beta Disc 5.25" floppy]] (see [[TR-DOS filesystem]])

== 8 Inch ==
[[File:floppy-disks-8in.jpg|thumb|upright|[[Some 8" floppy disks]]]]
* DEC
** [[DEC RX01]]
** [[DEC RX02]]
* IBM
** [[IBM Type 1]] (33FD)
** [[IBM Type 2]] (43FD)
** [[IBM Type 2D]] (53FD)
** [[IBM 23FD]]
** [[IBM 3740 format]]

== Data encoding formats ==
* [[FM encoding]]
* [[GCR encoding]]
* [[MFM encoding]]
* [[RLL encoding]]

== Devices to read floppy disks ==

* [http://www.deviceside.com/fc5025.html Device Side Data FC5025 USB 5.25" floppy controller]
* [[KryoFlux]]
* [http://discferret.com/wiki/DiscFerret DiskFerret]
* [http://wiki.icomp.de/wiki/Catweasel Catweasel]
* [http://www.cbmstuff.com/proddetail.php?prod=SCP SuperCard Pro]
* [http://cowlark.com/fluxengine/index.html FluxEngine]

== Disk transfer info ==

* [http://retro.icequake.net/apple2pc.html Info on disk transfers between Apple II and PC/Mac]
* [http://xfrstn.newmuseum.org/ XFER STN (New Museum)] (available to artists for converting old-format works)
* [http://www.macdisk.com/lecten.php PC-Lect, program to read old disk formats] (for PC/MS-DOS; doesn't work in Windows past Win98)

== Utilities ==

* [http://disktype.sourceforge.net/ disktype: detect format of disk or disk image]
* [http://digitalcontinuity.org/post/144268258748/floppy-disk-format-identifer-tool Floppy Disk Format Identifer Tool]

== Other links and references ==

* [[Wikipedia:List of floppy disk formats|List of Floppy Disk Formats]], Wikipedia.
* [http://digitize.archiveteam.org/index.php/Floppy_Disks Digitize the Planet: Floppy Disks]
* Michael Haardt et al's [http://www.moria.de/~michael/floppy/ Floppy User Guide] has some information on physical, magnetic, etc formats.
* [http://www.retrotechnology.com/herbs_stuff/drive.html Floppy drive tech info]
* [http://archive.org/details/commodore_protection Commodore copy protection books and manuals]
* [http://www.archiveteam.org/index.php?title=Rescuing_Floppy_Disks Rescuing Floppy Disks (Archive Team)]
* [http://archive.org/stream/bitsavers_kaypro3318uideFeb85_2222683/3318-A_Kaypro_Robbie_Users_Guide_Feb85#page/n15/mode/2up Care of diskettes]
* [http://vimeo.com/64248011 Floppy disk archaeology lecture (video)]
* [http://goughlui.com/?p=3239 Dealing with difficult disks and drives]
* [http://www.theonion.com/articles/new-improved-obamacare-program-released-on-35-flop,34294/ New, Improved Obamacare Program Released On 35 Floppy Disks (The Onion; humor)]
* [http://superuser.com/questions/231273/what-are-the-windows-a-and-b-drives-used-for What are the Windows A: and B: drives used for?]
* [http://ascii.textfiles.com/archives/4226 The Flippy Disk Thing]
* [http://offog.org/notes/archiving/minifloppies/ Imaging 5.25" floppies]
* [http://www.dustbury.com/archives/17950 This could take a while...]
* [http://studioforcreativeinquiry.org/events/warhol-discovery Previously Unknown Warhol Works Discovered on Floppy Disks from 1985]
* [http://studioforcreativeinquiry.org/public/warhol_amiga_report_v10.pdf Detailed report on the Warhol graphic recovery (PDF)]
* [https://twitter.com/mikko/status/460883199690678273/photo/1/large One of the computers that would receive a nuclear launch order from the President still uses 8" floppy disks.]
* [http://www.loc.gov/preservation/resources/rfs/softgame.html Library of Congress Recommended Format Specifications: Software/Gaming]
* [http://qanda.digipres.org/199/settings-should-imaging-floppy-disks-using-kryoflux-device What settings should be used when imaging floppy disks using a Kryoflux device?]
* [https://docs.google.com/spreadsheets/d/1g_xM_cmUAl2AIYwD3d_2IulZlOG6_JmDDf7FoIRW9EM/edit Spreadsheet of floppy formats and Kryoflux settings]
* [https://github.com/euanc/kryofluxDiskID Kryoflux Disk ID software; tries to identify disk types in image]
* [http://www.openplanetsfoundation.org/blogs/2014-06-26-bulk-disk-imaging-and-disk-format-identification-kryoflux Bulk disk imaging and disk-format identification with KryoFlux]
* [http://www.sugarcayne.com/2013/09/exile-zip-disks-floppies/ Zip Disks & Floppies: musical piece by artist who formerly used those media for storing beats]
* [http://dmweb.free.fr/?q=node/210 Notes on copy protection of Dungeon Master and Chaos Strikes Back for Atari ST and Amiga]
* [http://news.softpedia.com/news/Windows-10-Preview-Removes-Floppy-Disk-Drive-Support-468177.shtml Windows 10 Preview Removes Floppy Disk Drive Support]
* [http://forum.kryoflux.com/viewtopic.php?f=3&t=630&hilit=8+inch Some discussion of Shugart 801 8" drive]
* [http://www.macworld.com/article/3018315/storage/star-trek-creators-lost-words-recovered-from-old-floppies.html How Star Trek creator Gene Roddenberry’s words were freed from old floppy disks]
* [http://openpreservation.org/blog/2016/09/01/an-8-floppy-disk-challenge/ An 8″ Floppy Disk Challenge]
* [http://openpreservation.org/blog/2016/09/02/digital-obsolescence-reproducing-data-cables/ Digital Obsolescence: Reproducing Floppy Data Cables]
* [https://www.youtube.com/watch?v=EHRc-QMoUE4 The 8-Bit Guy: How Old School Floppy Drives Worked] (video)
* [http://journal.code4lib.org/articles/11986 Working with Floppy Disks from the 1980s]

See also [[Disk Imaging Software & Systems]].

PC-DOS 360K format

2024-09-05T10:30:14Z

SJK:

{{FormatInfo
|formattype=physical
|subcat=Floppy disk
|wikidata={{wikidata|Q29167905}}
}}
The '''PC-DOS 360K format''' was a very common floppy disk format in the 1980s, used on IBM PCs and compatibles. It replaced earlier [[PC-DOS 160K format|160K]], [[PC-DOS 180K format|180K]], and [[PC-DOS 320K format|320K]] formats using either fewer sectors, single-sided disks, or both, with a new format getting the most out of a double-sided, double-density 5 1/4" floppy disk. It had 40 tracks per side, with 9 sectors per track, and 512 bytes per sector. The disk turned at 300 RPM.

These disks were generally used with [[FAT12]] file systems under the MS-DOS or PC-DOS operating system, but (far more rarely) were used with other filesystems too (e.g CP/M-86). The sector headers, etc, were based on [[IBM 3740]] format, albeit with [[MFM encoding]] (double density) replacing the original [[FM encoding]] (single density).

After being a commonplace format for most of the 1980s, this format declined in favor of the high-density [[PC-DOS 1.2M format]] and the 3 1/2" [[PC-DOS 720K format]] and [[PC-DOS 1.44M format]]. (There were compatibility issues in reading 360K disks on low-density drives after they were written to with a high-density drive, even though the writing is done in an emulation of the old format, due to the different drive head on the newer drives. The high-density drive heads were smaller, and the data written by them might not be picked up correctly by the larger low-density heads, particularly if the new data was overwriting data stored earlier using large-headed drives, which might not be completely overwritten.)

In the late '80s and early '90s, it was common for desktop PCs to have both 5 1/4" and 3 1/2" disk drives in order to be compatible with all software and data, which might be distributed on either format. Often the 5 1/4" drive was drive A, and the 3 1/2" one was drive B. Later PCs, however, were more likely to have only a 3 1/2" drive, set up to respond to both drive letters. Eventually, PCs stopped having floppy disk drives altogether as other data storage and transfer media took over.

== Links ==
* [http://www.textfiles.com/programming/FORMATS/formats.pro Info on MS-DOS 1.x - 2.x disk formats]
* [http://67.185.176.54:8080/diskette_handling.html Working with old diskettes]
* [http://www.computerhistory.org/_static/atchm/microsoft-ms-dos-early-source-code/ Early PC-DOS source code]

[[Category:IBM]]
[[Category:Microsoft]]
[[Category:MS-DOS]]

PC-DOS 320K format

2024-09-05T10:29:37Z

SJK:

{{FormatInfo
|formattype=physical
|subcat=Floppy disk
}}

The '''PC-DOS 320K format''' was one of several low-capacity 5 1/4" disk formats used on IBM PCs and compatibles in the early days of PC-DOS before the [[PC-DOS 360K format]] became the standard. It used a double-sided, double-density disk with 40 tracks per side with 8 sectors per track, and 512 bytes per sector. The disk turned at 300 RPM. These disks were generally used with [[FAT12]] file systems under the MS-DOS or PC-DOS operating system, but (far more rarely) were used with other filesystems too (e.g CP/M-86). The sector headers, etc, were based on [[IBM 3740]] format, albeit with [[MFM encoding]] (double density) replacing the original [[FM encoding]] (single density).

This format was the double-sided counterpart of the [[PC-DOS 160K format]], but was soon superseded by the 360K format made possible by expanding the number of sectors per track to 9.

== Links ==
* [http://www.textfiles.com/programming/FORMATS/formats.pro Info on MS-DOS 1.x - 2.x disk formats]
* [http://www.computerhistory.org/_static/atchm/microsoft-ms-dos-early-source-code/ Early PC-DOS source code]

[[Category:IBM]]
[[Category:Microsoft]]

PC-DOS 180K format

2024-09-05T10:29:01Z

SJK:

{{FormatInfo
|formattype=physical
|subcat=Floppy disk
}}

The '''PC-DOS 180K format''' was one of several low-capacity 5 1/4" disk formats used on IBM PCs and compatibles in the early days of PC-DOS before the [[PC-DOS 360K format]] became the standard. It used a single-sided, double-density disk with 40 tracks with 9 sectors per track, and 512 bytes per sector. Data was stored with [[MFM encoding]]. The disk turned at 300 RPM. These disks were generally used with [[FAT12]] file systems under the MS-DOS or PC-DOS operating system, but (far more rarely) were used with other filesystems too (e.g CP/M-86). The sector headers, etc, were based on [[IBM 3740]] format, albeit with [[MFM encoding]] (double density) replacing the original [[FM encoding]] (single density). This format had one more sector per track than the [[PC-DOS 160K format]], and was in the same format as the [[PC-DOS 360K format]] except using only one side of the disk instead of both sides.

As with most single-sided disk formats, users often flipped the disks over to double the storage capacity, which required cutting a write-enable notch on the opposite side from the standard one. Some disks were manufactured with a second notch to cater to this use, though disk manufacturers tended to discourage double-sided use by claiming the reverse side wasn't properly certified for data (despite the fact that different single-sided formats on different platforms actually used different sides of the media) and that flipping the disks caused dust that builds up on the disk to get into the disk drive.

== Links ==
* [http://www.textfiles.com/programming/FORMATS/formats.pro Info on MS-DOS 1.x - 2.x disk formats]
* [http://www.computerhistory.org/_static/atchm/microsoft-ms-dos-early-source-code/ Early PC-DOS source code]

[[Category:IBM]]
[[Category:Microsoft]]

PC-DOS 160K format

2024-09-05T10:28:19Z

SJK:

{{FormatInfo
|formattype=physical
|subcat=Floppy disk
}}
The '''PC-DOS 160K format''' was one of several low-capacity 5 1/4" disk formats used on IBM PCs and compatibles in the early days of PC-DOS before the [[PC-DOS 360K format]] became the standard. It used a single-sided, double-density disk with 40 tracks with 8 sectors per track, and 512 bytes per sector. Data was stored with [[MFM encoding]]. The disk turned at 300 RPM. These disks were generally used with [[FAT12]] file systems under the MS-DOS or PC-DOS operating system, but (far more rarely) were used with other filesystems too (e.g CP/M-86). The sector headers, etc, were based on [[IBM 3740]] format, albeit with [[MFM encoding]] (double density) replacing the original [[FM encoding]] (single density).

As with most single-sided disk formats, users often flipped the disks over to double the storage capacity, which required cutting a write-enable notch on the opposite side from the standard one. Some disks were manufactured with a second notch to cater to this use, though disk manufacturers tended to discourage double-sided use by claiming the reverse side wasn't properly certified for data (despite the fact that different single-sided formats on different platforms actually used different sides of the media) and that flipping the disks caused dust that builds up on the disk to get into the disk drive.

== Links ==
* [http://www.textfiles.com/programming/FORMATS/formats.pro Info on MS-DOS 1.x - 2.x disk formats]
* [http://www.computerhistory.org/_static/atchm/microsoft-ms-dos-early-source-code/ Early PC-DOS source code]

[[Category:IBM]]
[[Category:Microsoft]]

FAT8

2024-09-05T05:21:27Z

SJK: links to some real examples of FAT8 filesystems

{{FormatInfo
|formattype=electronic
|subcat=Filesystem
}}

'''FAT8''' (Original 8-bit FAT; a variety of [[FAT]], which stands for File Allocation Table) is a simple filesystem with limited capabilities. The "8" refers to the number of bits in table entries. This was the original version of [[FAT]] created at Microsoft for use with versions of [[BASIC]] that had built-in disk support; it was then adopted by Tim Patterson of Seattle Computer Products, who adapted it into [[FAT12]] for use in his disk operating system that eventually got licensed to Microsoft (and in turn to IBM) as PC-DOS / [[MS-DOS]].

==Resources==
* [[wikipedia:File Allocation Table#Original 8-bit FAT|Wikipedia]]
* [https://retrocomputing.stackexchange.com/questions/27228/do-any-fat8-filesystem-images-survive Do any FAT8 filesystem images survive?] which links to a couple of example FAT8 disk images ([https://archive.org/details/ToshibaT100PersonalComputerTDISKBASICVersion101982 Toshiba T100 Personal Computer T-DISK BASIC (Version 1.0) (1982)] and [https://winworldpc.com/download/7922cb9c-c2aa-c592-7311-c3a5c28f1352 Microsoft BASIC-80 5.26 (10-27-1983, Alphatronic; incorrectly labelled by WinWorld as CPM-80)]

[[Category:Microsoft]]

IBM 3740 format

2024-09-05T05:18:12Z

SJK:

{{FormatInfo
|formattype=physical
|subcat=Floppy disk
|released=1973
}}
The '''IBM 3740 format''' of 8" floppy disks was used in the 1970s IBM 3740 data entry system, which replaced keypunch systems that stored data on [[punched card]]s.

The disk format was single-sided, single-density, and had 73 tracks with 26 sectors storing 128 bytes per sector. The total capacity was 237.25 KB. [[FM encoding]] was used.

Although 8-inch floppies were extremely rare on IBM PCs, the physical format of IBM PC 5.25 inch and 3.5 inch floppies is directly descended from that of the IBM 3740, with various enhancements – as well as the physical shrink in the disk size, there was also the switch to double-sided, double density ([[MFM encoding]]) instead of single density ([[FM encoding]]), and support for sectors larger than 128 bytes (most IBM PC floppy controllers support any power-of-2 sector size between 128 and 4096, but the vast majority of floppies were formatted with 512 byte sectors.) This includes inheriting various obscure and rarely used IBM 3740 features, such as "deleted sectors".

[[DEC RX01]] use the same physical format as IBM 3740, and [[DEC RX02]] floppies are the same but double-density (MFM). 3740 was also the most popular recording format for CP/M.

An ASCII version of the (originally EBCDIC) IBM 3740 filesystem was standardised by ECMA as ECMA-58 and ECMA-67. While many CP/M systems, Microsoft Standalone Disk Basic, and IBM PC's copied the IBM 3740 track format (sector headers, etc), CP/M and DOS did not copy the IBM 3740 filesystem. Systems that supported the IBM 3740 filesystem included IBM mainframes and mainframe peripherals, IBM midrange systems (System/32, System/34, System/36, System/38, AS/400), IBM Series/1 minicomputer, Olivetti P6060, Nixdorf 8820 (see [https://github.com/kkaempf/nixdisk/blob/main/nixdisk.rb tool to read Nixdorf 8820 floppies]). DEC also offered a utility to read the 3740 filesystem under RSTS-11, [https://github.com/hanshuebner/rsts10/blob/main/170052/flint.bas FLINT].

== Links ==
* [[Wikipedia:IBM 3740|Wikipedia article]]
* [http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/3740/GA21-9152-2_IBM_3740_DataEntrySystem_SystemSummary_and_InstallationManual_PhysicalPlanning_Jun74.pdf Manual]
* [https://www.ibm.com/ibm/history/exhibits/rochester/rochester_4016.html IBM archives page]

[[Category:IBM]]

IBM 3740 format

2024-09-05T05:15:29Z

SJK: distinguish disk format from filesystem

{{FormatInfo
|formattype=physical
|subcat=Floppy disk
|released=1973
}}
The '''IBM 3740 format''' of 8" floppy disks was used in the 1970s IBM 3740 data entry system, which replaced keypunch systems that stored data on [[punched card]]s.

The disk format was single-sided, single-density, and had 73 tracks with 26 sectors storing 128 bytes per sector. The total capacity was 237.25 KB. [[FM encoding]] was used.

Although 8-inch floppies were extremely rare on IBM PCs, the physical format of IBM PC 5.25 inch and 3.5 inch floppies is directly descended from that of the IBM 3740, with various enhancements – as well as the physical shrink in the disk size, there was also the switch to double-sided, double density ([[MFM encoding]]) instead of single density ([[FM encoding]]), and support for sectors larger than 128 bytes (most IBM PC floppy controllers support any power-of-2 sector size between 128 and 4096, but the vast majority of floppies were formatted with 512 byte sectors.) This includes inheriting various obscure and rarely used IBM 3740 features, such as "deleted sectors".

An ASCII version of the (originally EBCDIC) IBM 3740 filesystem was standardised by ECMA as ECMA-58 and ECMA-67. While many CP/M systems, Microsoft Standalone Disk Basic, and IBM PC's copied the IBM 3740 track format (sector headers, etc), CP/M and DOS did not copy the IBM 3740 filesystem. Systems that supported the IBM 3740 filesystem included IBM mainframes and mainframe peripherals, IBM midrange systems (System/32, System/34, System/36, System/38, AS/400), IBM Series/1 minicomputer, Olivetti P6060, Nixdorf 8820 (see [https://github.com/kkaempf/nixdisk/blob/main/nixdisk.rb tool to read Nixdorf 8820 floppies]). DEC also offered a utility to read the 3740 filesystem under RSTS-11, [https://github.com/hanshuebner/rsts10/blob/main/170052/flint.bas FLINT].

== Links ==
* [[Wikipedia:IBM 3740|Wikipedia article]]
* [http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/3740/GA21-9152-2_IBM_3740_DataEntrySystem_SystemSummary_and_InstallationManual_PhysicalPlanning_Jun74.pdf Manual]
* [https://www.ibm.com/ibm/history/exhibits/rochester/rochester_4016.html IBM archives page]

[[Category:IBM]]

IBM 3740 format

2024-09-05T04:08:09Z

SJK:

MS-DOS EXE

2024-09-04T21:49:55Z

SJK: /* Extended Header */

{{FormatInfo
|formattype=electronic
|subcat=Executables
|extensions={{ext|exe}}
|pronom={{PRONOM|x-fmt/409}}
|kaitai struct=dos_mz
}}
'''MS-DOS EXE''' (or '''DOS EXE'''), also known as '''MZ''' format, is an executable file format used mainly by [[MS-DOS]]. It is the successor of [[DOS executable (.com)|COM]]. A number of other executable formats are extensions or hybrids of it; see [[EXE]] for those formats.

== Format details ==
=== Header structure ===
DOS EXE files begin with a fixed 28-byte header.

The field names in this table are taken from the IMAGE_DOS_HEADER structure defined in modern Windows SDKs. Byte order is little-endian.

{| class="wikitable"
! Offset !! Type !! Name !! Description and remarks
|-
|0 || byte[2] || e_magic || Signature - ASCII "<code>MZ</code>" or "<code>ZM</code>"
|-
|2 || uint16 || e_cblp || If nonzero, the number of bytes in the last page
|-
|4 || uint16 || e_cp || Number of 512-byte pages in the file, not counting the "overlay" segment
|-
|6 || uint16 || e_crlc || Number of relocations
|-
|8 || uint16 || e_cparhdr || Header size, in 16-byte paragraphs
|-
|10 || uint16 || e_minalloc || Minimum allocation
|-
|12 || uint16 || e_maxalloc || Maximum allocation
|-
|14 || int16 || e_ss || Initial SS register
|-
|16 || uint16 || e_sp || Initial SP register
|-
|18 || uint16 || e_csum || Checksum - Usually unused and set to 0
|-
|20 || uint16 || e_ip || Initial IP register
|-
|22 || int16 || e_cs || Initial CS register
|-
|24 || uint16 || e_lfarlc || Relocation table offset, in bytes from the start of the file
|-
|26 || uint16 || e_ovno || Overlay number (or other custom data) - Usually unused
|}

The ZM signature was used by very old versions of the Microsoft linker (from while DOS 1.0 was still under development). By the time PC-DOS 1.0 was shipped, the ZM signature was already considered obsolete. However, DOS 1.0 accepted it for backwards compatibility, and that code was retained by all future DOS versions. Windows, however, rejects ZM and only accepts MZ.

Old versions of Microsoft's development tools would calculate the checksum correctly, but DOS has always ignored it when loading EXE files. As a result, many third party tools would either calculate it using the wrong algorithm, leave it at zero or at some other fixed value. In response to this reality, Microsoft eventually gave up and stopped setting it in their own build tools too (in Microsoft LINK 5.3, which corresponds to Microsoft C/C++ 7.0, which came out in the early 1990s). Hence, while in 1980s era executables it is commonly set, executables from the 1990s onwards it is likely zero. (see also [https://entropymine.wordpress.com/2023/09/27/the-exe-checksum-field/ blog post with detailed analysis of checksum])

==== Extended Header ====
DOS executables don't always contain these additional fields, but Windows and OS/2 executables always do:

{| class="wikitable"
! Offset !! Type !! Name !! Description and remarks
|-
|28 || byte[8] || e_res || Reserved bytes
|-
|36 || uint16 || e_oemid || OEM identifier (rarely used)
|-
|38 || uint16 || e_oeminfo || OEM information (rarely used, meaning depends on OEM identifier)
|-
|40 || byte[20] || e_res2 || Reserved bytes
|-
|60 || uint32 || e_lfanew || File offset of new format executable header (NE, LE, LX or PE)
|}

The extended header only exists if <code>e_lfarlc</code> is greater than 28 (0x1C); some MZ executables have the relocation table starting at offset 28 and the extended header is absent. Note however that some tools which handle newer executable formats (NE/LE/LX/PE/etc) ignore <code>e_lfarlc</code> and always test the validity of the <code>e_lfanew</code> offset. In particular, although NT-based Windows requires all executables and DLLs to start with an MZ header, it only actually checks the signature and the <code>e_lfanew</code> field, and the rest can all be zeroed. Such an executable obviously will not work under DOS.

There is some conflicting information on the purpose of the start of the <code>eres</code> field, offset 28 or 0x1C:
* [https://wiki.osdev.org/MZ OSDev Wiki] claims this is "Overlay information" and that "Files sometimes contain extra information for the main's program overlay management"
* The file [https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/DOSSYM.ASM#L585 DOSSYM.ASM] in the open sourced MS-DOS 2.0 source code claims this is a 4 byte field called "exe_sym_tab" with comment "offset of symbol table in file". It also contains a [https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/DOSSYM.ASM#L591 symbol_entry] structure definition which is likely the contents of the table. The same definitions occur in the open source MS-DOS 4.0 source code, moved to a different file ([https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/INC/EXE.INC#L67 EXE.INC]). However, this field is not used anywhere in the open source DOS source code; it is unknown whether any Microsoft tools stored a symbol table offset in this field or if any executables survive with one set. Later DOS era Microsoft tooling stored the symbol table in a "CodeView trailer" at end of the executable, so if this mechanism was ever used at all, it is likely to have only been in the early-to-mid 1980s.
* [https://www.ctyme.com/intr/rb-2939.htm#Table1594 Ralf Brown Interrupt List Table 1594] reports various uses for this field, including signatures for EXE packers. Under New Executable format, it mentions a 16-bit field "behavior bits" at offset 0x20 but there is limited information available on what that means (possibly used by multitasking MS-DOS 4.0; speculatively, may have stored some of the information that later ended up in PIF files, until MS worked out there was too much config required to just add it to the EXE). It also reports that Borland TLINK puts the bytes 0x01 0x00 in the field at offset 0x1C; however, some executables shipped with MS-DOS have those bytes there as well, suggesting that whatever that means, it might not be unique to Borland, since that implies Microsoft tooling sometimes generates those bytes as well.

=== Special file positions ===
When analyzing DOS EXE files, especially [[Executable envelopes|"envelope" formats]], it can be helpful to calculate certain special file positions. The positions given here are in bytes, from the start of the file.

* ''End of relocation table'': e_lfarlc + 4×e_crlc
* ''Start of code image segment'': 16×e_cparhdr
* ''Execution starting point'' (a.k.a. ''entry point''): 16×e_cparhdr + 16×e_cs + e_ip. Note that e_cs may be negative.
* ''Start of overlay segment'' (or ''end of code image segment''): If e_cblp=0, this is 512×e_cp. Otherwise, 512×(e_cp−1) + e_cblp.

== Identification ==
See [[EXE#Identification]] for EXE format in general.

It's not clear if there is any completely reliable way to identify a file as strictly DOS EXE, except in the negative (i.e., it looks like EXE, and is not a valid [[NE]], [[PE]], etc., file).

If the relocation table offset is from 28 to 63, or any segment (relocation table or code image) overlaps the four bytes starting at offset 60, it is pretty certainly DOS EXE.

Most non-DOS EXE files set the relocation table offset to 64, but it's probably not safe to rely on that.

== Sample files ==
* {{DexvertSamples|executable/exe}}

== Links ==
* [[Wikipedia:DOS MZ executable|Wikipedia article]]
* [http://wiki.osdev.org/MZ MZ], from the OSDev Wiki
* http://www.delorie.com/djgpp/doc/exe/
* [http://www.textfiles.com/programming/FORMATS/exefs.pro DOS EXE format]
* [http://www.mitec.cz/exe.html EXE Explorer utility]
* [http://www.ctyme.com/intr/rb-2939.htm Ralf Brown's Interrupt Reference] has an extensive list of (mostly older) MZ-based executable formats

[[Category:Microsoft]]
[[Category:MS-DOS]]

MS-DOS EXE

2024-09-04T21:45:12Z

SJK: /* Extended Header */

{{FormatInfo
|formattype=electronic
|subcat=Executables
|extensions={{ext|exe}}
|pronom={{PRONOM|x-fmt/409}}
|kaitai struct=dos_mz
}}
'''MS-DOS EXE''' (or '''DOS EXE'''), also known as '''MZ''' format, is an executable file format used mainly by [[MS-DOS]]. It is the successor of [[DOS executable (.com)|COM]]. A number of other executable formats are extensions or hybrids of it; see [[EXE]] for those formats.

== Format details ==
=== Header structure ===
DOS EXE files begin with a fixed 28-byte header.

The field names in this table are taken from the IMAGE_DOS_HEADER structure defined in modern Windows SDKs. Byte order is little-endian.

{| class="wikitable"
! Offset !! Type !! Name !! Description and remarks
|-
|0 || byte[2] || e_magic || Signature - ASCII "<code>MZ</code>" or "<code>ZM</code>"
|-
|2 || uint16 || e_cblp || If nonzero, the number of bytes in the last page
|-
|4 || uint16 || e_cp || Number of 512-byte pages in the file, not counting the "overlay" segment
|-
|6 || uint16 || e_crlc || Number of relocations
|-
|8 || uint16 || e_cparhdr || Header size, in 16-byte paragraphs
|-
|10 || uint16 || e_minalloc || Minimum allocation
|-
|12 || uint16 || e_maxalloc || Maximum allocation
|-
|14 || int16 || e_ss || Initial SS register
|-
|16 || uint16 || e_sp || Initial SP register
|-
|18 || uint16 || e_csum || Checksum - Usually unused and set to 0
|-
|20 || uint16 || e_ip || Initial IP register
|-
|22 || int16 || e_cs || Initial CS register
|-
|24 || uint16 || e_lfarlc || Relocation table offset, in bytes from the start of the file
|-
|26 || uint16 || e_ovno || Overlay number (or other custom data) - Usually unused
|}

The ZM signature was used by very old versions of the Microsoft linker (from while DOS 1.0 was still under development). By the time PC-DOS 1.0 was shipped, the ZM signature was already considered obsolete. However, DOS 1.0 accepted it for backwards compatibility, and that code was retained by all future DOS versions. Windows, however, rejects ZM and only accepts MZ.

Old versions of Microsoft's development tools would calculate the checksum correctly, but DOS has always ignored it when loading EXE files. As a result, many third party tools would either calculate it using the wrong algorithm, leave it at zero or at some other fixed value. In response to this reality, Microsoft eventually gave up and stopped setting it in their own build tools too (in Microsoft LINK 5.3, which corresponds to Microsoft C/C++ 7.0, which came out in the early 1990s). Hence, while in 1980s era executables it is commonly set, executables from the 1990s onwards it is likely zero. (see also [https://entropymine.wordpress.com/2023/09/27/the-exe-checksum-field/ blog post with detailed analysis of checksum])

==== Extended Header ====
DOS executables don't always contain these additional fields, but Windows and OS/2 executables always do:

{| class="wikitable"
! Offset !! Type !! Name !! Description and remarks
|-
|28 || byte[8] || e_res || Reserved bytes
|-
|36 || uint16 || e_oemid || OEM identifier (rarely used)
|-
|38 || uint16 || e_oeminfo || OEM information (rarely used, meaning depends on OEM identifier)
|-
|40 || byte[20] || e_res2 || Reserved bytes
|-
|60 || uint32 || e_lfanew || File offset of new format executable header (NE, LE, LX or PE)
|}

The extended header only exists if <code>e_lfarlc</code> is greater than 28 (0x1C); some MZ executables have the relocation table starting at offset 28 and the extended header is absent. Note however that some tools which handle newer executable formats (NE/LE/LX/PE/etc) ignore <code>e_lfarlc</code> and always test the validity of the <code>e_lfanew</code> offset. In particular, although NT-based Windows requires all executables and DLLs to start with an MZ header, it only actually checks the signature and the <code>e_lfanew</code> field, and the rest can all be zeroed. Such an executable obviously will not work under DOS.

There is some conflicting information on the purpose of the start of the <code>eres</code> field, offset 28 or 0x1C:
* [https://wiki.osdev.org/MZ OSDev Wiki] claims this is "Overlay information" and that "Files sometimes contain extra information for the main's program overlay management"
* The file [https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/DOSSYM.ASM#L585 DOSSYM.ASM] in the open sourced MS-DOS 2.0 source code claims this is a 4 byte field called "exe_sym_tab" with comment "offset of symbol table in file". It also contains a [https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/DOSSYM.ASM#L591 symbol_entry] structure definition which is likely the contents of the table. The same definitions occur in the open source MS-DOS 4.0 source code, moved to a different file ([https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/INC/EXE.INC#L67 EXE.INC]). However, this field is not used anywhere in the open source DOS source code; it is unknown whether any Microsoft tools stored a symbol table offset in this field or if any executables survive with one set. Later DOS era Microsoft tooling stored the symbol table in a "CodeView trailer" at end of the executable, so if this mechanism was ever used at all, it is likely to have only been in the early-to-mid 1980s.
* [https://www.ctyme.com/intr/rb-2939.htm#Table1594 Ralf Brown Interrupt List Table 1594] reports various uses for this field, including signatures for EXE packers. Under New Executable format, it mentions a 16-bit field "behavior bits" at offset 0x20 but there is limited information available on what that means (possibly used by multitasking MS-DOS 4.0). It also reports that Borland TLINK puts the bytes 0x01 0x00 in the field at offset 0x1C; however, some executables shipped with MS-DOS have those bytes there as well, suggesting that whatever that means, it might not be unique to Borland, since that implies Microsoft tooling sometimes generates those bytes as well.

=== Special file positions ===
When analyzing DOS EXE files, especially [[Executable envelopes|"envelope" formats]], it can be helpful to calculate certain special file positions. The positions given here are in bytes, from the start of the file.

* ''End of relocation table'': e_lfarlc + 4×e_crlc
* ''Start of code image segment'': 16×e_cparhdr
* ''Execution starting point'' (a.k.a. ''entry point''): 16×e_cparhdr + 16×e_cs + e_ip. Note that e_cs may be negative.
* ''Start of overlay segment'' (or ''end of code image segment''): If e_cblp=0, this is 512×e_cp. Otherwise, 512×(e_cp−1) + e_cblp.

== Identification ==
See [[EXE#Identification]] for EXE format in general.

It's not clear if there is any completely reliable way to identify a file as strictly DOS EXE, except in the negative (i.e., it looks like EXE, and is not a valid [[NE]], [[PE]], etc., file).

If the relocation table offset is from 28 to 63, or any segment (relocation table or code image) overlaps the four bytes starting at offset 60, it is pretty certainly DOS EXE.

Most non-DOS EXE files set the relocation table offset to 64, but it's probably not safe to rely on that.

== Sample files ==
* {{DexvertSamples|executable/exe}}

== Links ==
* [[Wikipedia:DOS MZ executable|Wikipedia article]]
* [http://wiki.osdev.org/MZ MZ], from the OSDev Wiki
* http://www.delorie.com/djgpp/doc/exe/
* [http://www.textfiles.com/programming/FORMATS/exefs.pro DOS EXE format]
* [http://www.mitec.cz/exe.html EXE Explorer utility]
* [http://www.ctyme.com/intr/rb-2939.htm Ralf Brown's Interrupt Reference] has an extensive list of (mostly older) MZ-based executable formats

[[Category:Microsoft]]
[[Category:MS-DOS]]

MS-DOS EXE

2024-09-04T21:22:39Z

SJK: /* Format details */

{{FormatInfo
|formattype=electronic
|subcat=Executables
|extensions={{ext|exe}}
|pronom={{PRONOM|x-fmt/409}}
|kaitai struct=dos_mz
}}
'''MS-DOS EXE''' (or '''DOS EXE'''), also known as '''MZ''' format, is an executable file format used mainly by [[MS-DOS]]. It is the successor of [[DOS executable (.com)|COM]]. A number of other executable formats are extensions or hybrids of it; see [[EXE]] for those formats.

== Format details ==
=== Header structure ===
DOS EXE files begin with a fixed 28-byte header.

The field names in this table are taken from the IMAGE_DOS_HEADER structure defined in modern Windows SDKs. Byte order is little-endian.

{| class="wikitable"
! Offset !! Type !! Name !! Description and remarks
|-
|0 || byte[2] || e_magic || Signature - ASCII "<code>MZ</code>" or "<code>ZM</code>"
|-
|2 || uint16 || e_cblp || If nonzero, the number of bytes in the last page
|-
|4 || uint16 || e_cp || Number of 512-byte pages in the file, not counting the "overlay" segment
|-
|6 || uint16 || e_crlc || Number of relocations
|-
|8 || uint16 || e_cparhdr || Header size, in 16-byte paragraphs
|-
|10 || uint16 || e_minalloc || Minimum allocation
|-
|12 || uint16 || e_maxalloc || Maximum allocation
|-
|14 || int16 || e_ss || Initial SS register
|-
|16 || uint16 || e_sp || Initial SP register
|-
|18 || uint16 || e_csum || Checksum - Usually unused and set to 0
|-
|20 || uint16 || e_ip || Initial IP register
|-
|22 || int16 || e_cs || Initial CS register
|-
|24 || uint16 || e_lfarlc || Relocation table offset, in bytes from the start of the file
|-
|26 || uint16 || e_ovno || Overlay number (or other custom data) - Usually unused
|}

The ZM signature was used by very old versions of the Microsoft linker (from while DOS 1.0 was still under development). By the time PC-DOS 1.0 was shipped, the ZM signature was already considered obsolete. However, DOS 1.0 accepted it for backwards compatibility, and that code was retained by all future DOS versions. Windows, however, rejects ZM and only accepts MZ.

Old versions of Microsoft's development tools would calculate the checksum correctly, but DOS has always ignored it when loading EXE files. As a result, many third party tools would either calculate it using the wrong algorithm, leave it at zero or at some other fixed value. In response to this reality, Microsoft eventually gave up and stopped setting it in their own build tools too (in Microsoft LINK 5.3, which corresponds to Microsoft C/C++ 7.0, which came out in the early 1990s). Hence, while in 1980s era executables it is commonly set, executables from the 1990s onwards it is likely zero. (see also [https://entropymine.wordpress.com/2023/09/27/the-exe-checksum-field/ blog post with detailed analysis of checksum])

==== Extended Header ====
DOS executables don't always contain these additional fields, but Windows and OS/2 executables always do:

{| class="wikitable"
! Offset !! Type !! Name !! Description and remarks
|-
|28 || byte[8] || e_res || Reserved bytes
|-
|36 || uint16 || e_oemid || OEM identifier (rarely used)
|-
|38 || uint16 || e_oeminfo || OEM information (rarely used, meaning depends on OEM identifier)
|-
|40 || byte[20] || e_res2 || Reserved bytes
|-
|60 || uint32 || e_lfanew || File offset of new format executable header (NE, LE, LX or PE)
|}

The extended header only exists if <code>e_lfarlc</code> is greater than 28 (0x1C); some MZ executables have the relocation table starting at offset 28 and the extended header is absent. Note however that some tools which handle newer executable formats (NE/LE/LX/PE/etc) ignore <code>e_lfarlc</code> and always test the validity of the <code>e_lfanew</code> offset. In particular, although NT-based Windows requires all executables and DLLs to start with an MZ header, it only actually checks the signature and the <code>e_lfanew</code> field, and the rest can all be zeroed. Such an executable obviously will not work under DOS.

There is some conflicting information on the purpose of the start of the <code>eres</code> field, offset 28 or 0x1C:
* [https://wiki.osdev.org/MZ OSDev Wiki] claims this is "Overlay information" and that "Files sometimes contain extra information for the main's program overlay management"
* The file [https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/DOSSYM.ASM#L585 DOSSYM.ASM] in the open sourced MS-DOS 2.0 source code claims this is a 4 byte field called "exe_sym_tab" with comment "offset of symbol table in file". It also contains a [https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/DOSSYM.ASM#L591 symbol_entry] structure definition which is likely the contents of the table. The same definitions occur in the open source MS-DOS 4.0 source code, moved to a different file ([https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/INC/EXE.INC#L67 EXE.INC]). However, this field is not used anywhere in the open source DOS source code; it is unknown whether any Microsoft tools stored a symbol table offset in this field or if any executables survive with one set. Later DOS era Microsoft tooling stored the symbol table in a "CodeView trailer" at end of the executable, so if this mechanism was ever used at all, it is likely to have only been in the early-to-mid 1980s.
* [https://www.ctyme.com/intr/rb-2939.htm#Table1594 Ralf Brown Interrupt List Table 1594] reports various uses for this field, including signatures for EXE packers. Under New Executable format, it mentions a 16-bit field "behavior bits" at offset 0x20 but there is a lack of information available on what that means. It also reports that Borland TLINK puts the bytes 0x01 0x00 in the field at offset 0x1C; however, some executables shipped with MS-DOS have those bytes there as well, suggesting that whatever that means, it might not be unique to Borland, since that implies Microsoft tooling sometimes generates those bytes as well.

=== Special file positions ===
When analyzing DOS EXE files, especially [[Executable envelopes|"envelope" formats]], it can be helpful to calculate certain special file positions. The positions given here are in bytes, from the start of the file.

* ''End of relocation table'': e_lfarlc + 4×e_crlc
* ''Start of code image segment'': 16×e_cparhdr
* ''Execution starting point'' (a.k.a. ''entry point''): 16×e_cparhdr + 16×e_cs + e_ip. Note that e_cs may be negative.
* ''Start of overlay segment'' (or ''end of code image segment''): If e_cblp=0, this is 512×e_cp. Otherwise, 512×(e_cp−1) + e_cblp.

== Identification ==
See [[EXE#Identification]] for EXE format in general.

It's not clear if there is any completely reliable way to identify a file as strictly DOS EXE, except in the negative (i.e., it looks like EXE, and is not a valid [[NE]], [[PE]], etc., file).

If the relocation table offset is from 28 to 63, or any segment (relocation table or code image) overlaps the four bytes starting at offset 60, it is pretty certainly DOS EXE.

Most non-DOS EXE files set the relocation table offset to 64, but it's probably not safe to rely on that.

== Sample files ==
* {{DexvertSamples|executable/exe}}

== Links ==
* [[Wikipedia:DOS MZ executable|Wikipedia article]]
* [http://wiki.osdev.org/MZ MZ], from the OSDev Wiki
* http://www.delorie.com/djgpp/doc/exe/
* [http://www.textfiles.com/programming/FORMATS/exefs.pro DOS EXE format]
* [http://www.mitec.cz/exe.html EXE Explorer utility]
* [http://www.ctyme.com/intr/rb-2939.htm Ralf Brown's Interrupt Reference] has an extensive list of (mostly older) MZ-based executable formats

[[Category:Microsoft]]
[[Category:MS-DOS]]

EXE

2024-09-04T21:21:21Z

SJK: /* Unrelated usage */

{{FormatInfo
|formattype=electronic
|subcat=Executables
|extensions={{ext|exe}}
}}
'''EXE''' most commonly refers to a family of executable file formats. It includes the original [[MS-DOS EXE]] format, and a number of newer formats built on top of that format. Most of them use the same '''.exe''' file extension.

Although all members of the EXE family have a file signature of "MZ", it seems that the term "MZ format" is generally used to mean only [[MS-DOS EXE]] (i.e. files designed for MS-DOS).

EXE files designed for operating systems other than MS-DOS usually contain a short program (called a DOS stub) which, when executed by DOS, prints a message like "This program cannot be run in DOS mode" or "This program requires Microsoft Windows", and immediately exits. Some programs contain a more functional DOS stub, e.g. the Windows 9x registry editor.

== Unrelated usage ==

Note .EXE is also used as an executable extension on some other operating systems, such as OpenVMS, TOPS-10, TOPS-20, RSX-11, etc. The file formats used by those operating systems are completely unrelated to those used by MS-DOS/PC-DOS and its descendants (OS/2, Windows, EFI, etc.) However, historically speaking, that's likely where Microsoft got the .EXE file extension from (early in Microsoft's history, they used TOPS-10 as a hosted cross-development environment for their microcomputer products, before switching to their own Unix distribution, Xenix, on PDP-11s.)

OpenVMS VAX and Alpha used their own proprietary executable format; GNU binutils [https://github.com/bminor/binutils-gdb/blob/master/include/vms/eihd.h has some knowledge of it] (at least the Alpha version, which was based on the VAX version but with some incompatible changes). .EXE files on OpenVMS Itanium and x86-64 are in ELF format.

== Formats ==
This is an incomplete outline of the EXE family of formats.
* '''EXE'''
** [[MS-DOS EXE]]
** [[NE]] (New Executable, 16-bit)
** [[Linear Executable]]
*** '''LE''' (mixed 16/32-bit)
*** '''LX''' (32-bit)
** [[PE]] (Portable Executable)
*** '''PE32''' (32-bit Windows)
*** '''PE32+''' (64-bit Windows)

== Identification ==
All EXE formats start with ASCII signature "{{magic|MZ}}" or, rarely, "{{magic|ZM}}".

The byte at offset 3 ''should'' be <code>0x00</code> or <code>0x01</code>, as it is the high byte of a field whose valid values are 0 through 511. However, EXE files for which this is not the case do exist, and may be tolerated by the OS.

The starting point for identifying extended formats is the field at offset 60, which if present, points to an extended header.

== Sample files ==
* {{DexvertSamples|executable/exe}}

== Links ==
* [http://www.ctyme.com/intr/rb-2939.htm Ralf Brown's Interrupt List], INT 21h, Function 4Bh, describes lots of the "older" style EXE formats
* [http://www.mitec.cz/exe.html EXE Explorer utility]

See also the articles for the specific EXE formats.

[[Category:Microsoft]]

MS-DOS EXE

2024-09-04T21:12:02Z

SJK: /* Extended Header */

{{FormatInfo
|formattype=electronic
|subcat=Executables
|extensions={{ext|exe}}
|pronom={{PRONOM|x-fmt/409}}
|kaitai struct=dos_mz
}}
'''MS-DOS EXE''' (or '''DOS EXE'''), also known as '''MZ''' format, is an executable file format used mainly by [[MS-DOS]]. It is the successor of [[DOS executable (.com)|COM]]. A number of other executable formats are extensions or hybrids of it; see [[EXE]] for those formats.

== Format details ==
=== Header structure ===
DOS EXE files begin with a fixed 28-byte header.

The field names in this table are taken from the IMAGE_DOS_HEADER structure defined in modern Windows SDKs. Byte order is little-endian.

{| class="wikitable"
! Offset !! Type !! Name !! Description and remarks
|-
|0 || byte[2] || e_magic || Signature - ASCII "<code>MZ</code>" or "<code>ZM</code>"
|-
|2 || uint16 || e_cblp || If nonzero, the number of bytes in the last page
|-
|4 || uint16 || e_cp || Number of 512-byte pages in the file, not counting the "overlay" segment
|-
|6 || uint16 || e_crlc || Number of relocations
|-
|8 || uint16 || e_cparhdr || Header size, in 16-byte paragraphs
|-
|10 || uint16 || e_minalloc || Minimum allocation
|-
|12 || uint16 || e_maxalloc || Maximum allocation
|-
|14 || int16 || e_ss || Initial SS register
|-
|16 || uint16 || e_sp || Initial SP register
|-
|18 || uint16 || e_csum || Checksum - Usually unused and set to 0
|-
|20 || uint16 || e_ip || Initial IP register
|-
|22 || int16 || e_cs || Initial CS register
|-
|24 || uint16 || e_lfarlc || Relocation table offset, in bytes from the start of the file
|-
|26 || uint16 || e_ovno || Overlay number (or other custom data) - Usually unused
|}

The ZM signature was used by very old versions of the Microsoft linker (from while DOS 1.0 was still under development). By the time PC-DOS 1.0 was shipped, the ZM signature was already considered obsolete. However, DOS 1.0 accepted it for backwards compatibility, and that code was retained by all future DOS versions. Windows, however, rejects ZM and only accepts MZ.

Old versions of Microsoft's development tools would calculate the checksum correctly, but DOS has always ignored it when loading EXE files. As a result, many third party tools would either calculate it using the wrong algorithm, leave it at zero or at some other fixed value. In response to this reality, Microsoft eventually gave up and stopped setting it in their own build tools either (in Microsoft LINK 5.3, which corresponds to Microsoft C/C++ 7.0, which came out in the early 1990s). Hence, while in 1980s era executables it is commonly set, executables from the 1990s onwards it is likely zero. (see also [https://entropymine.wordpress.com/2023/09/27/the-exe-checksum-field/ blog post with detailed analysis of checksum])

==== Extended Header ====
DOS executables don't always contain these additional fields, but Windows and OS/2 executables always do:

{| class="wikitable"
! Offset !! Type !! Name !! Description and remarks
|-
|28 || byte[8] || e_res || Reserved bytes
|-
|36 || uint16 || e_oemid || OEM identifier (rarely used)
|-
|38 || uint16 || e_oeminfo || OEM information (rarely used, meaning depends on OEM identifier)
|-
|40 || byte[20] || e_res2 || Reserved bytes
|-
|60 || uint32 || e_lfanew || File offset of new format executable header (NE, LE, LX or PE)
|}

The extended header only exists if <code>e_lfarlc</code> is greater than 28 (0x1C); some MZ executables have the relocation table starting at offset 28 and the extended header is absent. Note however that some tools which handle newer executable formats (NE/LE/LX/PE/etc) ignore <code>e_lfarlc</code> and always test the validity of the <code>e_lfanew</code> offset. In particular, although NT-based Windows requires all executables and DLLs to start with an MZ header, it only actually checks the signature and the <code>e_lfanew</code> field, and the rest can all be zeroed. Such an executable obviously will not work under DOS.

There is some conflicting information on the purpose of the start of the <code>eres</code> field, offset 28 or 0x1C:
* [https://wiki.osdev.org/MZ OSDev Wiki] claims this is "Overlay information" and that "Files sometimes contain extra information for the main's program overlay management"
* The file [https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/DOSSYM.ASM#L585 DOSSYM.ASM] in the open sourced MS-DOS 2.0 source code claims this is a 4 byte field called "exe_sym_tab" with comment "offset of symbol table in file". It also contains a [https://github.com/microsoft/MS-DOS/blob/main/v2.0/source/DOSSYM.ASM#L591 symbol_entry] structure definition which is likely the contents of the table. The same definitions occur in the open source MS-DOS 4.0 source code, moved to a different file ([https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/INC/EXE.INC#L67 EXE.INC]). However, this field is not used anywhere in the open source DOS source code; it is unknown whether any Microsoft tools stored a symbol table offset in this field or if any executables survive with one set. Later DOS era Microsoft tooling stored the symbol table in a "CodeView trailer" at end of the executable, so if this mechanism was ever used at all, it is likely to have only been in the early-to-mid 1980s.
* [https://www.ctyme.com/intr/rb-2939.htm#Table1594 Ralf Brown Interrupt List Table 1594] reports various uses for this field, including signatures for EXE packers. Under New Executable format, it mentions a 16-bit field "behavior bits" at offset 0x20 but there is a lack of information available on what that means. It also reports that Borland TLINK puts the bytes 0x01 0x00 in the field at offset 0x1C; however, some executables shipped with MS-DOS have those bytes there as well, suggesting that whatever that means, it might not be unique to Borland, since that implies Microsoft tooling sometimes generates those bytes as well.

=== Special file positions ===
When analyzing DOS EXE files, especially [[Executable envelopes|"envelope" formats]], it can be helpful to calculate certain special file positions. The positions given here are in bytes, from the start of the file.

* ''End of relocation table'': e_lfarlc + 4×e_crlc
* ''Start of code image segment'': 16×e_cparhdr
* ''Execution starting point'' (a.k.a. ''entry point''): 16×e_cparhdr + 16×e_cs + e_ip. Note that e_cs may be negative.
* ''Start of overlay segment'' (or ''end of code image segment''): If e_cblp=0, this is 512×e_cp. Otherwise, 512×(e_cp−1) + e_cblp.

== Identification ==
See [[EXE#Identification]] for EXE format in general.

It's not clear if there is any completely reliable way to identify a file as strictly DOS EXE, except in the negative (i.e., it looks like EXE, and is not a valid [[NE]], [[PE]], etc., file).

If the relocation table offset is from 28 to 63, or any segment (relocation table or code image) overlaps the four bytes starting at offset 60, it is pretty certainly DOS EXE.

Most non-DOS EXE files set the relocation table offset to 64, but it's probably not safe to rely on that.

== Sample files ==
* {{DexvertSamples|executable/exe}}

== Links ==
* [[Wikipedia:DOS MZ executable|Wikipedia article]]
* [http://wiki.osdev.org/MZ MZ], from the OSDev Wiki
* http://www.delorie.com/djgpp/doc/exe/
* [http://www.textfiles.com/programming/FORMATS/exefs.pro DOS EXE format]
* [http://www.mitec.cz/exe.html EXE Explorer utility]
* [http://www.ctyme.com/intr/rb-2939.htm Ralf Brown's Interrupt Reference] has an extensive list of (mostly older) MZ-based executable formats

[[Category:Microsoft]]
[[Category:MS-DOS]]

MS-DOS EXE

2024-09-04T12:53:49Z

SJK: /* Header structure */

MS-DOS EXE

2024-09-04T12:52:40Z

SJK: /* Header structure */

MS-DOS EXE

2024-09-04T12:50:07Z

SJK: /* Header structure */

MS-DOS EXE

2024-09-04T12:30:20Z

SJK: /* Extended Header */

EXE

2024-09-03T22:30:25Z

SJK:

{{FormatInfo
|formattype=electronic
|subcat=Executables
|extensions={{ext|exe}}
}}
'''EXE''' most commonly refers to a family of executable file formats. It includes the original [[MS-DOS EXE]] format, and a number of newer formats built on top of that format. Most of them use the same '''.exe''' file extension.

Although all members of the EXE family have a file signature of "MZ", it seems that the term "MZ format" is generally used to mean only [[MS-DOS EXE]] (i.e. files designed for MS-DOS).

EXE files designed for operating systems other than MS-DOS usually contain a short program (called a DOS stub) which, when executed by DOS, prints a message like "This program cannot be run in DOS mode" or "This program requires Microsoft Windows", and immediately exits. Some programs contain a more functional DOS stub, e.g. the Windows 9x registry editor.

== Unrelated usage ==

Note .EXE is also used as an executable extension on some other operating systems, such as OpenVMS, TOPS-10, TOPS-20, RSX-11, etc. The file formats used by those operating systems are completely unrelated to those used by MS-DOS/PC-DOS and its descendants (OS/2, Windows, EFI, etc.) However, historically speaking, that's likely where Microsoft got the .EXE file extension from (early in Microsoft's history, they used TOPS-10 as a hosted cross-development environment for their microcomputer products, before switching to their own Unix distribution, Xenix, on PDP-11s.)

== Formats ==
This is an incomplete outline of the EXE family of formats.
* '''EXE'''
** [[MS-DOS EXE]]
** [[NE]] (New Executable, 16-bit)
** [[Linear Executable]]
*** '''LE''' (mixed 16/32-bit)
*** '''LX''' (32-bit)
** [[PE]] (Portable Executable)
*** '''PE32''' (32-bit Windows)
*** '''PE32+''' (64-bit Windows)

== Identification ==
All EXE formats start with ASCII signature "{{magic|MZ}}" or, rarely, "{{magic|ZM}}".

The byte at offset 3 ''should'' be <code>0x00</code> or <code>0x01</code>, as it is the high byte of a field whose valid values are 0 through 511. However, EXE files for which this is not the case do exist, and may be tolerated by the OS.

The starting point for identifying extended formats is the field at offset 60, which if present, points to an extended header.

== Sample files ==
* {{DexvertSamples|executable/exe}}

== Links ==
* [http://www.ctyme.com/intr/rb-2939.htm Ralf Brown's Interrupt List], INT 21h, Function 4Bh, describes lots of the "older" style EXE formats
* [http://www.mitec.cz/exe.html EXE Explorer utility]

See also the articles for the specific EXE formats.

[[Category:Microsoft]]

MS-DOS EXE

2024-09-03T21:55:41Z

SJK: /* Format details */

User talk:MihaiPopa7

2024-08-29T11:04:00Z

SJK: /* The password to post links */ new section

can you be more specific about how your trick to bypass captcha works?

Sure. When you put a link on a page (like file samples), do with the HTTPS template, in an new tab, put Template:HTTPS and make a small edit (like httpa instead of https), save it and the page you're working on. Then undo the edit to Template:HTTPS. Problem solved!

How would you handle archive.org links like web.archive.org/web/20160324030807/hxxp://nibblemagazine.com/KeyPerfect2.0.dsk ? (replace 'hxxp' with 'http') The embedded link ends up getting caught.

edit: was able to get around it by omitting the http part inside the archive.org link

edit 2: was able to get a response from wiki@textfiles.com by using a different account. Try from a different provider (like gmail)

==Section==

Here's my talk page!

You can write anything on this page!

On a new section or on this section!

[[User:MihaiPopa7|MihaiPopa7]] ([[User talk:MihaiPopa7|talk]]) 03:24, 31 October 2023 (UTC)

== The password to post links ==

I emailed wiki@texfiles.com and Jason Scott gave me the password. I can't share it here because that would defeat the whole purpose of it. But if you aren't able to email him to ask for it, you could try sending him a DM via his [https://twitter.com/textfiles Twitter/X account] (assuming you have an account with that or are willing to sign up for one). His pinned tweet also provides details of his Mastodon and IRC accounts if those are an option for you. [[User:SJK|SJK]] ([[User talk:SJK|talk]]) 11:04, 29 August 2024 (UTC)

Category:File formats with extension .tlb

2024-08-29T10:58:58Z

SJK: Created page with "T"

[[Category:File formats by extension|T]]

Microsoft Type Library

2024-08-29T10:58:34Z

SJK: Created page with "{{FormatInfo |subcat=Development |extensions={{ext|tlb}} }} '''Microsoft Type Library''' (TLB) files store metadata on COM (Component Object Model) APIs (interfaces, methods, ..."

{{FormatInfo
|subcat=Development
|extensions={{ext|tlb}}
}}
'''Microsoft Type Library''' (TLB) files store metadata on COM (Component Object Model) APIs (interfaces, methods, data types, etc).

There are two main formats:
* the "original format" – file starts with the bytes "SLTG". [https://www.nationalarchives.gov.uk/PRONOM/fmt/1601 PRONOM format 1601]. Additionally, the string "TYPELIB" occurs near the end of the file.
* the "new format" – file starts with the bytes "MSFT", normally followed by the bytes 02,00,01,00 (which might be a version number) [https://www.nationalarchives.gov.uk/PRONOM/fmt/1602 PRONOM format 1602]
(PRONOM claims the TLB format is due to Borland, but that appears to be an error.)

Additionally, you will also find .TLB files which are actually in Windows PE format, and have a type library embedded as a resource. Rarely you may even encounter .TLB files for 16-bit Windows OLE which have a type library resource inside NE format.

The MSFT format is generated by the Windows [https://learn.microsoft.com/en-us/windows/win32/api/oleauto/nf-oleauto-createtypelib2 CreateTypeLib2] API. Conversely, the older SLTG format is generated by the Windows [https://learn.microsoft.com/en-us/windows/win32/api/oleauto/nf-oleauto-createtypelib CreateTypeLib] API.

== Links ==

*[https://gist.github.com/djhohnstein/e4a346ee1506895000ca0fa93e5a0024 MSFT format reverse-engineered documentation]. The original of that document is posted [http://theircorp.byethost11.com/files/TypeLib.txt here], but that version displays incorrectly due to a character encoding issue.

[[Category:Windows]]

IBM 3363 Optical WORM

2024-08-25T21:21:12Z

SJK:

{{FormatInfo
|formattype=physical
|subcat=Optical Discs
|released=1987 (?)
}}
'''IBM 3363 Optical WORM''' discs were a predecessor to CD-Rs.

200MB capacity, 512 byte sectors, custom filesystem.

Sectors could be written once but thereafter could not be modified. However, sectors could be deleted after writing, but deleted sectors could not be undeleted or reused.

* [http://www.mcamafia.de/pdf/3363_trm.pdf IBM Technical Reference Manual (1987)]

IBM 3363 Optical WORM

2024-08-25T18:40:02Z

SJK:

IBM 3363 Optical WORM

2024-08-25T18:39:37Z

SJK: Created page with "{{FormatInfo |formattype=physical |subcat=Optical Discs |thiscat=IBM 3363 |released=1987 (?) }} '''IBM 3363 Optical WORM''' discs were a predecessor to CD-Rs. 200MB capacity,..."

{{FormatInfo
|formattype=physical
|subcat=Optical Discs
|thiscat=IBM 3363
|released=1987 (?)
}}
'''IBM 3363 Optical WORM''' discs were a predecessor to CD-Rs.

200MB capacity, 512 byte sectors, custom filesystem.

Sectors could be written once but thereafter could not be modified. However, sectors could be deleted after writing, but deleted sectors could not be undeleted or reused.

Optical Discs

2024-08-25T18:33:34Z

SJK: /* List of formats */ mention IBM 3363 Optical WORM

{{FormatInfo
|formattype=physical
|thiscat=Optical Discs
|image=Optical-discs.jpg
|caption=Some CDs and DVDs
}}

An '''optical disc''' is read by a laser. They have been used extensively to store and distribute music, movies, and computer programs and data. CD drives became commonplace in personal computers in the mid-1990s, and burners to create CD-ROMs on personal computers were common by the early 2000s. Later, the higher-capacity DVD format became common both for reading and writing as well, and the even newer BluRay format won a "format war" against rival HD-DVD to get some popularity at present, though physical formats in general are on the wane as a distribution format due to the widespread deployment of the high-bandwidth Internet.

See also:
* [[Disk Image Formats#Optical Disc Image Formats]]
* [[Filesystem]]

== List of formats ==

* [[Blu-ray Disc]]
** [[M-Disc]]
** [[UHD Blu-ray]]
* [[CD]] (Compact Disc)
** [[CD-DA]] (Compact Disc Digital Audio or Red Book)
** [[CD-MIDI]]
** [[CD-ROM]] (Yellow Book)
** [[CD-ROM XA]]
*** [[Linked MultiSession]]
** [[DD-CD]] (Double-density Compact Disc)
** [[Enhanced CD]]
** [[Photo CD]] (Beige Book)
*** [[CD-i]] (Green Book)
** [[SACD]] (Super Audio CD or Scarlet Book)
** [[VCD]] (Video CD or White Book)
*** [[Super Video CD]]
* [[DVD]]
** [[DVD-Audio]]
** [[DVD-ROM]]
** [[M-Disc]]
* [[Enhanced Versatile Disc]]
* [[GD-ROM]]
* [[HD-DVD]]
** [[China Blue High-Definition Disc]]
* [[Laserdisc]]
** [[LV-ROM]]
* [[MiniDisc]]
* Nintendo optical discs
** [[Nintendo GameCube Game Disc]]
** [[Nintendo Wii Optical Disc]]
** [[Nintendo Wii U Optical Disc]]
* [[Thomson-CSF system]]
* [[Ultra Density Optical]]
* [[Universal Media Disc]]
* [[IBM 3363 Optical WORM]]

== Links ==
* [http://www.thexlab.com/faqs/opticalmedialongevity.html Optical media longevity]
* [http://www.sony.net/SonyInfo/News/Press/201403/14-0310E/index.html "Archival Disc" standard formulated for professional-use next-generation optical discs] (up to 1 TB capacity)
* [http://journal.code4lib.org/articles/9581 An Introduction to Optical Media Preservation] by [https://twitter.com/archivetype @archivetype]
* [http://www.loc.gov/preservation/resources/rfs/softgame.html Library of Congress Recommended Format Specifications: Software/Gaming]
* [http://arxiv.org/ftp/arxiv/papers/1309/1309.4932.pdf Developing a Robust Migration Workflow for Preserving and Curating Hand-held Media]
* [http://www.kurzweilai.net/5d-nanostructured-quartz-glass-optical-memory-could-provide-unlimited-data-storage-for-a-million-years 5D nanostructured quartz glass optical memory could provide ‘unlimited’ data storage for a million years] (but reference link there is already 404 Not Found!)
* [https://www.bitsgalore.org/2015/11/13/preserving-optical-media-from-the-command-line Preserving optical media from the command line]

OS/360 Object File Format

2024-03-03T02:19:52Z

SJK:

{{FormatInfo
|formattype=electronic
|subcat=Executables
|released=~1965
}}
'''OS/360 Object File Format''' is the original executable format for IBM mainframe operating system OS/360 and its successors. It is still supported by contemporary z/OS, although officially superseded by [[GOFF]]. It is also supported on z/VM (previously VM/CMS), although likewise superseded by GOFF there as well. It is also called "OBJ". There is also an extended version, which came after OBJ but before GOFF, called XOBJ, which has various important features, such as support for symbols with names longer than 8 bytes.

It was also used by some other mainframe vendors which partially copied IBM's technologies, such as UNIVAC Series 90.

== Links ==
*[[Wikipedia:OS/360_Object_File_Format|Wikipedia article]]

[[Category:IBM mainframe]]

GOFF

2024-03-03T02:02:13Z

SJK:

{{FormatInfo
|formattype=electronic
|subcat=Executables
|released=~1995
}}
''GOFF'' (Generalized Object File Format) is the current executable format for the IBM mainframe operating systems z/OS and z/VM. It supersedes the original [[OS/360 Object File Format]], although the later is still supported.

On z/OS, GOFF exists in two subtypes:
* '''load module''': this is code which can be dynamically loaded into memory – similar in concept to a DLL or shared library on other operating systems. GOFF is the successor to XOBJ, the earlier object format for load modules, which in turn was successor to OBJ
* '''program object''': this is an executable format

=== Program Objects ===

Note the "program object" format has never been fully and officially documented outside of IBM confidential materials (possibly available under NDA, but certainly not to the general public). That said, significant chunks of it are composed out of data structures which are documented in public z/OS manuals. The biggest missing component is the initial "IEWPLMH" header. However, several of those non-public bits have been revealed in an open source project, an incomplete port of GNU binutils/GDB to z/OS:

There is an [https://github.com/ambitus/binutils incomplete port of GNU binutils to z/OS]. The most important files are [https://github.com/ambitus/binutils/blob/program-object/bfd/po64-s390.c po64-s390.c] and [https://github.com/ambitus/binutils/blob/program-object/include/po/external.h po/external.h]

The file starts with an 8-byte EBCDIC header ("eyecatcher" in IBM-speak) which is "IEWPLMH" followed by a single EBCDIC space. In hex that is c9c5e6d7d3d4c840.

z/OS has two main filesystems: the traditional "dataset" filesystem, and a POSIX filesystem (originally HFS, more recently replaced by zFS; also supporting network file systems such as NFS and previously others such as DCE DFS). The traditional filesystem is based on very different concepts from POSIX; instead of files, it has "datasets", which have explicit record structure (such as fixed vs variable). One type of dataset is known as a "partitioned dataset" (PDS), later also PDSE (Partitioned Data Set Extended), which is like a ZIP file. Anyway, traditional z/OS load modules could not be stored directly in the POSIX filesystem, only in partitioned datasets; you could archive the partitioned dataset into a POSIX file (using utilities such as IEBCOPY and XMIT), but z/OS could not actually use it until it was turned back into a partitioned dataset. By contrast, z/OS Program Objects can be stored in a Unix file directly, as well as in partitioned datasets (which have to be the new PDSE format)

== Links ==
*[[Wikipedia:GOFF|Wikipedia article]]

[[Category:IBM mainframe]]

DOS/Windows file attributes

2023-05-29T09:56:46Z

SJK: /* Table of attributes */ more details on "SMR Blob"

{{FormatInfo
|formattype=electronic
|subcat=Metadata
}}
The '''DOS/Windows file attributes''' are a set of standard one-bit attributes for a file or directory. The original form was a one-byte field associated with [[FAT]], but it has been extended and updated over time. Some [[archiving]] and [[filesystem]] formats have a way to store (some subset of) these attributes.

== Table of attributes ==
Some of the one-letter identifiers used by the ATTRIB command are included in this table.

{| class="wikitable"
! Value !! ID !! Meaning
|-
|0x00000001 || R || READONLY
|-
|0x00000002 || H || HIDDEN
|-
|0x00000004 || S || SYSTEM
|-
|0x00000008 || || Volume label (or reserved)
|-
|0x0000000f || || LONG_NAME (see [[VFAT]])
|-
|0x00000010 || || DIRECTORY
|-
|0x00000020 || A || ARCHIVE
|-
|0x00000040 || || DEVICE (reserved for system use)
|-
|0x00000080 || || NORMAL (valid only when used alone)
|-
|0x00000100 || || TEMPORARY
|-
|0x00000200 || || SPARSE_FILE
|-
|0x00000400 || || REPARSE_POINT
|-
|0x00000800 || || COMPRESSED
|-
|0x00001000 || O || OFFLINE
|-
|0x00002000 || I || NOT_CONTENT_INDEXED
|-
|0x00004000 || || ENCRYPTED
|-
|0x00008000 || V || INTEGRITY_STREAM ([[ReFS]])
|-
|0x00010000 || || VIRTUAL (reserved for system use)
|-
|0x00020000 || X || NO_SCRUB_DATA ([[ReFS]])
|-
|0x00040000 || || RECALL_ON_OPEN
|-
|0x00080000 || P || PINNED ([[OneDrive]])
|-
|0x00100000 || U || UNPINNED ([[OneDrive]])
|-
|0x00400000 || || RECALL_ON_DATA_ACCESS
|-
|0x20000000 || B || FILE_ATTRIBUTE_STRICTLY_SEQUENTIAL (aka "SMR Blob")
|}

== Links ==
* [https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants Windows Dev Center: File Attribute Constants]
* [[Wikipedia: File attribute#DOS and Windows]]

[[Category:Microsoft]]
[[Category:MS-DOS]]
[[Category:Windows]]

IBM BookManager book

2023-05-04T22:46:32Z

SJK: /* External links */

{{FormatInfo
|formattype=electronic
|subcat=Document
|extensions={{ext|boo}}
}}
IBM BookManager is IBM's legacy online documentation system, historically used mostly on mainframes, midrange (AS/400) and OS/2, although it also saw some use in other areas including AIX. IBM no longer uses it for documenting current versions of its products, but there is an immense quantity of surviving electronic documentation from the period when IBM actively used it (from the 1990s thru 2010s), particularly documentation CD-ROMs/DVD-ROMs and images thereof.

The standard extension is BOO. No public documentation is known to be available for it. The header of BOO files commonly contains an EBCDIC copyright notice (this is true even for books for ASCII-based platforms such as OS/2). The file contents is almost certainly also in EBCDIC, but is not readable beyond the header. Maybe it is compressed with unknown compression algorithms (a relative of IBM's well-known proprietary algorithms such as TERSE?). However, the data seems too repetitive to be compressed–possibly it is just some obfuscation mechanism then?

https://github.com/kev009/boo2pdf is code to convert BOO files to PDF. However, it relies on using the IBM SoftCopy Reader (for 32-bit Linux)'s JAR files and native code libraries (.so files) to actually read the file. The author of that code previously hosted a free public web service for that conversion, but discontinued it.

Versions of IBM's SoftCopy Reader (previously known as IBM Library Reader and before that IBM BookManager READ) also existed for Windows, AIX (any other commercial Unix systems?), OS/2, DOS (meaning PC-DOS/MS-DOS, not mainframe DOS), MVS (later known as OS/390 then z/OS), VM/CMS (later known as z/VM), and OS/400 (later IBM i5/OS and then IBM i)–but apparently *not* mainframe DOS (DOS/360, DOS/VS, DOS/VSE, z/VSE).

"application/book" is sometimes used as a MIME type but was never officially registered

== Notes on file format ==

* Bytes 1-2: unknown 2 bytes probably flags. second byte never zero, first byte often is (but not always). probably not a size, since 0001 is a common value.
* Bytes 3-6: these 4 bytes appear to always be zero
* Bytes 7: unknown, can be zero, probably more flags???
Bytes 8+: EBCDIC copyright string. Can start with one or more EBCDIC spaces (0x40), sometimes also (0xB4) (some kind of control character?)

The header is 256 bytes long. The copyright string is padded to the end of the header with 0x40 (EBCDIC space). However, it seems to have a null terminator (0x00) at the end of the actual text, before the space padding.

What follows from 256 bytes onwards looks like it could be some kind of compression dictionary???? Not clear.

It looks like the file is composed of 256 byte records (so file size should be an integer multiple of 256), often with some all-zeros records appended to the end.

== External links ==
* http://www.edm2.com/index.php/BookManager – contains history of IBM BookManager releases

[[Category:IBM mainframe]]
[[Category:OS/2]]

IBM BookManager book

2023-05-04T22:45:17Z

SJK:

IBM BookManager book

2023-05-04T14:12:55Z

SJK:

{{FormatInfo
|formattype=electronic
|subcat=Document
|extensions={{ext|boo}}
}}
IBM BookManager is IBM's legacy online documentation system, historically used mostly on mainframes, midrange (AS/400) and OS/2, although it also saw some use in other areas including AIX. IBM no longer uses it for documenting current versions of its products, but there is an immense quantity of surviving electronic documentation from the period when IBM actively used it (from the 1990s thru 2010s), particularly documentation CD-ROMs/DVD-ROMs and images thereof.

The standard extension is BOO. No public documentation is known to be available for it. The header of BOO files commonly contains an EBCDIC copyright notice (this is true even for books for ASCII-based platforms such as OS/2). The file contents is almost certainly also in EBCDIC, but is not readable beyond the header. Maybe it is compressed with unknown compression algorithms (a relative of IBM's well-known proprietary algorithms such as TERSE?). However, the data seems to repetitive to be compressed–possibly it is just some obfuscation mechanism then?

https://github.com/kev009/boo2pdf is code to convert BOO files to PDF. However, it relies on using the IBM SoftCopy Reader (for 32-bit Linux)'s JAR files and native code libraries (.so files) to actually read the file. The author of that code previously hosted a free public web service for that conversion, but discontinued it.

Versions of IBM's SoftCopy Reader (previously known as IBM Library Reader and before that IBM BookManager READ) also existed for Windows, AIX (any other commercial Unix systems?), OS/2, DOS (meaning PC-DOS/MS-DOS, not mainframe DOS), MVS (later known as OS/390 then z/OS), VM/CMS (later known as z/VM), and OS/400 (later IBM i5/OS and then IBM i)–but apparently *not* mainframe DOS (DOS/360, DOS/VS, DOS/VSE, z/VSE).

"application/book" is sometimes used as a MIME type but was never officially registered

== Notes on file format ==

* Bytes 1-2: unknown 2 bytes probably flags. second byte never zero, first byte often is (but not always). probably not a size, since 0001 is a common value.
* Bytes 3-6: these 4 bytes appear to always be zero
* Bytes 7: unknown, can be zero, probably more flags???
Bytes 8+: EBCDIC copyright string. Can start with one or more EBCDIC spaces (0x40), sometimes also (0xB4) (some kind of control character?)

The header is 256 bytes long. The copyright string is padded to the end of the header with 0x40 (EBCDIC space). However, it seems to have a null terminator (0x00) at the end of the actual text, before the space padding.

What follows from 256 bytes onwards looks like it could be some kind of compression dictionary???? Not clear.

It looks like the file is composed of 256 byte records (so file size should be an integer multiple of 256), often with some all-zeros records appended to the end.

== External links ==
* http://www.edm2.com/index.php/BookManager – contains history of IBM BookManager releases

IBM BookManager book

2023-05-04T14:06:11Z

SJK:

{{FormatInfo
|formattype=electronic
|subcat=Document
|extensions={{ext|boo}}
}}
IBM BookManager is IBM's legacy online documentation system, historically used mostly on mainframes, midrange (AS/400) and OS/2, although it also saw some use in other areas including AIX. IBM no longer uses it for documenting current versions of its products, but there is an immense quantity of surviving electronic documentation from the period when IBM actively used it (from the 1990s thru 2010s), particularly documentation CD-ROMs/DVD-ROMs and images thereof.

The standard extension is BOO. No public documentation is known to be available for it. The header of BOO files commonly contains an EBCDIC copyright notice (this is true even for books for ASCII-based platforms such as OS/2). The file contents is almost certainly also in EBCDIC, but it is compressed with unknown compression algorithms (likely a relative of IBM's well-known proprietary algorithms such as TERSE, but that's speculation).

https://github.com/kev009/boo2pdf is code to convert BOO files to PDF. However, it relies on using the IBM SoftCopy Reader (for 32-bit Linux)'s JAR files and native code libraries (.so files) to actually read the file. The author of that code previously hosted a free public web service for that conversion, but discontinued it.

Versions of IBM's SoftCopy Reader (previously known as IBM Library Reader and before that IBM BookManager READ) also existed for Windows, AIX (any other commercial Unix systems?), OS/2, DOS (meaning PC-DOS/MS-DOS, not mainframe DOS), MVS (later known as OS/390 then z/OS), VM/CMS (later known as z/VM), and OS/400 (later IBM i5/OS and then IBM i)–but apparently *not* mainframe DOS (DOS/360, DOS/VS, DOS/VSE, z/VSE).

"application/book" is sometimes used as a MIME type but was never officially registered

== Notes on file format ==

* Bytes 1-2: unknown 2 bytes probably flags. second byte never zero, first byte often is (but not always). probably not a size, since 0001 is a common value.
* Bytes 3-6: these 4 bytes appear to always be zero
* Bytes 7: unknown, can be zero, probably more flags???
Bytes 8+: EBCDIC copyright string. Can start with one or more EBCDIC spaces (0x40), sometimes also (0xB4) (some kind of control character?)

The header is 256 bytes long. The copyright string is padded to the end of the header with 0x40 (EBCDIC space). However, it seems to have a null terminator (0x00) at the end of the actual text, before the space padding.

What follows from 256 bytes onwards looks like it could be some kind of compression dictionary???? Not clear.

It looks like the file is composed of 256 byte records (so file size should be an integer multiple of 256), often with some all-zeros records appended to the end.

== External links ==
* http://www.edm2.com/index.php/BookManager – contains history of IBM BookManager releases

IBM BookManager book

2023-05-04T13:22:41Z

SJK:

IBM BookManager book

2023-05-04T13:20:54Z

SJK:

IBM BookManager book

2023-05-04T13:19:50Z

SJK: Created page with "{{FormatInfo |formattype=electronic |subcat=Document |extensions={{ext|boo}} }} IBM BookManager is IBM's legacy online documentation system, historically used mostly on mainfr..."

Category:File formats with extension .xmit

2021-01-02T13:32:53Z

SJK:

[[Category:File formats by extension|X]]

Category:File formats with extension .savf

2021-01-02T13:32:40Z

SJK: Created page with "S"

[[Category:File formats by extension|S]]

SAVF

2021-01-02T13:30:27Z

SJK: Created page with "{{FormatInfo |subcat=Archiving |extensions={{ext|savf}} }} '''SAVF''' is a proprietary file format used to transfer IBM i (formerly known as i5/OS and OS/400) objects between ..."

{{FormatInfo
|subcat=Archiving
|extensions={{ext|savf}}
}}
'''SAVF''' is a proprietary file format used to transfer IBM i (formerly known as i5/OS and OS/400) objects between systems.

== Software ==
*[http://www.anerty.net/software/file/jSAVF/?lang=en Java-based application to view SAVF contents on other platforms]

[[Category:IBM]]

RFT

2021-01-02T13:23:57Z

SJK:

{{FormatInfo
|formattype=electronic
|subcat=Document
|extensions={{ext|rft}}
|pronom={{PRONOM|x-fmt/285}}
}}
[[RFT]] (Revisable Format Text) is a word processing file format which forms part of IBM's [[Wikipedia:Document_Content_Architecture#Revisable-Form_Text|Document Content Architecture]] (DCA).

[[Category:IBM]]

RFT

2021-01-02T13:21:59Z

SJK: Created page with "{{FormatInfo |formattype=electronic |subcat=Document |extensions={{ext|rft}} }} RFT (Revisable Format Text) is a word processing file format which forms part of IBM's [[Wi..."

{{FormatInfo
|formattype=electronic
|subcat=Document
|extensions={{ext|rft}}
}}
[[RFT]] (Revisable Format Text) is a word processing file format which forms part of IBM's [[Wikipedia:Document_Content_Architecture#Revisable-Form_Text|Document Content Architecture]] (DCA).

[[Category:IBM]]

XML Metadata Interchange

2021-01-02T13:13:34Z

SJK: Created page with "{{FormatInfo |subcat=Development |extensions={{ext|xmi}} |mimetypes={{mimetype|application/vnd.xmi+xml}} }} '''XML Metadata Interchange''' ('''XMI''') is an XML-based file for..."

{{FormatInfo
|subcat=Development
|extensions={{ext|xmi}}
|mimetypes={{mimetype|application/vnd.xmi+xml}}
}}
'''XML Metadata Interchange''' ('''XMI''') is an XML-based file format used to share modelling information between development tools. It is primarily used to exchange UML diagrams, but it can be used to exchange any abstract model used in designing and developing software systems.

== Links ==
* [[Wikipedia:XML Metadata Interchange|Wikipedia article]]

[[Category:XML based file formats]]

Category:File formats with extension .xmit

2021-01-02T13:07:41Z

SJK: Created page with "Category:File formats by extension"

[[Category:File formats by extension]]

XMIT

2021-01-02T13:07:09Z

SJK: Created page with "{{FormatInfo |subcat=Archiving |extensions={{ext|xmit}}, {{ext|xmi}} }} '''XMIT''' is a file format used to archive files from the IBM mainframe z/OS operating system. == Sof..."

{{FormatInfo
|subcat=Archiving
|extensions={{ext|xmit}}, {{ext|xmi}}
}}
'''XMIT''' is a file format used to archive files from the IBM mainframe z/OS operating system.

== Software ==
*[http://www.cbttape.org/xmitview.htm Tools to view XMIT files on Windows, Java, Android and other platforms]

[[Category:IBM mainframe]]

OS/360 Object File Format

2021-01-02T13:00:29Z

SJK:

{{FormatInfo
|formattype=electronic
|subcat=Executables
|released=~1965
}}
'''OS/360 Object File Format''' is the original executable format for IBM mainframe operating system OS/360 and its successors. It is still supported by contemporary z/OS, although officially superseded by [[GOFF]]. It is also supported on z/VM (previously VM/CMS), although likewise superseded by GOFF there as well.

It was also used by some other mainframe vendors which partially copied IBM's technologies, such as UNIVAC Series 90.

== Links ==
*[[Wikipedia:OS/360_Object_File_Format|Wikipedia article]]

[[Category:IBM mainframe]]

GOFF

2021-01-02T12:59:35Z

SJK: Created page with "{{FormatInfo |formattype=electronic |subcat=Executables |released=~1995 }} ''GOFF'' (Generalized Object File Format) is the current executable format for the IBM mainframe ope..."

OS/360 Object File Format

2021-01-02T12:57:25Z

SJK: Created page with "{{FormatInfo |formattype=electronic |subcat=Executables }} '''OS/360 Object File Format''' is the original executable format for IBM mainframe operating system OS/360 and its ..."

{{FormatInfo
|formattype=electronic
|subcat=Executables
}}
'''OS/360 Object File Format''' is the original executable format for IBM mainframe operating system OS/360 and its successors. It is still supported by contemporary z/OS, although officially superseded by [[GOFF]]. It is also supported on z/VM (previously VM/CMS), although likewise superseded by GOFF there as well.

== Links ==
*[[Wikipedia:OS/360_Object_File_Format|Wikipedia article]]

[[Category:IBM mainframe]]

TERSE

2021-01-02T12:53:37Z

SJK: /* Software */

{{FormatInfo
|formattype=electronic
|subcat=Compression
|released=1984?
}}
'''TERSE''' is a data compression format used on OS/2, and on IBM mainframes. It is still in regular use on IBM mainframes to this day.

More research is needed to understand the scope of what TERSE was used for, and how many versions of it there are.

It can at least be used for single-file compression, as is done by the Advantis software listed below. This file format does not appear to have a conventional filename extension – compressed files may keep their original name.

== Identification ==
At least some TERSE-compressed files start with bytes {{magic|05 01 01 00}}.

== Related formats ==
The [[ZIP]] format documentation (APPNOTE) lists two "TERSE" compression methods:

10 - PKWARE Data Compression Library Imploding (old IBM TERSE)
18 - File is compressed using IBM TERSE (new)

So, apparently, [[PKWARE DCL Implode]] is closely related to TERSE.

== Software ==
* TERSE utility by Michael Nagy and Advantis
** [http://thorntonzone.com/afp/Mainframe/TERSE%20%28IBM%20mainframe%20compression%29/image-list.php?showsource=1] → [http://thorntonzone.com/afp/Mainframe/TERSE%20%28IBM%20mainframe%20compression%29/tersepc.zip tersepc.zip] - Collection of binaries for several platforms
** [https://www.sac.sk/download/pack/terse.zip terse.zip] - OS/2 binaries
** [https://www.ibm.com/support/knowledgecenter/SSB27H_6.2.0/fa2ut_part3_terse.html IBM Knowledge Center: Terse Utility]
* [https://github.com/openmainframeproject/tersedecompress TerseDecompress] – open source (Apache2 licensed) Java program, written by IBM, to decompress TERSE files for mainframe.

== Links ==
* [[Wikipedia:Terse (file format)|Wikipedia article]]

[[Category:IBM]]
[[Category:OS/2]]

TERSE

2021-01-02T12:53:22Z

SJK: /* Software */

{{FormatInfo
|formattype=electronic
|subcat=Compression
|released=1984?
}}
'''TERSE''' is a data compression format used on OS/2, and on IBM mainframes. It is still in regular use on IBM mainframes to this day.

More research is needed to understand the scope of what TERSE was used for, and how many versions of it there are.

It can at least be used for single-file compression, as is done by the Advantis software listed below. This file format does not appear to have a conventional filename extension – compressed files may keep their original name.

== Identification ==
At least some TERSE-compressed files start with bytes {{magic|05 01 01 00}}.

== Related formats ==
The [[ZIP]] format documentation (APPNOTE) lists two "TERSE" compression methods:

10 - PKWARE Data Compression Library Imploding (old IBM TERSE)
18 - File is compressed using IBM TERSE (new)

So, apparently, [[PKWARE DCL Implode]] is closely related to TERSE.

== Software ==
* TERSE utility by Michael Nagy and Advantis
** [http://thorntonzone.com/afp/Mainframe/TERSE%20%28IBM%20mainframe%20compression%29/image-list.php?showsource=1] → [http://thorntonzone.com/afp/Mainframe/TERSE%20%28IBM%20mainframe%20compression%29/tersepc.zip tersepc.zip] - Collection of binaries for several platforms
** [https://www.sac.sk/download/pack/terse.zip terse.zip] - OS/2 binaries
** [https://www.ibm.com/support/knowledgecenter/SSB27H_6.2.0/fa2ut_part3_terse.html IBM Knowledge Center: Terse Utility]
* [https://github.com/openmainframeproject/tersedecompress TerseDecompress] – open source (Apache2 licensed) Java program, written by IBM, to decompresses TERSE files for mainframe.

== Links ==
* [[Wikipedia:Terse (file format)|Wikipedia article]]

[[Category:IBM]]
[[Category:OS/2]]

TERSE

2021-01-02T12:48:41Z

SJK:

{{FormatInfo
|formattype=electronic
|subcat=Compression
|released=1984?
}}
'''TERSE''' is a data compression format used on OS/2, and on IBM mainframes. It is still in regular use on IBM mainframes to this day.

More research is needed to understand the scope of what TERSE was used for, and how many versions of it there are.

It can at least be used for single-file compression, as is done by the Advantis software listed below. This file format does not appear to have a conventional filename extension – compressed files may keep their original name.

== Identification ==
At least some TERSE-compressed files start with bytes {{magic|05 01 01 00}}.

== Related formats ==
The [[ZIP]] format documentation (APPNOTE) lists two "TERSE" compression methods:

10 - PKWARE Data Compression Library Imploding (old IBM TERSE)
18 - File is compressed using IBM TERSE (new)

So, apparently, [[PKWARE DCL Implode]] is closely related to TERSE.

== Software ==
* TERSE utility by Michael Nagy and Advantis
** [http://thorntonzone.com/afp/Mainframe/TERSE%20%28IBM%20mainframe%20compression%29/image-list.php?showsource=1] → [http://thorntonzone.com/afp/Mainframe/TERSE%20%28IBM%20mainframe%20compression%29/tersepc.zip tersepc.zip] - Collection of binaries for several platforms
** [https://www.sac.sk/download/pack/terse.zip terse.zip] - OS/2 binaries
** [https://www.ibm.com/support/knowledgecenter/SSB27H_6.2.0/fa2ut_part3_terse.html IBM Knowledge Center: Terse Utility]

== Links ==
* [[Wikipedia:Terse (file format)|Wikipedia article]]

[[Category:IBM]]
[[Category:OS/2]]