How Windows 3.11 Processed Window Resizing

In Microsoft Windows 3.11, resizing an application window was managed through a lightweight, message-driven process designed to conserve limited 16-bit system resources. Instead of dynamically re-rendering the application contents in real time, the operating system relied on a modal message loop that drew a temporary wireframe outline (often called a "rubber-band" box) during the drag operation. Once the user released the mouse button, the window management system recalculated the geometry, clipped the affected areas, and signaled the application to redraw its interface through standard Graphics Device Interface (GDI) invalidation routines.

The Modal Sizing Loop and Hit-Testing

When a user hovered the mouse cursor over a window border, the system evaluated the cursor's coordinates using the WM_NCHITTEST (non-client hit-test) message. If the hit-test returned a sizing border code (such as HTBOTTOMRIGHT), the mouse cursor changed to the corresponding resize cursor.

Upon clicking and dragging the border, the standard window procedure (DefWindowProc) intercepted the action via a WM_SYSCOMMAND message carrying the SC_SIZE parameter. This shifted the system into a dedicated modal sizing loop. During this state, the window manager captured all mouse input, preventing other non-essential user actions from interrupting the operation under Windows 3.11's cooperative multitasking model.

The XOR Wireframe Technique

Because personal computers of the early 1990s lacked the processing power and video memory bandwidth to smoothly redraw full window contents on the fly, Windows 3.11 used an XOR (exclusive OR) raster operation to show feedback.

As the user dragged the border, the system retrieved a Device Context (DC) for the entire screen and drew an inverted four-pixel-wide rectangular outline representing the pending window dimensions:

  1. Drawing the Outline: An XOR pen inverted the screen pixels beneath the border rectangle.
  2. Moving the Pointer: When a WM_MOUSEMOVE occurred, the system drew the exact same rectangle in the previous location using the same XOR operation, which instantly restored the original screen pixels underneath.
  3. Updating the Outline: The system immediately drew a new rectangle at the updated coordinates.

This method eliminated the need to back up and restore background screen memory, keeping CPU overhead minimal and interface response immediate.

Finalizing Geometry and Invalidation

When the user released the primary mouse button to commit the resize, the modal loop exited, and the final wireframe was erased using a final XOR draw. The window manager then carried out the internal layout transition:

  1. Geometry Calculation: The core USER.EXE module processed the new coordinates, issuing WM_WINDOWPOSCHANGING and WM_WINDOWPOSCHANGED messages to allow the window to accept, reject, or modify its target dimensions.
  2. Sending WM_SIZE: The application received a WM_SIZE message detailing its new client width and height, signaling internal components (such as scrollbars, toolbars, or internal child controls) to recalculate their layouts.
  3. Region Invalidation: The operating system determined which regions of the screen were newly exposed or modified. It added these areas to the window’s "update region" using an internal call equivalent to InvalidateRect.

The Redraw Cycle via GDI

Windows 3.11 treated graphical updates as low-priority events to keep the user interface responsive. A WM_PAINT message was not posted directly to the standard FIFO queue; instead, it was generated dynamically whenever the application's message queue was empty and an update region was present.

When the application finally processed WM_PAINT:

  • The application called BeginPaint, which returned a handle to a display device context (HDC) pre-configured with a clipping region matching only the invalidated portions of the window.
  • Pixels outside the invalidated region were protected from being redrawn, preventing unnecessary draw operations.
  • If the window class included flags like CS_HREDRAW or CS_VREDRAW, the entire client area was marked invalid upon horizontal or vertical resizing, forcing a full redraw of the content.
  • The application called EndPaint, which validated the client area, cleared the update region, and released the display device context back to the GDI resource pool.