How Windows 95 Processed Dynamic Window Dragging

This article examines the underlying architecture and graphical pipeline Windows 95 used to process dynamic screen updates when dragging windows. While the default behavior relied on a lightweight bounding-box outline, enabling full-window dynamic dragging required complex interactions between the USER subsystem, the Graphics Device Interface (GDI), display drivers, and clipping calculations. Below is a breakdown of how the operating system managed message loops, dirty region invalidations, screen-to-screen blits, and hardware constraints to render windows in real time during a move operation.

The Default Bounding Box vs. Dynamic Dragging

By default, Windows 95 did not dynamically redraw window contents while moving them. Due to the limited bandwidth of contemporary system buses (such as ISA and early PCI) and modest CPU speeds, dynamic updates were too computationally expensive for the baseline hardware profile (an 80386 or 80486 processor with 4 MB of RAM).

Instead, the default operation used a wireframe outline. Windows drew a dotted, single-pixel rectangle directly to the display Device Context (DC) using a logical XOR raster operation (specifically, R2_NOTXORPEN or PatBlt with the PATINVERT raster operation). Drawing the bounding box in XOR inverted the underlying screen pixels; redrawing it at the previous position reversed the inversion and restored the original screen data without sending redraw requests to underlying applications.

Full dynamic dragging—internally termed "Full Window Drag" or "Show window contents while dragging"—was introduced as an optional enhancement in the Microsoft Plus! for Windows 95 pack and later integrated into Windows 95 OSR2. It could be toggled via the SystemParametersInfo API using the SPI_SETDRAGFULLWINDOWS flag.

The Dynamic Dragging Message Loop

When a user clicked and held the title bar of a window, the sequence unfolded through standard non-client hit-testing:

  1. Hit-Testing: The operating system dispatched a WM_NCLBUTTONDOWN message with a hit-test code of HTCAPTION.
  2. Modal Drag Loop: The window procedure typically forwarded this to DefWindowProc, which entered an internal modal tracking loop via WM_SYSCOMMAND with SC_MOVE.
  3. Mouse Capture: The system called SetCapture on the window to route all subsequent mouse movements directly to the drag handler, even if the cursor exited the physical boundaries of the window or screen.
  4. Position Calculation: On each received WM_MOUSEMOVE message, the system calculated the delta between the current mouse coordinates and the previous coordinates.

Screen-to-Screen BitBlt Optimization

Redrawing the entire window from scratch via repeated WM_PAINT messages on every mouse pixel movement would overwhelm the CPU and cause severe stutter. To avoid this, the Windows 95 USER subsystem worked with GDI to perform screen-to-screen memory copies:

  • Direct Pixel Shifting: GDI executed a screen-to-screen BitBlt (Bit Block Transfer). The graphical contents of the moving window were copied directly from the source rectangle in the frame buffer to the destination rectangle.
  • Hardware Acceleration: Windows 95 relied heavily on the 2D hardware acceleration capabilities of display adapters (such as S3 Trio, Tseng Labs ET4000/W32, or Cirrus Logic chips). These cards contained dedicated hardware blitters that moved rectangular blocks of video memory without routing the pixel data back through the system CPU or system RAM.

Region Calculation and Clipping

Moving a window exposed areas beneath it while obscuring new areas ahead of it. The Window Manager handled this through region mathematics:

  1. Uncovered Regions: The USER subsystem subtracted the window's new screen region from its old screen region. The remaining area represented newly uncovered desktop space.
  2. Invalidation: USER marked this uncovered region as "dirty" by calling internal equivalents of InvalidateRect or InvalidateRgn.
  3. Dispatching Paint Messages: The system placed a low-priority WM_PAINT message into the message queues of the newly exposed windows (or the desktop window). If an application did not handle its repaint immediately, Windows preserved system responsiveness by prioritizing the drag operation over background window repaints.
  4. Clipping: For windows obscured by the move, the clipping regions (HRGN) maintained by GDI were updated. GDI ensured that subsequent drawing operations executed by underlying programs were clipped to exclude the new coordinates of the moving window.

Architectural Bottlenecks

Dynamic window dragging pushed the hybrid 16-bit/32-bit architecture of Windows 95 to its limits. The Window Manager (USER) and GDI still retained substantial amounts of 16-bit code carried over from Windows 3.1 for backward compatibility.

Every move operation required entering the Win16Mutex (the global 16-bit lock that prevented concurrent execution of non-reentrant 16-bit subsystem code). If an underlying application was slow to process WM_ERASEBKGND or WM_PAINT, or if the video driver held the lock during a slow software blit, the cursor would hitch, leaving visual artifacts or "trails" across the desktop. Consequently, dynamic dragging remained disabled by default unless the system met strict performance criteria.