How Windows 98 Changed Resolution Without Rebooting

Unlike earlier operating systems that required a full system restart to modify video settings, Microsoft Windows 98 introduced the ability to adjust screen resolution and color depth on the fly. This capability was made possible through architectural enhancements in the Graphics Device Interface (GDI), modernized display driver standards, the implementation of dynamic mode-switching APIs, and an operating system messaging pipeline that alerted running applications to redraw their interfaces immediately.

The Limitation of Earlier Windows Versions

In Windows 3.x and initial releases of Windows 95, display configurations were treated as static hardware parameters loaded during system boot. Video drivers allocated a fixed memory footprint, fixed font metrics, and static system palettes at startup. Changing any display property typically meant editing configuration files or registry keys, which required an operating system reboot to unload the active display driver and initialize a new configuration.

The Win32 ChangeDisplaySettings API

The core mechanism enabling dynamic changes was the implementation of the ChangeDisplaySettings and ChangeDisplaySettingsEx functions within the Win32 subsystem. When a user adjusted settings in the Display Properties control panel, the operating system passed the desired parameters (horizontal and vertical resolution, color depth, and refresh rate) to the graphics subsystem without unloading the core display components.

The API verified whether the requested configuration was valid for both the monitor and the graphics adapter before committing the change. It could test the mode, switch it immediately, and revert if the hardware failed to respond correctly.

Modernized Display Mini-Drivers

Windows 98 enforced stricter requirements on hardware vendors through updated display driver specifications. Video drivers were split into a hardware-independent layer managed by the operating system and a hardware-dependent mini-driver provided by the hardware manufacturer.

To support live switching, drivers were required to implement dynamic mode-switching routines. When instructed by the OS, the driver directly reconfigured the graphics processing unit's (GPU) internal registers, modified frame-buffer allocations in video RAM, and updated the digital-to-analog converter (RAMDAC) parameters without terminating the driver process.

The WM_DISPLAYCHANGE Broadcast

Handling the hardware layer was only half the process; running applications also needed to adapt to the new visual parameters. Windows 98 coordinated this through its messaging architecture:

  1. Hardware Reset: The display driver reconfigured the video card to the new resolution and color depth.
  2. GDI Update: The Graphics Device Interface updated the system device context, re-evaluating the desktop dimensions, aspect ratios, and color palettes.
  3. Message Broadcast: The operating system sent a WM_DISPLAYCHANGE message to all top-level windows. This message carried the new color depth in its wParam and the new resolution dimensions (width and height) in its lParam.
  4. Application Repaint: Running programs receiving the message re-evaluated their window positions, reloaded UI assets if necessary, and invalidated their client areas to trigger a complete redraw.
  5. Shell Realignment: Windows Explorer caught this broadcast to dynamically resize the desktop canvas, reposition the taskbar, and recalculate coordinates for desktop icons.

Graceful Fallback for Legacy Hardware

To maintain backward compatibility, Windows 98 queried driver capability flags before attempting a live switch. If an older or uncertified legacy driver lacked dynamic mode-switching support, Windows 98 suppressed the instant transition and safely prompted the user to restart the computer, preventing system crashes or corrupted screen memory.