home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Power-Programmierung
/
CD2.mdf
/
doc
/
dosref22
/
chapter.007
< prev
next >
Wrap
Text File
|
1992-01-11
|
36KB
|
620 lines
** Programmer's Technical Reference for MSDOS and the IBM PC **
USA copyright TXG 392-616 ALL RIGHTS RESERVED
───────────────────────────────┤ DOSREF (tm) ├────────────────────────────────
ISBN 1-878830-02-3 (disk-based text)
Copyright (c) 1987, 1992 Dave Williams
┌─────────────────────────────┐
│ Shareware Version, 01/12/92 │
│ Please Register Your Copy │
└─────────────────────────────┘
C H A P T E R S E V E N
DOS FILE STRUCTURE
FILE MANAGEMENT FUNCTIONS├─────────────────────────────────────────────────────
Use DOS function calls to create, open, close, read, write, rename, find, and
erase files. There are two sets of function calls that DOS provides for support
of file management. They are:
* File Control Block function calls (0Fh-24h)
* Handle function calls (39h-69h)
Handle function calls are easier to use and are more powerful than FCB calls.
Microsoft recommends that the handle function calls be used when writing new
programs. DOS 3.0 up have been curtailing use of FCB function calls; it is
possible that future versions of DOS may not support FCB function calls.
The following table compares the use of FCB calls to Handle function calls:
┌──────────────────────────────┬─────────────────────────────────────────┐
│ FCB Calls │ Handle Calls │
├──────────────────────────────┼─────────────────────────────────────────┤
│ Access files in current │ Access files in ANY directory │
│ directory only. │ │
│ │ │
│ Requires the application │ Does not require use of an FCB. │
│ program to maintain a file │ Requires a string with the drive, │
│ control block to open, │ path, and filename to open, create, │
│ create, rename or delete │ rename, or delete a file. For file │
│ a file. For I/O requests, │ I/O requests, the application program │
│ the application program │ must maintain a 16 bit file handle │
│ also needs an FCB │ that is supplied by DOS. │
└──────────────────────────────┴─────────────────────────────────────────┘
The only reason an application should use FCB function calls is to maintain
the ability to run under DOS 1.x. To to this, the program may use only function
calls 00h-2Eh. Though the FCB function calls are frowned upon, many of the
introductory assembly language programming texts use the FCB calls as examples.
FCB FUNCTION CALLS ├───────────────────────────────────────────────────────────
FCB function calls require the use of one File Control Block per open file,
which is maintained by the application program and DOS. The application program
supplies a pointer to the FCB and fills in ther appropriate fields required by
the specific function call. An FCB function call can perform file management on
any valid drive, but only in the current logged directory. By using the current
block, current record, and record length fields of the FCB, you can perform
sequential I/O by using the sequential read or write function calls. Random I/O
can be performed by filling in the random record and record length fields.
Several possible uses of FCB type calls are considered programming errors and
should not be done under any circumstances to avoid problems with file sharing
and compatibility with later versions of DOS.
Some errors are:
1) If program uses the same FCB structure to access more than one open file. By
opening a file using an FCB, doing I/O, and then replacing the filename field
in the file control block with a new filename, a program can open a second
file using the same FCB. This is invalid because DOS writes control info-
rmation about the file into the reserved fields of the FCB. If the program
then replaces the filename field with the original filename and then tries to
perform I/O on this file, DOS may become confused because the control info-
rmation has been changed. An FCB should never be used to open a second file
without closing the one that is currently open. If more than one File Control
Block is to be open concurrently, separate FCBs should be used.
2) A program should never try to use the reserved fields in the FCB, as the
function of the fields changes with different versions of DOS.
3) A delete or a rename on a file that is currently open is considered an error
and should not be attempted by an application program.
It is also good programming practice to close all files when I/O is done. This
avoids potential file sharing problems that require a limit on the number of
files concurrently open using FCB function calls.
HANDLE FUNCTION CALLS├─────────────────────────────────────────────────────────
The recommended method of file management is by using the extended "handle"
set of function calls. These calls are not restricted to the current directory.
Also, the handle calls allow the application program to define the type of
access that other processes can have concurrently with the same file if the file
is being shared.
To create or open a file, the application supplies a pointer to an ASCIIZ
string giving the name and location of the file. The ASCIIZ string contains an
optional drive letter, optional path, mandatory file specification, and a
terminal byte of 00h. The following is an example of an ASCIIZ string:
format [drive][path] filename.ext,0
DB "A:\path\filename.ext",0
If the file is being created, the application program also supplies the
attribute of the file. This is a set of values that defines the file read
only, hidden, system, directory, or volume label.
If the file is being opened, the program can define the sharing and access
modes that the file is opened in. The access mode informs DOS what operations
your program will perform on this file (read-only, write-only, or read/write)
The sharing mode controls the type of operations other processes may perform
concurrently on the file. A program can also control if a child process inherits
the open files of the parent. The sharing mode has meaning only if file sharing
is loaded when the file is opened.
To rename or delete a file, the appplication program simply needs to provide
a pointer to the ASCIIZ string containing the name and location of the file
and another string with the new name if the file is being renamed.
The open or create function calls return a 16-bit value referred to as the
file handle. To do any I/O to a file, the program uses the handle to reference
the file. Once a file is opened, a program no longer needs to maintain the
ASCIIZ string pointing to the file, nor is there any need to stay in the same
directory. DOS keeps track of the location of the file regardless of what
directory is current.
Sequential I/O can be performed using the handle read (3Fh) or write (40h)
function calls. The offset in the file that IO is performed to is automatically
moved to the end of what was just read or written. If random I/O is desired, the
LSEEK (42h) function call can be used to set the offset into the file where I/O
is to be performed.
SPECIAL FILE HANDLES├──────────────────────────────────────────────────────────
DOS reserves five special file handles for use by itself and applications
programs. They are:
┌───────┬────────┬─────────────────────────────────────────────────────────────┐
│ 0000h │ STDIN │ standard input device (input can be redirected) │
│ 0001h │ STDOUT │ standard output device (output can be redirected) │
│ 0002h │ STDERR │ standard error output device (output cannot be redirected) │
│ 0004h │ STDAUX │ standard auxiliary device │
│ 0005h │ STDPRN │ standard printer device │
└───────┴────────┴─────────────────────────────────────────────────────────────┘
These handles are predefined by DOS and can be used by an application program.
They do not need to be opened by a program, although a program can close these
handles. STDIN should be treated as a read-only file, and STDOUT and STDERR
should be treated as write-only files. STDIN and STDOUT can be redirected. All
handles inherited by a process can be redirected, but not at the command line.
These handles are very useful for doing I/O to and from the console device.
For example, you could read input from the keyboard using the read (3Fh)
function call and file handle 0000h (STDIN), and write output to the console
screen with the write function call (40h) and file handle 0001h (STDOUT). If
you wanted an output that could not be redirected, you could output it using
file handle 0002h (STDERR). This is very useful for error messages that must
be seen by a user.
File handles 0003h (STDAUX) and 0004h (STDPRN) can be both read from and
written to. STDAUX is typically a serial device and STDPRN is usually a parallel
device.
ASCII and BINARY MODE├─────────────────────────────────────────────────────────
I/O to files is done in binary mode. This means that the data is read or
written without modification. However, DOS can also read or write to devices in
ASCII mode. In ASCII mode, DOS does some string processing and modification to
the characters read and written. The predefined handles are in ASCII mode when
initialized by DOS. All other file handles that don't refer to devices are in
binary mode. A program, can use the IOCTL (44h) function call to set the mode
that I/O is to a device. The predefined file handles are all devices, so the
mode can be changed from ASCII to binary via IOCTL. Regular file handles that
are not devices are always in binary mode and cannot be changed to ASCII mode.
The ASCII/BINARY bit was called "raw" in DOS 2.x, but it is called ASCII/BINARY
in DOS 3.x.
The predefined file handles STDIN (0000h) and STDOUT (0001h) and STDERR
(0002h) are all duplicate handles. If the IOCTL function call is used to change
the mode of any of these three handles, the mode of all three handles is
changed. For example, if IOCTL was used to change STDOUT to binary mode, then
STDIN and STDERR would also be changed to binary mode.
FILE I/O IN BINARY (RAW) MODE├─────────────────────────────────────────────────
The following is true when a file is read in binary mode:
1) The characters ^S (scroll lock), ^P (print screen), ^C (control break) are
not checked for during the read. Therefore, no printer echo occurs if ^S or
^P are read.
2) There is no echo to STDOUT (0001h).
3) Read the number of specified bytes and returns immediately when the last
byte is received or the end of file reached.
4) Allows no editing of the ine input using the function keys if the input is
from STDIN (0000h).
The following is true when a file is written to in binary mode:
1) The characters ^S (scroll lock), ^P (print screen), ^C (control break) are
not checked for during the write. Therefore, no printer echo occurs.
2) There is no echo to STDOUT (0001h).
3) The exact number of bytes specified are written.
4) Does not caret (^) control characters. For example, ctrl-D is sent out as
byte 04h instead of the two bytes ^ and D.
5) Does not expand tabs into spaces.
FILE I/O IN ASCII (COOKED) MODE├───────────────────────────────────────────────
The following is true when a file is read in ASCII mode:
1) Checks for the characters ^C,^S, and ^P.
2) Returns as many characters as there are in the device input buffer, or the
number of characters requested, whichever is less. If the number of
characters requested was less than the number of characters in the device
buffer, then the next read will address the remaining characters in the
buffer.
3) If there are no more bytes remaining in the device input buffer, read a
line (terminated by ^M) into the buffer. This line may be edited with the
function keys. The characters returned terminated with a sequence of 0Dh,
0Ah (^M,^J) if the number of characters requested is sufficient to include
them. For example, if 5 characters were requested, and only 3 were entered
before the carriage return (0Dh or ^M) was presented to DOS from the console
device, then the 3 characters entered and 0Dh and 0Ah would be returned.
However, if 5 characters were requested and 7 were entered before the
carriage return, only the first 5 characters would be returned. No 0Dh,0Ah
sequence would be returned in this case. If less than the number of
characters requested are entered when the carriage return is received, the
characters received and 0Dh,0Ah would be returned. The reason the 0Ah
(linefeed or ^J) is added to the returned characters is to make the devices
look like text files.
4) If a 1Ah (^Z) is found, the input is terminated at that point. No 0Dh,0Ah
(CR,LF) sequence is added to the string.
5) Echoing is performed.
6) Tabs are expanded.
The following is true when a file is written to in ASCII mode:
1) The characters ^S,^P,and ^C are checked for during the write operation.
2) Expands tabs to 8-character boundaries and fills with spaces (20h).
3) Carets control characters, for example, ^D is written as two bytes, ^ and D.
4) Bytes are output until the number specified is output or a ^Z is
encountered. The number actually output is returned to the user.
NUMBER OF OPEN FILES ALLOWED├──────────────────────────────────────────────────
The number of files that can be open concurrently is restricted by DOS. This
number is determined by how the file is opened or created (FCB or handle
function call) and the number specified by the FCBS and FILES commands in the
CONFIG.SYS file. The number of files allowed open by FCB function calls and the
number of files that can be opened by handle type calls are independent of one
another.
RESTRICTIONS ON FCB USAGE├─────────────────────────────────────────────────────
If file sharing is not loaded using the SHARE command, there are no
restrictions on the nuumber of files concurrently open using FCB function calls.
However, when file sharing is loaded, the maximum number of FCBs open is set
by the the FCBS command in the CONFIG.SYS file.
The FCBS command has two values you can specify, 'm' and 'n'. The value for
'm' specifies the number of files that can be opened by FCBs, and the value 'n'
specifies the number of FCBs that are protected from being closed.
When the maximum number of FCB opens is exceeded, DOS automatically closes the
least recently used file. Any attempt to access this file results in an int 24h
critical error message "FCB not availible". If this occurs while an application
program is running, the value specified for 'm' in the FCBS command should be
increased.
When DOS determines the least recently used file to close, it does not include
the first 'n' files opened, therefore the first 'n' files are protected from
being closed.
RESTRICTIONS ON HANDLE USAGE├──────────────────────────────────────────────────
The number of files that can be open simultaneously by all processes is
determined by the FILES command in the CONFIG.SYS file. The number of files a
single process can open depends on the value specified for the FILES command. If
FILES is greater than or equal to 20, a single process can open 20 files. If
FILES is less than 20, the process can open less than 20 files. This value
includes three predefined handles: STDIN, STDOUT, and STDERR. This means only
17 additional handles can be added. DOS 3.3 includes a function to use more than
20 files per application.
ALLOCATING SPACE TO A FILE├────────────────────────────────────────────────────
Files are not nescessarily written sequentially on a disk. Space is allocated
as needed and the next location availible on the disk is allocated as space for
the next file being written. Therefore, if considerable file generation has
taken place, newly created files will not be written in sequential sectors.
However, due to the mapping (chaining) of file space via the File Allocation
Table (FAT) and the function calls availible, any file may be used in either a
sequential or random manner.
Space is allocated in increments called clusters. Cluster size varies
according to the media type. An application program should not concern itself
with the way that DOS allocates space to a file. The size of a cluster is only
important in that it determines the smallest amount of space that can be
allocated to a file. A disk is considered full when all clusters have been
allocated to files.
MSDOS / PCDOS DIFFERENCES├─────────────────────────────────────────────────────
There is a problem of compatibility between MS-DOS and IBM PC-DOS having to
do with FCB Open and Create. The IBM 1.0, 1.1, and 2.0 documentation of OPEN
(call 0Fh) contains the following statement:
"The current block field (FCB bytes C-D) is set to zero [when an FCB is
opened]."
This statement is NOT true of MS-DOS 1.25 or MS-DOS 2.00. The difference is
intentional, and the reason is CP/M 1.4 compatibility. Zeroing that field is
not CP/M compatible. Some CP/M programs will not run when machine translated if
that field is zeroed. The reason it is zeroed in the IBM versions is that IBM
specifically requested that it be zeroed. This is the reason for the complaints
from some vendors about the fact that IBM MultiPlan will not run under MS-DOS.
It is probably the reason that some other IBM programs don't run under MS-DOS.
NOTE: Do what all MS/PC-DOS systems programs do: Set every single FCB field you
want to use regardless of what the documentation says is initialized.
.COM FILE STRUCTURE├───────────────────────────────────────────────────────────
The COM file structure was designed for DOS 1.0 and maximum compatibility
with programs ported from the CP/M operating system. COM files normally
comprise one segment only.
.EXE FILE STRUCTURE├───────────────────────────────────────────────────────────
The EXE file is the native mode for DOS. EXE files may make use of multiple
segments for code, stack, and data. The design of the EXE file reflects the
segmented design of the Intel 80x86 CPU architecture. EXE files may be as
large as availible memory and may make references to specific segment addresses.
The EXE files produced by the Linker program consist of two parts, control and
relocation information and the load module itself.
The control and relocation information, which is described below, is at the
beginning of the file in an area known as the header. The load module
immediately follows the header. The load module begins in the memory image of
the module contructed by the Linker.
When you are loading a file with the name *.EXE, DOS does NOT assume that it
is an EXE format file. It looks at the first two bytes for a signature telling
it that it is an EXE file. If it has the proper signature, then the load
proceeds. Otherwise, it presumes the file to be a .COM format file.
If the file has the EXE signature, then the internal consistency is checked.
Pre-2.0 versions of MSDOS did not check the signature byte for EXE files.
The .EXE format can support programs larger than 64K. It does this by
allowing separate segments to be defined for code, data, and the stack, each
of which can be up to 64K long. Programs in EXE format may contain explicit
references to segment addresses. A header in the EXE file has information for
DOS to resolve these references.
The .EXE header is formatted as follows:
┌─────────┬───────────────────────────────────────────────────────────────────┐
│ Offset │ C O N T E N T S │
├─────────┼─────┬─────────────────────────────────────────────────────────────┤
│ 00h │ 4Dh │ This is the Linker's signature to mark the file as a valid │
├─────────┼─────┤ .EXE file (The ASCII letters M and Z, for Mark Zbikowski, │
│ 01h │ 5Ah │ one of the major designers of DOS at Microsoft) │
├─────────┼─────┴─────────────────────────────────────────────────────────────┤
│ 02h-03h │ Length of the image mod 512 (remainder after dividing the load │
│ │ module image size by 512) │
├─────────┼───────────────────────────────────────────────────────────────────┤
│ 04h-05h │ Size of the file in 512 byte pages including the header. │
├─────────┼───────────────────────────────────────────────────────────────────┤
│ 06h-07h │ Number of relocation table items following the header. │
├─────────┼───────────────────────────────────────────────────────────────────┤
│ 08h-09h │ Size of the header in 16 byte increments (paragraphs). This is │
│ │ used to locate the beginning of the load module in the file. │
├─────────┼───────────────────────────────────────────────────────────────────┤
│ 0Ah-0Bh │ Minimum number of 16 byte paragraphs required above the end of │
│ │ the loaded program. │
├─────────┼───────────────────────────────────────────────────────────────────┤
│ 0Ch-0Dh │ Maximum number of 16 byte paragraphs required above the end of │
│ │ the loaded program. If the minimum and maximum number of │
│ │ paragraphs are both zero, the program will be loaded as high in │
│ │ memory as possible. │
├─────────┼───────────────────────────────────────────────────────────────────┤
│ 0Eh-0Fh │ Displacement in paragraphs of stack segment within load module. │
│ │ This size must be adjusted by relocation. │
├─────────┼───────────────────────────────────────────────────────────────────┤
│ 10h-11h │ Offset to be in SP register when the module is given control. │
├─────────┼───────────────────────────────────────────────────────────────────┤
│ 12h-13h │ Word Checksum - negative sum of all the words in the file, │
│ │ ignoring overflow. │
├─────────┼───────────────────────────────────────────────────────────────────┤
│ 14h-15h │ Offset to be in the IP register when the module is given control. │
├─────────┼───────────────────────────────────────────────────────────────────┤
│ 16h-17h │ Displacement in paragraphs of code segment within load module. │
│ │ This size must be adjusted by relocation. │
├─────────┼───────────────────────────────────────────────────────────────────┤
│ 18h-19h │ Displacement in bytes of the first relocation item in the file. │
├─────────┼───────────────────────────────────────────────────────────────────┤
│ 1Ah-1Bh │ Overlay number (0 for the resident part of the program) │
└─────────┴───────────────────────────────────────────────────────────────────┘
THE RELOCATION TABLE├──────────────────────────────────────────────────────────
The word at 18h locates the first entry in the relocation table. The
relocation table is made up of a variable number of relocation items. The number
of items is contained at offset 06-07. The relocation item contains two fields
- a 2 byte offset value, followed by a 2 byte segment value. These two fields
represent the displacement into the load module before the module is given
control. The process is called relocation and is accomplished as follows:
1. The formatted part of the header is read into memory. Its size is 1Bh.
2. A portion of memory is allocated depending on the size of the load module
and the allocation numbers in offsets 0Ah-0Ch and 0Ch-0Dh. DOS always
tries to allocate 0FFFFh paragraphs. Since this call will always fail,
the function returns the amount of free memory. If this block is larger
than the minimum specified at offset 0Ah and the loaded program size,
DOS will allocate the size specified at offset 0Ch or the largest free
memory space, whichever is less.
3. A Program Segment Prefix is built following the resident portion of the
program that is performing the load operation.
4. The formatted part of the header is read into memory (its size is at
offset 08h)
5. The load module size is determined by subtracting the header size from the
file size. Offsets 04h and 08h can be used for this calculation. The
actual size is downward adjusted based on the contents of offsets 02-03.
Note that all files created by the Linker programs prior to version 1.10
always placed a value of 4 at this location, regardless of the actual
program size. Therefore, Microsoft recommends that this field be ignored if
it contains a value of 4. Based on the setting of the high/low loader switch,
an appropriate segment is determined for loading the load module. This
segment is called the start segment.
6. The load module is read into memory beginning at the start segment. The
relocation table is an ordered list of relocation items. The first relocation
item is the one that has the lowest offset in the file.
7. The relocation table items are read into a work area one or more at a time.
8. Each relocation table item segment value is added to the start segment value.
The calculated segment, in conjunction with the relocation item offset value,
points to a word in the load module to which is added the start segment
value. The result is placed back into the word in the load module.
9. Once all the relocation items have been processed, the SS and SP registers
are set from the values in the header and the start segment value is added
to SS. The ES and DS registers are set to the segment address of the program
segment prefix. The start segment value is added to the header CS register
value. The result, along with the header IP value, is used to give the
module control.
"NEW" .EXE FORMAT (Microsoft Windows and OS/2)├────────────────────────────────
The "old" EXE format is documented here. The "new" EXE format puts more
information into the header section and is currently used in applications that
run under Microsoft Windows. The linker that creates these files comes with the
Microsoft Windows Software Development Kit and is called LINK4. If you try to
run a Windows-linked program under DOS, you will get the error message "This
program requires Microsoft Windows".
PIF Files
PIF stands for "Program Information File". The PIF format was developed by
IBM for use with TopView, its multitasking manager. Microsoft also uses PIF
files to pass information regarding the amount of memory and type of I/O a
program running under Microsoft Windows requires.
The actual internal format of the PIF files is documented in the IBM TopView
Programmers' ToolKit.
STANDRD FILE CONTROL BLOCK├────────────────────────────────────────────────────
The standard file control block is defined as follows, with offsets in hex:
┌──────────────────────────────────────────────────────────────────────────────┐
│ F I L E C O N T R O L B L O C K │
├───────┬──────────────────────────────────────────────────────────────────────┤
│ Bytes │ Function │
├───────┼──────────────────────────────────────────────────────────────────────┤
│ 0 │ 1 byte Drive number. For example: │
│ │ Before open: 00h = default drive │
│ │ 01h = drive A: │
│ │ 02h = drive B: etc. │
│ │ After open: 00h = drive C: │
│ │ 01h = drive A: │
│ │ 02h = drive B: etc. │
│ │ An 0 is replaced by the actual drive number during open. │
├───────┼──────────────────────────────────────────────────────────────────────┤
│ 1-8 │ 8 bytes Filename, left justified with blanks. If a reserved device │
│ │ name is placed here (such as PRN) do not include the optional colon. │
├───────┼──────────────────────────────────────────────────────────────────────┤
│ 9-B │ 3 bytes Filename extension, left justified with trailing blanks. │
├───────┼──────────────────────────────────────────────────────────────────────┤
│ C-D │ 2 bytes Current block # relative to start of file, starting with 0 │
│ │ (set to 0 by the open function call). A block consists of 128 │
│ │ records, each of the size specified in the logical record size field.│
│ │ The current block number is used with the current record field │
│ │ (below) for sequential reads and writes. │
├───────┼──────────────────────────────────────────────────────────────────────┤
│ E-F │ 2 bytes Logical record size in bytes. Set to 80h by OPEN function │
│ │ If this is not correct, you must set the value because DOS uses it │
│ │ to determine the proper locations in the file for all disk reads and │
│ │ writes. │
├───────┼──────────────────────────────────────────────────────────────────────┤
│ 10-13 │ 4 bytes File size in bytes. In this field, the first word is the │
│ │ low-order part of the size. │
├───────┼──────────────────────────────────────────────────────────────────────┤
│ 14-15 │ 2 bytes Date file was created or last updated. mm/dd/yy are mapped │
│ │ as follows: │
│ │ 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 │
│ │ y y y y y y y m m m m d d d d d │
│ │ where: mm is 1-12 │
│ │ dd is 1-31 │
│ │ yy is 0-119 (1980-2099) │
├───────┼──────────────────────────────────────────────────────────────────────┤
│ 16-17 │ 2 bytes time file was created or last updated. │
├───────┼──────────────────────────────────────────────────────────────────────┤
│ │ These bytes contain the time when the file was created or last │
│ │ updated. The time is mapped in the bits as follows: │
│ ├───────────────────────────────┬───────────────────────────────┐ │
│ │ B Y T E 16h │ B Y T E 17h │ │
│ ├───────────────────────────────┼───────────────────────────────┤ │
│ │ F E D C B A 9 8 │ 7 6 5 4 3 2 1 0 │ │
│ ├───────────────────┬───────────┴───────────┬───────────────────┤ │
│ │ H H H H H │ M M M M M M │ D D D D D │ │
│ ├───────────────────┼───────────────────────┼───────────────────┤ │
│ │ binary # hrs 0-23 │ binary # minutes 0-59 │ bin. # 2-sec incr │ │
│ ├───────────────────┴───────────────────────┴───────────────────┘ │
│ │ note: The time is stored with the least significant byte first. │
├───────┼──────────────────────────────────────────────────────────────────────┤
│ 18-19 │ 2 bytes Reserved for DOS. │
├───────┼──────────────────────────────────────────────────────────────────────┤
│ 20 │1 byte Current relative record number (0-127) within the current │
│ │ block. This field and the Current Block field at offset 0Ch make up │
│ │ the record pointer. This field is not initialized by the OPEN │
│ │ function call. You must set this field before doing sequential read- │
│ │ write operations to the diskette. │
├───────┼──────────────────────────────────────────────────────────────────────┤
│ 21-25 │ 4 bytes Relative Record. Points to the currently selected record, │
│ │ counting from the beginning of the file starting with 0. This field │
│ │ is not initialized by the OPEN system call. You must set this field │
│ │ before doing a random read or write to the file. │
│ │ If the record size is less than 64 bytes, both words are used. │
│ │ Otherwise, only the first 3 bytes are used. Note that if you use the │
│ │ File Control Block at 5Ch in the program segment, the last byte of │
│ │ the FCB overlaps the first byte of the unformatted parameter area. │
└───────┴──────────────────────────────────────────────────────────────────────┘
note 1) An unopened FCB consists of the FCB prefix (if used), drive number, and
filename.ext properly filled in. An open FCB is one in which the
remaining fields have been filled in by the CREAT or OPEN function
calls.
2) Bytes 0-5 and 32-36 must be set by the user program. Bytes 16-31 are set
by DOS and must not be changed by user programs.
3) All word fields are stored with the least significant byte first. For
example, a record length of 128 is stored as 80h at offset 14, and 00h
at offset 15.
EXTENDED FILE CONTROL BLOCK├───────────────────────────────────────────────────
The extended file control block is used to create or search for files in the
disk directory that have special attributes.
It adds a 7 byte prefix to the FCB, formatted as follows:
┌──────────────────────────────────────────────────────────────────────────────┐
│ E X T E N D E D F I L E C O N T R O L B L O C K │
├───────┬──────────────────────────────────────────────────────────────────────┤
│ Bytes │ Function │
├───────┼──────────────────────────────────────────────────────────────────────┤
│ 0 │ Flag byte containing 0FFh to indicate an extended FCB. │
├───────┼──────────────────────────────────────────────────────────────────────┤
│ 1-6 │ Reserved │
├───────┼──────────────────────────────────────────────────────────────────────┤
│ 6-7 │ Attribute byte. Refer to function call 11h (search first) for │
│ │ details on using the attribute bits during directory searches. This │
│ │ function is present to allow applications to define their own files │
│ │ as hidden (and thereby excluded from normal directory searches) and │
│ │ to allow selective directory searches. │
└───────┴──────────────────────────────────────────────────────────────────────┘
Any reference in the DOS function calls to an FCB, whether opened or unopened,
may use either a normal or extended FCB. If you are using an extended FCB, the
appropriate register should be set to the first byte of the prefix, rather than
the drive-number field.
Common practice is to refer to the extended FCB as a negative offset from the
first byte of a standard File Control Block.