DOS-C Architecture

The DOS-C architecture is a layered one similar to what you'll find in other operating systems. The only difference between DOS-C and other monolithic operating systems is that there is a decoupling between the upper and lower layers of the operating system. To guarantee that DOS-C is MS-DOS compatible, there are two interface layers where full compliance is necessary. The first interface layer is the DOS API. This is the set of entry points that you expect from a DOS compatible operating system. These include the traditional INT 20h, 21h, 22h, 23h, 24h, 27h, 28h and 2Fh. The other interface layer is the device driver interface. This layer is also well documented and supported by many hardware and software vendors. This layer allows DOS-C to be compatible with MS-DOS to assure proper support of loadable device drivers.

The kernel is written in C wherever possible. However, certain functions are written in assembly language for either efficiency or necessity. These functions typically perform direct machine control, such as stack manipulation and flipping interrupt bits. You will find this code in a number of assembly files along with C to assembly interface functions.

DOS-C API

A DOS API entry point handler intercepts any system call to DOS-C and translates it into a C call. We do this as close to the entry point as possible in order to use C as early as possible. The C call then does some context switching and performs a call to the appropriate internal service function. It is up to the service routine to dispatch the system call through the kernel to the appropriate handler.

The dispatcher directs a system call into the kernel. A large number of calls are directed into the dosfns, or DOS Functions, layer. This layer works with the lower layers to add the DOS appearance to the system calls. It does this by combining calls into the various managers in the next lower layers with code to add features to the manager calls that are unique to a DOS interface. For example, this layer contains functions that encompass all rules for handling file I/O that deals with PSP, handles or character and block I/O functionality.

DOS-C File System

The DOS-C design allows for a file manager that is independent from the design of the rest of the operating system. The fs module is the DOS-C file manager. Whenever an application requests an operation on a file resident on a block device, fs performs the operation. It does this by working with an internal table, called the fnode (or file node) table.

The fnode table is the foundation for the design of the FAT file system manager. The fnode data structure controls all internal file operations and virtualizes the file. When fs performs an operation such as create or open, it allocates an entry from the fnode table and populates the fnode fields. The call returns a number that is the index into the fnode table. From here on out, any function that performs an operation on the file receives this number. The fnode table entry that corresponds to this index controls all file parameters.

If you are familiar with DOS internals from the undocumented internals books and articles, you will recognize the need to map internal fnode to the SFT (System File Table) structure used by DOS. We handle this through the dosfns layer function. The module dosfns maps the fnode number to an SFT handle, which is part its "DOS personality" responsibility. At the fs level, it does its work in an "OS neutral" mode in order to localize unique features to the personality module.

DOS-C Memory Management

Memory management in DOS-C closely emulates MS-DOS. Since DOS-C is a real mode operating system, the DOS-C memory manager is much simpler than what you'll find in other protected mode 80X86 operating systems. In a manner similar to the MS-DOS, DOS-C manages memory through the use of a memory block linked list that utilizes the same arena header as the one MS-DOS uses.

The arena header in DOS-C is known as the MCB (Memory Control Block). As with MS-DOS, this data structure is in front of each allocated and free memory block. DOS-C uses the same 'M' and 'Z' signatures to identify the block type. Also, the segment value of the PSP of the program it belongs to or a 0008h if it belongs to DOS-C, identifies the owner of the block in the same way. DOS-C uses all other entries in an identical manner. Many applications make use of this information and DOS-C provides this same information for sake of compatibility. Unlike fs where MS-DOS personality splits between it and dosfns, memmgr contains all DOS personality.

DOS-C Task Management

Because DOS-C design is designed to emulate MS-DOS, it should be of little surprise that the operating system is not multitasking. As a result, the task manager, task, manages a single user task. Its primary function is to act as a task loader, unlike other operating systems where task loading is an incidental to managing the task. Also, there are only two relatively simple executable file types, .COM and .EXE.

Both executable file types start from a single load entry. It is up to DOS-C to identify which file type it is. It does this by examining the first two bytes of the file. If it is an 'MZ', then it is an .EXE file and task invokes the .EXE loader, otherwise task assumes it to be a .COM binary image and task invokes the .COM loader.

Both loaders initially allocate memory from memmgr to place the environment strings in. The differences begin when the actual file loading occurs. The .COM loader merely allocates memory and begins loading the file into memory for a maximum of 64K. The .EXE loader, on the other hand, computes the size required and then allocates memory. It then proceeds to load the image. When task completes loading the image, it does a seek to the relocation offset and does a segment fixup (necessary for the segmented architecture of the 80X86 family). From this point, both loaders proceed with creating the PSP, cloning the file table, initializing the task's registers and executing the task if so requested.

DOS-C Device Driver Interface Layer and Device Drivers

At the bottom of the DOS-C architecture, but just above the device drivers, is the device driver interface layer. There are two handlers in this layer, chario and blockio. Although each handler uses different methods, both handlers are the primary interface between the device drivers and the remainder of the kernel. Both handlers perform all the necessary buffer management for both types of I/O, including line buffer management.

Both I/O handlers are loosely based on the UNIX I/O model. As with UNIX, there are two types of I/O handlers. The first type is the character I/O type. This type of I/O appears as a stream of bytes to the kernel. The kernel either sequentially reads a byte from or writes a byte to a device driver. There are also functions to read a buffer into memory and handle the familiar DOS line editing functions.

The block I/O interface provides functions to read and write a block of data to a block device -- usually a disk. Each block corresponds to a sector and is represented in memory as a data structure in a block cache. When the kernel reads data from a disk, blockio reads the sector into a buffer and places it into a Least Recently Used (LRU) chain. When blockio needs a new buffer, it writes the tail of the list to disk, if needed, and returns that buffer. When blockio completes the data transfer, the buffer goes to the head of the LRU chain, indicating that it is the newest buffer. Management functions handle these operations for dirty buffer write back, as well as buffer fill. There are also buffer management functions to perform operations such as LRU management and flush.

As with the API, the device driver interface is well documented. Since the interface is designed for an assembly language system, a special assembly language function interfaces all device drivers. This function, execrh, accepts a request packet from the I/O handlers that contains a function number requested by the device driver. It handles the correct sequence of calls to the strategy and interrupt entry points for the device driver and returns the packet to the I/O handler.

The DOS-C device drivers are the bottom layer of the kernel. Like the remainder of the kernel, C is used in these device drivers also. The device drivers perform the necessary device interface between the kernel and the device itself. DOS-C has the same device drivers as MS-DOS and they perform the same functions as their MS-DOS counterparts.