How Windows 98 Handled 16-Bit and WDM Sound Drivers

Windows 98 served as a transitional bridge between legacy DOS-era computing and modern 32-bit architecture by supporting two distinct audio driver models simultaneously: the legacy 16-bit/VxD (Virtual Device Driver) framework and the then-new 32-bit Windows Driver Model (WDM). To enable backwards compatibility while pushing hardware capabilities forward, Microsoft implemented a multi-layered subsystem featuring dynamic thunking, kernel streaming, and software mixing. This architecture allowed legacy 16-bit entertainment titles and modern 32-bit multimedia applications to play audio seamlessly on the same system, regardless of which driver type the underlying sound card used.

The Dual Audio Architecture

Before Windows 98, Windows 95 and Windows 3.1 relied on VxD drivers tightly coupled with the WinMM (Windows Multimedia) API. These drivers ran in ring 0, often granting applications direct, exclusive control over the sound hardware.

With Windows 98, Microsoft introduced WDM to unify driver architectures between the consumer line and the Windows NT kernel. WDM decoupled hardware access from the WinMM interface, organizing audio handling around a modular Kernel Streaming (KS.SYS) model. Because vendors took years to transition to WDM, Windows 98 had to support systems running pure VxD drivers, modern WDM drivers, and configurations where both were needed for disparate hardware functions.

Thunking and User-Mode Translation

To manage communications between disparate bit-depths and API generations, Windows 98 utilized dynamic "thunking"—a mechanism for translating pointers and system calls between 16-bit and 32-bit environments.

  1. 16-bit Application with a WDM Driver: When a 16-bit program issued an audio call to the legacy MMSYSTEM.DLL, the call was intercepted by a 16-to-32-bit thunking layer and forwarded to the 32-bit WINMM.DLL. From there, WDMAUD.DRV (the user-mode WDM audio driver interface) converted the WinMM calls into Kernel Streaming requests sent down to the 32-bit WDM driver stack.
  2. 32-bit Application with a Legacy VxD Driver: If the system relied on an older VxD driver, the process was reversed. The 32-bit application communicated with WINMM.DLL, which routed the call to a 32-to-16-bit thunk layer, down to MMSYSTEM.DLL, which then engaged the 16-bit/VxD driver stack directly.

Kernel Streaming and KMixer

A major limitation of legacy 16-bit and VxD drivers was their frequent inability to handle multiple audio streams simultaneously, leading to "device busy" errors when two applications attempted to play sound at once. WDM resolved this through the Kernel Mixer (KMIXER.SYS).

When a WDM driver was active, KMIXER.SYS acted as a central clearinghouse inside the kernel:

  • It captured streams originating from DirectSound (32-bit), WinMM (32-bit), and thunked 16-bit applications.
  • It dynamically resampled varying sample rates and bit depths into a single format.
  • It mixed these streams into a single hardware stream before delivering the data to the sound card's WDM miniport driver.

If an application used a legacy VxD driver instead, KMIXER.SYS was bypassed entirely. The system relied instead on hardware-level mixing if the card supported it, or fell back to exclusive locking, where the first application to grab the sound device retained sole access until release.

Real-Mode DOS Compatibility

For MS-DOS games running outside the Win32 subsystem or in "DOS Mode," pure 16-bit real-mode drivers or hardware Sound Blaster compatibility were still required. Because 32-bit WDM drivers operated solely within the protected-mode kernel, they could not natively process real-mode DOS interrupts (such as IRQ 5 or DMA 1).

To solve this, WDM drivers included an emulation layer via SBEMUL.SYS. This component trapped Sound Blaster-targeted hardware interrupts and port requests from DOS boxes running within Windows and redirected the output into the WDM Kernel Streaming pipeline. Consequently, Windows 98 enabled 16-bit DOS games, legacy Win16 programs, and 32-bit Windows software to cohabitate on modern audio hardware without restarting into native DOS.