Installs and configures the SMARTDrive disk-caching utility.


SMARTDRV [parameters] [/switches]
drive Sets caching options on specific drive(s).
+: Enables write-behind caching for the specified drive.
-: Disables all caching for the specified drive(default if drive is specified).
InitCacheSizeSpecifies XMS memory (KB) for the cache.
WinCacheSizeSpecifies XMS memory (KB) for the cache with Windows.
/X Disables write-behind caching for all drives.
/UDo not load CD-ROM caching module.
/CWrites all information currently in write-cache to hard disk.
/RClears the cache and restarts SMARTDrive.
/FWrites cached data before command prompt returns (default).
/NDoesn't write cached data before command prompt returns.
/LPrevents SMARTDrive from loading itself into upper memory.
/VDisplays SMARTDrive status messages when loading.
/QDoes not display status information.
/SDisplays additional information about SMARTDrive's status.
/E:ElementSizeSpecifies how many bytes of information to move at one time.
/B:BufferSizeSpecifies the size of the read-ahead buffer.


  1. For general use in Win 95/8, disk caching is organised by VCache and Smartdrive is neither required nor offers any benefits. The only circumstance I have been able to determine where Smartdrive has a role is when the CD drive is operating with real-mode drivers that have to be loaded in config.sys/autoexec.bat. These drives are listed in the MS Knowledge Base article Q131499 and include Micro Solutions' Backpack external CD-ROM along with several that connect to sound cards. For these drives, SmartDrive will improve performance and should be installed in autoexec.bat.
  2. Smartdrv cannot be loaded in a Dos box.
  3. A good explanation of how Smartdrv works can be found at Q83325 and is quoted below: The information in this article applies to: Microsoft Windows 3.1                                INTRODUCTION
      Microsoft Windows operating system version 3.1 has a number of
      enhancements over previous versions that improve both its usability
      and its performance. Foremost among these enhancements are Windows
      3.1's improved features for accessing and utilizing the hard drive of
      your PC.
                             SMARTDRIVE 4.0 DISK CACHE
      Microsoft's first release of the Windows graphical environment
      included a disk caching program called SMARTDrive 3.03. SMARTDrive has
      been improved with each subsequent release of Windows and has been
      entirely redesigned in Windows version 3.1. SMARTDrive 4.0 in Windows
      3.1 provides faster and more intelligent disk caching that takes
      better advantage of the revolutionary way that Windows and Windows-
      based applications use extended memory.
      SMARTDrive 4.0 gives Windows 3.1:
          - Improved performance by speeding up hard disk and RAM access.
          - Improved stability in 386 enhanced mode by double buffering data
            when needed.
      The remainder of this section compares the performance of SMARTDrive
      4.0 to SMARTDrive 3.x and illustrates how SMARTDrive 4.0 works at a
      more technical level.
      SMARTDrive is a disk caching program that intercepts system calls to
      the hard disk to control read/write access to the disk. SMARTDrive
      intercepts any calls to the hard disk and loads the needed data into a
      cache it establishes in RAM. (Unless specified otherwise, SMARTDrive
      automatically determines a reasonable cache size based on the amount
      of free extended memory available when it initially loads; the maximum
      amount it will take is around 2 MB.) Subsequent calls to the hard disk
      are intercepted by SMARTDrive, which scans the cache for the requested
      data. If the data is already present in the cache, SMARTDrive can
      access it directly in RAM. If the data is not in the cache, SMARTDrive
      accesses the hard disk and loads the necessary data into the cache.
      The least recently used data residing in RAM is cached back to the
      hard disk to make room for the new data. By loading blocks of data
      from the hard disk into RAM, SMARTDrive helps decrease the number of
      calls to the hard disk. This can dramatically speed up applications
      that repeatedly access the hard disk for data because accessing the
      hard disk is considerably slower than accessing RAM. Essentially,
      SMARTDrive attempts to maintain information in RAM that an application
      needs at any given time from the hard disk.
      To understand why SMARTDrive needed to be redesigned, lets look at
      how SMARTDrive 3.x works and examine some of the shortcomings of its
      design. First, SMARTDrive 3.x is a read-only track cache, which means
      that it caches on a track basis and for read operations only. This
      means that the internal data structures of the SMARTDrive program are
      tied to the logical geometry of the disk (that is, what MS-DOS sees).
      In the diagram below, you can see that SMARTDrive 3.x caches at the
      ROM BIOS INT13 level and uses the BIOS-specified disk geometry to
      decide the size of its caching element (that is, track size). INT13 is
      the most common method for interacting with hard disks (and has
      evolved into the industry standard). SMARTDrive under Windows 3.0 can
      be loaded into either extended memory or expanded memory.
             (Read/Write INT21)
      - - - - - - - - - - - - - - - - -
             Call HD Driver
                HD Driver
                 INT 13
                    --------->  SMARTDrive 3.x
                                 Chains INT13
                ROM BIOS
               Hard Drive
      SMARTDRIVE 4.0
      SMARTDrive 4.0 is designed as a block-oriented disk cache. It hooks
      into the system at the MS-DOS device driver level rather than at the
      ROM BIOS INT13 level (as with SMARTDrive 3.x). Each block device
      driver on the MS-DOS device driver chain is "front-ended" by a
      SMARTDrive 4.0 module that provides the actual caching. This new
      design yields the following benefits:
          - It is independent of the INT13 interface.
          - It is independent of disk geometry.
           (Read/Write INT21)
      - - - - - - - - - - - - - - -
              Call HD Driver
                    --------->  SMARTDrive 4.0
                                 HOOKS Driver
                 HD Driver
                 INT 13
                ROM BIOS
               Hard Drive
      Independent of INT13 Interface
      Many device drivers do not use the INT13 (BIOS) interface (for
      example, Bernoulli drives, some hard cards, and many SCSI and WORM
      drives). This means that SMARTDrive 4.0 can cache these devices,
      whereas SMARTDrive 3.x cannot. SMARTDrive 4.0 can cache any disk
      controller that uses an MS-DOS block device driver.
      Independent of Disk Geometry
      Some disk managers and disk controllers use a disk geometry mapping
      scheme that causes the logical geometry to be different from the
      physical geometry (for example, many PS/2 systems, Ontrack's Disk
      Manager, and several disk controllers). The INT13-based disk caches
      are sensitive to this and often have problems. For example, some disk
      management software actually changes the ROM BIOS-specified disk
      geometry, which confuses INT13-based disk caches (including SMARTDrive
      There usually is an interface to determine the true geometry, but this
      requires detection of the specific disk manager driver and generally
      complicates the disk cache software. Often, logical tracks actually
      cross physical track boundaries, causing the track caches to incur
      performance penalties (intertrack seeks and rotational latencies, for
      example). To get around the ROM BIOS 1024-cylinder limitation, disk
      managers and controllers sometimes fold multiple tracks into one
      logical track. This results not only in problems with the physical
      track boundaries as noted above, buts forces track caches to have a
      very large track buffer as well. In some cases, this buffer can be as
      large as 31.5K and must reside in conventional memory. The design of
      SMARTDrive 4.0 eliminates this geometry mismatch problem.
      Write-Behind Cache
      SMARTDrive 4.0 is a write-behind cache, also known as lazy write. A
      write-behind cache adds significant performance improvements wherever
      files are being written to disk. For example, an application writes
      data to what it thinks is the hard disk. SMARTDrive takes this data
      and places it in the cache, rather than physically writing it to the
      disk. This write-behind data stays in the cache until one of the
      following occurs:
      1. The cache fills up. The oldest block in the cache is freed up, and
         if it is write-behind data, physically written to the disk.
      2. The system goes idle. SMARTDrive writes the oldest write-behind
         data block to the physical disk. As long as the system is idle,
         SMARTDrive continues to write to the disk until all the write-
         behind data is written. This write-behind data also comes from
         Windows-based and MS-DOS-based applications that are idle.
      3. SMARTDrive detects that you have pressed CTRL+ALT+DEL. When you
         restart by pressing CTRL+ALT+DEL, SMARTDrive writes all write-
         behind data to the physical disk. This is a synchronous operation--
         SMARTDrive does not give up control until all data is written.
      4. A block is older than five seconds. If a block is older than five
         seconds, it is written to the physical disk.
      Shrink Algorithm
      Similar to SMARTDrive 3.x, SMARTDrive 4.0 implements a shrink
      algorithm that frees memory for Windows (that is, the cache set up by
      SMARTDrive is removed from memory). The difference is that SMARTDrive
      4.0 watches for the Windows startup broadcast while SMARTDrive 3.x
      provides an IOCTL interface. The net effect is identical, but the
      SMARTDrive 4.0 code is much simpler. Upon exiting Windows, the process
      is reversed and the memory is reacquired by SMARTDrive 4.0.
      Automatic Load High
      When an upper memory block (UMB) provider (such as EMM386.EXE) is
      loaded, SMARTDrive 4.0 (SMARTDRV.EXE) automatically attempts to load
      itself high. Unlike the Windows 3.0 SMARTDrive, SMARTDrive 4.0 can
      only be loaded into extended memory.
      The second major benefit of SMARTDrive 4.0 is the protection it
      provides through double buffering. Double buffering is a response to
      bus mastering, which is supported by certain (usually older) disk
      controllers. Bus mastering refers to a situation in which the hard
      disk controller takes over the bus to directly transfer data to or
      from system RAM, bypassing the CPU entirely. A problem occurs when
      Windows 3.x virtual machines and/or popular memory managers (such as
      EMM386.EXE and QEMM.SYS) are running in virtual 8086 mode. The read or
      write address that is passed to MS-DOS from the bus master controller
      is often not the same as the actual physical memory address. This can
      cause data to be read from the wrong location, or worse, can cause
      data to be written to the wrong RAM address, resulting in erratic
      system behavior and potential file corruption.
      When paging is enabled on an 80386 or faster processor, it is possible
      for the physical address (the actual location of the memory) to be
      different from the virtual address (the address that programs are
      using to access memory). Paging is enabled by all device drivers that
      can provide load high capability and by Windows in 386 enhanced
      mode. For example, say SMARTDrive wants to write to an area of memory
      that has a virtual address in conventional memory, but a physical
      address in extended memory. When the hard drive controller takes over
      the bus and transfers data from the UMB to the disk, the controller
      does not use the CPU, so there is no address translation, resulting in
      the wrong data being written to disk. To avoid this problem, double
      buffering copies the data into a buffer in conventional memory and
      then passes the information to the hard disk controller. So, the
      virtual address always equals the physical address when using devices
      that only recognize conventional memory.
      Installing Double Buffering
      To install the SMARTDrive double-buffering feature, add the following
      line to your CONFIG.SYS file:
         device=c:\windows\smartdrv.exe /double_buffer
      Including this line does not install the cache, only the double-
      buffering driver. The cache must be installed from the AUTOEXEC.BAT
      file or MS-DOS command line.
      Most disk controllers do not need double buffering. These include all
      MFM, RLL, and IDE controllers as well as many ESDI and SCSI devices.
      The Setup program in Windows 3.1 will install the double buffer in the
      following cases:
      1. If the computer has an 80386 or faster processor
      2. If 32-Bit Disk Access was not installed in the SYSTEM.INI file (see
         next section)
      You should install the double buffer in these cases in the interest of
      added safety. Another new feature of SMARTDrive 4.0 that helps you
      determine if double buffering is necessary is the smartdrv command.
      Once your system is running with SMARTDrive loaded, type "smartdrv"
      (without the quotation marks) at the MS-DOS prompt and press ENTER.
      Information similar to the following is displayed:
           Microsoft SMARTDrive Disk Cache version 4.0
           Copyright 1991, 1992 Microsoft Corp.
           Cache size: 1,048,576 bytes
           Cache size while running Windows: 1,048,576 bytes
                         Disk Caching Status
           drive    read cache    write cache    buffering
           A:       yes           no             no
           B:       yes           no             no
           C:       yes           yes            yes
           D:       yes           yes            ---
           For help, type "Smartdrv /?".
      Note the column labeled "buffering." For each drive that is being
      cached, one of three values is displayed--"yes," indicating that
      double buffering is needed; "no," indicating that double buffering is
      not needed; or "---," indicating that SMARTDrive has not yet
      determined the necessity of double buffering. If the buffering column
      displays a "no" for each drive, the double buffer driver is
      unnecessary, and you can safely remove it from your CONFIG.SYS file.
      Setting Up SMARTDrive 4.0
      The Setup program in Microsoft Windows 3.1 automatically installs
      SMARTDrive (SMARTDRV.EXE) in the first line of your AUTOEXEC.BAT file.
      In general, you should let the Setup program configure SMARTDrive's
      cache size for you. However, please note it is critical that
      SMARTDRV.EXE load after any block devices that reside on your system,
      such as:
          - Hard disk partitioning software (for example, DMDRVR.BIN and
          - Hard disk drivers (for example, SCSI drives, hard cards, and
            Bernoulli drives)
          - Data encryption software (for example, Stacker and DoubleDisk)
      The configuration of SMARTDRV.EXE is controlled by command-line
      parameters. Most configuration options can be modified without
      restarting; however, without the Windows Resource Kit utility
      SMARTDrive Monitor (SMARTMON.EXE), the configuration cannot be altered
      while running Windows. Also note that SMARTDrive:
          - Needs a minimum cache size of 16K.
          - Creates a cache size of 16K by default if you supply an invalid
            cache size.
          - Gives you benefits up to a cache size of 2 MB, whereupon the
            benefits typically plateau.
                                32-BIT DISK ACCESS
      Another new feature of Windows 3.1 is its use of 32-Bit Disk Access.
      32-Bit Disk Access is not a program but rather a term used to refer to
      a system of Windows components working together. The main purpose of
      these components is to allow Windows to interact directly with the
      hard disk, bypassing the BIOS, which is normally used for
      communicating with the hard disk. Under 386 enhanced mode Windows,
      where 32-Bit Disk Access is supported, you get the following benefits:
          - Faster hard disk access
          - Ability to run more MS-DOS-based applications
          - Faster overall system response, even when running MS-DOS-based
            applications in the background
          - More powerful off-the-shelf disk utilities to choose from, since
            independent software vendors (ISVs) are writing programs that
            take advantage of this new set of services
          - A SYSTEM OF WINDOWS COMPONENTS. Some of these components are
            called 32-Bit Disk Access devices, but they are useless without
            the rest of the components to support them. Each of these
            components is discussed below.
          - A REPLACEMENT FOR THE HARD DISK BIOS. 32-Bit Disk Access serves
            as a device driver that interacts with the hard disk controller.
            32-Bit Disk Access watches for INT13H calls and handles them if
            they are for the disk it represents; otherwise, it passes the
            calls on to the BIOS in the usual way, as if 32-Bit Disk Access
            were not available.
            HARD DISK). There are some standards for hardware communication
            that work on many different controllers. The most widely adopted
            standard is that introduced by Western Digital in its 1003
            controllers. This is the standard supported by Windows 3.1 and
            more than 90 percent of hard disk controllers, with the
            exception of ESDI and SCSI controllers.
            an open standard that is being promoted to all manufacturers of
            hard disk controllers. This means that every manufacturer has
            the opportunity to write a device driver that supports 32-Bit
            Disk Access functionality for its hardware. Many hardware
            manufacturers are writing 32-Bit Disk Access device drivers that
            will be available at the time Windows 3.1 ships or shortly
          - AN OPTION, NOT A SYSTEM REQUIREMENT. Without the 32-Bit Disk
            Access device driver installed, you lose the hardware-access
            benefits provided by 32-Bit Disk Access, but your system is
            otherwise unaffected. Windows 3.1 without 32-Bit Disk Access has
            the same disk access capabilities of Windows 3.0.
      The 32-Bit Disk Access feature bypasses the system BIOS to more
      directly control hard disk access. It acts, in a sense, as the hard
      disk controller. Before discussing how disk access has changed under
      Windows 3.1, let's look at how MS-DOS handles calls to the hard disk.
      In the MS-DOS-based PC, when an application wants to read from the
      disk, it tracks the following sequence:
               INT21H          INT13H          I/O
              ------>           ----->        ----->
       -----           ------           ----          ----------     -----
      | APP |         |MS-DOS|         |BIOS|        |Controller| ->|Drive|
       -----           ------           ----          ----------     -----
      1. The application makes an INT21H call to MS-DOS.
      2. MS-DOS locates the requested part of the file on the hard disk.
      3. MS-DOS issues an INT13H call to talk to the hard disk BIOS. The
         BIOS contains a program to control each device in the system.
      4. The BIOS driver talks directly to the hard disk controller. Each
         hard disk controller requires its own BIOS driver, but these BIOS
         drivers are usually not specific to the hard disk itself, but
         rather to the controller board (or adapter) that connects the hard
         disk to the rest of the system.
      This system works well, because MS-DOS is able to identify the files
      and directories and keep track of their locations, regardless of the
      type of hard disk MS-DOS is accessing. But, on the other hand, the
      system BIOS is wholly linked to the hard disk, which provides disk
      independence for the applications but does not allow the BIOS to
      differentiate between a call from MS-DOS or a program such as
      But remember that not all disk device drivers reside in ROM. If you
      purchase an off-the-shelf disk drive and install it, your computer's
      ROM BIOS may not know how to communicate with it. If this is the case,
      you must install a device driver that is specific to your new hard
      disk. This additional device driver is usually installed in your
      CONFIG.SYS file when you install the software that comes with your
      hard disk. With some devices, such as a CD-ROM drive, a device driver
      that provides the BIOS interface and INT13H interface to the CD-ROM
      drive appears in your AUTOEXEC.BAT file. This type of device driver
      traps INT13H calls to the hard disk and makes sure the calls are
      understood by the hard disk. Usually, the device driver handles any
      attempts to access the hard disk; the calls never get passed on to the
      real ROM BIOS. If the call is not for the device that the device
      driver represents, then the INT13H call is passed on to the BIOS,
      where it is handled in the usual way. 32-Bit Disk Access represents a

      way for Windows to provide a BIOS that better suits customers' device
      support needs.
      On many machines, the resident hard disk BIOS is slow and inefficient.
      Since 32-Bit Disk Access is specific to devices, it is often more
      efficient, leading to very impressive performance increases. 32-Bit
      Disk Access also allows Windows 3.1 to handle BIOS requests in
      protected mode, rather than in real mode, which may also speed up disk
      access. The following diagram charts the flow of calls under Windows
      in standard mode:
               INT21H          INT13H          I/O
              ------>           ----->        ----->
       -----           ------           ----          ----------     -----
      | APP |         |MS-DOS|         |BIOS|        |Controller| ->|Drive|
       -----           ------           ----          ----------     -----
      Under 386 enhanced mode Windows, the flow of calls is more
              |         Enhanced Mode Virtual Devices           |
      Protected   / \          /    \ 
        Mode     /   \        /      \ 
      Virtual  /       \    /          \ 
       Mode   /         \  /            \ 
         -----   INT21H  ------   INT13H ----    H/W   ----------     -----
        | APP |         |MS-DOS|        |BIOS|   I/O  |Controller|-->|Drive|
         -----           ------          ----  ----->  ----------     -----
      Windows 3.1 and Windows applications run in protected mode. Windows
      has to switch back into real mode (or virtual 8086 mode) to run older
      code (for MS-DOS and the BIOS calls, for example). Switching modes is
      very time consuming. For example, when a non-Windows application
      running under 386 enhanced mode tries to read from a file, the
      following occurs:
         Windows starts out in virtual mode running the application. Windows
         makes an INT21H call to read from the file. 386 enhanced mode traps
         this interrupt and switches to protected mode, where a number of
         virtual device drivers look at the call and try to qualify it. If
         none of the device drivers intercepts the call, the call is
         accepted and is subsequently handed off to MS-DOS.
         Windows then switches back to virtual mode to let MS-DOS handle the
         call. MS-DOS reads a particular location on the disk and then
         generates an INT13H call to talk to the BIOS. Windows in 386
         enhanced mode then traps the call again and switches to protected
         mode to perform certain tasks, hands the call back to the real
         BIOS, and switches back to virtual mode.
         The BIOS handles the call and accesses the hard disk controller to
         set the physical read in motion. Once the BIOS reads the call,
         Windows goes back to protected mode to perform more tasks and then
         returns to virtual mode to let MS-DOS see the returned call.
         Windows returns the INT21H call, switches to protected mode to
         perform yet more tasks, and then finally switches back to virtual
         mode to communicate with the application that issued the call to
         begin with.
      All this mode switching takes time but is necessary due to the nature
      of the 80386 processor, MS-DOS, and the PC BIOS. With a 32-Bit Disk
      Access device installed, Windows can start trapping INT13H calls and
      handling them entirely in protected mode. With 32-Bit Disk Access, the
      call diagram now looks like this:
         ----------------------------     H/W     ----------     -----
        |Enhanced Mode   |32-Bit Disk|    I/O    |Controller| ->|Drive|
        |Virtual Devices |     Access|  ----->    ----------     -----
      Protected    /   \           / 
        Mode      /     \         / 
      -----------/-------\-  ----/---------------------------------------
      Virtual   /         \     / 
       Mode    /           \   / 
            -----   INT21H  ------  INT13H   ----
           | APP |         |MS-DOS|         |BIOS|
            -----           ------           ----
      With 32-Bit Disk Access, Windows no longer has to go through two mode
      transitions--one mode to get to the BIOS and the other mode to get
      back. Only two mode switches per INT13H call, rather than four, are
      now being performed.
      Sometimes Windows shows an adequate amount of free memory and large
      Windows-based applications run just fine, yet an "Out of Memory"
      message is generated when a non-Windows application is started. Also,
      in spite of the available memory, Windows-based applications may slow
      down and constantly access the hard disk after a non-Windows
      application is started.
      These discrepancies occur because of the difference between virtual
      memory (which is often large) and physical memory (RAM, which is
      usually limited). On a given machine, virtual memory might be four
      times the size of RAM. But, while virtual memory works well for
      Windows-based applications, it doesn't always meet all the system's
      memory needs for MS-DOS-based applications.
      Because each non-Windows application runs in its own virtual machine,
      each application takes up 640K or more of virtual memory. When the
      virtual machine is actually running, all of the program code needs to
      occupy RAM. Parts of the non-Windows application cannot be paged out
      while keeping other parts in RAM, as is the case with Windows-based
      applications. The virtual machine in which the non-Windows application
      runs must be treated as a single block. This is true even if the
      application is currently inactive in the background.
      With Windows-based applications, most of the program remains resident
      on the hard disk, while only the parts that are actually being used
      are loaded in RAM. Problems occur when Windows tries to do this with
      non-Windows-based applications.
      If a part of the application that is not currently being used--a data
      buffer, for example--is paged out, it can always be read back in
      whenever the application needs to access it. However, if the
      application makes a call to MS-DOS to read some data from the disk
      into a buffer, MS-DOS starts handling the call by making a call to
      INT13H to talk to the BIOS, which in turn talks to the hard disk
      controller, resulting in the transfer of data into the buffer. So when
      the application needs to transfer the page into the buffer, which is
      currently out on disk, the application tries to call MS-DOS to read
      the page.
      Because MS-DOS is already occupied, the application can't call MS-DOS;
      and MS-DOS is not reentrant, so the second call from the application
      fails. Nor can the application have the page read by calling the BIOS,
      because the BIOS is also in the middle of a call, so it can't be
      reentered either. This situation results in a type of deadlock: the
      application can't let the current call finish until the page is put in
      the buffer, but the page cannot be placed in the buffer until the
      current call finishes.
      The only way to ensure that this deadlock situation does not occur is
      to make sure that Windows never has to page anything in while the
      application is in the middle of an MS-DOS or BIOS call. Because
      Windows cannot predict ahead of time what the application will try to
      access, the only way to be 100-percent safe from deadlocking is to
      make sure everything the application might try to access is already in
      RAM (that is, never paged out to disk). In other words, all 640K-plus
      of the virtual machine in which the non-Windows application is running
      has to remain resident in RAM, thereby using up a lot of physical
      memory. Running several non-Windows-based applications at once uses
      large amounts of RAM, so you may soon end up with only a small amount
      of free RAM left for everything else you're trying to do, such as run
      Windows-based applications. When you check the Program Manager About
      dialog box (from the Help menu), it shows that you have plenty of
      memor-virtual memor-and you do. But if you try to start another
      non-Windows application, which requires yet another 640K of RAM, the
      application won't start. So, Windows starts running sluggishly and/or
      may generate the "Out of Memory" message.
      So how does 32-Bit Disk Access help? Windows 3.0 offered a contiguous
      paging file (which is created with Swapfile) for any pages using the
      INT13H BIOS calls. Windows 3.1 handles the same task by making calls
      to the 32-Bit Disk Access system. Unlike MS-DOS or the BIOS, the 32-
      Bit Disk Access system can queue up multiple requests and is
      completely reentrant. Windows no longer needs to rely on MS-DOS or the
      BIOS; so regardless of what the application is doing, Windows can
      always page calls in from the hard disk. Free from a potential
      deadlock situation, Windows 3.1 can now make the virtual machines that
      are running completely pageable. Non-Windows-based applications no
      longer need to take up so much RAM, since they can now use virtual
      memory the way Windows-based applications do. When Windows needs some
      RAM space, it can now page out pieces of these virtual machines.
      With Windows 3.1 and 32-Bit Disk Access, you can run multiple non-
      Windows-based applications and Windows-based applications without
      generating an "Out of Memory" message. When the About box tells you
      that you have 14 MB of memory, you can actually use all 14 MB for
      running your applications, whether they are Windows or non-Windows.
      Improved Performance for Non-Windows Applications Under Windows
      In the previous example, we saw how 32-Bit Disk Access in Windows can
      page non-Windows-based applications to free up enough RAM for those
      applications when they need to use it. The 32-Bit Disk Access feature
      also improves Windows performance all around, making the system run
      much more quickly.
      Switching between non-Windows-based applications by pressing ALT+TAB
      is faster with 32-Bit Disk Access. Without 32-Bit Disk Access, a non-
      Windows application can only be swapped out to disk if it is
      configured to not run in the background. This means when you press
      ALT+TAB to switch to such an application, Windows has to read the
      entire program into RAM, causing the task switching to take a long
      time. When Windows is paging using 32-Bit Disk Access, Windows can
      load in just the small amount of information that the application is
      actually using, so task switching becomes almost instant. And, since
      only a small part of the application needs to be in RAM at one time,
      Windows may not have to access the hard disk at all.
      The 32-Bit Disk Access system is composed of the following 386
      enhanced mode virtual devices:
          - WDCTRL, which is the 32-Bit Disk Access device that talks to
            standard Western Digital 1003 or ST506 hard disk controllers
            (about 90 percent of the installed base). WDCTRL is only
            installed if Setup detects a compatible hard disk controller.
          - BlockDev, which coordinates calling block I/O services between
            devices and the 32-Bit Disk Access devices that provide those
            services for specific hard disk controllers. BlockDev is always
          - PageFile, which handles the virtual memory paging file and calls
            through BlockDev if any 32-Bit Disk Access devices are
            available. PageFile is always installed.
          - INT13, which traps and emulates INT13H BIOS calls by calling
            BlockDev. INT13 is only installed if at least one 32-Bit
            Disk Access device is present.
      Because WDCTRL is the only 32-Bit Disk Access device included in the
      Windows box, the standard Windows components only support 32-Bit Disk
      Access for Western Digital-standard controllers. When you run Setup,
      it automatically detects these controllers and adds the following
      lines to the [386Enh] section of your SYSTEM.INI file:
      If you want to disable 32-Bit Disk Access, start the Control Panel and
      choose the 386 Enhanced icon, or comment the lines out of your system
      by placing a semicolon (;) at the beginning of both lines. You do not
      need to delete any files from your hard disk, as the 32-Bit Disk
      Access devices are contained within the file WIN386.EXE.
      Microsoft identified machines where the use of WDCTRL can stop the
      system. Usually, this is caused by hard disk controllers that appear
      to be Western Digital 1003 compatible but are really not. WDCTRL has
      been put though rigorous testing to make sure it is as safe as
      possible, and is designed with a built-in safety measure--every time
      it starts, it performs elaborate tests to make sure it can communicate
      in the same language as the hard disk controller before it attempts to
      read and write data. WDCTRL starts testing by taking a peripheral look
      at some data on the hard disk for tell-tale traces of a Western
      Digital 1003-compatible controller. If the controller passes that
      test, WDCTRL then starts calling up larger pieces of data to try to
      elicit the correct response. Finally, after much redundant checking,
      WDCTRL tries actually reading data from the disk. If it is able to
      read data, WDCTRL then tries to write data and read it back. Only
      after the read/write test is passed does WDCTRL continue and start
      Windows, reassured that it will not cause any catastrophic errors on
      the hard disk.
      However, there are still a few exceptions. There are drives that
      appear to be WD1003 compatible but are not, and which cannot be
      detected by WDCTRL. In addition, there can be problems even with
      compatible controllers on some portable computers, specifically those
      that power down the hard disk to conserve power without telling the
      running software. If the disk is powered down and then back up while
      it is being tracked by WDCTRL, the tracking information will be
      incorrect, and serious damage can result. For these reasons, 32-Bit
      Disk Access is not turned on by default. When you install Windows, 32-
      Bit Disk Access is disabled until you make the decision to enable it
      through Control Panel. Only original equipment manufacturers (OEMs)
      who preinstall Windows 3.1 on a 100-percent-compatible system can turn
      32-Bit Disk Access on before the user receives the system without
      jeopardizing the user's hard disk.
      When something does go wrong, WDCTRL may do different things,
      depending on where it is in its verification code. The initial tests
      have reported WDCTRL as extremely safe. The controllers that WDCTRL
      fails with are considered incompatible with 32-Bit Disk Access, so
      WDCTRL simply does not load when it senses these unsupported
      controllers. This procedure is invisible to the user; he or she just
      won't receive the benefits of 32-Bit Disk Access. If WDCTRL fails a
      test after it is installed, Windows displays an error message that
      warns that something is wrong, most likely that the hard disk might
      have been damaged, and advises to restart the machine (so that WDCTRL
      does not load, and 32-Bit Disk Access is disabled).

File Details

File NameDefault LocationDos Ver.Win Ver.SizeDateSource
Smartdrv.exec:\windows\command7.0Win9545 14511/07/95\win95
7.1Win95 (OSR2.x)44 86724/08/96\win95
Win9845 37911/05/98\Win98
Win98 SE45 37923/04/99\Win98

This page last revised:
January 1, 2003.