DOS Information

See the disclaimer on the main page

This document contains information about the internal workings of the DOS operating system for PCs. Its purpose is to give an overview to those wishing to create programs to run under DOS and to those wishing to write their own version of DOS, or a DOS emulation.

Contents

Assumed knowledge: Understanding of computing terms; basic understanding of IBM-compatible computer architecture, including Intel 80x86 processor architecture; basic understanding of DOS operating system; understanding of the hexadecimal counting system and notation.

Intel is a registered trademark of Intel Corporation.
IBM and PC-DOS are registered trademarks of International Business Machines.
CP/M is a registered trademark of Digital Research


History

DOS is an abbreviation for 'Disk Operating System'. When IBM was searcing for an operating system for its newly developed PC (in 1980), the original intention was to use CP/M, a popular system already tried on other machines. The main problem was that a new 16-bit version would have to be created.

There are some rumours that there was a communication breakdown between IBM and IDR (Intergalactic Digital Research, the company who owned the rights for CP/M, now known by the less austentatious name of Digital Research), but whatever the reason, the system finally licensed was the then-small Microsoft's 'MS-DOS', which was itself adapted from 86-DOS, also known as 'QDOS' - for 'Quick and Dirty Operating System'.

Because of bugs found in the early MSDOS, IBM wrote their own version of DOS, designed to be compatible with Microsoft's specification, which they called PCDOS (presumably standing for Personal Computer Disk Operating System). To this day the two DOS's are marketed seperately by their respective companies, though the Microsoft product is by far the most popular.

Since those early times DOS has developed rather significantly. Other companies including Digital Research began to market different versions of DOS; DOS version numbers increased and DOS became more complex and powerful. The most significant advancement was version 2.0 which was designed to allow the used of hard drives, and then DOS 3.0 (3.3 by the time the bugs were removed) which had built-in support for networking. Further enhancements were also made but more and more rarely were they an internal part of DOS.

Further reference: 'DOSREF 3.3' by Dave Williams (disk based text)


Understanding DOS: How it works, how it is organized

The way in which DOS and programs interact with the computer can best be looked upon as a set of layers. The lowest layer is the hardware itself. The next layer is the BIOS, which has functions to communicate with the hardware. There are several things missing from this setup, and DOS is responsible for filling in the gaps, that is, for the sharing of memory and devices between programs, and for providing standards for allowing programs to be run. Thus DOS is the next layer.

However, in a sense, a fourth layer exists between the BIOS and DOS level (or in some cases directly between DOS and the hardware). This layer is comprised of device drivers. Device drivers are special programs which interface DOS to a hardware device (either directly or through the device).

Device drivers can be classified in various ways. The biggest distinction is between 'block devices' and 'character devices'. Block devices are devices which operate on blocks of data and are represented in DOS as disk drives, accessible through a drive letter. Character devices on the other hand will accept as little as a single byte at a time to operate on; character devices include the video screen and printers.

Some hardware devices can not be classified as either, however; an example is the mouse. Although the mouse driver could be implemented as a character device driver, this would prove inefficient and cumbersome, and mouse drivers generally do not adhere to the DOS device driver standard but rather provide functions to programs through a seperate interface.

Also, be aware that some devices which appear as block devices (in the sense that they are accessed through a drive letter) are actually using a special network interface that DOS provides (the 'redirector interface'). The allocation of physical space on such devices is allocated not by DOS but by the device driver itself, or by the hardware or network which the driver interfaces with. Such devices include network drives and CD-ROM drives. As a matter of fact, CD-ROMS are seperated even by a further layer - the MSCDEX program (Microsoft CD extensions). The redirector interface is not well documented; many references neglect to even mention it.

Note as well that a single block device driver can control more than one block device, and a single device driver file can contain more than one driver. This effectively allows one device driver to be responsible for a number of devices.

In summary, there are three types of drive devices: 'local' block devices, 'remote' network drives, and local drives using the network interface. There are also two other types of drivers: character devices and 'alternate' devices such as the mouse.

Device allocation

A higher level division of device drivers is that between internal DOS drivers and explicitly loaded device drivers. DOS contains code to interface several standard devices, and in doing so provide a number of internal device drivers (which are accessed in the same way as explicit drivers).

The internal block devices are A: and B: - the floppy drives; if no B: exists, then B: becomes a second way of referencing the first floppy. Normally, when B: is accessed after A:, the DOS internal driver displays a message 'to insert a diskette for drive B:', and when when A: is accessed after that, the same occurs 'for drive A:'. This can be used to emulate the presence of two floppy drives. C: and D: refer to the first and second hard disk drive respectively. If no hard drives exist, C: and D: will not be automatically created; if a second HD does not exist, C: but not D: will be created. No emulation of a second HD is performed.

Standard character drivers (except for NUL) can easily be replaced by installing a new driver with the same name. The character devices are:

NUL: This device simply ignores all output and gives no input. It is mainly used with re-direction on the DOS command line to suppress a program's output. NUL is the only character device driver which cannot be replaced.

COM1 - 4 (eg COM1, COM2...): The computer's serial ports. Interestingly enough, if there are less than four devices, four driver interfaces are still supported. The extras act just like the NUL driver.

LPT1 - 3 (eg LPT1, LPT2...): The computer's parallel ports. The behaviour here is the same as for the COMx devices.

PRN: An alias for LPT1

AUX: An alias for COM1

CON: Any output sent to CON will (usually) go to the screen; any input will come from the keyboard (the keys the user has pressed). This device works by calling the BIOS keyboard and video functions. DOS checks the character in the devices (keyboard's) input buffer on many function calls (depending on the value of BREAK, see the discussion of control variables in Programs Under DOS) and takes action on certain combinations (see below). Also, this device intercepts INT 1Bh calls (made by BIOS when the CTRL-BREAK key combination is pressed) and returns CTRL-C as the next character if a CTRL-BREAK has been detected.

CTRL-SPauses until another character recieved available in CON.
CTRL-P or CTRL-PrintScreenToggles transmittal of everything going to a STDOUT device, and every input that is echoed back to a STDIN device (from within a DOS function), to also go to the PRN device.
CTRL-CClears CONs input buffer, displays ^C to CON and then calls INT 23h, which by default terminates the program.

$CLOCK: The clock device is used to control the time-keeping clock on systems equipped with such a device. The $CLOCK device uses a special format for input and output, as shown below:

WORDNumber of days since 1-Jan-1980
BYTENumber of minutes since the beginning of the hour
BYTENumber of hours since the beginning of the day
BYTEHundredths of seconds (...)
BYTENumber of seconds (...)

Disk Organization

Block devices are so named because they operate on blocks of data at a time. The size of the blocks is dependent on the device; usually it is the sector size of the device to which the driver refers (usually 512 bytes). The size must always be a power of 2.

In essence, all a block device needs to be able to do is to follow instructions from DOS to read from and write to certain sectors (or clusters as they are called, as a device may use a block size of several physical sectors).

Each block device may have a certain number of 'reserved sectors' which DOS does not use. For a floppy drive, this contains the boot sector (which contains code executed if the computer is 'booted from the floppy' - usually this is done by simply resetting the computer with the floppy in the drive). Hard drives also have a 'master partition table' although this is usually made completely invisible to DOS (it is not one of the reserved sectors).

There are also a number of FATs (usually 2). a FAT is a 'file allocation table' and contains information about which clusters are being used by which files. All FATs are modified one after the other so all should be identical. If one FAT is inadvertantly destroyed, another can be used to replace it, with minimal loss of information.

Following the FATs is the root directory space. Because this space is a fixed size, there is a practical limit to the number of root directory entries. The volume label of a drive is also stored as a root directory entry. Each entry contains a file name (or volume name), date and time which the file was last altered, file attributes (volume label, directory, hidden, read-only, system and archive), size, and first cluster occupied by the file- subsequent clusters can be found by examining the FAT.

The volume label attribute describes the entry as being a volume label rather than a file. The directory attribute specifies the entry is for a directory rather than a file (though a directory is stored in the same way as a file; the format is similar to that of the root directory itself). The hidden attribute is used to signal to programs that the file should not be listed in a normal directory listing, and not interpreted as being part of a file specification that uses wild cards. The read-only attribute causes DOS to give error messages to programs attempting to write to, destroy or alter the file (although the attributes may still be altered, in order to be able to remove the read-only attribute if alteration is necessary). The system attribute has in essence the same meaning as the 'hidden' attribute; system files are considered crucial in the operation of the system, and should generally not be moved from their location on disk. The archive attribute is set by DOS whenever a file is changed, as is the file date and time (accurate to two seconds).

Raw and cooked modes, STDIN and STDOUT

Character devices may operate in two modes - 'raw' (or binary) mode and 'cooked' (or 'processed' or 'text') mode. Character devices begin operation in cooked mode.

Cooked mode means that on any 'input with echo' performed on the device, if a control character is input, it is echoed as double character, the first being a caret (^) and the second being the appropriate alphabetical character. Also, any output is scanned for CTRL-Z and if a CTRL-Z is found, the output block is terminated (that is, output only continues up until the CTRL-Z is reached, the rest of the output block is discarded; further output continues when the next output block is sent). Input from the device is also scanned: If the first character of a buffered read is CTRL-Z, no input is returned until the next read is made. However a CTRL-Z embedded within a block of input is not treated specially (tests made in DOS version 6.22)

All character devices may be flagged as being STDIN and/or STDOUT devices. Standard input devices are treated specially by DOS, in that when a buffered input occurs, the user has a chance to edit the line of input using the backspace key to delete the previous character. All characters input in this way are echoed as output to the device (so that the user can see what they are typing or inputting), the backspace key is converted to 'backspace-space-backspace' (so that it overwrites the character which would otherwise be left visible for this purpose). STDOUT only has special purpose when printer echo is turned on (see DOS interface to programs).

The DOS interface

When a program is executed under DOS, it is expected to communicate with DOS (if necessary) using a standard interface. Most DOS functions can be accessed using Interrupt 21h. Through the Int 21h interface, file and device I/O can occur, memory* can be allocated and de-allocated (freed), and various system functions can be performed. On some DOS function calls (exactly which depends on the status of the BREAK variable; see below and consult function call reference for more information), the CON device's input buffer is checked for various key combinations; see the CON device description under Device Allocation for more info.

Most input/output is performed using a 'handle' which is a numerical value indicating to DOS upon what the operation in question is to be performed. The five standard devices are 'open' and assigned a handle automatically; these are STDIN: 0, STDOUT: 1, STDERR: 2, STDAUX: 3, STPRN: 4. Interestingly enough any device can be assigned as a STDIN or STDOUT device, though the STDIN and STDOUT of a program by default refers to the CON device. STDIN (standard input) is usually assigned to the CON device and thus the computer's keyboard, STDOUT is usually also assigned to the CON device and so the video screen (both STDOUT and STDIN can be redirected on the DOS command line using the COMMAND.COM interpreter), STDAUX is usually AUX, STDPRN is usually PRN, and STDERR is also a reference to CON (for the purpose of displaying messages that must be seen even if output has been redirected). Note that a program refers to a standard device by number and not by name.

Any other I/O requires that the file or device be 'opened' first. The open request is made by the application using the Int 21h interface, and DOS returns (assuming no error occurs) a handle that the application can use in subsequent requests (known as 'calls'). When the application is finished with the file or device, the handle is 'closed' using another DOS call.

* DOS will only directly access the first 640 kilobytes of memory. Enhancements which allow the use of UMBs (upper memory blocks) allow access to a full megabyte of memory. Further memory is considered 'expanded' or 'extended' according to the way in which it is accessed, and can be allocated or deallocated using the appropriate interface for the type. This is beyond the scope of this document.


Internal Operation and Structures

In keeping track of all the things that it manages, DOS maintains many lists and control structures for various different purposes. DOS also maintains a 'list-of-lists' containing pointers to the locations of these structures in memory, mainly to make them accessible to applications. The format of the list-of-lists has been altered in the past, but is unlikely to change much further due to the incompatibility this would create. Much of the data can be found in the 'DOS data segment', which is also now somewhat confined in format.

The 'System File Tables' (SFTs) contain information about all the presently open files. The SFTs are stored in a chain so that in knowing the address of the first, the address of subsequent tables can be found.

The 'Current Directory Structures' maintain information about the current directory of each logical drive. These structures can be manipulated to create redirection (whereby one drive unit actually references a different drive, or even a subdirectory of another drive), including network redirection. This is how the DOS SUBST command works.

'File Control Blocks' (FCBs) are an obselete method of file access, now replaced with the file handle functions. DOS still supports the FCB functions to maintain compatibility with previous versions, but now all FCB files also have an entry in the SFTs. The FCB functions are really just 'layered over' the handle functions.

'Memory Control Blocks' (MCBs) are headers at the start of each allocated and free memory block, giving information about the size of the block as well as information such as what program 'owns' the block (that is, what application requested the allocation of the block). For Upper Memory Blocks (those beyond the 640KB barrier), the corresponding control blocks are known as 'UMCBs'.

'Program Segment Prefixes' or PSPs are structures containing information local to specific programs. Every running program should have a PSP. When a program exits, the PSP is destroyed and the memory it occupies is freed. The main use of PSPs is to hold a 'local file table' which actually contains indexes into the SFTs.

In most applications, there will be no need to manipulate these structures directly; DOS does everything necessary when requested to do so (for instance, when a file is opened by an application, the application's PSP file table is updated and a new entry (if necessary) is created in the SFTs.


Programs under DOS

There are two main types of programs which can run under DOS: The first, device drivers, have already been mentioned. Device drivers are loaded when DOS starts up. Usually, a command in the CONFIG.SYS file is used to start the drivers. Device drivers have a very specific purpose and need little further discussion.

Then there are application programs (which can also take the form of utilities, games etc). These programs are stored in 'executable files' on a DOS drive. Programs can be loaded in one of two ways: By DOS at boot time (if the program is the 'shell'; the default shell is of course 'COMMAND.COM', the command-line interpreter), or by starting them from within another program (for instance, starting a program by typing its name on the command line).

All DOS programs have their own data information block called a 'Program Segment Prefix' (PSP). The PSP contains information about the currently running program, including the return address to the parent program (or 'parent process': The process which caused the 'child' process to execute), and information about what files the program has opened (in the form of indexes into the system file table). The program references files through an index into its own internal table; these local indexes are also known as 'file handles'.

DOS programs also have an 'environment' (or 'environment table', or 'environment string table') which is a number of named strings of text of any value. Any program inherits an exacr copy of its parent's environment (except of course the shell, which has no parent). The environment variables as they are called are used to keep track of information and provide information that is easily accessible to all programs. Environment variables and their values have no direct meaning to the DOS kernel, but many DOS utilities and programs make use of them - for example, the command interpreter:

Two variables commonly used by many programs are 'TEMP' and 'TMP', which are used to specify a 'temporary directory' into which 'temporary files' (non-permanent files created by programs, usually as a form of virtual memory). Personally I prefer programs using 'TEMP'.

Programs also have access to certain global DOS variables. These are the 'Verify' switch (which when 'on' causes DOS to verify any write operation is performed correctly, by reading the information back from the device and comparing it with what was supposed to be written) and the 'Break' switch (which controls how often checking for Control-C from standard input is performed). DOS also keeps a 'machine name' which is generally used only in networking systems to identify a node of the network.

DOS allows its programs a great deal of freedom. As DOS is a real mode operating system, direct hardware manipulation (using IO ports or BIOS) is possible, though wherever possible, the use of DOS functions is recommended. The use of direct hardware programming and BIOS gives much flexibility to DOS programs.