Jump to content

File Control Block

From Alfawiki
File Control Block
Company typeData structure
IndustryComputer file systems
PredecessorNone
Founded1970s (approximate, with CP/M)
SuccessorFile handles
ProductsFile status tracking in CP/M and DOS

A File Control Block (FCB) is a data structure within a file system designed to track the status of an open file. Controlled by the operating system, it is stored in the memory space of the application accessing the file, enabling a single process to manage multiple open files, constrained only by the available memory allocated for each FCB.

The concept of the FCB originated with CP/M and was subsequently adopted in various DOS versions, mainly retained for backward compatibility in MS-DOS starting from version 2.0 onward. Typically, an FCB occupies 36 bytes in size, whereas earlier CP/M implementations utilized 33 bytes. Due to its fixed length, which restricted extensibility, the FCB gradually fell out of favor as the primary mechanism for file operations.

Although the interpretation of specific fields differs between CP/M and DOS as well as among different operations, several fields remain consistent:

Offset Byte
size
Description
0x00 1 Drive identifier — 0 indicates default drive, 1 corresponds to A:, 2 to B:, etc.
0x01 8 Filename and extension combined to form an 8.3 filename.
0x09 3
0x0C 20 Implementation-specific data; initialized to zero prior to file opening.
0x20 1 Sequential access record number.
0x21 3 Record number used for random access.

Within the 20-byte segment at offset 0x0C, the following details are included:

Offset Byte
size
Description
0x0E 2 Length of each file record in bytes.
0x10 4 Overall file size in bytes.
0x14 2 Date when the file was last modified.
0x16 2 Time of last modification.

Subsequent DOS iterations incorporated additional values beyond these specified bytes. Certain reserved areas in CP/M’s Zero Page and DOS's Program Segment Prefix held file attribute information.

Usage

In early operating systems such as CP/M, 86-DOS, and initial versions of MS-DOS (1.x), FCBs represented the exclusive method for accessing files, supported by multiple INT 21h subfunctions. With the introduction of MS-DOS version 2, which brought features like multitasking, multi-user support, networked file access, and alternative filesystem compatibility, FCBs were considered inadequate due to their inability to store necessary metadata including sub-directory paths and their exposure of filesystem internals to user-level programs posed security concerns. As a result, FCBs were supplanted by file handles—integer-based identifiers managed entirely by the operating system—similar to those used in UNIX systems.

The adoption of file handles facilitates flexible internal structure management by the OS without disrupting existing applications. However, due to DOS’s straightforward memory management model, supporting numerous concurrently open files requires preallocating resources during system boot via the FILES= setting in CONFIG.SYS. This contrasts with DOS version 1 or CP/M environments where all file-related state information was maintained directly within program memory through FCBs.

From MS-DOS version 3 onward, FCB functionality is influenced by SHARE.EXE and whether files are accessed locally or over a network; typically, only four FCBs may be open simultaneously but this limit can be raised using the FCBS= configuration. In DR-DOS, both FILES and FCBS directives draw from a unified pool of handle structures that are allocated dynamically.

Support for FCBs persisted across MS-DOS and Microsoft Windows until the introduction of the FAT32 filesystem. Operating systems such as Windows 95, Windows 98, and Windows Me do not support FCB usage on FAT32-formatted drives due to their reliance on 32-bit cluster numbers—restricting FCB functionality primarily to reading volume labels—and causing compatibility challenges with legacy DOS software like WordStar.

On modern Windows NT-based platforms including Windows NT and Windows 2000, the FCB interface is no longer functional. Nevertheless, DOS emulation environments such as DOSEMU and DOSBox provide full support for FCBs, enabling legacy DOS applications dependent on this interface to operate correctly on contemporary systems.

Disk Transfer Area

The Disk Transfer Area (DTA) functioned as a temporary storage buffer used in conjunction with the File Control Block (FCB) for reading from or writing to files. Early DOS file operations based on the FCB relied on a predetermined DTA location, originally set within the Program Segment Prefix (PSP), though this default could be modified through a dedicated DOS system call. As the FCB method became obsolete, newer DOS file access routines employing file handles introduced the ability to specify distinct memory buffers during each call, allowing greater flexibility and simultaneous file processing.

Program Segment Prefix & Program Initialization

When DOS programs were executed via the command interpreter (COMMAND.COM), they were provided with a 256-byte data structure known as the Program Segment Prefix (PSP). Important elements within this structure include:

Offset Byte
size
Description
0x02 2 Amount of available memory for the program, measured in 16-byte paragraphs.
0x2C 2 Segment address pointing to the environment variables.
0x5C 16 Pre-initialized but unopened FCB corresponding to the first command line argument.
0x6C 20 Pre-initialized but unopened FCB corresponding to the second command line argument.
0x80 1 Length of the command line string.
0x81 127 The actual command line input.

Positioned at the beginning of the program’s data segment (DS and ES registers), the PSP contained an exact copy of the command line starting at offset 0x81. To facilitate programming, DOS automatically prepared two unopened FCBs based on the first two words of the command line, which typically represented filenames. Initially, the DTA address overlapped with the PSP’s command line buffer at offset 0x80, meaning applications needed to parse command arguments before calling DOS functions that used the DTA or relocate the DTA buffer elsewhere. However, modern software generally preferred utilizing file handle-based APIs rather than relying on FCBs and DTAs.

See also

Further reading

  • Ralf D. Brown, 210F: DOS 1+ - OPEN FILE USING FCB, Ralf Brown's Interrupt List 61, ctyme.com, 2000-07-17 [archived]
  • John C. Elliott, CP/M File Control Block, Seasip.info, 2002-12-29 [archived]
  • CP/M Internals, 2017-08-23 [archived] – Comprehensive explanation of CP/M FCB mechanisms