Jump to content
 







Main menu
   


Navigation  



Main page
Contents
Current events
Random article
About Wikipedia
Contact us
Donate
 




Contribute  



Help
Learn to edit
Community portal
Recent changes
Upload file
 








Search  

































Create account

Log in
 









Create account
 Log in
 




Pages for logged out editors learn more  



Contributions
Talk
 



















Contents

   



(Top)
 


1 Usage  





2 Disk Transfer Area  





3 Program Segment Prefix & Program Initialisation  





4 See also  





5 References  





6 Further reading  














File Control Block






Català
Deutsch
Español

Қазақша
Русский
 

Edit links
 









Article
Talk
 

















Read
Edit
View history
 








Tools
   


Actions  



Read
Edit
View history
 




General  



What links here
Related changes
Upload file
Special pages
Permanent link
Page information
Cite this page
Get shortened URL
Download QR code
Wikidata item
 




Print/export  



Download as PDF
Printable version
 
















Appearance
   

 






From Wikipedia, the free encyclopedia
 


AFile 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, provided it can spare enough memory for an FCB per file.

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, led 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]

Offset Byte
size
Contents
0x00 1 Drive number — 0 for default, 1 for A:, 2 for B:, ...
0x01 8 File name and extension — together these form a 8.3 file name.
0x09 3
0x0C 20 Implementation dependent — should be initialised to zero before the FCB is opened.
0x20 1 Record number in the current section of the file — used when performing sequential access.
0x21 3 Record 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]

Offset Byte
size
Contents
0x0E 2 File's record length in bytes.
0x10 4 Total file size in bytes.
0x14 2 Date of last modification to file contents.
0x16 2 Time 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[edit]

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 whether SHARE.EXE is loaded and whether the FCB refers to a local or remote file and often refers 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[edit]

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[edit]

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]

Offset Byte
size
Contents
0x02 2 Available memory for the program in 16-byte chunks.
0x2C 2 Segment address containing the program's environment variables.
0x5C 16 Prepared FCB for first command line argument (unopened).
0x6C 20 Prepared FCB for second command line argument (unopened).
0x80 1 Length of command line.
0x81 127 Command 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[edit]

References[edit]

  1. ^ a b c "FCB - Standard DOS File Control Block".
  • ^ a b c Rodriguez-Rosello, Miguel (1992). 8088-8086/8087 Programacion Ensamblador En Entorno MSDOS (in Spanish). Ediciones Anaya Multimedia. ISBN 84-7614-128-9.
  • ^ a b c d e f 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. [1])
  • ^ a b c d e f g 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 [2][3]) Errata: [4][5][6]
  • ^ Paul, Matthias R. (1997-07-30). NWDOS-TIPs — Tips & Tricks rund um Novell DOS 7, mit Blick auf undokumentierte Details, Bugs und Workarounds. Release 157 (in German) (3 ed.). Archived from the original on 2017-08-23. Retrieved 2012-01-11. {{cite book}}: |work= ignored (help) (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[edit]


    Retrieved from "https://en.wikipedia.org/w/index.php?title=File_Control_Block&oldid=1116761064"

    Categories: 
    Disk file systems
    CP/M technology
    DOS technology
    Hidden categories: 
    CS1 Spanish-language sources (es)
    CS1 errors: periodical ignored
    CS1 German-language sources (de)
    Articles needing additional references from January 2014
    All articles needing additional references
    Wikipedia articles that are too technical from October 2022
    All articles that are too technical
    Articles with multiple maintenance issues
    Use dmy dates from May 2019
     



    This page was last edited on 18 October 2022, at 05:49 (UTC).

    Text is available under the Creative Commons Attribution-ShareAlike License 4.0; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.



    Privacy policy

    About Wikipedia

    Disclaimers

    Contact Wikipedia

    Code of Conduct

    Developers

    Statistics

    Cookie statement

    Mobile view



    Wikimedia Foundation
    Powered by MediaWiki