Windows 95 Screen Redraws in the Win32 GDI

Windows 95 managed screen redraws by coordinating the user interface manager, an invalidation messaging pipeline, and a hybrid 16-bit/32-bit Graphics Device Interface (GDI) subsystem. When an on-screen visual changed, the operating system generated invalid regions, prioritized pending user input before dispatching paint messages, routed rendering commands through a thunking layer, and converted high-level drawing calls into hardware operations via display drivers.

Invalidation and Update Regions

Screen redraws in Windows 95 were demand-driven rather than continuous. When a window moved, resized, minimized, or was uncovered by another application, the operating system's window manager (USER) calculated the exposed area. Instead of immediately redrawing the pixels, the system marked the damaged area as an "invalid region" and appended it to the window's existing update region. Multiple invalidations were coalesced into a single bounding region to minimize redundant draw operations. Developers could also manually trigger this process using Win32 API functions such as InvalidateRect or InvalidateRgn.

The WM_PAINT Cycle

Windows 95 treated screen updates as low-priority tasks to keep the user interface responsive. The operating system did not place a WM_PAINT message into an application's message queue if other events, such as keyboard input, mouse movements, or timer messages, were pending.

Once the message queue was empty of higher-priority events and an invalid region remained, the system generated a WM_PAINT message. The application handled this message by calling BeginPaint, which performed several critical tasks:

  • It validated the invalid region, resetting the update status so duplicate messages were not generated.
  • It returned a handle to a Device Context (HDC).
  • It automatically set the clipping region of the DC to match the invalid area, ensuring that drawing routines could not write outside the exposed boundary.

After issuing drawing commands, the application called EndPaint, which released the DC resources and signaled the completion of the paint cycle.

The Win32 GDI Hybrid Architecture

Although Windows 95 introduced 32-bit preemptive multitasking via the Win32 API, its graphical subsystem relied heavily on legacy architecture to preserve compatibility and save memory. The GDI subsystem existed across two primary components: GDI32.DLL (the 32-bit entry point) and GDI.EXE (the 16-bit core engine).

When a 32-bit application issued a GDI drawing call, GDI32.DLL validated the parameters and passed the call down to the 16-bit GDI.EXE through an internal translation mechanism known as the "thunk layer." To prevent race conditions during GDI execution, Windows 95 used the "Win16 Lock." When a thread entered the 16-bit GDI core to execute a redraw command, it claimed this global lock, serializing access to the underlying 16-bit graphics engine across all running applications.

Device Driver Interface (DDI) and Hardware Output

Once inside the GDI engine, high-level drawing commands (such as text rendering, line drawing, or bit-block transfers) were mapped against the physical display hardware:

  1. Clipping: GDI evaluated the target coordinates against the clipping region established by BeginPaint and the window’s desktop coordinates.
  2. DIB Engine: Windows 95 routed bitmap and software-rendering operations through a 32-bit Device Independent Bitmap (DIB) engine, which provided optimized rasterization routines directly in system memory.
  3. Display Mini-Driver: For hardware-supported operations, GDI communicated with the display driver via the Device Driver Interface (DDI). The driver determined whether the video card's 2D acceleration hardware could perform the operation (such as a hardware blit or fill) or if the DIB engine needed to render the pixels in system RAM before copying the final bitmap into the video card's frame buffer.

Once the display driver committed the pixel data to the video adapter's frame buffer, the RAMDAC read the buffer and refreshed the physical monitor, completing the screen redraw.