File Control Block

Last updated

A File Control Block (FCB) is a file system structure in which the state of an open file is maintained. A FCB is managed by the operating system, but it resides in the memory of the program that uses the file, not in operating system memory. This allows a process to have as many files open at one time as it wants to, provided it can spare enough memory for an FCB per file.

Contents

The FCB originates from CP/M and is also present in most variants of DOS, though only as a backwards compatibility measure in MS-DOS versions 2.0 and later. A full FCB is 36 bytes long; in early versions of CP/M, it was 33 bytes. This fixed size, which could not be increased without breaking application compatibility, lead to the FCB's eventual demise as the standard method of accessing files.

The meanings of several of the fields in the FCB differ between CP/M and DOS, and also depending on what operation is being performed. The following fields have consistent meanings: [1]

OffsetByte
size
Contents
0x001Drive number — 0 for default, 1 for A:, 2 for B:, ...
0x018File name and extension — together these form a 8.3 file name.
0x093
0x0C20Implementation dependent — should be initialised to zero before the FCB is opened.
0x201Record number in the current section of the file — used when performing sequential access.
0x213Record number to use when performing random access.

The 20-byte-long field starting at offset 0x0C contained fields which (among others) provided further information about the file: [2]

OffsetByte
size
Contents
0x0E2File's record length in bytes.
0x104Total file size in bytes.
0x142Date of last modification to file contents.
0x162Time of last modification.

Further values were used by newer versions of DOS until new information could no longer fit in these 20 bytes. Some preceding "negative offset" bytes were squeezed from reserved spaces in CP/M Zero Page and DOS Program Segment Prefix for storing file attributes. [1]

Usage

In CP/M, 86-DOS and PC DOS 1.x/MS-DOS 1.xx, the FCB was the only method of accessing files. Under DOS a few INT 21h subfunctions provided the interface to operate on files using the FCB. [1] [3] [4] When, with MS-DOS 2, preparations were made to support multiple processes or users, [3] [4] use other filesystems [3] [4] than FAT or to share files [4] over networks in the future, FCBs were felt to be too small to handle the extra data required for such features [4] and therefore FCBs were seen as inadequate for various future expansion paths. [3] Also, they didn't provide a field to specify sub-directories. [3] Exposing file system related data to user-space was also seen as a security risk. [4] FCBs were thus superseded by file handles, as used on UNIX and its derivatives. [3] File handles are simply consecutive integer numbers associated with specific open files.

If a program uses the newer file handle API to open a file, the operating system will manage its internal data structure associated with that file in its own memory area. This has the great advantage that these structures can grow in size in later operating system versions without breaking compatibility with application programs; its disadvantage is that, given the rather simplistic memory management of DOS, space for as many of these structures as the most "file-hungry" program is likely to use has to be reserved at boot time and cannot be used for any other purpose while the computer is running. Such memory reservation is done using the FILES= directive in the CONFIG.SYS file. This problem does not occur with FCBs in DOS 1 or in CP/M, since the operating system stores all that it needs to know about an open file inside the FCB and thus does not need to use any per-file memory in operating system memory space. When using FCBs in MS-DOS 3 or later, the FCB format depends on if SHARE.EXE is loaded and if the FCB refers to a local or remote file and often refer to a SFT entry. Because of this, the number of FCBs which can be kept open at once in DOS 3 or higher is limited as well, usually to 4; using the FCBS= directive in the CONFIG.SYS file, it may be increased beyond that number if necessary. Under DR-DOS, both FILES and FCBS come from the same internal pool of available handles structures and are assigned dynamically as needed. [5]

FCBs were supported in all versions of MS-DOS and Windows until the introduction of the FAT32 filesystem. Windows 95, Windows 98 and Windows Me do not support the use of FCBs on FAT32 drives due to its 32-bit cluster numbers, [4] except to read the volume label. This caused some old DOS applications, including WordStar, to fail under these versions of Windows.

The FCB interface does not work properly on Windows NT, 2000, etc. either – WordStar does not function properly on these operating systems. DOS emulators DOSEMU and DOSBox implement the FCB interface properly, thus they are a way to run older DOS programs that need FCBs on modern operating systems.

Disk Transfer Area

A companion data structure used together with the FCB was the Disk Transfer Area (DTA). [2] This is the name given to the buffer where file contents (records) would be read into/written from. File access functions in DOS that used the FCB assumed a fixed location for the DTA, initially pointing to a part of the PSP (see next section); this location could be changed by calling a DOS function, with subsequent file accesses implicitly using the new location.

With the deprecation of the FCB method, the new file access functions which used file handles also provided a means to specify a memory buffer for file contents with every function call, such that maintaining concurrent, independent buffers (either for different files or for the same file) became much more practical.

Program Segment Prefix & Program Initialisation

Every DOS executable started from the shell (COMMAND.COM) was provided with a pre-filled 256-byte long data structure called the Program Segment Prefix (PSP). Relevant fields within this structure include: [2]

OffsetByte
size
Contents
0x022Available memory for the program in 16-byte chunks.
0x2C2Segment address containing the program's environment variables.
0x5C16Prepared FCB for first command line argument (unopened).
0x6C20Prepared FCB for second command line argument (unopened).
0x801Length of command line.
0x81127Command line contents.

This data structure could be found at the beginning of the data segment whose address was provided by DOS at program start in the DS and ES segment registers. Besides providing the program's command line verbatim at address 0x81, DOS also tried to construct two FCB's corresponding to the first two words in the command line, the purpose being to save work for the programmer in the common case where these words were filenames to operate on. Since these FCB's remained unopened, no problem would ensue even if these command line words did not refer to files.

The initial address for the DTA was set to overlay the area in the PSP (at address 0x80) where the command line arguments were stored, such that a program needed to parse this area for command line arguments before invoking DOS functions that made use of the DTA (such as reading in a file record), unless the program took care to change the address of the DTA to some other memory region (or not use the DTA/FCB functions altogether, which soon became deprecated in favour of file handles).

See also

Related Research Articles

WordStar Word processor application

WordStar was a word processor application for microcomputers. It dominated the market in the early and mid-1980s, succeeding the market leader Electric Pencil. It was published by MicroPro International, originally written for the CP/M-80 operating system, and later written also for MS-DOS and other 16-bit PC OSes. Seymour I. Rubinstein was the principal owner of the company, and Rob Barnaby was the sole author of the early versions of the program. Starting with WordStar 4.0, the program was built on new code written principally by Peter Mierau.

Drive letter assignment Alphabetical assignment to logical drives on computers (e.g., C:\)

In computer data storage, drive letter assignment is the process of assigning alphabetical identifiers to volumes. Unlike the concept of UNIX mount points, where volumes are named and located arbitrarily in a single hierarchical namespace, drive letter assignment allows multiple highest-level namespaces. Drive letter assignment is thus a process of using letters to name the roots of the "forest" representing the file system; each volume holds an independent "tree".

In computing, the working directory of a process is a directory of a hierarchical file system, if any, dynamically associated with each process. It is sometimes called the current working directory (CWD), e.g. the BSD getcwd function, or just current directory. When the process refers to a file using a simple file name or relative path, the reference is interpreted relative to the working directory of the process. So for example a process with working directory /rabbit-shoes that asks to create the file foo.txt will end up creating the file /rabbit-shoes/foo.txt.

VxD is the device driver model used in Microsoft Windows/386 2.x, the 386 enhanced mode of Windows 3.x, Windows 9x, and to some extent also by the Novell DOS 7, OpenDOS 7.01, and DR-DOS 7.02 multitasker (TASKMGR). VxDs have access to the memory of the kernel and all running processes, as well as raw access to the hardware. Starting with Windows 98, Windows Driver Model was the recommended driver model to write drivers for, with the VxD driver model still being supported for backward compatibility, until Windows Me.

A20 line Signal in the system bus of an x86-based computer system

The A20, or address line 20, is one of the electrical lines that make up the system bus of an x86-based computer system. The A20 line in particular is used to transmit the 21st bit on the address bus.

In computing, end-of-file (EOF) is a condition in a computer operating system where no more data can be read from a data source. The data source is usually called a file or stream.

High memory area

In DOS memory management, the high memory area (HMA) is the RAM area consisting of the first 65520 bytes above the one megabyte in an IBM AT or compatible computer.

A fat binary is a computer executable program or library which has been expanded with code native to multiple instruction sets which can consequently be run on multiple processor types. This results in a file larger than a normal one-architecture binary file, thus the name.

COM file

A COM file is a type of simple executable file. On the Digital Equipment Corporation (DEC) VAX operating systems of the 1970s, .COM was used as a filename extension for text files containing commands to be issued to the operating system. With the introduction of Digital Research's CP/M, the type of files commonly associated with COM extension changed to that of executable files. This convention was later carried over to DOS. Even when complemented by the more general EXE file format for executables, the compact COM files remained viable and frequently used under DOS.

The Program Segment Prefix (PSP) is a data structure used in DOS systems to store the state of a program. It resembles the Zero Page in the CP/M operating system. The PSP has the following structure:

ANSI.SYS is a device driver in the DOS family of operating systems that provides extra console functions through ANSI escape sequences. It is partially based upon a subset of the text terminal control standard proposed by the ANSI X3L2 Technical Committee on Codes and Character Sets.

Virtual DOS machines (VDM) refer to a technology that allows running 16-bit/32-bit DOS and 16-bit Windows programs when there is already another operating system running and controlling the hardware, and is a userland that originated in earlier versions of Windows and included up to Windows 10.

DOS Plus Discontinued computer operating system for x86 processors

DOS Plus was the first operating system developed by Digital Research's OEM Support Group in Newbury, Berkshire, UK, first released in 1985. DOS Plus 1.0 was based on CP/M-86 Plus combined with the PCMODE emulator from Concurrent PC DOS 4.11. While CP/M-86 Plus and Concurrent DOS 4.1 still had been developed in the United States, Concurrent PC DOS 4.11 was an internationalized and bug-fixed version brought forward by Digital Research UK. Later DOS Plus 2.x issues were based on Concurrent PC DOS 5.0 instead. In the broader picture, DOS Plus can be seen as an intermediate step between Concurrent CP/M-86 and DR DOS.

Long filename (LFN) support is Microsoft's backward compatible extension of the 8.3 filename naming scheme used in DOS. Long filenames can be more descriptive, including longer filename extensions such as .jpeg, .tiff, .html, and .xhtml that are common on other operating systems, rather than specialized shortened names such as .jpg, .tif, .htm, or .xht. The standard has been common with File Allocation Table (FAT) filesystems since its first implementation in Windows NT 3.5 of 1994.

Debug (command) Line-oriented debug utility in DOS

The line-oriented debugger DEBUG is an external command in operating systems such as DOS, OS/2 and Windows.

MSCDEX

MSCDEX or Microsoft CD-ROM Extensions is a software program produced by Microsoft and included with MS-DOS 6.x and certain versions of Windows to provide CD-ROM support. Earlier versions of MSCDEX since 1986 were installable add-ons for MS-DOS 3.1 and higher.

In Unix-like operating systems, a device file or special file is an interface to a device driver that appears in a file system as if it were an ordinary file. There are also special files in DOS, OS/2, and Windows. These special files allow an application program to interact with a device by using its device driver via standard input/output system calls. Using standard system calls simplifies many programming tasks, and leads to consistent user-space I/O mechanisms regardless of device features and functions.

SpartaDOS X

SpartaDOS X is a disk operating system for the Atari 8-bit family of computers that closely resembles MS-DOS. It was developed and sold by ICD, Inc. in 1987-1993, and many years later picked up by the third-party community SpartaDOS X Upgrade Project, which still maintains the software.

MS-DOS Microsofts discontinued operating system

MS-DOS is an operating system for x86-based personal computers mostly developed by Microsoft. Collectively, MS-DOS, its rebranding as IBM PC DOS, and few operating systems attempting to be compatible with MS-DOS, are sometimes referred to as "DOS". MS-DOS was the main operating system for IBM PC compatibles during the 1980s, from which point it was gradually superseded by operating systems offering a graphical user interface (GUI), in various generations of the graphical Microsoft Windows operating system.

DOS Group of closely related PC-compatible operating systems

DOS is a platform-independent acronym for disk operating system which later became a common shorthand for disk-based operating systems on IBM PC compatibles. DOS primarily consists of Microsoft's MS-DOS and a rebranded version under the name IBM PC DOS, both of which were introduced in 1981. Later compatible systems from other manufacturers include DR DOS (1988), ROM-DOS (1989), PTS-DOS (1993), and FreeDOS (1998). MS-DOS dominated the IBM PC compatible market between 1981 and 1995.

References

  1. 1 2 3 "FCB - Standard DOS File Control Block".
  2. 1 2 3 Rodriguez-Rosello, Miguel (1992). 8088-8086/8087 Programacion Ensamblador En Entorno MSDOS (in Spanish). Ediciones Anaya Multimedia. ISBN   84-7614-128-9.
  3. 1 2 3 4 5 6 Zbikowski, Mark; Allen, Paul; Ballmer, Steve; Borman, Reuben; Borman, Rob; Butler, John; Carroll, Chuck; Chamberlain, Mark; Chell, David; Colee, Mike; Courtney, Mike; Dryfoos, Mike; Duncan, Rachel; Eckhardt, Kurt; Evans, Eric; Farmer, Rick; Gates, Bill; Geary, Michael; Griffin, Bob; Hogarth, Doug; Johnson, James W.; Kermaani, Kaamel; King, Adrian; Koch, Reed; Landowski, James; Larson, Chris; Lennon, Thomas; Lipkie, Dan; McDonald, Marc; McKinney, Bruce; Martin, Pascal; Mathers, Estelle; Matthews, Bob; Melin, David; Mergentime, Charles; Nevin, Randy; Newell, Dan; Newell, Tani; Norris, David; O'Leary, Mike; O'Rear, Bob; Olsson, Mike; Osterman, Larry; Ostling, Ridge; Pai, Sunil; Paterson, Tim; Perez, Gary; Peters, Chris; Petzold, Charles; Pollock, John; Reynolds, Aaron; Rubin, Darryl; Ryan, Ralph; Schulmeisters, Karl; Shah, Rajen; Shaw, Barry; Short, Anthony; Slivka, Ben; Smirl, Jon; Stillmaker, Betty; Stoddard, John; Tillman, Dennis; Whitten, Greg; Yount, Natalie; Zeck, Steve (1988). "Technical advisors". The MS-DOS Encyclopedia: versions 1.0 through 3.2. By Duncan, Ray; Bostwick, Steve; Burgoyne, Keith; Byers, Robert A.; Hogan, Thom; Kyle, Jim; Letwin, Gordon; Petzold, Charles; Rabinowitz, Chip; Tomlin, Jim; Wilton, Richard; Wolverton, Van; Wong, William; Woodcock, JoAnne (Completely reworked ed.). Redmond, Washington, USA: Microsoft Press. ISBN   1-55615-049-0. LCCN   87-21452. OCLC   16581341. (xix+1570 pages; 26 cm) (NB. This edition was published in 1988 after extensive rework of the withdrawn 1986 first edition by a different team of authors. )
  4. 1 2 3 4 5 6 7 Chappell, Geoff (January 1994). Schulman, Andrew; Pedersen, Amorette (eds.). DOS Internals. The Andrew Schulman Programming Series (1st printing, 1st ed.). Addison Wesley Publishing Company. ISBN   978-0-201-60835-9. (xxvi+738+iv pages, 3.5"-floppy ) Errata:
  5. Paul, Matthias R. (1997-07-30). NWDOS-TIPs Tips & Tricks rund um Novell DOS 7, mit Blick auf undokumentierte Details, Bugs und Workarounds. MPDOSTIP. Release 157 (in German) (3 ed.). Archived from the original on 2017-08-23. Retrieved 2012-01-11. (NB. NWDOSTIP.TXT is a comprehensive work on Novell DOS 7 and OpenDOS 7.01, including the description of many undocumented features and internals. It is part of the author's yet larger MPDOSTIP.ZIP collection maintained up to 2001 and distributed on many sites at the time. The provided link points to a HTML-converted older version of the NWDOSTIP.TXT file.)

Further reading