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 DOS’s system services

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.

[Paths]
WinDir=C:\WINDOWS
; path for environmental variables TMP, TEMP and PATH
WinBootDir=C:\WINDOWS
; path for environmental variable WINBOOTDIR
HostWinBootDrv=C
; announcement of the disk used to boot the PC
[Options]
Logo=0
; hide loading messages under logo (= 1) or not (= 0)
BootMenu=0
; display Windows’s boot menu (= 1) or not (= 0)
BootMenuDelay=20
; delay in seconds of default menu item choice
BootMenuDefault=1
; menu item number to be chosen as default
BootKeys=1
; enable (= 1) or disable (= 0) the "hot keys" F5,
; Shift-F5, F6, F8 and Shift-F8, described in article 1.02
BootDelay=2
; waiting time (in seconds) for "hot key" keystroke
BootMulti=0
; disable the F4 key (1.02) for previous DOS version
BootWin=1
; load MS-DOS 7 and Windows (= 1) or previous DOS (= 0)
BootSafe=0
; load Windows in ordinary (= 0) or in safe mode (= 1)
BootWarn=0
; don’t warn about loading Windows in safe mode
BootGUI=0
; load Windows with its GUI (= 1) or MS-DOS 7 (= 0)
LoadTop=0
; load Command.com and Dblspace.bin below 640 kb
AutoScan=0
; Scandisk.exe automatic launching conditions:
;       – never launch automatically (= 0),
;       – launch after each identified failure (= 1)
;       – launch during each PC loading procedure (= 2)
DBLSpace=0
DRVSpace=0
; don’t load compression on-the-fly drivers. Otherwise
; value = 1 may be specified for one such driver only
Network=0
; load (= 1) or don’t load (= 0) network support
DoubleBuffer=0
; cancel default loading of Dblbuff.sys driver (5.06-02)
DisableLog=1
; don’t write loading report into Bootlog.txt file.

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 :

DEVICEHIGH=C:\DOS\DRV\Setver.exe

where :

C:\DOS\DRV\ – 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 :

Setver.exe /?

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

Setver.exe Qbasic.exe 6.22

where :

Qbasic.exe – name example of the utility to be "deceived". The name must have suffix *.COM or *.EXE.
6.22	–	an example of required DOS version number.

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

Setver.exe Qbasic.exe /D

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) :

0	– successful completion
1	– invalid command line switch specification
2	– invalid filename specification
3	– no memory enough to carry out the command
4	– invalid version number format
5	– specified entry isn't found in the table of versions
8	– too many parameters in command line
9	– one or more necessary parameters are missing
10	– an error detected while reading the table of versions
11	– the table of versions is corrupt
13	– no more space in table of versions for a new entry
14	– an error while writing SETVER.EXE with new table

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 National adaptation drivers

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 :

COUNTRY=007,866,C:\DOS\DRV\Country.sys

where :

007	–	country code (A.02-2), in particular for Russia;
866	–	number of codepage (A.02-2), defining character set for Russia;
C:\DOS\DRV\ – path example to file COUNTRY.SYS, copied into common directory for DOS drivers.

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 :

DEVICE=C:\DOS\DRV\Display.sys CON=(EGA,866,2,1)

where :

C:\DOS\DRV\ – example of a path to DISPLAY.SYS driver, copied into special directory for DOS drivers.
CON	–	(console) – specification of display as output device (no alternative).
EGA	–	means that PC is equipped with EGA, VGA or SVGA video card ; alternatives to EGA type are : LCD – video module used in obsolete portable PCs (notebooks) ; CGA – obsolete color video card without codepage switching ; MONO – obsolete monochrome MDA video card, also without codepage switching. When type of video card is omitted, the driver DISPLAY.SYS will try to determine it, but that leaves a chance for error.
866	–	number of primary codepage (A.02-2), this one is in particular for Russia. Several codepages are supplied in each of the files EGA.CPI, EGA2.CPI, EGA3.CPI and ISO.CPI. Later the MODE.COM utility (6.18) enables to select proper codepage and write it into memory buffer prepared by DISPLAY.SYS driver.
2	–	number of memory buffers to be prepared for character sets, besides the one prepared for the primary character set, specified by preceding codepage number. From 0 to 6 auxiliary buffers are allowed for EGA, VGA and SVGA video cards, no more than 1 – for LCD video modules, and only 0 – for CGA and MDA video cards.
1	–	number of hardware-supported fonts for each codepage. This number may be omitted together with preceding comma. Default is 1 for LCD type and 2 for EGA, VGA and SVGA video cards.

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 :

INSTALLHIGH=C:\DOS\DRV\Nlsfunc.exe C:\DOS\DRV\Country.sys

where :

C:\DOS\DRV\ – path example to NLSFUNC.EXE driver, copied into common directory for DOS drivers.

C:\DOS\DRV\Country.sys – path and name examples for a file with national specifications data (5.02-01).

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 :

INSTALL=C:\DOS\DRV\Keyb.com UK,850,C:\DOS\DRV\Keybrd3.sys /E /ID:168

where :

C:\DOS\DRV\ – path example to KEYB.COM driver, copied into common directory for DOS drivers.
UK	–	example of a two-letter national keyboard layout code (other layout codes in appendix A.02-2 ).
850	–	example of national codepage number (A.02-2). When it is specified just here, it will not be changed automatically following display codepage change by CHCP command. If synchronous change of codepages (on both display and keyboard) is preferable, then codepage number here should be omitted, but both enclosing commas must remain intact (. . .UK, ,C:\DOS\DRV\Keybrd3.sys. . .).
C:\DOS\DRV\KEYBRD3.SYS – path and name examples for keyboard data file. Each such file contains several national layout tables (A.02-2).
/E	–	this parameter specifies that keyboard layout should be adapted to "enhanced" 101/108-key keyboard.
/ID:168	–	identifier of a certain keyboard subtype, needed for those countries only, where more than one keyboard layout is used (A.02-2). Most countries, including Russia, use only one keyboard layout, and then the subtype identifier /ID should be omitted.

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

CTRL-RightSHIFT – to type symbols 128-255, specific for each selected national codepage ;

CTRL-LeftSHIFT – to type symbols 032-127 (english letters, digits and punctuation symbols), common for all codepages ;

CTRL-ALT-F1 – activate original american codepage 437 (selected national codepage becomes disabled) ;

CTRL-ALT-F2 – return from american codepage 437 back to selected national codepage ;

CTRL-ALT-F7 – enable typewriter keyboard mode, if supported by the loaded keyboard layout table.

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

LH C:\DOS\DRV\Keyrus.com

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) :

LH C:\DOS\DRV\Keyrus.com @Opt_file.ext

KEYRUS.COM is not loaded and doesn't affect its loaded TSR part when it is executed in command line to show default options Keyrus /?, or to extract internal fonts and keyboard layout, with Keyrus /FILES, 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 /SAVE.

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 :

/KEYBOARD=Off – don’t load keyboard module, use BIOS’ layout.

/BASE_KEYS – enables key reallocation ( default is OFF).

/KEYS=filename.ext – take keyboard layout from a file. This file (either 212 or 318 bytes long) may be created by KEYEDIT utility, supplied together with the driver. When KEYRUS.COM is launched with /SAVE option, then specified file is not loaded, but rather becomes KEYRUS’s internal default layout.

/BUFFER=ON – expands keyboard’s buffer up to 31 characters.

/FAST=ON,10,1 – set keyboard’s speed (0 – the fastest, then 1, 2, 4, 8, 10, 13, 16, 20, 31 – the slowest) and delay from 0 (0,25 s) to 3 (1 s).

/RUSALT=ON – enables typing symbols [ ] ; ' , . / in any national keyboard layout while the ALT key is kept pressed.

/BEEP=OFF,rus – no beep at keystroke in RUS (any national) keyboard layout. Instead of RUS the LAT (latin) and ALT (pseudographic) layouts may be specified.

/CLICK=OFF,rus – no click at keystroke in RUS (any national) keyboard layout. Instead of RUS the LAT (latin) and ALT (pseudographic) layouts may be specified.

/LAMP=ON,rus – lit ScrollLock lamp in RUS (any national) keyboard layout. Instead of RUS the LAT (latin) and ALT (pseudographic) layouts may be specified.

/COLOR=0,2 – indicate keyboard layout with border color. Left color code (0 = black) is for RUS (any national) keyboard layout. Right color code (2 = dark green) is for ALT (pseudographic) keyboard layout. Other allowable color codes in appendix A.10-5.

/ALT=87,4 – set a "hot" key for switching to pseudographic keyboard layout. Shift 4 and scancode 87 mean switching by CTRL-F11 key combination.[Note 3][Note 4] /ALT=OFF means no access to pseudographic keyboard layout.

/SCAN=54,4 – set a "hot" key for switching to RUS (any national) keyboard layout. Shift 4 and scancode 54 mean switching by CTRL-RightSHIFT key combination.[Note 3][Note 4]

/LAT=42,4 – set a "hot" key for switching to latin keyboard layout. Shift 4 and scancode 42 mean switching by CTRL-LeftSHIFT key combination.[Note 3][Note 4] /LAT=OFF means using one "hot" key for toggling to national keyboard layout and back.

/MODESHIFT=87,1 – set a "hot" key for temporary switching keyboard layouts while this "hot" key is kept pressed. Shift 1 and scancode 87 correspond to RightSHIFT-F11 key combination.[Note 3][Note 4] /MODESHIFT=OFF disables temporary switching.

/CLRSCAN=ON – reset all "hot keys" to original defaults. Reconfiguration of "hot" keys requires KEYRUS's interface module to be loaded. The hooked "hot" keys must be chosen so as to be not intercepted later by resident shells or by other TSRs.

Character generator's module accepts the following options:

/BLANK=ON,9,ON,ON – blank screen after 9 minutes idle ; the second "ON" to feel mouse's movement, the rightmost "ON" to sense screen output.
/SWITCH=22,6 – set a "hot" key to switch character generator to DOS's default codepage 437 ; scancode 22 corresponds to letter "U", shift 6 means keeping pressed both CTRL and LeftSHIFT keys.[Note 3][Note 4] Switching of codepages doesn't affect keyboard's layout. /SWITCH=OFF means no access to codepage 437.
/EGA	–	assume the PC is equipped with EGA-compatible video card. Instead of /EGA you may specify /VGA to assume a VGA-compatible video card. Both /EGA and /VGA options are not saved by /SAVE operation.
/8x8=ON	–	load 8x8 font for 80x43, 80x50 and similar textual videomodes. This option may be set to OFF and AUTO, the latter means loading on software request.
/8x14=ON	–	load 8x14 font (used by MS WORD for DOS). This option also may be set to OFF and AUTO, just as the /8x8 option.
/8x16=ON	–	load 8x16 font for 80x25 main DOS's videomode 03. This option also may be set to OFF and AUTO, just as the /8x8 option.
/FULL	–	load all 3 sorts of internal fonts.
/ROM	–	don't load internal fonts, use DOS's default fonts.
/FONT=filename.ext – load an external font given in a separate file ; when used together with /SAVE option, the font is not loaded into memory, but becomes accepted as the default internal font of KEYRUS driver.
/DELETEFONT – delete the font which was installed the last.
/COMPRESS=OFF – don't compress fonts (ON is allowed for textual videomodes only). Choose OFF for graphic videomodes and for "DOS window" of Windows operating system.
/ALL	–	load all symbols 0–255. Implies no font compression (/COMPRESS=OFF)
/128	–	load symbols 128–255. Implies no font compression (/COMPRESS=OFF)
/RANGE=128-175,224-239 – load symbols within 2 specified ranges, shown as an example.
/RUSSIAN	–	load the same ranges as in the example above, but with font compression (/COMPRESS=ON). To switch compression OFF the option /COMPRESS=OFF must be specified explicitly.

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

/ANYWAY	–	allow to load driver's TSR modules into memory once more.
/DELAY_INIT – suspend initialization of driver's TSR modules until the KEYRUS.COM driver is launched from command line.
/INTERFACE=OFF – keep interface module inactive. When inactive, programmable reconfiguration is disabled, the KEYRUS.COM driver can't detect presence of its TSR modules in memory and can't unload them from memory.
/RELEASE	–	unload TSR modules of the KEYRUS.COM driver from memory. This operation needs the interface module to be active (by default /INTERFACE=ON).

Notes

1. 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.
2. Resident interface module of the KEYRUS.COM driver interacts with programs via INT 2F\AX=4352h (8.03-24).
3. ^ ^{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.
4. ^ ^{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.
5. 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.

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 :

INSTALLHIGH=C:\DOS\DRV\Gmouse.com

where :

C:\DOS\DRV\ – 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 :

/1	– mouse connection via serial port COM1
/2	– mouse connection via serial port COM2
/3	– mouse connection via serial port COM3
/4	– mouse connection via serial port COM4
/P	– mouse connection via PS2 Port.
/P2	– 2-button mouse, connected via PS2 port.
/P3	– 3-button mouse, connected via PS2 port.
/U	– unload GMOUSE.COM driver from memory.
/?	– display short help.

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 :

C:\DOS\DRV\Mouse.com /C1 /R1 /S50 /P2 /N50 /Y

where :

C:\DOS\DRV\ – an example of a path to MOUSE.COM driver.
/C1	–	select COM1 port. Instead of /C1 there may be : /C2 – for mouse connected to COM2 port; /Z – for mouse connected to PS2 port; /I1 – for mouse on LPT1 port ; /I2 – for mouse on LPT2 port ; /B – for bus mouse.
/R1	–	specifies interrupt rate 30 Hz (the default). Alternatives are : /R2 – interrupt rate 50 Hz, /R3 – interrupt rate 100 Hz, /R4 – interrupt rate 200 Hz.
/S50	–	specifies sensitivity; the number after /S is allowed within range 0-100, 50 is the default. Instead of /S50 there may be separate /H50 – horizontal and /V50 – vertical sensitivity specifications.
/P2	–	slow acceleration profile number. Alternatives are: P1 – profile without acceleration P3 – moderate acceleration profile ; P4 – fast acceleration profile.
/N50	–	number after /N specifies cursor redraw rate (0–255 is allowed).
/Y	–	use hardware cursor feature.

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 :

C:\DOS\DRV\Mouse.com OFF

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 :

INSTALL=\DOS\DRV\Ctmouse.exe /S14 /3 /R33 /N

where :

\DOS\DRV\ – path example to Ctmouse.exe driver.
/S14	–	search for mouse pointing device through serial ports only. The first digit denotes serial port number (=COM1) ; the second, the interrupt request line number (=IRQ 4). If the /S parameter is not specified, the driver will examine PS2 port first, and then all serial ports.
/3	–	activate mouse's third button. This function can't be applied to mice of Mouse System type and to mice with a wheel instead of middle button.
/R33	–	sensitivity settings: first digit is a grade of horizontal sensitivity; the second digit, of vertical sensitivity. If only one digit is specified, it is applied to both coordinates. The default value for /R is 33.
/N	–	load Ctmouse.exe driver even if a mouse driver has been loaded already. This parameter enables to compose batch files so that after unloading of Ctmouse.exe driver the configuration returns back to its original state, whichever this state was.

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

/?	– display a short help ;
/P	– examine the PS2 port only ;
/Y	– don’t search for "mouse" of Mouse System type ;
/V	– reverse search order: examine serial ports first ;
/O	– disable mouse wheel detection ;
/L	– adapt buttons order for left-handed people ;
/B	– don’t load Ctmouse.exe, if some mouse driver is loaded yet ;
/W	– load Ctmouse.exe into conventional memory ;
/U	– unload CTMOUSE.EXE driver from memory (this cannot be done if functions of the driver are intercepted).

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 :

DEVICE=C:\DOS\DRV\Himem.sys /V

where :

C:\DOS\DRV\ – path example to HIMEM.SYS driver ;
/V	–	display loading information. The same may be achieved if the ALT key is kept pressed while HIMEM.SYS is being loaded.

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 :

/a20control:OFF – allows HIMEM.SYS to take control over A20 bus only when inactive, thus preventing A20 bus interruptions (default is to always take control).
/cpuclock:ON – activate CPU clock frequency control when this frequency becomes affected by upper memory access. This parameter makes HIMEM.SYS work slower.
/eisa	–	provides access beyond 16 Mb on PCs with EISA bus.
/hmamin=40 – prevents reserving of HMA area (1024–1088 kb) to any program demanding less than 40 kb (range is 0–63 kb). By default HMA area is allocated to the first program that requests it, regardless of how much of HMA space the program intends to use.
/int15=128 – reserve 128 kb (range 64–65535, default is 0) for programs, accessing memory via interrupt INT 15\AH=87h (8.01-76).
/machine:AT – specification of PC types which HIMEM.SYS can't identify properly, by number (from 1 to 17) or by literal identifier (see table A.11-2). Default is number 1 or identifier AT (both correspond to IBM's PC/AT).
/noabove16 – don't use INT 15\AX=E801h (Compaq Bigmem support) to scan for memory beyond 16 Mb. In this case HIMEM.SYS cannot provide XMS access beyond 16 Mb.
/noeisa	–	prohibit search for memory extension cards on EISA bus.
/numhandles=32 – maximum number of active references (handles) to XMS memory blocks which can be kept open simultaneously ; allowed range is from 1 to 128, 32 is the default.
/shadowRAM:ON – don't prevent BIOS to RAM transfer into segment address space F000–FFFFh. When HIMEM.SYS detects RAM size 2 Mb or less, it tries to prevent BIOS to RAM transfer in order to get more memory free.
/testmem:OFF – bypass XMS memory test.
/X	–	don't explore memory with INT 15\AX=E820h (8.01-80).

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 –

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.

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

DEVICE=C:\DOS\DRV\Emm386.exe RAM V

where :

C:\DOS\DRV\ – path example to EMM386.EXE driver ;
RAM	–	allow arrangement of EMS pages and UMB blocks (another form of RAM parameter usage is shown further) ;
V	–	display allocation of EMS pages and UMB blocks.

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

OFF	–	suspend activation of EMM386.EXE until command "EMM386.EXE ON" is launched from command line. Parameter AUTO (instead of OFF) also allows activation on software request. While EMM386.EXE is not active, it doesn't support loading beyond conventional memory by LH command and by all other commands ending with "…HIGH".
8196	–	an example of requested EMS-memory size in kb, from 16 kb up to actual size of free XMS-memory (latter is the default), but not more than 32768 kb. If NOEMS switch is specified (see further), the default value is set to zero. EMM386 rounds any requested value down to the nearest multiple of 16 kb.
min=256	–	don't establish EMS-memory, if its available amount doesn't exceed this minimum value, ranging from 0 up to requested memory size, 256 kb is the default (unless the NOEMS switch is specified).
W=ON	–	enable Weitek coprocessor support (default is OFF). When EMM386 is active, it accepts from command line commands EMM386 W=OFF EMM386 W=ON
M4	–	an example of start segment address specification for page frame placement. Page frame is a region for successive continuous placement of EMS pages 0–3 (16 kb each). The number after "M" is a code (from 1 to 14) which denotes segment addresses 1 =C000h, 2 =C400h, 3 =C800h, 4 =CC00h, 5 =D000h, 6 =D400h, 7 =D800h, 8 =DC00h, 9 =E000h (the default setting), 10 =8000h, 11 =8400h, 12 =8800h, 13 =8C00h, 14 =9000h
FRAME=CC00 – an example of direct specification for the same page frame start address. Other start addresses, except those shown above, are not allowed. In order to prohibit frame page you may specify FRAME=NONE, and this will be equivalent to the NOEMS parameter (see further).
/PCC00	–	one more example of another form for the same page frame start address specification; the same 14 values can be specified after the /P parameter.
P4=DC00	–	an example of specification for adding one more EMS page P4 (the fifth) to the page frame CCOOh–DBFFh. There may be several "P" parameters for EMS pages denoted by numbers from 4 to 14. When page frame start address is not specified otherwise, numbers 0–3 are allowed too, but sequential continuous allocation of EMS pages 0–3 must be preserved.
X=F000-FFFF – a specification example for a prohibited region of segment addresses (within A000h–FFFFh range) which must be left intact. Specified segment addresses will be rounded down to the nearest 4-kilobyte multiple.
I=BC00-BFFF – a specification example for a region of segment addresses to be allocated for UMB blocks. Specified segment addresses will be rounded down to the nearest 4-kilobyte multiple. When "I" and "X" specifications overlap, the "X" option takes preference.
B=4000	–	lowest boundary segment address (within range 1000h–4000h) of allowed EMS pages placement region. Default lowest boundary is 4000h.
L=256	–	size of memory space (in kb) reserved for XMS-type access (default is 0 kb).
A=7	–	number of register banks to provide support for multitasking (0–254 allowed, default is 7). Each register bank takes about 200 bytes.
h=64	–	number of references (handles) to EMS memory areas which can be kept open for access simultaneously (2–255 allowed, default is 64).
d=32	–	size of reserved Direct Memory Access (DMA) buffer (16–256 kb allowed, default is 32 kb).
RAM=C000-EFFF – a specification example of region boundaries for UMBs and EMS pages placement. When "RAM" parameter is not followed by boundary segment addresses, all available memory space is regarded as allowable.
WIN=E000-EFFF – an example of segment addresses, specifying boundaries of address space region, reserved for being used by Windows OS.
ROM=F000-FFFF – load BIOS shadow into a part of address space, specified by segment addresses of its boundaries, if this is not done by PC’s BIOS itself. Copying of BIOS code can make your PC more fast.
NOEMS	–	don't create EMS page frame, don't provide LIM EMS memory access, but use all available address space in 640–1024 kb region for arranging UMBs and for loading drivers.
NOHI	–	load the whole resident module of EMM386.EXE driver into conventional memory below 640 kb.
NOMOVEXBDA – cancel default loading of BIOS shadow.
NOTR	–	exclude network card search (for EMM386.EXE versions 4.45 – 4.95)
NOVCPI	–	disable support for VCPI functions,[Note 2] requested by other programs. This switch should be used together with the NOEMS switch.
HIGHSCAN – launch a thorough search for free stretches of address space, thus making its usage more efficient. But there is a chance to consider engaged space as free, and then your PC may get hanged.
ALTBOOT	–	replace hot reboot handler (only if CTRL-ALT-DEL "hot key" combination stops responding or goes wrong after loading of EMM386.EXE driver).
NOBACKFILL – prevent conventional memory from being backfilled, when EMM386 attempts to create UMBs in a PC having total memory 640 kb or less.

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.

Notes

1. The EMM386.EXE driver accepts requests from other programs via INT 67 (8.03-57 – 8.03-74).
2. ^ 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.
3. A version of EMM386.EXE from MS-DOS 8 is not compatible with some models of obsolete 486 processor and may cause hanging.
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.

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 …HIGH ending. The line loading UMBPCI.SYS driver may look, for example, as

DEVICE=\DOS\DRV\Umbpci.sys /I=D000–DFFF

where :

\DOS\DRV\ – path example to UMBPCI.SYS driver.

/I=D000–DFFF – an optional specification of segment address space which should be allocated for UMB blocks. Boundaries of the allocated space must be multiples of 16 kb (that is C800, CC00, D000, D400, D800 and so on).

If the /I= parameter is specified, then UMBPCI.SYS will not examine address space areas on whether they are free or not. Presence of several /I= 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 /L: 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 /I= 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.

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

http://www.uwe-sieber.de/files/hiram.zip .

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:

DEVICE=C:\DOS\DRV\Ramdrive.sys 16000 512 256 /E

where :

C:\DOS\DRV\ – a path example to RAMDRIVE.SYS driver.
16000	–	an example of requested RAM-disk size in kilobytes, 4–32767 kb range is allowed, 64 kb is the default value.
512	–	an example of sector size in bytes; 128, 256 and 512 bytes are allowed, 512 is the default value. If sector size is specified, RAM-disk size must be specified too.
256	–	an example specification of entries number in the root directory of RAM-disk, 2–1024 are allowed, 64 is the default value. If number of entries is specified, sector size must be specified too.
/E	–	optional parameter, forcing to arrange RAM-disk in XMS memory, provided by HIMEM.SYS driver. Instead of /E you may specify /A parameter, forcing to use EMS memory access, provided by EMM386.EXE driver.

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 DOS=NOAUTO 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

DEVICEHIGH=C:\DOS\DRV\Bitdisk.exe 0

or else as:

DEVICE=C:\DOS\DRV\Tdsk.exe 0

where :

C:\DOS\DRV\ – path example to the driver ;
0	–	zero size denotes that RAM-disk shouldn't be arranged at once.

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 :

C:\DOS\DRV\Bitdisk.exe R: 5600 512 384 4 /F:2

or else

C:\DOS\DRV\Tdsk.exe R: 5600 512 384 4 /F:2 /E /M /I=1

where :

R:	–	letter-name of the addressed RAM-disk, if there are several RAMdisks. Letter-name of a single RAM-disk may be omitted.
5600	–	an example of required disk's size specification (in kb). Minimum size is 4 kb, maximum – 32766 kb for BITDISK.EXE and 65534 kb for TDSK.EXE. Command with size 0 releases all occupied memory, except that for driver's TSR module: it remains loaded and ready to rearrange RAM-disk on request.
512	–	optional specification example for sector size (in bytes); sector sizes 64, 128, 256 and 512 bytes are allowed, the latter is the default.
384	–	optional number of entries in the root directory. Allowed values are from 1 to disk size limit, 384 is the default. When number of entries isn't omitted, sector size must be specified too.
4	–	optional number of sectors per cluster, in MS-DOS 7 must be a power of 2. Default is the minimum number corresponding to RAM-disk's size. When number of sectors per cluster isn't omitted, then number of entries in the root directory must be specified too.
/F:2	–	specifies creation of TWO copies of FAT, as in real disks (default is creation of a single FAT table). In rare cases some disk addressing utilities can't work properly with virtual disks, having only one FAT.

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 :

/E	–	arrange RAM-disk in XMS memory (the default), provided by HIMEM.SYS driver, which has to be loaded yet.
/C	–	arrange RAM-disk in conventional memory.
/X (or equivalently /A) – arrange RAM-disk in EMS memory, provided by EMM386.EXE driver. In this case both EMM386.EXE and HIMEM.SYS memory drivers must be loaded in advance.
/B	–	don't load TDSK.EXE driver, if at least one real disk drive is found (this option isn't accepted by original version 2.3 of TDSK.EXE driver).
/M	–	display screen messages in monochrome (default is color).
/I=1	–	display messages in english (the default); besides this, spanish (/I=34) and german (/I=49) languages may be chosen.

Auxiliary options /E, /C, /X, /A 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 :

• if it is called without parameters to show current status ;
• if it is called with a single /? parameter to show help.

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 :

SET RAMDRIVE=?:

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 :

0	– RAM-disk is not arranged since it isn't defined ;
252	– syntax error ;
253	– attempt to define a RAM-disk under Windows OS ;
254	– incorrect specification of disk’s letter-name ;
255	– TSR module of TDSK.EXE driver is not loaded.

5.06 HDD services

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 :

C:\DOS\DRV\Smartdrv.exe /X A- B- C+ /U /N /L /V 128 /E:2048 /B:4096

where :

C:\DOS\DRV\ – path example to SMARTDRV.EXE driver.
/X	–	disable write-behind caching for disks, except those enlisted after the /X parameter with plus sign (as C+). On disks followed by minus sign (as A–, B–), read-ahead buffering is disabled too. If the /X parameter is omitted, then write-behind caching is enabled only for HDDs.
/U	–	don't load CD-ROM caching module.
/N	–	allow to accept the next command when write cache is not written yet onto disk. This parameter affects those drives only, where write-behind caching is enabled. If the /N parameter is omitted, command prompt does not appear until cache writing to disk operation terminates.
/L	–	forces to arrange cache buffer in conventional memory. This is needed, when DMA controller has no access to UMB address space.
/V	–	display status message (by default nothing is displayed, when SMARTDRV.EXE is launched for the first time). Instead of /V there may be /S – display status message and cache statistics.
128	–	cache size in kilobytes. It must be specified, if a large part of XMSmemory is to be used for other purposes, for example, as a RAM-disk.
/E:2048	–	size in bytes of transferred data blocks; 1024, 2048, 4096 and 8192 are allowed, 8192 is the default.
/B:4096	–	size in bytes of read-ahead buffer, it must be a multiple of transferred data block, 16384 is the default.

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 :

C:\DOS\DRV\Smartdrv.exe /X C– D+ /R /F /Q

where :

/X	–	disable write-behind caching for all disks (if not followed by particular disk's letter-names). This parameter may be applied, if write-behind caching was not disabled in current state of SMARTDRV.EXE. Here C– and D+ letter-names mean disable write-behind caching for disk C: and enable it for disk D:.
/R	–	clear the cache and restart SMARTDRV.EXE. One more operation to be performed immediately (instead of /R) is /C – write information currently present in write-behind cache to disk.
/F	–	discard the /N parameter, if it is active in current state, and return to default state, when command prompt doesn't appear until cache writing operation terminates. If the state should be reversed in opposite direction, then /N parameter should be specified instead of /F.
/Q	–	cancel default status message display. Instead of /Q there may be /S – display status message plus cache statistics.

Notes

1. /C operation (writing cache) ignores /V and /S 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 :

DEVICE=C:\DOS\DRV\Dblbuff.sys /D+

where :

C:\DOS\DRV – path example to DBLBUFF.SYS driver.
/D+	–	an optional parameter, instructing to arrange permanent double-buffering for all disks. Otherwise only I/O to UMB blocks (5.04-02) will be double-buffered, and it wouldn't be done automatically if it appears unnecessary.

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 "DRVSPACE=0" in MSDOS.SYS file (5.01-01) or by a "DOS=NOAUTO" 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 :

DEVICE=C:\Drvspace.sys /MOVE /NOHMA /LOW

where :

C:\	–	path example to DRVSPACE.SYS loader.
/MOVE	–	initiates relocation of DRVSPACE.BIN from upper part of conventional memory into UMB or HMA areas, because original placement may be incompatible with other software. Relocation takes place after execution of all DEVICE and DEVICEHIGH commands in CONFIG.SYS file. If address space beyond 640 kb is inaccessible, the /MOVE option induces relocation to lower part of conventional memory.
/NOHMA	–	don't relocate TSR compression module into HMA (1024–1088 kb).
/LOW	–	forces relocation of TSR compression module into lower part of conventional memory even when address space beyond 640 kb is accessible.

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 Interface controller's drivers

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 :

DEVICE=DOS\DRV\Atapimgr.sys /P:170,15 /W:2 /NDR /NRS /C:2 /T:5 /LUN

where :

DOS\DRV\	–	path example to ATAPIMGR.SYS driver.
/P:170,15	–	hexadecimal address of I/O port and decimal interrupt request line number (IRQ). Allowable port addresses are 1F0, 170, 1E8, 168 (A.14-1). Allowable IRQ numbers are 10, 11, 12, 14, 15. If /P is omitted, the driver will search for disk drives throughout all mentioned port addresses and IRQ lines.
/W:2	–	number of waiting cycles (0–99 allowed) for data I/O operations in old PCs, not supporting readiness confirmation (IOCHRDY) check. Recommended number of waiting cycles depends on CPU clock frequency: for 50 MHz – /W:2, for 75 MHz – /W:6, for 100 MHz – /W:9, for 166 MHz – /W:19, for 240 MHz – /W:30. For PCs with higher CPU clock frequency the /W parameter is not needed.
/NDR	–	don't issue the reset command to CD/DVD-ROM drives. This option is essential for booting from a CD/DVD disc, since otherwise the reset command will disrupt booting process.
/NRS	–	don't return request sense confirmation, when drive sends a request for conditions check.
/C:2	–	recalculate PIO mode for a particular drive : 0 – for master drive at primary IDE controller, 1 – for slave drive at primary IDE controller, 2 – for master drive at secondary IDE controller, 3 – for slave drive at secondary IDE controller.
/T:5	–	set timeout (in seconds) for waiting drive's response ; the default is 30.
/LUN	–	selectively support addressing to a device with LUN (= Local Unit Number) zero. The LUN numbers enable to regard multifunctional disc drives as different devices, for example, a drive with inserted DVD-RAM disc – as equivalent of hard disk drive, and the same drive with inserted CD-ROM disc – as an ordinary CD-ROM drive. Addressing with LUN numbers is not supported by default.

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 :

ATAPIMGR.SYS ; MKE ATAPI Manager

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

Nvicdf.exe /E

or

Nvihd.exe /E /I

where parameters mean :

/E – initialize PCMCIA card ;

/I – spin drive's motor.

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 :

DEVICEHIGH = \DOS\DRV\Uhci.exe
DEVICEHIGH = \DOS\DRV\Ohci.exe

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 :

/e	–	activate USB controllers of EHCI class only.
/o	–	activate USB controllers of OHCI class only.
/u	–	activate USB controllers of UHCI class only.
/nocbc	–	don't search for USB adapters in PCMCIA slots.
/w	–	prompt the user that they have to connect and to switch on the external device(s), which should be registered on USB bus.
/slow	–	decrease speed of polling the connected devices, so that even the most lazy devices have enough time to respond.
/v	–	display data about registered USB controllers and about all devices, detected on USB bus(es).
/r	–	don't decline loading of the driver because of errors and in case of BIOS's control over USB controller(s).
/norst	–	don't send the RESET command to USB devices in order to prevent disruption of OS loading process from one of those devices.

The /e, /o, /u 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 (/r and /norst) 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 /r parameter in command line. The whole set of allowed command line options includes the following :

/id=2:0+1	–	an example of specification for devices which should be taken under driver's control: the device number 2, connected to USB bus of the first USB controller, and devices number 0 and 1, connected to USB bus of the second USB controller.
/nospinup	–	don't issue command to switch on drive's motor at the moment of driver's initialization.
/d	–	display status message about devices which are taken under driver's control.
/pause	–	suspend further execution until any keystroke in order to give an opportunity to read the status message.
/r4	–	an example of request to reserve 4 disk's letter-names for non-first partitions on removable media in drives, taken under driver's control. From 1 to 24 letter-names can be reserved.

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 /D: parameter, followed by an arbitrary identifier (for example, /d:USBCD001) 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

DEVICEHIGH=\DOS\DRV\Usbaspi.sys /slow /v
DEVICEHIGH=\DOS\DRV\Aspidisk.sys /nospin /d /pause
DEVICEHIGH=\DOS\DRV\Njusbcda.sys /d:USBCD001

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 /SLOW and /PAUSE 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 :

/w	–	prompt the user that he has to connect and to switch on the external device(s) which should be registered by USB controller.
/v	–	display data about detected devices on USB bus of the first USB controller.
/r	–	don't unload driver's resident module when the first USB controller is under control of PC's BIOS.
/m=D0	–	an example of contact memory zone specification for USB controller of OHCI class. D0 denotes segment addresses zone D000–DFFFh.
/p=A400	–	an alternative example of port address specification for USB controller of UHCI class.

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 /dS – 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

DEVICE=\DOS\DRV\Duse.exe NOC EMU XFER=8

where the shown options mean :

NOC	–	decline loading of CD/DVD-ROM support module.
EMU	–	emulate IRQ calls in order to prevent driver's mutual incompatibility.
XFER=8	–	reduce buffer size to 8 kb (1 to 64 kb are allowed, default is 64 kb).

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 Services for installable file systems

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 DOS=NOAUTO 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 :

C:\DOS\DRV\Ntfsdos.exe /L:K /C:1024 /N /X /U /V

where :

C:\DOS\DRV\ – path example to NTFSDOS.EXE driver.
/L:K	–	an option, assigning the "K" letter-name to the first found NTFS disk. The next NTFS disks, if there are any, will be given next letter-names after "K". If /L: parameter is omitted, NTFS disk(s) name assignment will start from the first free letter-name.
/C:1024	–	an option, forcing to create a 1024 kb cache buffer in XMS memory. Default cache buffer size is 500 kb.
/N	–	this option prevents loading of decompression module. It is not needed, when NTFS volume contains no compressed fragments. The /N option decreases conventional memory requirements.
/X	–	this option forbids usage of extended INT 13 functions (8.01-55). The /X parameter should be specified for old PCs, produced before 1996 and having a HDD not larger than 8.4 Gb.
/U	–	this option enables translation of names written in unicode (two bytes per character).
/V	–	this option forces to display driver's memory usage. By default assigned disk's letter-names only are displayed.

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 :

C:\DOS\DRV\Mscdex.exe /D:MSCD001 /e /k /s /v /L:N /M:12

where :

C:\DOS\DRV\ – path example to MSCDEX.EXE file.
/D:MSCD001	–	is an example of arbitrary identifier ("MSCD001") of up to 8 characters long for association with a particular CD/DVD-ROM driver, which must be loaded yet and must be given the same identifier in its command line. If there are several CD/DVD-ROM drivers, these must be given different identifiers, and each must be specified after a separate /D: parameter in command line loading MSCDEX.EXE.
/e	–	this option gives preference to arrangement of buffers beyond conventional memory, provided that access beyond conventional memory is opened yet by EMM386.EXE memory manager (5.04-02).
/k	–	this option gives preference to secondary volume descriptor with Japanese characters (Kanji), if it can be found. By default primary descriptor is used, secondary descriptor even is not searched for.
/s	–	this option forces to make preparations for subsequent loading of network server software; this helps to avoid letter-name allocation conflicts and enables sharing of CD-ROM logical disks.
/v	–	display information about status of CD-ROM drives.
/L:N	–	optional assignment of letter-name "N:" to the drive, which corresponds to the first /D:MSCD001 identifier; drive(s) related to the following identifier(s), if there are any, will be given the next letternames. By default CD/DVD drive(s) are given the nearest spare letternames, but MSCDEX.EXE can't exceed the limit, set by LASTDRIVE command (4.17) in CONFIG.SYS file.
/M:12	–	is an example of reserving 24 kb of memory for arranging 12 buffers (2048 bytes each) in order to increase reading speed; figures between 4 and 64 are recommended, 12 is the default.

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 :

INSTALLHIGH=\DOS\DRV\Shsucdx.com /D:?CD001,N,0,2 /~+ /R /Q

where

\DOS\DRV\	–	path example to SHSUCDX.COM file
/D:?CD001	–	specification of an arbitrary identifier ("CD001") of up to 8 characters long for association with a particular CD/DVD-ROM driver, which must be loaded yet and must be given the same identifier in its command line. If there are several CD/DVD-ROM drivers, these must be given different identifiers, and each must be specified after a separate /D: parameter in command line loading SHSUCDX.COM. The question mark preceding the identifier marks those drives, which may be absent in some configurations, since PC's hardware may be not known beforehand.
,N,0,2	–	a group of options for that CD/DVD-ROM driver, which is given the same identifier after the /D: parameter. The first letter ("N") is an example of letter-name to be appointed to the corresponding logical disc. The second digit ("0") is an example of disc drive number in a list of disc drives, controlled by this driver. The third digit ("2") is number example of disc drives, accepted by SHSUCDX.COM program from this driver. By default all disc drives will be accepted, and next disc drives will get letter-names, following the specified letter-name or the first spare letter-name.
/~+	–	this option forces to insert the tilde sign ( ~ ) as the last character in long names, truncated to standard length (8 characters). Action of this option may be cancelled later by launching the SHSUCDX.COM program from command line with inverse parameter /~–.
/R	–	this option prescribes to take off the "Read only" attribute from files, copied from non-writable optical discs.
/Q	–	this option forbids display of status message, the letter-name appointment(s) only will be displayed. If you want just nothing to be displayed, you should specify the /QQ parameter instead.

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

/L:N	–	an alternative form of prescription to appoint the specified letter-name ("N") to the first optical disc drive, taken under control of SHSUCDX.COM program. The next disc drives, if there are any, will be given next letter-names. The /L: parameter is equivalent to synonymous parameter of MSCDEX.EXE program (5.08-03). The SHSUCDX.COM program accepts the /L: parameter if only additional group of options to the /D: parameter is not specified.
/C	–	load resident module of SHSUCDX.COM program into conventional memory. By default resident module is loaded in UMB address space, if it is accessible.
/V	–	show some more details in displayed status message. Having been loaded in advance, SHSUCDX.COM program can be launched with this parameter once more from command line. Obviously, the /V parameter is incompatible with /Q and /QQ parameters.
/U	–	unload resident module of SHSUCDX.COM program from memory. This parameter is accepted from command line only, provided that resident module is loaded yet. Unloading releases occupied memory and disables all logical disks, controlled by that resident module.

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 :

DEVICEHIGH=\DOS\DRV\Oakcdrom.sys /D:MSCD001 /V

where :

\DOS\DRV\	–	path example to OAKCDROM.SYS driver.
/D:MSCD001	–	announcement of an arbitrary identifier up to 8 characters long. This identifier enables recognition of the driver by MSCDEX.EXE program (5.08-03) or by SHSUCDX.COM program (5.08-04). One of these should be loaded afterwards, and it must be given the same /D: parameter followed by exactly the same identifier in its command line.
/V	–	this option causes status message display.

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 :

DEVICEHIGH=\DOS\DRV\Vide-cdd.sys /D:MSCD001 /P:170,15

where :

\DOS\DRV\	–	path example to VIDE-CDD.SYS driver.
/D:MSCD001	–	announcement of an arbitrary identifier up to 8 characters long. This identifier enables recognition of the driver by MSCDEX.EXE program (5.08-03) or by SHSUCDX.COM program (5.08-04). One of these should be loaded afterwards, and it must be given the same /D: parameter followed by exactly the same identifier in its command line.
/P:170,15	–	an optional specification for port base address and for interrupt request line number (IRQ).

There may be more than one /P parameter specified in one line. When at least one /P parameter is given, all other port addresses and IRQ line numbers will not be examined. When /P parameter is omitted, a search for CD/DVD-ROM drives will be initialized throughout all typical IDE port addresses and IRQ line numbers : /P:1F0,14, /P:170,15, /P:1E8,12, /P:168,10 (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 :

DEVICEHIGH=\DOS\DRV\Qcdrom.sys /D:MSCD001 /L

where :

\DOS\DRV\	–	path example to QCDROM.SYS driver.
/D:MSCD001	–	announcement of an arbitrary identifier up to 8 characters long. This identifier enables recognition of the driver by MSCDEX.EXE program (5.08-03) or by SHSUCDX.COM program (5.08-04). One of these should be loaded afterwards, and it must be given the same /D: parameter followed by exactly the same identifier in its command line. If the /D: parameter is omitted, QCDROM.SYS will appoint default identifier QCDROM1.
/L	–	this option prescribes to refrain from direct memory access (DMA) beyond conventional memory (640 kb). This may be necessary, when PC's memory controller doesn't support DMA access to UMB memory region, while UMBs are opened for ordinary access, for example, by UMBPCI.SYS driver (5.04-04). If the /L option is specified, then data transfer is performed via a buffer in XMS-memory; therefore in this case the HIMEM.SYS driver (5.04-01) must be loaded in advance.

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

/A	–	forces to use old alternate IDE controller addresses 01E8h–01EFh on primary channel, and 0168h-016Fh on secondary channel. This may be required for "odd" SATA BIOS or other unusual cases.
/I	–	forces QCDROM.SYS to arrange its own XMS buffer. This enables to avoid possible conflicts with "odd" DMA and BIOS services.
/UF	–	prescription to enable accelerated direct memory access (UltraDMA). Feasibility of UltraDMA is confirmed for many motherboard's chipsets, but not for all. A check whether the /UF parameter is permissible can be recommended for each particular case.
/UX	–	refrain from UltraDMA usage, even if both disc drive and motherboard claim support for UltraDMA. The /UX option is used for diagnostics and testing purposes. When /UX option is specified, the QCDROM.SYS driver doesn't need XMS memory.
/PM	–	(= Primary Master): don't search for disc drives, but check presence of master disc drive only on the bus of primary IDE controller.
/PS	–	(= Primary Slave): don't search for disc drives, but check presence of slave disc drive only on the bus of primary IDE controller.
/SM	–	(= Secondary Master): don't search for disc drives, but check presence of master disc drive only on the bus of secondary IDE controller.
/SS	–	(= Secondary Slave): don't search for disc drives, but check presence of slave disc drive only on the bus of secondary IDE controller.

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 :

DEVICEHIGH=\DOS\DRV\Dvs.sys /D:MSCD001

where :

\DOS\DRV\	–	path example to DVS.SYS driver.
/D:MSCD001	–	announcement of an arbitrary identifier up to 8 characters long. This identifier enables recognition of the driver by MSCDEX.EXE program (5.08-03) or by SHSUCDX.COM program (5.08-04). One of these should be loaded afterwards, and it must be given the same /D: parameter followed by exactly the same identifier in its command line.

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).