Windows 3.11 SMARTDRV Dynamic Cache Management

This article explains how Microsoft Windows 3.11 worked in tandem with the SMARTDrive (SMARTDRV) disk-caching utility to dynamically manage memory allocation. By implementing a dual-size cache model controlled via command-line parameters and internal operating system hooks, SMARTDRV could adjust its footprint based on whether the computer was operating in real-mode MS-DOS or protected-mode Windows. The following sections outline the mechanics of this dynamic scaling, the communication between MS-DOS and Windows, and the evolution toward native protected-mode caching in Windows for Workgroups 3.11.

The Two-Tier Cache Architecture

SMARTDRV was loaded via AUTOEXEC.BAT or CONFIG.SYS during system startup under MS-DOS. To balance the performance needs of raw DOS environments with the heavier memory demands of the graphical Windows environment, SMARTDRV implemented two distinct cache size settings specified in its syntax:

SMARTDRV.EXE [InitCacheSize] [WinCacheSize]
  • InitCacheSize (DOS Cache Size): The amount of extended memory (XMS) SMARTDRV claimed upon booting MS-DOS. Since MS-DOS applications rarely used all available extended memory, SMARTDRV defaulted to a larger cache to maximize I/O throughput.
  • WinCacheSize (Windows Cache Size): A smaller, secondary target size intended for when Windows was running. Windows required significant amounts of extended memory to manage its own memory manager, run multitasking applications, and establish virtual memory paging.

If the user did not explicitly specify these values, SMARTDRV calculated defaults based on the total amount of physical RAM detected in the system.

The Dynamic Transition Mechanism

The resizing process occurred through coordinated communication between SMARTDRV and the Windows kernel:

  1. DOS State: At boot time, SMARTDRV allocated the full InitCacheSize from the Extended Memory Manager (HIMEM.SYS) using XMS functions.
  2. Entering Windows: When the user typed win to launch Windows 3.11 in 386 Enhanced Mode, the Windows kernel detected the presence of SMARTDRV via software interrupts (specifically multiplex interrupt INT 2Fh). Windows then signaled SMARTDRV to shrink.
  3. Memory Surrender: Upon receiving the signal, SMARTDRV flushed any pending write buffers to disk and freed the difference between InitCacheSize and WinCacheSize back to the XMS pool. Windows subsequently absorbed this released memory into its global memory pool for application use.
  4. Exiting Windows: When the user exited Windows back to the MS-DOS prompt, the operating system issued a termination hook. SMARTDRV intercepted this event, requested additional blocks from the XMS pool, and re-expanded the cache back to the original InitCacheSize.

Write Caching and Reliability

By the release of Windows 3.11, SMARTDRV (version 4.0 and later) supported write caching (delayed write/write-behind) in addition to read caching. When Windows requested a reduction in cache size, SMARTDRV had to ensure cache consistency. It synchronized dirty blocks to the physical drive before releasing the buffer pages back to the system, preventing data corruption during the memory reallocation phase.

The Transition to 32-Bit File Access in Windows for Workgroups 3.11

Windows for Workgroups 3.11 introduced a major architectural change: 32-Bit File Access. This feature utilized two protected-mode drivers—VFAT.386 (a 32-bit protected-mode FAT file system) and VCACHE.386 (a 32-bit protected-mode cache manager).

When 32-Bit File Access was enabled in the Control Panel under the 386 Enhanced Virtual Memory settings, VCACHE.386 entirely bypassed SMARTDRV for protected-mode hard disk access. In this configuration, SMARTDRV was relegated strictly to caching real-mode disk access and CD-ROM drives (via MSCDEX), while VCACHE dynamically allocated and freed memory directly within Windows protected mode, eliminating the real-mode overhead inherent to SMARTDRV.