DirectDraw HAL Graphics Acceleration in Windows 98

This article examines how Microsoft Windows 98 utilized the DirectDraw Hardware Abstraction Layer (HAL) to deliver high-performance 2D and basic 3D graphics acceleration. By acting as a thin, low-level bridge between the DirectDraw runtime and video card drivers, the HAL allowed applications to bypass slow operating system graphics pipelines and execute rendering operations directly on the physical display hardware.

DirectDraw Architecture Overview

In Windows 98, the legacy Graphical Device Interface (GDI) was safe and device-independent, but it introduced significant overhead for multimedia and gaming. DirectDraw resolved this by providing applications with direct access to display memory and accelerated hardware features.

The architecture relied on two primary components beneath the DirectDraw API:

  1. Hardware Abstraction Layer (HAL): A vendor-supplied, 32-bit software layer that directly exposed the specific acceleration capabilities of the installed graphics card.
  2. Hardware Emulation Layer (HEL): A software-only fallback provided by Microsoft to emulate features unsupported by the physical graphics hardware.

Capability Negotiation and Callbacks

When an application initialized DirectDraw in Windows 98, the runtime queried the graphics driver to determine what the video card could process in hardware. The driver communicated this through a series of capability flags (DDCAPS) and callback structures.

These structures contained function pointers for supported hardware features:

  • DDHAL_DDCALLBACKS: Managed core functions such as surface creation and destruction.
  • DDHAL_DDSURFACECALLBACKS: Handled surface operations, including page flipping and locking memory.
  • DDHAL_DDBLTCALLBACKS: Controlled hardware BitBlt (bit block transfer) operations, color-keying, and scaling.

If a requested function pointer was non-null in the HAL structure, the DirectDraw runtime knew the hardware supported that specific operation natively.

The Acceleration Execution Path

When an application requested a graphics operation—such as a surface blit, transparent color fill, or page flip—DirectDraw processed the request through a defined execution sequence:

  1. Application Request: The program called a DirectDraw method (e.g., IDirectDrawSurface::Blt).
  2. HAL Verification: DirectDraw evaluated the driver’s capability table.
  3. Hardware Dispatch: If the graphics card supported the operation natively, the DirectDraw runtime invoked the corresponding HAL callback. The HAL executed the command directly on the GPU or 2D blitter engine by writing to the card's memory-mapped I/O registers or FIFO command buffers.
  4. HEL Fallback: If the driver reported that the hardware lacked support for the operation, the call was automatically redirected to the HEL, which performed the rendering in system RAM using the CPU.

Direct Framebuffer and Hardware Blitting

A major performance advantage of the DirectDraw HAL in Windows 98 was the elimination of intermediate memory copies.

The HAL enabled hardware-level page flipping by altering the display start address in the video controller's registers during the vertical blanking interval (VBLANK). This eliminated visual tearing without CPU overhead.

Additionally, operations like transparent blitting (color-keying) and hardware stretching were processed entirely by the graphics card’s dedicated 2D fixed-function pipelines via the HAL. Applications could also lock the video memory surfaces, allowing the CPU direct linear access to the physical VRAM when custom rendering routines were necessary.

Driver Model Integration in Windows 98

Windows 98 supported both legacy 16/32-bit mixed Virtual Device Drivers (VxD) and the newer Windows Driver Model (WDM). The DirectDraw HAL was optimized to function with minimal transition overhead between user-mode application code and kernel-mode driver execution. By avoiding the GDI message queue and executing low-overhead driver calls, the DirectDraw HAL provided Windows 98 systems with near-bare-metal rendering performance while maintaining standard OS stability.