First steps towards system programming under MS-DOS 7/Selected drivers

Chapter 5 Selected drivers for MS-DOS 7

Drivers are files with executable resident code inside. Resident code is the code adapted for being written into RAM (random accessed memory) and left there, waiting for its chance of being requested on certain occasion(s). When this particular occasion happens, driver's code is executed, performs its mission and then again is left waiting for the next request. This mode of action is similar to the "life" of operating system's core. MS-DOS combines a limited number of main core's functions with various functional extensions, provided by drivers. Proper choice and renewal of drivers is an important factor for DOS's survival amongst ever changing PC's hardware.

Drivers may be presented in a form of files with special header (A.05-1), most often marked with *.SYS suffix, or in a form of ordinary executable files (*.COM or *.EXE) having a TSR (Terminate and Stay Resident) part. Drivers with *.SYS suffix must be loaded by DEVICE (4.06) or DEVICEHIGH (4.07) commands from lines of configuration file CONFIG.SYS. Composition examples for CONFIG.SYS file are shown in articles 9.01-01, 9.04-01 and 9.09-01. Loading by DEVICE or DEVICEHIGH commands gives more chances to affect DOS system structures construction, because it is not finished yet at that moment.

Drivers with *.COM and *.EXE suffixes usually are loaded later either from CONFIG.SYS file with INSTALL (4.15) or INSTALLHIGH (4.16) commands, or from AUTOEXEC.BAT file (9.01-02, 9.04-02, 9.09-02), or from command line — directly or with LH command (3.17). Loading from CONFIG.SYS file is less subjected to mutual software interference and therefore is considered more safe. On the other hand, INSTALL and INSTALLHIGH commands can't be involved in memory optimization procedure by MEMMAKER.EXE optimizer. If memory optimization is significant, loading with LH command from AUTOEXEC.BAT file should be preferred.

The main group of drivers for MS-DOS 7 constitute those supplied within WINDOWS-95/98 operating system release and on its rescue diskette. In case of standard operating system installation all drivers for MS-DOS 7 are in directories \WINDOWS and \WINDOWS\COMMAND. But if MS-DOS 7 is installed as an independent operating system, it is better to arrange a separate directory for drivers, for example, C:\DOS\DRV. This path is shown in the most part of presented examples. When you will intend to follow these examples in practice, it's important to remember: the path you specify must not be necessarily C:\DOS\DRV, it must be exactly the one that leads to each particular driver in your particular computer.

Beside "native" Microsoft's drivers, a lot of drivers for MS-DOS 7 have been developed since 1995 by other software vendors and by manufacturers of PC's hardware. Existing drivers are too numerous, and only a limited selection of them can be described here. The following text doesn't include descriptions of some other Microsoft's drivers (that can be found in MSDOSDRV.TXT, supplied with Windows 95 software release) as well as of drivers for some non-common equipment (MO, PD and ZIP drives, LS120 floppies, streamers, etc.). Preference has been given to those drivers which are the most necessary for reparatory works.

5.01-01 The core file IO.SYS and parameters file MSDOS.SYS
In the root directory of the disk used to load Windows 95/98 or MS-DOS 7, there are two hidden system files: IO.SYS and MSDOS.SYS. These files are there since installation of the operating system, they implement its loading. File IO.SYS combines the core of MS-DOS 7 with interpreter and with DOS loader. The MSDOS.SYS file contains a set of loading parameters. If you have no such files, you may get them from a disc with Windows 95/98 release, or else you may download them, for example, packed into archive DOS7.ZIP from internet site http://www.micosyen.com/msdos.php.

In order to make a disk bootable with MS-DOS 7, presence of the mentioned system files is necessary, but not sufficient. Boot-sector's executable code will not "know" where control should be transferred, unless the name of loader is written into boot-sector. This is why copying of system files is combined with boot-sector updating in joint mission of SYS.COM utility (6.24).

Having got control over booting process, DOS loader reads loading parameters from MSDOS.SYS file. These parameters define the alternatives, described in article 1.02, and also define which operating system should be loaded: MS-DOS 7 or WINDOWS-95/98. If the HRS attributes (H =Hidden, R =Read-only, S =system) of the MSDOS.SYS file are taken off by the ATTRIB.EXE utility (6.01), then MSDOS.SYS becomes an ordinary nonformatted textual file, which can be opened, changed and rewritten with editor utility, for example, with EDIT.COM (6.09).

Several or even all parameters may be not specified in MSDOS.SYS file, and then the omitted parameters will be given the default values. Contrary to other system files, MSDOS.SYS is not copied by SYS.COM utility, but rather is created empty anew, and this doesn't hamper normal loading of WINDOWS-95/98 operating system. At least some of the default parameter's values wouldn't fit, though, if you intend to load MS-DOS 7 as a stand-alone operating system. Suitable values of all parameters are shown in an example of MSDOS.SYS file presented below. Lines of the MSDOS.SYS file are read by an interpreter, integrated into the same IO.SYS file. The interpreter ignores all lines starting with semicolon, and this is why such lines are used to insert comments. Of course, lines with comments can be omitted, but there is one argument against it: for compatibility with obsolete antivirus programs the length of hidden system files must be not less than 1024 bytes. For most modern antivirus programs this restriction is not significant.

All parameter's values in the shown example of MSDOS.SYS file are compatible with variants of configuration files, presented in articles 9.01, 9.04, 9.09 and 9.11. Settings in the [PATHS] section are taken into account by WINDOWS operating system only; for MS-DOS 7 the corresponding values of environmental variables should be ignored or reassigned later, during interpretation of the second configuration file - AUTOEXEC.BAT. A large part of parameters in the [OPTIONS] section can be omitted too. Nevertheless the shown complete list of parameters will help you to decide, whether any particular parameter should be specified and which value it should be given. Having prepared your own version of MSDOS.SYS file, don't forget to return back its original attributes HRS (Hidden, Read-only, System).

In accordance with the prepared parameters the DOS loader loads the core of MS-DOS 7. The core is responsible for system DOS services and for main INT 21 handlers, described in part 8.02. The last loader's mission is execution of commands from configuration file CONFIG.SYS, which define loading of most drivers. Several variants of CONFIG.SYS file are shown in articles 9.01-01, 9.04-01 and 9.09-01. Later MS-DOS 7 never calls the IO.SYS file for execution, but its presence is nevertheless necessary for copying each time, when you have to make bootable any other disk.


 * Notes
 * 1) In earlier versions of MS-DOS the MSDOS.SYS file was not a textual file, it contained the core of DOS and was loaded almost as an ordinary driver.
 * 2) In 2001 a bug has been revealed in the core of MS-DOS 7: it didn't cope properly with HDD's LBA-errors. Therefore Microsoft issued a patched core file IO.SYS inside SFX-archive 311561usa8.exe. The latter can be downloaded from http://support.microsoft.com/kb/311561/en-us?spid=6519&sid=global . WINRAR version 3.2 (or higher) unpacks 311561usa8.exe as CAB-archive. Two subversions of IO.SYS file are hidden there under nicknames Winboot.98s and Winboot.98g. If the VER command (3.32) reports version 4.10.2222, then IO.SYS should be obtained by renaming Winboot.98s. If reported version is 4.10.1998, then Winboot.98g should be similarly renamed and used as IO.SYS.

5.01-02 DOS version number substitution: driver SETVER.EXE
Evolution of OS versions is complicated by a problem of application programs which have been developed for previous versions of DOS. Compatibility of any application with future OS versions is a matter of faith rather than prediction. Microsoft suggested to solve this problem by informing definitely compatible application programs via INT 21\AH=30h (8.02-22) about not the actual, but the required DOS version number. SETVER.EXE is just that driver, charged with the mission of deceiving application programs by substitution of DOS version number.

In case of standard installation of WINDOWS-95/98 the SETVER.EXE driver is in the \WINDOWS directory. But if you want to use MS-DOS 7 separately, it's better to have a copy of SETVER.EXE in common directory with other DOS drivers. It has to be loaded by DEVICE (4.06) or DEVICEHIGH (4.07) command from a line of CONFIG.SYS file :

where :
 * – is a path example to SETVER.EXE driver stored in separate directory for DOS drivers.

Application program will receive the substituted DOS version number only if the name of this program together with the required DOS version number is in advance registered in internal versions table inside the loaded TSR module of SETVER.EXE driver. Though such substitution doesn't guarantee a proper outcome, nevertheless most old programs are able to operate properly in MS-DOS 7. The SETVER.EXE driver can be launched from command line just as an ordinary utility, for example, in order to display its short help text :

Being run from command line without parameters, SETVER.EXE driver displays its internal table of versions. Originally table of versions is not empty: its entries reflect Microsoft's recommendations. In order to append the table of versions with one more entry you should type

where :

Command to delete the same entry from internal table of versions requires the /D parameter and looks as

After any operation with its internal table the SETVER.EXE driver leaves one of the following errorlevel values (more about errorlevels in 3.15-03 and in 9.07-03) :

All successful operations affecting contents of internal table are finished in the same way : former internal table on a disk is overwritten with its updated variant, containing changed entries. But writing the changes in a file on a disk is not enough to make them active. They will become active when the changed table of versions is transferred from a file into driver's TSR module, loaded into memory by DEVICE or by DEVICEHIGH command. This is why the changes come into effect only after PC's reboot.

5.02-01 COUNTRY.SYS – specifications data file
In case of standard installation of WINDOWS-95/98 OS the COUNTRY.SYS file can be found in \WINDOWS\COMMAND directory. COUNTRY.SYS is in fact a set of data tables, one of which is to be loaded from CONFIG.SYS file with special COUNTRY command (4.05), for example :

where :

Having been loaded, data from COUNTRY.SYS change several internal DOS settings, related to country-specific conventions on displaying time, dates, currency and punctuation symbols, character sorting and national restrictions on character set for names (A.02-5). The latter feature is of special importance, since otherwise the files, having national characters in their names, may become inaccessible.

5.02-02 DISPLAY.SYS – character generator driver
DISPLAY.SYS driver prepares memory buffers for one or more national codepage tables, specifying character set and outline (A.02-2). Normally the DISPLAY.SYS driver can be found in \WINDOWS\COMMAND directory. This driver must be loaded by a DEVICE (4.06) or DEVICEHIGH (4.07) command from a line in CONFIG.SYS file :

where :


 * Notes
 * 1) All parameters in parenthesis may be omitted (brackets left empty), and then DISPLAY.SYS driver will appoint default settings.
 * 2) TSR module of DISPLAY.SYS driver is opened for interaction with programs via INT 2F\AX=AD00-AD03h (8.03-26, 8.03-27).

5.02-03 NLSFUNC.EXE – codepage switch
The NLSFUNC.EXE driver activates CHCP command (3.04) for switching between different codepages, coordinated with changing of other national settings. Normally this driver can be found in \WINDOWS\COMMAND directory. The NLSFUNC.EXE driver may be loaded directly or with LH command (3.17) from command line or from AUTOEXEC.BAT file, or else from CONFIG.SYS file with INSTALL (4.15) or INSTALLHIGH (4.16) command, for example :

where :


 * Notes
 * 1) Switching between american english and any other national notation doesn't imply changing codepages: american english notation is accessible within any single national codepage (A.02-02).
 * 2) Switching between different national codepages can be performed by MODE.COM utility too (6.18-03). The latter is usually preferred, because MODE.COM is not a TSR program and releases occupied memory after termination.

5.02-04 KEYB.COM – keyboard driver
Control over keyboard layouts is provided by Microsoft's keyboard driver KEYB.COM. Normally it can be found in \WINDOWS\COMMAND directory. The KEYB.COM driver can be loaded directly or with LH command (3.17) from AUTOEXEC.BAT file, or else from CONFIG.SYS file with INSTALL (4.16) or INSTALLHIGH (4.17) command, for example :

where :

When loaded, KEYB.COM driver activates the following "hot" key combinations:

All those "hot" keys switchings are accompanied with lousy beep sound, and there is no simple way to get rid of it.


 * Notes
 * 1) TSR module of KEYB.COM driver is opened for interaction with programs via INT 2F\AX=AD80h-AD83h (8.03-28, 8.03-30).

5.02-05 KEYRUS.COM – combined keyboard and display driver
KEYRUS.COM driver (written by D.Gurtjak, Donetzk) is a combined keyboard and character generator driver. It is popular among russian users, because it is originally supplied with internal 866 (russian) codepage and with russian keyboard layout. But the original release of KEYRUS.COM also contains supplementary programs which enable the user to write, to install and to activate any codepage and any keyboard layout. The KEYRUS.COM driver can be downloaded for free from many russian internet sites. The last version 8.0b (1994), packed into keyrus8b.zip archive, is available from author's site http://www.gurtjak.skif.net/pages/programs.htm.

The KEYRUS.COM driver may be loaded from CONFIG.SYS file with INSTALL (4.15) or INSTALLHIGH (4.16) command, or else from command line or from a line of AUTOEXEC.BAT file - directly or with the LH command (3.17), for example

When default settings don't suffice, options should be specified after the driver name in the same command line. As options may be numerous, they can be specified inside a separate file ; arbitrary name of this file must be preceded by symbol "@" (at) :

KEYRUS.COM is not loaded and doesn't affect its loaded TSR part when it is executed in command line to show default options, or to extract internal fonts and keyboard layout, with , or to change the default specifications, in which case the driver name (KEYRUS.COM) must be followed by a group of options, and the last option in this group must be.

KEYRUS.COM driver consists of three TSR modules: keyboard module, character generator module and interface module. Each module accepts its own set of options. If not specified otherwise, acceptance of option "ON" by KEYRUS.COM instead of option "OFF" (and vice versa) everywhere in examples below is always allowed and leads to reverse results.

Options for keyboard module are :

Character generator's module accepts the following options:

Interface module of KEYRUS.COM driver accepts the following set of options :

 The KEYRUS.COM driver is not compatible with Microsoft’s drivers DISPLAY.SYS (5.02-02) and KEYB.COM (5.02-04), as well as with Microsoft's keyboard layout tables KEYB*.SYS (A.02-2). Those files shouldn't be used, if you intend to load KEYRUS.COM driver. Resident interface module of the KEYRUS.COM driver interacts with programs via INT 2F\AX=4352h (8.03-24). ^ a b c d e The shift here is a sum of digit 1 for the RightSHIFT key, digit 2 for LeftSHIFT key, digit 4 for CTRL key, digit 8 for ALT key, number 16 for ScrollLock switch, number 32 for NumLock switch, number 64 for CapsLock switch and number 128 for Insert switch (see 8.01-85, the byte returned in AL). For example, shift 12 means holding CTRL and ALT keys while pressing the main "hot" key, defined by its scancode. ^ a b c d e The KEYRUS.COM driver accepts decimal scancodes, so hexadecimal values from the second column in table A.02-1 must be translated into decimal form. Besides this, KEYRUS.COM can't discriminate properly scancodes with and without prefix E0h. Inside "DOS window" of Windows-95/98 operating systems the KEYRUS.COM driver operates properly only in textual videomodes, that is, when this "DOS window" is extended to the whole screen with ALT-ENTER keystroke. The "DOS window" of Windows 2000/XP operating systems can be served by KEYRUS.COM driver too, but in that case it must be loaded either from CONFIG.NT file or from AUTOEXEC.NT file, located in \WINDOWS\SYSTEM32 directory. 
 * Notes

5.03 Drivers for "mouse" pointing devices
Functions of mouse pointing device become accessible, when four conditions are met. First, you must have a mouse which is able to perform the desired function(s) and can be connected to your computer. Second, you must load a driver which supports execution of the desired function(s) by the mouse with appropriate type of connection. Third, the desired functions must be called by the program which you want to employ these functions. Fourth, both the driver and the program must be able to operate under the operating system which is installed in your computer.

As to the mouse pointing devices, the MS-DOS 7 operating system seems inconsistent. On one hand, the Windows-95/98 release provides no mouse driver for MS-DOS 7. On the other hand, mouse's functions are needed, for example, for editor utility EDIT.COM (6.09), and mouse drivers from previous versions of DOS operate properly under MS-DOS 7. All those mouse drivers for DOS interact with application programs in the same way, via interrupt INT 33 (8.03-31 – 8.03-55).

Connection of mouse pointing device to a PC is defined by port address (A.14-1) and by interrupt request line number (IRQ). Mouse drivers described below are able to search for mouse pointing devices throughout all relevant ports and IRQ numbers. Though connection specification is not necessary, it nevertheless may be given in order to avoid search and make loading faster.

Since the new millennium another breed of "mice" has appeared — those with USB port connection. Such "mice" rely on pointing device BIOS interface (INT15\AX=C2xx) and on driver's interaction with this interface (5.03-3). In obsolete PCs, where BIOS system doesn't respond to INT15\AX=C2xx calls, necessary support may be provided by a choice of appropriate driver for USB controller (5.07-05), and then any mouse driver will be able to suffice a mouse connected via USB port.

5.03-01 GMOUSE.COM – mouse driver from KYE Systems Corp.
The GMOUSE.COM driver is supplied in software packets for mouse pointing devices with a well-known trade mark GENIUS, belonging to KYE Systems Corporation. This driver also can be found on compact discs, containing collections of drivers. Version 10.20 of GMOUSE.COM driver (1996) packed into GMOUSE.ZIP archive is available for free downloading from internet site http://www.dosbootsector.narod.ru/drivers.htm. The GMOUSE.COM driver can be loaded either directly or by LH command (3.17) from command line or from AUTOEXEC.BAT file, or else by INSTALL (4.15) or INSTALLHIGH (4.16) command from CONFIG.SYS file, for example :

where :
 * – an example of a path to GMOUSE.COM driver.

Normally the GMOUSE.COM driver doesn't needs parameter specifications, but nevertheless it can accept any one of the following mutually exclusive parameters :

The listed parameters are also suitable for newer versions of GMOUSE.COM driver, which have increased file size and several superfluous functions, such as automatic determination of language for messages on basis of the loaded codepage. Contrary to newer versions, version 10.20 of GMOUSE.COM driver can accept some more parameters from a special parameter file GMOUSE.INI, if it is present in the same directory with the driver.


 * Notes
 * 1) If during loading a search for mouse pointing device is stopped by BREAK keystroke, for example, in order to read the displayed messages, then after any other keystroke the GMOUSE.COM driver is unable to resume the search, and PC gets hanged.
 * 2) When mouse pointing device is connected to port COM3 or COM4, the GMOUSE.COM driver doesn't provide compatibility with Windows OS.

5.03-02 MOUSE.COM – "mouse" driver from Microsoft Corp.
The MOUSE.COM name was common for several mouse drivers, written at different times by different authors. Here the version 8.20 is described of Microsoft's MOUSE.COM driver (file size 37681 bytes, file date 29.06.93). It was supplied within MS-DOS6.22 release, but was found compatible with MS-DOS 7 too. Archive MOUSE.ZIP containing MOUSE.COM driver can be downloaded from internet site http://www.computerhope.com/download/hardware.htm#05. The MOUSE.COM driver may be installed either from CONFIG.SYS file with INSTALL (4.15) or INSTALLHIGH (4.16) command, or else directly or with LH command (3.17) from AUTOEXEC.BAT file or later from command line :

where :

In most cases all optional specifications are not needed, since the default values are sufficient, and the driver is able to search for mouse pointing devices throughout all relevant ports.

In order to disable mouse you may unload this driver by launching it with single OFF parameter :

5.03-03 CTMOUSE.EXE – freeware "mouse" driver
The CTMOUSE.EXE driver is developed since 2002 as a part of FreeDOS project, but it is made compatible with MS-DOS 7. Version 2.1 of CTMOUSE.EXE (dated 2007), packed in archive CTMOUS21.ZIP, may be downloaded from internet site http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/mouse/. Another address, where recent versions of this driver can be found, is http://cutemouse.sourceforge.net/.

Functionally CTMOUSE.EXE is similar to other mouse drivers for DOS, but it occupies less memory and supports pointing devices equipped with a wheel. One more important feature of this driver is its interaction with pointing device BIOS interface (INT15\AX=C2xx). Therefore it provides better chances to suffice USB mice in modern PCs. CTMOUSE.EXE driver has an elaborated set of defaults which makes command line parameters in most cases unnecessary. It may be loaded either from command line or from AUTOEXEC.BAT file – directly or by LH command (3.17), or else from CONFIG.SYS file by INSTALL (4.15) or INSTALLHIGH (4.16) command, for example :

where :

Besides the shown parameters, Ctmouse.exe driver can accept the following options :

5.04 Memory managers
In AT-compatible computers the 640–1024 kb memory region is hardware consigned for special usage as BIOS code "shadow", as a "window" into video memory, as a page frame "window", etc. (see notes 2 and 3 to A.12-1 for more details). Because of 16-bit addressing and because of special status of 640–1024 kb memory region the accessible memory space for DOS programs is considerably limited. Since early 1980s researchers in all leading software companies attempted to overcome memory space restrictions. Nowadays these attempts are continued by many independent software vendors. The best solutions of this problem are presented here in the following articles.

5.04-01 HIMEM.SYS – extended memory driver
HIMEM.SYS is Microsoft's memory driver for PCs with CPU 80386 or higher, providing machine-dependent access to memory beyond the 1024 kb boundary according to eXtended Memory Specification (XMS). Therefore the memory, opened by HIMEM.SYS, is often called XMS memory. Since version 3.10 of HIMEM.SYS driver the upper limit of XMS memory is 65535 kb.

Besides access to XMS memory, the HIMEM.SYS driver performs two important functions : control over switching of A20 line gate and allocation of memory space, requested by different programs. Both these functions are necessary in order to prevent conflicts between programs, addressing memory beyond conventional memory limit (640 kb). Due to HIMEM.SYS driver each program, requesting some space in UMB region or in XMS memory, is given exclusive access rights to the allocated part of memory space.

Official explanations of HIMEM's operation principle are not known, but analysis of its code gives some grounds to suppose that it uses 32-bit linear addressing in real mode (more about that in 9.10). In any case, HIMEM's operation principle gives no chance to execute programs in XMS memory, it gives only an opportunity to copy executable code together with data from conventional memory into XMS memory and back.

Version 3.95 of HIMEM.SYS driver (1995) is supplied in Windows 95/98 release and normally may be found in \WINDOWS directory. The HIMEM.SYS driver should be loaded with DEVICE command (4.06) preferably in the first executable line of CONFIG.SYS file, for example :

where :

HIMEM.SYS has internal default settings which are suitable for a wide variety of PC's hardware. In rare cases you may have to specify other settings by optional parameters. Allowable optional parameters are :

is developed as a part of FreeDOS project and is supplied together with Emm386.exe (see note 4 to 5.04-02). Alternative XMS memory drivers accept different sets of options, described in attached files.
 * Notes
 * 1) HIMEM.SYS driver provides no access to memory beyond 16 Mb if CMOS BIOS parameter "Memory hole 15–16 Mb" is enabled.
 * 2) HIMEM.SYS driver accepts program's requests via CALL FAR commands (7.03-08). Address for CALL FAR commands can be obtained with INT 2F\AX=4310h function (8.03-23). A list of operations which can be requested by programs is shown in table A.12-3.
 * 3) Several similar XMS memory drivers have been developed by different authors. J.R.Ellis wrote QHIMEM2.SYS driver, which extends XMS memory limit to 4 Gb. Version 3.1 of this driver (dated 2005) is available inside SFX diskette image USB18.EXE from site http://johnson.tmfc.net/dos/usbdrv.html . The most recent 4 Gb XMS memory driver XMGR.SYS can be downloaded from page http://johnson.tmfc.net/dos/driver.html . One more similar driver – Himem.exe –
 * 1) In MS-DOS 8 the XMS access code is integrated into the core, hence there is no need to load Himem.sys.

5.04-02 EMM386.EXE – memory mapping driver and VCPI server.
EMM drivers (EMM = Expanded Memory Manager) originally were developed in 1983–1984 in order to provide access to memory banks on expansion cards for IBM PC, so that any memory bank can be addressed through the same "window" in address space (usually in segment addresses E000–EFFFh). This method of addressing memory banks was institutionalized by LIM EMS specification. Among other details, LIM EMS specification stipulates division of the address space "window" into several pages of 16 kb each, which independently direct addressing to different memory banks.

Later the main computer's memory has grown far above 1 Mb, and expansion cards with memory banks have come out of use. But some popular programs still relied on old-fashioned LIM EMS access, and compatibility with these programs had to be preserved. Therefore the fundamental principle of EMM driver's operation has been changed : control over expansion cards has been replaced by control over address translation mechanism embedded in all CPU's since 80386. This is why such memory managers are named EMM386. They enable to address the main computer's memory above 1 Mb through the same LIM EMS "window" in address space.

Here is just a place to remind that main computer's memory above 1 Mb is controlled by XMS driver HIMEM.SYS (5.04-01), and memory space allocation according to program's requests is just its prerogative. Hence the EMM386 driver plays a role of an intermediary transactor : having got a program's request for LIM EMS access to a memory space, it asks the HIMEM.SYS driver and gets a suitable piece of memory beyond 1 Mb. EMM386 then rewrites the data in CPU's TLB table so that the calling program becomes able to access the allocated piece of memory via the LIM EMS "window" in address space. When there is no a single piece of requested size, the EMM386 driver combines several pieces of smaller size. Due to address translation in CPU, the LIM EMS "window" in address space enables not only access, but execution of programs too.

The mission of EMM386 driver is complicated by the fact that address translation mechanism is activated only when CPU works in protected mode. Therefore the EMM386 driver switches CPU into virtual 8086 (V86) mode, a variant of protected mode, then all DOS programs are executed in this mode at the third (the lowest) privilege level. Of course, PC must have a CPU of 80386 type or newer, able to implement V86 mode. EMM386 driver gives to DOS programs a permission for I/O operations at the lowest privilege level, so that conditions of access to disks and to ports are the same as in real mode. Additional features, inherent to the V86 mode, are used by EMM386 driver for loading other drivers "through" free areas of UMB address space (640–1024 kb) and for control over attempts of other programs to affect implementation of protected mode.

At least three types of programs pretend to control protected mode implementation in DOS. These are extender programs (for example, DOS4GW.EXE), DPMI servers (for example, CSWDPMI.EXE), and loaders of operating systems (for example, the Windows' GUI loader WIN.COM). Such contenders can't perform their mission in V86 mode at the lowest privilege level. In order to enable smooth control transfer to such programs the VCPI protocol (VCPI = Virtual Control Program Interface) has been adopted in 1989. It was developed jointly by Phar Lap Software and Quarterdeck Office Systems. According to VCPI protocol, the program, which switches CPU into V86 mode, must perform several extra functions on request, including transition to the highest privilege level. Since EMM386 implements these extra functions, it is also called VCPI server. Some of VCPI server's functions are described in articles 8.03-71 – 8.03-73.

Direct execution of programs beyond 1088 kb boundary is necessary for loading drivers there, but that's not enough. Ordinary driver's code is not adapted to page-by-page addressing. Therefore for loading drivers the EMM386 manager arranges static mapping of memory beyond 1088 kb onto UMB blocks, which can be squeezed in all free stretches of address space between 640 and 1024 kb. If EMM386 memory manager is loaded yet, and then is launched from command line once more (without parameters), it will show on the screen the exact allocation of entrusted address space.

Windows-95/98 release includes version 4.95 of EMM386.EXE driver (date 6/12/1996, size 125495 bytes). This version is not intended, though, for service to a separate operating system MS-DOS 7. Version 4.95 transfers exception calls to protected mode handlers, installed by Windows OS. But when MS-DOS 7 runs alone, exception calls don't find their handlers, and PC gets hanged. This is why earlier versions 4.49 or 4.50 of EMM386.EXE driver are more suitable for MS-DOS 7. These versions are loaded in the same way and accept the same set of options. Version 4.49 (date 31/05/1993, size 120926 bytes) can be downloaded from server ftp://ftp.vgt.ru/dos/ inside diskette image Dos622_1.img, which can be written to diskette by IMG.EXE (6.06). Then file EMM386.EX_ should be unpacked by EXPAND.EXE (6.10). Version 4.50 (date 30/04/1998, size 119390 bytes) from IBM's PC DOS 2000 release can be downloaded inside SFX archive Pcdos2k.exe from server ftp://ftp.eesnet.ru/dos/.

Loading of DOS structures and of other drivers beyond conventional memory by LH (3.17), DEVICEHIGH (4.07) and other commands, ending with ...HIGH, requires memory manager to be loaded yet. But access beyond conventional memory must be provided in advance, before the EMM386.EXE driver is loaded. Therefore EMM386.EXE driver should be loaded by DEVICE command (4.06) from that line of CONFIG.SYS file, which follows HIMEM.SYS (5.04-01) loading line, but precedes to all lines with commands, having the ...HIGH ending. A line loading EMM386.EXE driver may look, for example, as

where :

Besides the shown options, EMM386.EXE driver can accept optional parameters from the following list :

When the EMM386.EXE driver is loaded yet and active, it can accept commands "EMM386 OFF" and "EMM386 AUTO" from command line. But these commands will not be executed if at that moment UMB address space has already been used for other drivers which must remain available for DOS.

 The EMM386.EXE driver accepts requests from other programs via INT 67 (8.03-57 – 8.03-74). ^ VCPI services, provided via INT 67\AX=DE00h-DE0Ch, give a chance to perform their mission for programs which have to affect V86 mode of CPU operation, set by EMM386.EXE. Due to VCPI services, in particular, the Windows OS can be loaded even if the V86 mode is set yet. But the Windows OS itself inside its "DOS window" disables VCPI services, thus excluding risk to lose control over the PC.</li> <li id="note-5.04-02-3">A version of EMM386.EXE from MS-DOS 8 is not compatible with some models of obsolete 486 processor and may cause hanging.</li> <li id="note-5.04-02-4">Several similar EMM386 managers are known to be developed. The most advanced is JEMM386.EXE driver, written by a group of authors under auspices of Tom Ehlert. Now, in december 2007, archive JEMM568.ZIP with version 5.68 of this driver can be downloaded from internet site http://japheth.de/. One more version of EMM386.EXE driver is developed as a part of FreeDOS project; it can be downloaded from server ftp://ftp.devoresoftware.com/downloads/. Both mentioned drivers are more compact, than original EMM386.EXE, and accept different sets of options, described in attached files.</li> </ol>
 * Notes

5.04-03 Memory allocation optimization: CHKSTATE.SYS
CHKSTATE.SYS is a special service utility for memory optimization procedure, developed for MS-DOS6, but proved to be suitable in MS-DOS 7. A line loading CHKSTATE.SYS is inserted into CONFIG.SYS file automatically by memory optimization manager MEMMAKER.EXE, and is deleted in the same way when memory optimization procedure terminates. Being executed, CHKSTATE.SYS utility forms a textual report file, containing exact data about memory areas, allocated for each loaded driver.


 * Notes
 * 1) For performing memory optimization procedure the main optimization manager MEMMAKER.EXE must be in one directory with auxiliary files CHKSTATE.SYS, EMM386.EXE, HIMEM.SYS, MEMMAKER.HLP, MEMMAKER.INF and SIZER.EXE. All these files are present in MS-DOS6.22 release, and also are contained in SFX archive OLDDOS.EXE, freely available from server ftp://ftp.microsoft.com/softlib/mslfiles/.
 * 2) The MEMMAKER.EXE optimizer is unable to make proper corrections in AUTOEXEC.BAT file and in CONFIG.SYS file, if the latter contains a menu with several loading alternatives. Each alternative variant should be optimized separately. Nevertheless the data, obtained for each loading alternative separately, enable to compose optimized configuration files with several loading alternatives.

5.04-04 UMBPCI.SYS – freeware UMB region driver
In order to open UMB address space (C000h–EFFFh) for loading drivers, the EMM386.EXE memory manager (5.04-02) arranges address translation via CPU's TLB tables and forces to pay for that with switching CPU into V86 mode. But when it is necessary to stay in real mode, access to UMB address space may be opened by reprogramming memory controller, a part of chipset on PC's motherboard. This alternative way of access to UMB address space is implemented by UMBPCI.SYS driver.

The UMBPCI.SYS driver has a long development history with a lot of participants. Now it is continued by Uwe Sieber. The most recent version of UMBPCI.SYS can be found in internet site http://www.uwe-sieber.de/, packed in archive UMBPCI.ZIP with attached texts in german, or else in archive UMBPCI_E.ZIP with attached texts in English. The description below is based on version 3.66 of UMBPCI.SYS, dated march 2006.

By no means is UMBPCI.SYS a replacement of EMM386.EXE : it does not implement LIM EMS specification. UMBPCI.SYS performs only functions stipulated by XMS specification, but just those which are incumbent upon EMM386.EXE driver (see note 6 to A.12-3).

In order to affect memory controller's settings, the UMBPCI.SYS driver calls BIOS's interrupt handlers INT 1A\AH=B1h, related to PCI bus services. This is why the UMBPCI.SYS driver can perform its mission only in computers which are equipped with PCI bus, controlled by PC's BIOS. These conditions are met by almost all AT-compatible computers, produced after 1996. One exception is represented by computers with AMD-K7 processor: in such computers the UMB blocks, created by UMBPCI.SYS driver, can't be used for loading those drivers which control expansion cards on PCI bus.

The UMBPCI driver provides access to free parts of "shadow" memory area, intended for copying executable codes from slow fixed storage BIOS chips. Not every chipset is able to provide direct memory access (DMA) into this "shadow" memory region. The DMA access is necessary for floppy disks controller, for SMARTDRV.EXE driver (5.06-01), and even for the WINDOWS OS, if it would be loaded later. The archives with UMBPCI.SYS driver contain some auxiliary utilities, enabling to avoid undesirable consequences of restrictions on DMA access to "shadow" memory areas. In the same archives there are files with advices, helping to overcome problems, specific for some particular chipsets. Of course, relevant peculiarities must be taken into account.

The UMBPCI.SYS driver should be loaded by DEVICE command (4.06) from that line of CONFIG.SYS file that follows loading of HIMEM.SYS driver (5.04-01) and precedes all lines with commands LH and those having the &hellip;HIGH ending. The line loading UMBPCI.SYS driver may look, for example, as

where :

If the  parameter is specified, then UMBPCI.SYS will not examine address space areas on whether they are free or not. Presence of several  occurrences in one command line is allowed, each UMB area will be given a serial number. The DEVICEHIGH (4.07) and LH (3.17) commands accept serial number of UMB area after their  parameter, and due to that there is an opportunity to load any particular driver through the prescribed part of UMB address space. The latter is important for those drivers which use direct memory access (DMA), because some chipsets — for example, i430TX — provide DMA access only inside the E000–EFFFh part of UMB region. Most often the  parameter is not needed, since popular modern chipsets (i815, i820, i845, i850, i855 and many others) apply no restrictions on DMA access to UMB region.

http://www.uwe-sieber.de/files/hiram.zip.
 * Notes
 * 1) In obsolete computers, having no PCI bus, access to UMB address region may be provided by HIRAM.EXE driver (written in 1993) and its auxiliary utilities. This set of software can be downloaded as one archive from internet site

5.05 RAM-disk drivers
RAM-disk drivers occupy a part of computer's random access memory (RAM) in order to simulate a virtual disk drive. This provides access to writable disk space during exploratory and reparatory works, when physical disk space may not exist or must be preserved free from traces of access. Virtual RAM-disks are much faster, than any physical disk. Since contents of RAM-disk is lost each time the PC is switched off, RAMdisks sometimes are used as a place for temporary files in order to avoid pollution of physical disk space.

A common drawback of many RAM-disk drivers is that they are unable to assign a certain letter-name for the created virtual disk. DOS always assigns to virtual disk the first free letter-name, which can’t be known beforehand. One solution, presented in article 9.04-02, is a search for a particular letter-name, assigned to the arranged virtual disk. Another solution is to write a special driver which will deceive DOS with a false number of registered disks, so that the next disk could be given an arbitrary prescribed letter-name. An example of the latter solution is presented in article 9.08.

5.05-01 RAM-disk driver RAMDRIVE.SYS
RAMDRIVE.SYS is Microsoft's RAM-disk driver for DOS, supplied within WINDOWS-95/98/ME releases. Normally it can be found in \WINDOWS directory.

RAMDRIVE.SYS should be loaded by a DEVICE (4.06) or DEVICEHIGH (4.07) command from a line of CONFIG.SYS file, for example:

where :

You may set up as many RAM-disks as free memory space allows : just add one such line to your CONFIG.SYS file per each extra RAM-disk.


 * Notes
 * 1) RAM-disk driver RDISK.COM with 2 Gb size limit may be downloaded from http://johnson.tmfc.net/dos/driver.html . This driver should be used together with XMS memory managers providing 4Gb XMS memory limit (note 3 to 5.04-01).

5.05-02 Reconfigurable drivers TDSK.EXE and BITDISK.EXE
Freeware drivers TDSK.EXE and BITDISK.EXE enable to define RAM-disk size not only at the moment of loading, as RAMDRIVE.SYS driver does, but also enable to postpone RAM-disk size definition, and even enable to do it repeatedly. This feature is very important for installation of MS-DOS 7 on an unknown computer, because you need to determine available amount of memory before a decision can be made about whether to arrange a RAM-disk and of what size.

Both TDSK.EXE and BITDISK.EXE drivers were written by Garcia de Celis, Valladolid, Spain, in 1992–1995, and then the last was version 2.3. Later these drivers were modernized and became a part of FreeDOS project. Now both these drivers can be downloaded from http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/ramdisk/. Original drivers of Garcia de Celis are there in archive TDSK23.ZIP, and modernized version 2.42 of the TDSK.EXE driver in archive TDSK242B.ZIP.

BITDISK.EXE is a simplified version of TDSK.EXE. While the latter is able to employ EMS, XMS or conventional memory, BITDISK.EXE can cope with XMS memory only. Therefore it always needs the HIMEM.SYS driver to be loaded in advance. TDSK.EXE can accept all BITDISK's options and, besides that, some options of its own.

Original drivers of Garcia de Celis should be initialized by DEVICE (4.06) or DEVICEHIGH (4.07) command in a line of CONFIG.SYS file. Modernized version 2.42 of the TDSK.EXE driver must be loaded in conventional memory only by DEVICE command (4.06), provided that CONFIG.SYS file also contains a line with  command (4.08). RAM-disk initialization line may include all required parameters (see further), and then RAM-disk will be created at once. But when creation of RAM-disk should be retarded, command line in CONFIG.SYS file must not include particular parameter's values; it may look, for example, as

or else as:

where :

The shown command doesn't cause memory allocation for the RAM-disk, but induces loading and initialization of driver's TSR module (about 600 bytes). At this stage DOS registers new RAM-disk and assigns its letter-name. If you repeat this line in CONFIG.SYS file more than once, you can initialize several RAM-disks.

In order to make RAM-disk accessible, the same driver must be invoked later by a command, written into a line of AUTOEXEC.BAT file or directly into DOS' command line, for example :

or else

where :

Command line, addressed to TDSK.EXE, contains some additional options, accepted by TDSK.EXE only. Allowable additional options for version 2.42 of TDSK.EXE driver are :

Auxiliary options,  ,  ,   are mutually exclusive and usually are omitted, because TDSK.EXE driver itself is able to choose optimum place to arrange RAM-disk.

The shown form of command can be repeatedly used to call either TDSK.EXE or BITDISK.EXE in order to change RAM-disk's size. Each time after this command RAMdisk is rearranged anew, and all its contents becomes lost. RAM-disk data are not affected by either driver in two cases : In order to solve the problem of RAM-disk letter-name determination, version 2.42 of TDSK.EXE driver is able to assign this letter-name as a value to environmental variable named TURBODSK or RAMDRIVE. An environmental variable with any of the mentioned names should be prepared in advance with SET command (3.26), and it should be given a question mark and a colon as its preliminary value :
 * if it is called without parameters to show current status ;
 * if it is called with a single  parameter to show help.

If a variable with the same name has another value, it will be preserved intact. But if this variable has just the shown value, and if at that moment RAM-disk is arranged already, then after execution of TDSK.EXE driver the question mark in variable's value will be replaced by letter-name of the RAM-disk. When RAM-disk’s letter-name is known yet, then it's easy to compose AUTOEXEC.BAT file so that this letter-name is automatically written into all relevant paths (an example in article 9.09-02).

After execution the TDSK.EXE driver returns errorlevel code (3.15-03, 9.07-03). Errorlevel values from 1 to 128 denote a reference number (handle) for XMS or EMS access to allocated memory area; other errorlevel values mean the following :

5.06-01 SMARTDRV.EXE – cache buffer driver
The SMARTDRV.EXE driver arranges and maintains disk's cache buffer. Data transfer operations in this buffer are performed via DMA controller. DMA access gives some relief to CPU and makes transfer operations faster for both HDDs and CD drives. Time saving effect becomes essential in case of large data amounts transfer, for example, during installation of operating systems Windows ME/2000/XP under DOS.

The SMARTDRV.EXE driver is a part of Windows-95/98 release and must be present in \WINDOWS directory. But WINDOWS OS itself performs buffering otherwise and doesn't need SMARTDRV.EXE. It is needed only in DOS, and in MS-DOS 7 as well. Since the cache buffer is expedient beyond conventional memory, access above 640 kb must be opened in advance. Therefore appropriate memory manager(s) (5.04-01, 5.04-02, 5.04-04) must be loaded before SMARTDRV.EXE. If you intend to access CD-ROMs with MSCDEX.EXE (5.08-03), the latter also should be loaded in advance. Most often SMARTDRV.EXE is loaded either by INSTALL command (4.15) from CONFIG.SYS file or from a line in AUTOEXEC.BAT file, for example :

where :

When SMARTDRV.EXE is running yet, it may be called from command line with other set(s) of options for execution of a command or for reconfiguration, for example :

where :


 * Notes
 * 1)  operation (writing cache) ignores   and   parameters, nothing is displayed.
 * 2) DMA data transfer, arranged by SMARTDRV.EXE driver, doesn't involve operations, performed by SHSUCDX.COM (5.08-04).
 * 3) In order to cope with SATA drives and with UltraDMA data transfer the UIDE.SYS cache driver should be preferred. This driver can be downloaded from site http://johnson.tmfc.net/dos/driver.html.

5.06-02 Double buffering driver DBLBUFF.SYS
The DBLBUFF.SYS driver provides compatibility for some HDD controllers, which otherwise may be unable to work with EMS memory and with WINDOWS OS. In particular, double buffering may be needed for HDDs with SCSI interface. The DBLBUFF.SYS driver is included in WINDOWS-95/98 release and normally can be found in \WINDOWS directory.

A way of loading DBLBUFF.SYS depends on contents of configuration parameter file MSDOS.SYS (5.01-01). If there is a line with "DoubleBuffer=1" parameter, then MS-DOS 7 will attempt to load DBLBUFF.SYS by default. Otherwise it should be loaded explicitly by DEVICE command (4.06) from a line in CONFIG.SYS file :

where :


 * Notes
 * 1) Status message, displayed by SMARTDRV.EXE driver (5.06-01), contains a column "buffering". If there is at least one "yes" in this column, then DBLBUFF.SYS driver must be loaded.
 * 2) If double buffering is needed, then a non-zero number of secondary buffers should be reserved by BUFFERS (4.03) or by BUFFERSHIGH (4.04) command in CONFIG.SYS file.

5.06-03 DRVSPACE.SYS – compressed drive's shell loader
DRVSPACE.SYS is a loader for TSR program DRVSPACE.BIN which provides on-the-fly compression and decompression for logical disks. Data flow is processed just in the course of access operations. Compression improves disk space usage, since compressed data are written continuously, and free disk space is not lost in partially filled clusters.

Files DRVSPACE.SYS and DRVSPACE.BIN are included in WINDOWS-95 release and normally must be written in the same directory outside compressed region of logical disk (most often in the root directory). When MS-DOS 7 discovers presence of a compressed region on the bootable disk, both DRVSPACE.SYS and DRVSPACE.BIN are loaded by default. Default loading may be discarded either by a line with parameter " " in MSDOS.SYS file (5.01-01) or by a " " command in CONFIG.SYS file (4.08, 9.01-01).

When DRVSPACE.SYS is to be loaded explicitly, it should be loaded before memory managers (5.04-01, 5.04-02) just as a driver by DEVICE command (4.06) from a line of CONFIG.SYS file, for example :

where :

When DRVSPACE.BIN is loaded, the DRVSPACE word becomes a command, invoking a dialog shell. This shell gives an opportunity to convert ordinary disks (and diskettes) into compressed ones and back, to create new compressed disks, to test and defragment compressed disks, to arrange protection of compressed disk space, etc.

Disk compression with DRVSPACE hasn't got much success because of several reasons. The first is incompatibility with other versions of DOS and with other operating systems (WINDOWS-95 is an exception). The second reason is that compression makes disks more vulnerable to possible errors and less accessible for data recovery procedures. The third reason is that nowadays the problem of disk's space is not so acute, as in early 1990s. Large and fast modern disk drives make compression "on the fly" not worth that loss of access speed caused by compression and decompression operations. This is why DRVSPACE usage is not included in examples of configuration files, presented in chapter 9.


 * Notes
 * 1) The DRVSPACE.BIN program provides compression for logical disks formatted with file systems FAT-12 or FAT-16. Disks formatted with FAT-32 can't be compressed by DRVSPACE.BIN.

5.07-01 ATAPI interface BIOS extension: ATAPIMGR.SYS
Disk drives with Integrated Drive Electronics (IDE) were developed by Western Digital Corp. and were employed for the first time in IBM's PC-AT in 1984. Since then such drives became the most widely used. Protocol of IDE drive's interaction with HDD controller has been named ATA (= Advanced Technology Attachment). In 1994 it has got status of standard ANSI X3.221-1994. With advent of CD-ROMs and other types of removable drives the ATA protocol was supplemented with new commands, including those for packet data transfer, and since 1998 became known as ATA Packet Interface, or ATAPI.

In computers produced after 2003, the ATAPI interaction protocol is implemented by PC's BIOS. A specific symptom of ATAPI support is BIOS's ability to load OS from optical DVD discs. In PCs unable to load OS from DVD disks, the ATAPI functions may be provided by interface driver ATAPIMGR.SYS, developed under Panasonic trade mark by Matsushita Corp. Due to this driver a standard (obsolete) IDE controller becomes able to give access to DVD disks, to removable magnetic, magneto-optical and solid-state media of high capacity. SFX archive 85X_DOS.EXE, containing version 2.04 of ATAPIMGR.SYS driver, can be downloaded from internet site http://panasonic.co.jp/pcc/products/drive/internal/support/info_dd2.html.

The ATAPIMGR.SYS driver should be loaded from CONFIG.SYS file before any other driver, which will need ATAPI interface support. A line loading the ATAPIMGR.SYS driver with DEVICE (4.06) or DEVICEHIGH (4.07) command may look like this :

where :

If "above" MS-DOS 7 with loaded ATAPIMGR.SYS the Windows-95/98 OS is launched, the latter will run in "MS-DOS compatibility mode" unless you add the following line into the \Windows\IOS.INI file :

If the ATAPIMGR.SYS driver finds that ATAPI interface functions are supported by PC's BIOS, it will not load. When ATAPIMGR.SYS is not loaded, some CD-ROM drivers (in particular, SR_ASPI.SYS) will not load either. Hence, in cooperation with ATAPIMGR.SYS, CD-ROM drivers which use ATAPI functions regardless of their origin should be preferred. Examples are OAKCDROM.SYS (5.09-01) and VIDE-CDD.SYS (5.09-02). Such drivers provide access to DVD-ROM discs in any case, whether ATAPIMGR.SYS will "agree" to load or not.

5.07-02 PCMCIA interface drivers
Since early 1990-ies portable PCs of "notebook" class were equipped with special 68-pin slot for external memory expansion cards. Interface for these cards was standardized in 1990 by PC Memory Card International Association (PCMCIA). In 1995 it was renamed into PC card interface, because at that time it was also used for a variety of peripheral equipment: modems, external disk drives, etc. The last 8th version of PC card interface standard was adopted in 2001. Later PC card interface was ousted by USB 2.0 interface (5.07-05).

In early 1990-ies there were several mutually exclusive types of PCMCIA controllers, and then external devices with PCMCIA interface had to be supplied with a number of PCMCIA drivers for DOS. Thus, CD-ROM drive Panasonic KXL-DN720A (1995) was supplied with 3 drivers for different PCMCIA controllers. These drivers enable to address the device with unified ASPI commands, just as devices with SCSI (5.07-03) or USB interface (5.07-05). This set of drivers, packed into SFX archive 720PCM32.EXE, can be downloaded from server ftp://ftp.panasonic.com/pub/Panasonic/Drivers/CDROM/.

Later PCMCIA controllers of i82365 type and those compatible with i82365 have ousted all other types. Most modern portable PCs are sold with pre-installed WINDOWS operating system, and are not supplied with PCMCIA drivers for DOS. In order to enable usage of external disk drives with PCMCIA interface for emergency maintenance, some hardware vendors have developed PCMCIA drivers which directly address from DOS to ports of i82365 controller. In particular, such drivers are proposed by Novac Co : driver NVIHD.EXE for non-optical storage devices and driver NVICDF.EXE for optical disc drives. From site http://www.driver.novac.co.jp/driver/hd150p/hd150p_drv.html you can download archive compact_PCMCIA.zip with version 4.0 (2000) of NVIHD.EXE driver. Version 4.0 (2001) of NVICDF.EXE driver, packed in archive FDOS.ZIP, can be downloaded from http://www.driver.novac.co.jp/driver/sta_PCMCIA/pcm_drv.html. Both mentioned Novac's PCMCIA drivers should be loaded without parameters by DEVICE (4.06) or DEVICEHIGH (4.07) command from a line of CONFIG.SYS file. After a storage device card is inserted into a PCMCIA slot, the same driver should be launched from command line once more, for example

or

where parameters mean :

The NVICDF.EXE driver doesn't need the /I parameter, because motor in optical disc drives is activated automatically, just after insertion of optical disc. Given information about the mentioned PCMCIA drivers should be treated with some caution, since the author had no opportunity to test these drivers.


 * Notes
 * 1) Windows ME release includes a DOS PCMCIA driver CARDDRV.EXE for external storage devices. However, exact information about it hasn't been found.

5.07-03 SCSI interface drivers
Small Computer's System Interface (SCSI) has been developed in 1982 by Shugart Co. and became widely known due to its implementation in Apple Computers, which were popular then. In 1986 SCSI interface has got status of standard ANSI X3.131-1986. Since then it has been modernized several times. For AT-compatible PCs the SCSI bus is a rare requisite, it is used predominantly in servers. Because of this reason SCSI bus driver's features are not described here in detail. Nevertheless a short survey of SCSI bus access principles is given below.

SCSI bus access may be provided either by PC's BIOS or by special drivers. Server's motherboards usually have embedded SCSI controller and BIOS extensions, enabling to access SCSI devices just as IDE devices, without special SCSI drivers. Known BIOS extensions need at least one active device to be present on SCSI bus when PC starts, and wouldn't be loaded otherwise. Removable disk drives without media inside are considered inactive. If a particular removable SCSI drive must be taken under BIOS control (for example, in order to be formatted as a HDD), you should manage to insert a media in this drive before BIOS launches its start tests. If BIOS senses a valid media inside a SCSI drive, the latter can be used to boot the PC, but beforehand you have to mark this drive as bootable in BIOS setup options. SCSI drives initially registered by BIOS as inactive can't be taken under BIOS control, even if SCSI BIOS extensions are loaded and provide access to other drives.

Some SCSI controllers on extension boards have internal read-only memory, containing BIOS software extensions for SCSI bus, and then SCSI bus access is just as that provided by embedded controllers. You can easily determine presence of BIOS software extensions by exploring BIOS setup options. Unfortunately, lesser SCSI extension boards have no BIOS software extensions. SCSI devices which are not supported by BIOS software extensions cannot be used to boot the PC, and access should be arranged by drivers. This form of access is preferable for removable disk drives, because many drivers are able to register their current media partition structure (while most BIOS versions register media partition structure only once at start-up).

SCSI driver sets for DOS have been developed by several vendors; the most known are Adaptec, DTC, Mylex, Tekram. Each driver set consists of SCSI controller driver (ASPI8U2.SYS from Adaptec, AS80DOS.SYS from DTC, etc.), HDD driver for SCSI (ASPIDISK.SYS from Adaptec, DISKDOS.SYS from DTC, etc.) and a CD-ROM driver for SCSI (ASPICD.SYS from Adaptec, CDDOS.SYS from DTC, etc.). Drivers of either set must be loaded by DEVICE or DEVICEHIGH command from a line in CONFIG.SYS file. SCSI controller driver always must be loaded in advance, before drivers for other devices connected to SCSI bus.

Drivers for HDDs and CD-ROMs, proposed by SCSI controller vendors, accept standardized ASPI command codes and are suitable for almost any device of the same class with SCSI interface. This is not true for all devices: those having unique functions definitely need proprietary drivers. Most SCSI controller drivers are suitable for series of SCSI controller types. Emergency diskettes for Windows-95/98 include two sets of SCSI drivers : from Adaptec and from Mylex. This is often thought to be enough for almost any PC with SCSI bus. In any case configuration file(s) on these diskettes may be taken as example of loading drivers for SCSI bus.

5.07-04 IEEE1394 (FireWire) interface drivers
The FireWire interface has been developed by Apple Company in 1987 for connecting devices having large data transfer rates, up to 393 Mb/sec. Such data transfer rates are typical for video cameras, for video storage devices, for external hard disk drives. Since 1995 the FireWire interface specification has been adopted as standard IEEE1394. For AT-compatible PCs expansion cards with IEEE1394 interface controllers are produced, but up to now the FireWire interface hasn't become widely used.

Now two drivers for IEEE1394 interface controllers are known, which are claimed to be suitable under MS-DOS 7. The first is ASPI1394.SYS driver, developed by Iomega Company. From site http://www.stefan2000.com/darkehorse/PC/DOS/Drivers/USB/ you can download archive iomega_usb_firewire_dos_driver_boot_disk.zip with version 1.01 of ASPI1394.SYS driver (dated 2002). Just there is an example of loading this driver, but explanation of parameters isn't given. Version 1.02 of another driver – SBP2ASPI.SYS, developed by Medialogic Company, is contained in SFX archive DAT.EXE, which can be downloaded from site http://www.datoptic.com/fw25fr.html.

Since both mentioned drivers implement the same unified set of ASPI commands for HDDs and for CD-ROM drives connected via IEEE1394 bus, those two drivers are reported to be suitable for devices of the same class on SCSI bus (5.07-03) and on USB bus (5.07-05). But this feature hasn't been tested by the author, and is reported here for contemplation only.

5.07-05 USB interface drivers
Universal Serial Bus (USB) is a joint development of Compaq, Intel, Microsoft and NEC. In 1996 these companies have adopted version 1.0 of USB bus specification. Since then an embedded USB controller has become ordinary requisite of motherboards in almost all AT-compatible computers. Practical importance of USB bus has increased even more in 2002 with adoption of USB 2.0 specification, stipulating data transfer rates up to 480 Mb/s. Now a vast majority of external devices is designed for connection via USB bus.

USB controllers implement three different types of interaction with PC's software :
 * Open Host Controller Interface (OHCI),
 * Universal Host Controller Interface (UHCI),
 * Enhanced Host Controller Interface (EHCI).

Each type of interaction needs a specific treatment. All modern USB controllers match USB 2.0 specification and implement EHCI type of interaction, but are able to simulate USB controllers of previous generation, implementing either OHCI or UHCI type of interaction. UHCI controllers transfer data via an allotted port, whereas OHCI controllers transfer data via a buffer zone in memory. The OHCI type of interaction is implemented by chipsets from SIS and ALI, whereas UHCI — by chipsets from INTEL, VIA, and others.

Access from DOS to peripheral devices, connected via USB bus, can be provided either by PC's BIOS system or by loaded drivers. Access provided by BIOS is necessary, when operating system must be loaded from an external storage device. Solutions of this problem are considered in detail in article 9.11-01. But PC's BIOS is not necessarily ready to cope with any external device: some BIOS systems accept external devices of a certain class only, for example, floppy drives with USB interface. Besides that, BIOS systems register properties of storage media only once, just after PC is switched on. If, for example, in a USB adapter slot the originally inserted storage card will be replaced by some other card, then BIOS wouldn't provide access to that other card. An opportunity to access removable storage media can be obtained by loading an appropriate driver for storage devices of a particular class.

In order to avoid possible conflicts between driver(s) and PC's BIOS, parameter "Legacy USB support" on page "Advanced" of BIOS Setup settings should be set to "Disabled". If there is no similar parameter(s) in BIOS Setup settings of your computer, then, most probably, this BIOS system doesn't support USB storage devices. Access to media in these devices is still possible, but only by means of appropriate driver(s). Generally, USB controller driver should be loaded first, and then, drivers for all USB devices which you intend to use.

The very first drivers for USB controllers, UHCI.EXE and OHCI.EXE, were developed in 1998–2001 by SoftConnex Co. Version 2.3 of these drivers is present in bootable diskettes, formed by a known software packet Norton Ghost (up to its version 8.0). Version 2.5 of the same drivers can be downloaded from internet site http://www.stefan2000.com/darkehorse/PC/DOS/Drivers/USB/. In order to suffice any USB controller, the mentioned drivers should be loaded sequentially, one after the other, but actually only one of them will be loaded – the one that corresponds to interaction type, implemented by a particular USB controller. Loading may be performed either just from command line, or by LH command (3.17) from a line of AUTOEXEC.BAT file, or else by DEVICE (4.06) or DEVICEHIGH (4.07) command from a line of CONFIG.SYS file, for example :

Drivers from SoftConnex Co. are devised for USB keyboards, for USB mouse pointing devices and for external ports on USB bus. Obviously, a driver for a particular external device should be loaded afterwards. In particular, for mouse pointing devices, any of those drivers will work which are described in part 5.03. But you have to connect your external device to port of the first USB controller, because additional USB controllers such as can be found in more recent computers, cannot be detected by drivers from SoftConnex Co. Besides that, these drivers don't provide functions for access to storage cards and to external disk drives.

Problem of access from DOS to USB storage devices has become especially urgent now. There is differing advice about that in various internet sites. The author of this book had to undertake some experiments in order to form his own opinion. In these experiments the role of a drive under test was played by USB adapter ImageMate-2 for Compact Flash cards.

Of the various USB controller drivers, USBASPI.SYS from Matsushita (trade mark Panasonic) has been acknowledged the best. Latest version 2.27 of this driver (dated 22.10.2008), packed into SFX archive F2H_USB.EXE, can be downloaded from site http://panasonic.co.jp/pcc/products/drive/other/f2h_usb.html. This driver is able to detect all active USB controllers of any type. It scans each USB bus, and registers all connected devices with all their LUN numbers (see note 1 to appendix A.03-2 for details). Unlike most other USB drivers, version 2.27 of this driver doesn't cause conflicts with PC's BIOS when "Legacy USB support" parameter is enabled. Complete specification for USBASPI.SYS driver isn't made public. Nevertheless, the following options have been discovered :

The,  ,   parameters give a chance to save some time, if class of USB controller(s) in a particular computer is known in advance. The last two parameters ( and  ) are necessary, when operating system is to be loaded from a USB device under BIOS control, because otherwise either the loading process will be disrupted or else other USB devices will be left inaccessible. One more warning: the USBASPI.SYS driver doesn't allow loading of drivers for optical disc drives in advance, even if these disc drives have a non-USB interface.

The best driver for mass storage devices is still ASPIDISK.SYS, originally developed by Adaptec for hard disk drives with SCSI interface. But ASPIDISK.SYS has no direct relation to interface type, because it addresses storage devices via standardized set of ASPI functions, provided by SCSI controller's driver. Since just this set of ASPI functions is provided by USBASPI.SYS driver too, the ASPIDISK.SYS driver is able to cope with storage devices, connected to USB bus.

Version 4.01b of the ASPIDISK.SYS driver (size 15060 bytes, dated 02.12.1998) can be found inside SFX archive DOSDRVR.EXE from Adaptec's internet site http://www.adaptec.com/en-US/speed/scsi/dos/dosdrvr_exe.htm. This driver gives access to logical disks with file systems FAT-12, FAT-16, FAT-32 and "Big Floppy". If removable media is not present in the storage device at the moment of initialization, then this storage device will be given one of reserved letter-names. But there are removable media which may be formatted as hard disk drives with several FAT-16 partitions, each representing a separate logical disk. The ASPIDISK.SYS driver can provide access to all such partitions (including those beyond the first), if an appropriate number of disk's letternames is reserved beforehand by specifying this number after the  parameter in command line. The whole set of allowed command line options includes the following :

If specification for controlled devices is not given in command line, then the ASPIDISK.SYS driver will examine each encountered device and will attempt to take under its control all mass storage devices, even those having no removable media inside at that moment. When specification for controlled devices is given, no time will be lost for examination of unsuitable devices. In the example above the specification of device number 2 means that driver will not examine devices 0 and 1, connected to bus of the first USB controller, since these devices may happen to be, for example, a scanner and a printer.

For external optical CD/DVD-ROM drives with USB interface the NJUSBCDA.SYS driver from Workbit Corp. may suffice. Archive BST_DOS.ZIP, containing version 3.9 of NJUSBCDA.SYS driver (dated 2000), can be downloaded from internet site http://www.driver.novac.co.jp/driver/sta_black/bst_drv.html. As many other CD/DVDROM drivers, NJUSBCDA.SYS accepts from command line the  parameter, followed by an arbitrary identifier (for example,  ) of up to 8 characters long. It is used for drive's identification by file system translation utility – either MSCDEX.EXE (5.08-03) or SHSUCDEX.EXE (5.08-04), one of which should be loaded afterwards. It should be given exactly the same identifier in its command line.

The described drivers of USB devices should be loaded by DEVICE (4.06) or by DEVICEHIGH (4.07) commands from lines of CONFIG.SYS file. Let's assume that all mentioned drivers are present in the \DOS\DRV directory of bootable disk; then lines for loading these drivers may look, for example, as Parameters in the shown example are selected for loading MS-DOS 7 from a device with some other (non-USB) interface, when it is not known in advance, how many USB controllers there are in the PC and which devices are connected to USB bus(es). But when PC's hardware is known, and MS-DOS 7 loading is performed not for the first time, parameters  and   may be omitted. Besides that, the loading goes faster if parameters specify the type of USB controller and particular devices which should be registered.

The above-described USBASPI.SYS driver, developed by Matsushita (version 2.27, file length 39729 bytes), is often confused with synonymous driver supplied by Novac (version 1.07, file's size 43528 bytes). The latter driver detects only the first USB controller, works according to the USB 1.1 specification exclusively, ignores all devices with non-zero LUN number,note 1 to appendix A.03-2 and accepts from command line a somewhat different set of options :

The Novac's USBASPI.SYS driver, packed into archive HD352u_dos.zip, can be downloaded from site http://www.driver.novac.co.jp/driver/hd352u/hd352u_drv.html. Besides the USBASPI.SYS driver itself, the HD352u_dos.zip archive contains version 2.0 of the Novac's driver Di1000dd.sys for mass storage devices. The Di1000dd.sys driver accepts from command line parameter  – an example of disk's letter-name ("S") which should be appointed to the logical disk, opened for access by the Di1000dd.sys driver.

However, letter-name appointment by the Di1000dd.sys driver goes "dirty", created dummy disks (phantoms) are not hidden. The Di1000dd.sys driver can't cope with multiple LUN numbers, can't provide access to disks with FAT-32 file system, to devices beyond the bus of first USB controller, needs a media to be present in storage device(s) at the moment of initialization. Though capabilities of both mentioned Novac's drivers seem substantially limited, they may be sufficient for performing main data transfer operations in computers with known hardware.

One more way of access to USB storage devices from DOS is opened by combined driver DUSE.EXE, developed by Cypress Semiconductor. Version 4.9 of this driver (dated 2003), packed into archive Duse_4_9.zip, is available in subdirectory "downloads" of site http://www.pocketec.net/support.taf. The DUSE.EXE driver combines USB controller driver with driver for CD-ROMs and with driver for non-optical storage devices, including HDDs and solid-state storage cards.

The opportunity to get all-in-one seems attractive, but comes with an unexpected consequence : for some odd reason, DUSE.EXE requires DOS working in real mode only, that is, without the EMM386.EXE driver (5.04-02), which gives access to UMB memory region. Having no access to UMBs, DOS is forced to load all drivers into conventional memory (below 640 kb), and then resident module of DUSE.EXE with default settings occupies yet more 233 kb of precious conventional memory, so that no free space is left there for normal operation of other programs.

Some tolerable configuration can be obtained, if access to UMB region is provided in real mode by UMBPCI.SYS driver (5.04-04) and if you decline loading of DUSE's CD/DVD-ROM support module. Thus total size of DUSE's resident module has been reduced to 153 kb, but all attempts to load it beyond conventional memory have failed. For comparison : resident modules of USBASPI.SYS and ASPIDISK.SYS drivers provide nearly the same functions, but together occupy 45 kb only and can be loaded beyond conventional memory either in CPU's real mode or in V86 mode as well. If circumstances will force you to use the DUSE.EXE driver, then a line in CONFIG.SYS file for loading DUSE.EXE may look, for example, as

where the shown options mean :

The whole list of DUSE's options can be found in file DUSEUsersGuide.pdf inside the same archive Duse_4_9.zip. The INT option, proposed there among other options, deserves special notice. It claims to provide an opportunity to divide external HDDs into partitions with FDISK.EXE utility (6.13), but in fact doesn't. Moreover, making HDD partitions with ASPI functions (note 5 to 6.13) was not available too, either with or without the INT option, whereas the USBASPI.SYS driver enables to do it easily.

Two personal attempts to create sets of USB drivers for DOS became known recently. Version 1.0 of driver's set, developed by G.Potthast, appeared in december 2006 at internet site http://www.georgpotthast.de/usb/. Later, in august 2009, B.Johnson has uploaded version 0.08 of another USB driver's set at his site http://bretjohnson.us/.

The set developed by G.Potthast presents drivers for USB controller, for non-optical storage devices and for some types of USB printers. Besides drivers, it includes a number of service utilities, enabling to detect and to fix errors of USB interface configuration. This set of drivers can't determine actual number of USB storage devices, can't detect devices on bus(es) of non-first USB controller(s), requires a media to be present in storage device at the moment of initialization, provides access to the first partition only of a physical disk and has some other considerable drawbacks.

The set developed by B.Johnson, besides the same main drivers and some service utilities, includes drivers for USB keyboard, for USB mouse and provides access to disks formatted with FAT-32. USB controller must be either of UHCI or EHCI type and can be used with 12 Mb/s transfer speed only. Probably, some drawbacks are not revealed yet, because this set of drivers appeared in the last moment and wasn't tested thoroughly.

Despite all drawbacks of early versions, those sets of drivers are worth serious attention. Both sets are still under development, and their future versions may be much better. But the most valuable feature of these driver's sets is their partially opened executable code. There is a lot of interesting detail for all those who intend to have a closer deal with USB interface.

5.08-01 IFSHLP.SYS – IFS service driver
Auxiliary driver IFSHLP.SYS provides service functions for IFS (= Installable File Systems) procedures. IFS file system is a form of hiding real data structures and real ways of access, enabling to avoid explicit technical complications and implement selective access rights.

Original 16-bit access to storage devices is performed by BIOS's INT 13 handlers, which require CPU's real mode and can't do their job indirectly, for example, via a network. When CPU works in protected mode or in V86 mode, each call to INT 13 handler implies a callback with switches to real mode and back. These switches make a slow 16-bit access even slower. Service functions, provided by IFSHLP.SYS driver, enable a much faster 32-bit direct and indirect disk access without callbacks in both protected and V86 modes. But If you intend to work in real mode only and without network communications, then, most probably, the IFSHLP.SYS driver will not be needed.

The IFSHLP.SYS driver is present in Microsoft Network Client packet, and also in Windows-3.11\95\98\ME releases. MS-DOS 7 searches in the \Windows directory for the IFSHLP.SYS driver and loads it by default, unless default loading is forbidden by  command (4.08) in CONFIG.SYS file.

5.08-02 NTFSDOS.EXE – NTFS file system translator
An opportunity of access from DOS to disks with NTFS file system is provided by driver NTFSDOS.EXE, written by Mark Russinovich and Bryce Cogswell. Full-functional versions of this driver (latest the 5th) were not free. Here a freeware version 3.02 (dated 2001) is described, which enables only reading NTFS volumes, including reading programs into memory for execution. However, NTFSDOS driver and several other helpful items disappeared from their author's personal site since 2006, when the authors joined Microsoft's developers team. Now archive Ntfs30r.zip containing NTFSDOS.EXE driver is still available from, for example, server ftp://ftp.uni-koeln.de/pc/msdos/diskutils/ and from http://web.archive.org/web/20020123013310/www.sysinternals.com/new.shtml.

This is just the moment to remind that Windows-2000/XP installation program, being launched from a CD-ROM disc, gives an opportunity to open the so called Recovery Console. Default settings of the Recovery Console enable writing to NTFS volumes, but prohibit copying of file(s) from NTFS volumes. Consequently, version 3.02 of the NTFSDOS.EXE driver enables to do just what is not allowed by Recovery Console.

The NTFSDOS.EXE driver uses XMS-memory and therefore needs the HIMEM.SYS driver (5.04-01) to be loaded beforehand. Besides that, NTFSDOS.EXE needs much space in conventional memory. In particular, for access to a 10 Gb NTFS disk the NTFSDOS.EXE driver occupies 285 kb of conventional memory. Because of such memory requirements it's not reasonable to keep the NTFSDOS.EXE driver constantly loaded. Therefore it is loaded from command line just before access to NTFS disk becomes necessary, for example :

where :


 * Notes
 * 1) NTFSDOS.EXE driver loads handlers, enabling to read long names of files and directories in NTFS volume(s). Non-truncated names are displayed by Volkov Commander file manager (6.25) and can be got by any program, which is able to address the mentioned handlers. However, file copying commands and utilities in DOS truncate long names.
 * 2) Attempts to access disk(s) with damaged NTFS file system may cause the PC to hang. Suspected NTFS file system should be checked and fixed in advance by CHKDSK procedure, provided by Recovery Console.

5.08-03 MSCDEX.EXE – optical disc's file system translator
MSCDEX.EXE is a resident program, which cooperates with one or more CD/DVDROM drivers, enables disk's letter-names assignment and access to the associated logical disks. In fact it is a file system translator for CD-ROM's file systems "High Sierra" and ISO 9660, which differ from those "understandable" to DOS' core.

The MSCDEX.EXE program is contained in Windows-95/98 releases and normally can be found in \Windows\Command directory. MSCDEX.EXE should be loaded after all necessary CD-ROM drivers, but before SMARTDRV.EXE (5.06-01) cache driver, if the latter is used. Most often the MSCDEX.EXE program is loaded from CONFIG.SYS file with INSTALL (4.15) or INSTALLHIGH (4.16) command, but may be launched from AUTOEXEC.BAT file with LH command (3.17) or just from command line, for example :

where :


 * Notes
 * 1) Resident module of MSCDEX.EXE program accepts other program's requests via INT 2F\AX=1500–150Fh (8.03-13 – 8.03-19).

5.08-04 SHSUCDX.COM – optical disc's file system translator
In recent years several amendments to CD/DVD-ROM file system specifications have been adopted, stipulating usage of long filenames. The MSCDEX.EXE program (5.08-03) can't cope with modified file systems on optical discs: it shows truncated long names, but gives no access to such files. This drawback isn't inherent to SHSUCDX.COM program ; except this, SHSUCDX.COM is a close functional equivalent of MSCDEX.EXE. Development of SHSUCDX.COM program has been started by John McCoy and now is continued by Jason Hood. Archive Shcdx302.zip contains version 3.02 (dated 2005) of SHSUCDX.COM.

The SHSUCDX.COM program can be loaded from a line of AUTOEXEC.BAT file by LH command (3.17) or just from command line, but usually it is loaded by INSTALL (4.15) or by INSTALLHIGH (4.16) command from a line of CONFIG.SYS file, for example :

where

Besides the parameters shown above, SHSUCDX.COM program can accept the following options:


 * Notes
 * 1) Data transfers, arranged by SHSUCDX.COM program, are not supported by SMARTDRV.EXE cache buffer driver (5.06-01), but are supported by UIDE.SYS cache buffer driver (note 3 to 5.06-01).

5.09 Drivers for optical disc drives
Optical disc drives with different interfaces usually need different drivers. Some drivers for optical disc drives with SCSI and USB interfaces are mentioned in articles 5.07-03 and 5.07-05. But in AT-compatible PCs a vast majority of internal disc drives has the IDE (ATA) interface, and drivers for such disc drives are presented here, in part 5.09.

Popular types of motherboards are equipped with two IDE controllers. Each of them enables to connect two devices, which may be optical disc drive(s) and magnetic hard disk drive(s) as well. Connection of optical and magnetic drives to one IDE controller is allowed, but can't be recommended, since relatively slow optical disc drives cause reduction of total data transfer rate. It's better to connect optical device(s) to a separate IDE controller, which must be enabled in settings of BIOS Setup program.

In modern PCs the BIOS Setup programs propose several operation modes for IDE controllers, including that with polling serial ATA buses only (S-ATA). Since most optical disc drives have parallel ATA interface, a compatible operation mode should be preferred. If BIOS Setup program enables to affect direct memory access (UltraDMA), then an ordinary mode of IDE access should be set ("Legacy IDE mode"). These settings guarantee proper operation of optical disc drives and drivers in modern PCs under MS-DOS 7.

5.09-01 OAKCDROM.SYS – CD-ROM driver from OTI Corp.
The OAKCDROM.SYS driver is developed by Oak Technology for CD-ROM disc drives with standard IDE interface. OAKCDROM.SYS file, dated 1997, is present in WINDOWS-95/98 emergency diskettes. The same version of OAKCDROM.SYS can be downloaded from site http://www.computerhope.com/download/hardware.htm#02.

In modern PCs equipped with a DVD drive, the OAKCDROM.SYS driver enables access to both CD and DVD discs. But in PCs produced before 2003, presence of a DVD drive is not enough, since BIOS system may provide no support for ATAPI protocol (see 5.07-01 for details), and then OAKCDROM.SYS will enable access to CD discs only. In such computers, access to DVD discs is still possible, but requires ATAPI protocol support module to be installed in advance by ATAPIMGR.SYS driver (5.07-01).

The OAKCDROM.SYS driver should be loaded by DEVICE (4.06) or DEVICEHIGH (4.07) command from a line of CONFIG.SYS file, for example :

where :

The OAKCDROM.SYS driver is able to search for CD/DVD-ROM disc drives throughout all IDE-controllers having typical port addresses (1F0h, 170h) and typical interrupt request (IRQ) line numbers. If PC is equipped with several such disc drives, the OAKCDROM.SYS driver will take under its control all drives, which will be found.

5.09-02 VIDE-CDD.SYS – CD-ROM driver from Acer Co.
Version 2.14 of the VIDE-CDD.SYS driver, dated 1998, is a close functional equivalent of OAKCDROM.SYS driver (5.09-01), but VIDE-CDD.SYS is more compact (size 11.8 kb) and can accept port address(es) together with IRQ line number(s) from command line. The latter feature is important when non-standard interface specifications are used, and search for disc drives must be avoided. SFX archive Apicd214.exe, containing VIDE-CDD.SYS driver, can be downloaded via internet, for example, from ftp://ftp.benq.co.uk/cd-rom/drivers/apicd214.exe.

If PC's BIOS doesn't support ATAPI protocol, then VIDE-CDD.SYS can provide access to DVD discs, but needs the ATAPIMGR.SYS driver (5.07-01) to be loaded in advance. VIDE-CDD.SYS must be loaded from a line in CONFIG.SYS file with DEVICE (4.06) or DEVICEHIGH (4.07) command, for example :

where :

There may be more than one  parameter specified in one line. When at least one  parameter is given, all other port addresses and IRQ line numbers will not be examined. When  parameter is omitted, a search for CD/DVD-ROM drives will be initialized throughout all typical IDE port addresses and IRQ line numbers : ,  ,  ,   (A.14-1). The VIDE-CDD.SYS driver will take under its control all optical disc drives, which will be found.

5.09-03 QCDROM.SYS – a freeware CD/DVD-ROM driver
Version 4.2 of QCDROM.SYS driver was developed in 2007 by J. R.Ellis on the basis of his earlier driver XCDROM.SYS. Contrary to the latter, the QCDROM.SYS driver is able to provide access to DVD discs and does not need ATAPI protocol support from either the PC's BIOS or the ATAPIMGR.SYS driver. The QCDROM.SYS driver can control up to three CD/DVD-ROM drives, connected to IDE controller(s) with standard port base address(es) and standard interrupt request line(s): 1F0h with IRQ 14 and/or 170h with IRQ 15.

The QCDROM.SYS driver, packed into archive QCDROM42.ZIP, can be downloaded from internet site http://cyberia.dnsalias.com/Cyb.05.Htm.

QCDROM.SYS should be loaded by DEVICE (4.06) or DEVICEHIGH (4.07) command from a line of CONFIG.SYS file, for example :

where :

Besides the shown parameters, QCDROM.SYS driver can accept from command line the following options :

Up to three parameters, prohibiting search for disc drives, may be specified in one command line. Disc drives will be numerated according to order of corresponding parameters in command line. If specified checks don't reveal presence of disc drive(s), then all other optical disc drives will be ignored, and resident module of QCDROM.SYS driver wouldn't be loaded.

5.09-04 DVS.SYS – CD/DVD-ROM driver from DVS Corp.
The DVS.SYS driver has been developed in 1999 by Digital Video Systems Corp. DVS.SYS driver is able to provide access to DVD discs and doesn't need ATAPI protocol support neither from PC's BIOS, nor from ATAPIMGR.SYS driver. Version 1.1 of DVS.SYS driver, packed into SFX archive Drdvdwd.exe, can be downloaded from internet site http://web.archive.org/web/20030212210152/www.dr-tech.com/drivers/cdroms.html.

The DVS.SYS driver should be loaded by DEVICE (4.06) or DEVICEHIGH (4.07) command from a line of CONFIG.SYS file, for example :

where :

The DVS.SYS driver is able to search for disc drives, but performs search more slowly, than other similar drivers. An experiment has confirmed that DVS.SYS driver can take under its control at least two optical disc drives, connected to either of IDE controllers with standard specifications of port base addresses and interrupt request line numbers (1F0h with IRQ 14 and/or 170h with IRQ 15).