DOS Info Block: A Definitive Guide

Abstract

Systems programming has always been an attraction to the programming geeks. Gone are the days when we used to use DOS, but DOS is still a programmer's heaven. Technology is churning out more sophisticated and intricate tools to help out research and development, yet you need to retrace your footprints to the realm of DOS. This is a research article and the main focus is on the DIB (Dos Info Block). I have formed an easy-to-use structure and chalked down many areas of DIB to facilitate the programmers for system and low-level programming. Only a few people know what the DIB structure is and what kind of information it contains. When I tried to utilize the Path Table and Device Parameter Block, I found very little information about it and I feel the need to synthesize these undocumented areas.

Hitherto, many reference books discuss undocumented information about DOS, but I have found some DOS structures still undocumented—such as the DOS Info Block (DIB). In fact, certain kinds of programming depend on this structure and some applications couldn't be created without them. For example, hard disk management utilities extensively use these undocumented structures.

Although it's admittedly an old technology, I am sure this research article will be very beneficial for system programmers (in low-level programming).

The DOS Info Block (DIB)

The DOS Info Block (DIB) is the key to accessing the most important DOS structures. This block contains pointers to several DOS structures and to other information. The DIB is useful to a program only if its address in memory is known. This address isn't in a fixed memory location, and cannot be obtained with any of the documented functions of DOS interrupt 21H. However, the undocumented function 52H can help locate this address. Calling function 52H returns the address of the DOS Info Block to the ES: BX register pair.

Interrupt 21H, Function 52H

Determines the pointer to the DOS-Info-Block.

This function returns a pointer to the DOS-Info-Block (DIB). With this function, much interesting information can be obtained, which otherwise would not be accessible to a program.

Input:AH = 52H
Output:    Carry-Flag = 0: ok, in this case
ES: BX = FAR-pointer to the DIB
Carry-Flag = 1: Error, in this case
AX = Error Code

The contents of the CX, DX, SI, DI, BP, CS, DS, and SS registers are not affected by this function.

Unlike other DOS functions that retrieve pointers to a structure or date area, the contents of the ES: BX register pair point to the second, instead of the first, field within the DIB after the function call.

DIB structure

The first field in the DIB contains a pointer to the Memory Control Block (MCB) of the first allocated memory area.

DOS Info Block (DIB) Structure
Addr Contents Type
-04H Pointer to MCB 1 ptr
ES:BX Pointer to first Drive Parameter Block (DPB) 1 ptr
+04H Pointer to last DOS buffer 1 ptr
+08H Pointer to clock driver (CLOCK) 1 ptr
+0CH Pointer to console driver (CON) 1 ptr
+10H Sector length (based on connected drives) 1 word
+12H Pointer to first DOS buffer 1 ptr
+16H Pointer to path table 1 ptr
+1AH Pointer to System File Table (SFT) 1 ptr
Length: 30 bytes

Drive parameter block

The pointer in the second field of the DIB provides access to information that cannot be accessed in any other way. It points to the first Drive Parameter Block (DPB), which is a structure that DOS creates for all mass storage devices (floppy diskettes, hard disks, tape drives, and so forth).

Drive Parameter Block (DPB) Structure
Addr Contents Type
+00H Drive number or character (0 = A, 1 = B, and so on) 1 byte
+01H Sub-unit of device driver for drive 1 byte
+02H Bytes per sector 1 word
+04H Interleave factor 1 byte
+05H Sectors per cluster 1 byte
+06H Reserved sectors (for boot sector) 1 word
+08H Number of File Allocation Tables (FATs) 1 byte
+09H Number of entries in root directory 1 word
+0BH First occupied sector 1 word
+0DH Last occupied cluster 1 word
+0FH Sectors per FAT 1 byte
+10H First data sector 1 word
+12H Pointer to header (corresponding device driver) 1 ptr
+16H Media Descriptor 1 byte
+17H Used flag (0FFH = Device not yet enabled) 1 byte
+18H Pointer to next DPB (XXXX: FFFF = last DPB) 1 ptr
Length: 1CH (28) bytes

The first field of the DPB indicates the device to which the block belongs. 0 represents drive A, 1 represents B, 2 represents C, and so on. The second field specifies the number of the subunit. To understand the meaning of this field, remember that access to the individual devices occurs through the device driver. DOS doesn't perform direst access to a disk drive or hard disk. So, DOS doesn't have to deal with the physical characteristics of a mass storage device. Instead, DOS calls a device driver, which acts as mediator between DOS and hardware.

Obviously, not every device has a separate device driver, because one device driver can support many devices. For example, the device driver built into DOS manages the floppy disk drives and the first available hard disk. Because DOS configures a DPB for each device, a hard disk system automatically has 3 DPBs available. (A DPB is always configured for floppy disk drive B, even if only one floppy disk drive is actually available.) Each device receives a number between 0 and the total number of devices minus 1, to help each driver identify the devices it manages. This is the number found in the subunit field.

The next field lists the number of bytes per sector. Under DOS, this is usually 512. After this is the interleaf factor, which provides the number of logical sectors displayed by physical sectors when the medium is formatted. This value can be 1 for floppy disk drives, 6 for the XT hard disk, and 3 for the AT hard disk. For floppy disk drives, this field can also have the value FEH if the disk in the drive hasn't been accessed. The value FEH indicates that the interleaf factor is currently unknown.

Several other fields are related to these two fields. Among other things, these fields describe the status and the size of the structures DOS created to manage mass storage devices. A pointer to the header of the device driver is located within these fields. DOS uses this pointer when accessing the device. Additional information can be obtained with this pointer because, for example, the driver attribute is listed in the header of the device driver.

Following this field is the media descriptor to which the used flag is connected. As long as the device hasn't been accessed, this flag contains the value 0FFH. After the first access, it changes to 0 and remains unchanged until a system reset. The DPB ends with a pointer that establishes communication with the next DPB. Because every DPB defines its end with such a pointer, a kind of chain is created, through which all DPBs can be reached. To signal the end of the chain, the offset address of this pointer in the last DPB contains the value 0FFFFH.

DPB access

When a program needs the information within the DPB, there are many ways to find the address of the desired DPB. One method is to follow the chain previously described by first determining the address of the DIB. This gives you the pointer to the first DPB, from which you can follow the chain until you reach the desired DPB.

However, there's a better method, which isn't as susceptible to changes within the DIB. This method involves two undocumented DOS functions, 1FH and 32H functions. Although these functions have been included in DOS since Version 2.0, Microsoft didn't document them. When called, both return a pointer to a DPB to the DS: BX register pair. Although function 1FH always delivers a pointer to the DPB of the current disk driver, the address delivered by function 32H refers to the device whose number is passed to the function in the DL register at the time it's called (0 represents the current drive, 1 is drive A, 2 drive B, and so forth). Function 32H is much more flexible than function 1FH.

Interrupt 21H, Function 1FH

Gets the DPB pointer to the current drive.

Gets the pointer to a DOS Parameter Block for the current disk drive.

Input:AH = 1FH
Output    AL = 000H: Operation successful
AL= 0FFH: Error
DS: BX = FAR pointer to DPB structure

Interrupt 21H, Function 32H

Gets the DPB pointer for any drive.

Gets the pointer to a DOS Parameter Block for any disk drive.

Input:AH = 32H
DL = Drive code (0 = current, 1 = A, 2 = B, etc.)
Output    Carry flag = 1: Error
Carry flag = 0: Ok
DS: BX = FAR pointer to the DPB

If the device indicated is a diskette drive, DOS accesses the drive to fill the DPB with data about the drive and the format of the diskette. For hard disks, this information is already stored in the memory and no hardware access is required.

An error during the function call can only occur if an invalid drive code was indicated. If this occurs, error code 15 is returned in the AL register.

The construction of the DOS Parameter Block varies between DOS versions. The contents of the AH, CX, DX, SI, DI, BP, CS, SS, and ES registers are not affected by this function.

Using 1FH and 32H to access the various DPBs is also useful because it forces DOS to retrieve other information, such as the interleaf factor and the media descriptor byte, which is determined for the disk drive only after the first access. If you get to the DPB through the pointer in the DIB block, the various fields may not have been initialized, and could contain the wrong values.

The DOS Buffer

Besides the pointer to the first DPB, the DIB also contains the pointer to the first DOS buffer at address 12H. These DOS buffers store individual sectors, so that the sectors don't have to be repeatedly loaded from disk. The DOS buffers are most effective when they're used to store disk sectors that are frequently needed by the currently running program. Besides the FAT, these sectors include the root directory and its subdirectories. The number of buffers can be defined by the user in the CONFIG.SYS file. If this number exceeds those needed for the FAT, root directory, and subdirectories, normal sectors can also be temporarily stored here. This is done so that, if they are called again in the near future, they can be taken directly from the buffer.

The individual sectors are linked together. This enables DOS to quickly check each buffer for the desired sector with each read operation.

DOS Buffer Structure
Addr Contents Type
+00H Pointer to next DOS buffer 1 byte
+04H Drive number (0 = A, 1 = B, and so on) 1 byte
+05H Flags 1 byte
+06H Sector number 1 word
+08H Reserved 2 bytes
+0AH Contents of buffered sector 512 bytes
Length: 210H (528) bytes

As with DPBs, this occurs with the help of a pointer that appears at the start of every buffer. Also, the last buffer is reached when the offset address of the pointer contains the value 0FFFFH. After the field linking one buffer to the next is the number of the drive where the buffered sector originates. The value is 0 for drive A, 1 for B, 2 for C, and the like. Besides the drive number, the identification of a sector requires a sector number. This is located beginning at position 06H in the DOS buffer. The last field in the buffer header stores a pointer to the corresponding DPB, so that DOS can obtain information about the device that loaded the buffered sector. Although this is the last field in the header of the DOS buffer, the buffered sector doesn't end immediately after this field. There are two more bytes that follow. The reason for this is that the DOS code is written in machine language. So, when working with memory blocks, it's most efficient to have the buffered sector begin with an address that is divisible by 16.

The Path Table

The header of the DOS buffer isn't the last place you encounter the DPB. It appears again in the path table, which starts at address 16H in the DIB. This table contains the current path for each drive as well as a pointer to its DPB.

As long as the LASTDRIVE command is in the system's configuration file, the table will have entries for drives A through the one specified by LASTDRIVE. If this command is missing, however, the table will have entries only for each device supported by the installed device driver(s). If you change the entries in this table, you can divert one drive to another. The JOIN and SUBSTDOS commands also utilize this by manipulating the path table entry of the drive to be diverted.



About the Author

Najam ul Hassan

I have done Masters in Computer Sciences and for last Six years, working in Visual C++ in different Software Houses. Keep programming in Visual C++ :)

Comments

  • Used DIB in 1991

    Posted by owillebo on 10/25/2005 02:58pm

    I found a TSR I wrote in 1991 (when I was still in school) that turns the screen up side down and uses the DIB structure. I learned a lot about system programming from writing this TSR. If you want I can send you the TSR.

    Reply
  • Thanks for your writing

    Posted by donrong on 10/23/2005 09:13am

    Recently I have decided to learn something about System Programming.Of course,DOS is a good OS.But just a few programmers pay their attention to it.I hope we can communicate with each other through E-MAIL.Mine is donrong@gmail.com. Regards.

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: October 29, 2014 @ 11:00 a.m. ET / 8:00 a.m. PT Are you interested in building a cognitive application using the power of IBM Watson? Need a platform that provides speed and ease for rapidly deploying this application? Join Chris Madison, Watson Solution Architect, as he walks through the process of building a Watson powered application on IBM Bluemix. Chris will talk about the new Watson Services just released on IBM bluemix, but more importantly he will do a step by step cognitive …

  • It's no secret what keeps CIOs up at night. Mobile, cloud, data, security, and social have become the "five imperatives," the drivers of business progress, innovation, and competitive differentiation. Business leaders around the world want to hear how other companies are succeeding. How are they applying the latest technologies? How did they get started? What outcomes are they achieving? Read this online magazine for success stories from organizations like the NBA, Pfizer, and San Jose State University as they …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds