Real-Mode Drivers and the IOS.INI Safe Driver List

Microsoft strongly recommends that you use 32-bit, protected-mode drivers wherever possible. With protected-mode drivers, configuration information is stored in the Registry rather than in CONFIG.SYS or other files.

The following shows the general guidelines for device entries in CONFIG.SYS, and whether such entries are required or can be removed under Windows 95:

When you use only protected-mode drivers, the only configuration information the operating system needs to know for system startup is the location of the Windows 95 system files and the directory for the swap file. You do not need to load drivers in CONFIG.SYS or AUTOEXEC.BAT.
Any boot device in your computer that needs real-mode support does not require an entry in CONFIG.SYS. In the unusual case that the CD-ROM is part of system startup, entries for this device must be included in CONFIG.SYS.
If your computer requires any real-mode drivers, an entry for loading the driver must be included in CONFIG.SYS and AUTOEXEC.BAT, as was true under earlier versions of MS-DOS.

Windows 95 automatically unloads any real-mode drivers for which it has protected-mode drivers to provide the same functionality. For example, the real-mode DBLSPACE.BIN driver is unloaded and the protected-mode DBLSPACE.VXD driver takes over. However, the protected-mode device driver should take over only when it guarantees similar functionality to the real-mode driver, not merely because it can drive the hardware.

Tip

To determine whether a particular driver is running in real mode versus protected mode, click the Performance tab in the System option in Control Panel.

Real-mode drivers that can safely be replaced are identified in the safe driver list, which identifies drivers and TSRs that Windows 95 can replace with corresponding protected-mode drivers. The safe driver list (IOS.INI in the Windows directory) can include the following information:

Name of the driver or TSR, using the same name as used in CONFIG.SYS or AUTOEXEC.BAT
Driver requirements
Whether the driver hooks INT 13
Whether the driver monitors INT 13 (regardless of whether I/O is controlled by a protected-mode driver)
Whether the driver accesses hardware directly

Windows 95 does not store the version number of the driver or TSR in the list, so the vendor must change the name of the driver if a future version is enhanced so that the driver is safe or unsafe.

By default, the following drivers are considered safe:

MS-DOS 5.0-compatible real-mode block device drivers
INT 13 driver (provides INT 13 functionality and directly accesses hardware)
INT 13 monitors (hooks INT 13 for monitoring I/O but does not access hardware directly or modify the I/O buffer)
INT 13 hooker (hooks INT 13 for altering I/O but does not access hardware directly)
ASPI Manager (implements the Advanced SCSI Programming Interface for MS-DOS specification)
CAM Manager (implements MS-DOS Common Access Method specification)

A real-mode driver is considered unsafe if it implements functionality that is not provided by protected-mode drivers. For example, a real-mode IDE or ESDI driver that uses dynamic encryption is an unsafe driver because Windows 95 does not support encryption. Windows 95 protected-mode drivers do not implement the following functions, so if a real-mode driver uses any of the following functions it is considered unsafe and should not be added to the safe driver list:

Data compression (other than DriveSpace-compatible compression)
Data encryption
Disk mirroring
Bad sector mapping
Fault tolerance (maintaining ECC correction on a separate disk)
IOCTLS defined or extended by the vendor

If Windows 95 provides an appropriate protected-mode driver, you should use only the real-mode driver in these cases:

If the real-mode driver is used for a boot device.
If an MS-DOS Mode application uses the driver's device, in which case the protected-mode driver must be unloaded in order to load the real-mode driver.

Tip for Using Real-Mode versus Safe Protected-Mode Drivers

If a real-mode driver provides better performance or provides some functions not present in the Windows 95 protected-mode driver, you should remove the real-mode driver from the safe driver list, so that Windows 95 uses real mode to access the driver. Similarly, if a real-mode driver can safely be taken over by a protected-mode driver, add the real-mode driver to the safe driver list.

To determine whether you can use a protected-mode driver, you will have to test the equivalent functionality provided from the protected-mode driver versus your existing real-mode driver.

The following is the syntax of the safe driver list in IOS.INI:

filename, qualifier_string ; comments

The qualifier_string can be one shown in the following list.

Qualifier string	Meaning
do_not_care	Indicates that it is acceptable to load the protected-mode driver and not use the mapper for this real-mode driver because it doesn't matter whether it sees any I/O requests. This is the default.
must_chain	Implies that the device driver or TSR is safe, but it has an INT 13 hook that needs to see INT 13 requests. In this case, the protected-mode drivers are loaded, but the system routes the logical requests through the real-mode mapper and then switches back to protected-mode at the end of the INT 13 chain.
must_not_chain	Implies that the driver is safe as long as it does not see any INT 13 requests. In this case, the protected-mode drivers are loaded and the real-mode mapper is not used.
non_disk	Indicates a driver that controls a device that is not a disk, such as Interlnk. IOS issues INT 25 calls to all logical volumes in the system and determines whether the request is mapped to INT 13, ASPI, or CAM. If the request is not mapped, then this is a monolithic driver, as is the case for Interlnk. Adding non_disk prevents IOS from considering Interlnk in its safe-driver processing.
monolithic	Similar to non_disk. Any driver that is monolithic and safe must have this qualifier set to indicate to IOS that the protected-mode port drivers can be loaded and the driver's entry point can be handled to prevent contention.

IOS.INI also contains an Unsafe CD section in IOS.INI. Adding a driver to this section indicates that this CDFS will not be loaded on the CD drives that this driver controls.

The following is an example of some IOS.INI entries.

386max.sys   ; Qualitas
4dos.com   ; 4DOS shell program
ad-dos.com   ; Afterdark
ad_wrap.com   ; Afterdark
adi2.com   ; Afterdark
aspi3x90.sys   ; DTC SCSI no PM driver
...
[CDUnsafe]
drd600.sys   ; Acme 60X series CDROM
drd60asp.sys   ; Acme 60X series CDROM
drd60ps.sys   ; Acme 60X series CDROM

Tip for Troubleshooting Protected-Mode Drivers

If you believe that a protected-mode driver should be controlling a device, but the device appears with a real-mode driver in the System option in Control Panel, you can check entries in IOS.LOG. The IOS.LOG file in the Windows directory is created when a protected-mode driver is not available or if the operating system detects that an unknown device driver is controlling a device.

In most cases, the first line in IOS.LOG states why the protected-mode driver was not loaded. If the first line mentions MBRINT13.SYS, then the problem most likely is a virus (except if you are using a driver that replaces the master boot record).