Windows 3.11 Graphics Scaling for Non-Standard Displays
During the era of Microsoft Windows 3.11, modern dynamic display scaling did not exist, forcing the operating system to rely on device-specific drivers, static font configurations, and Graphics Device Interface (GDI) mapping modes to adapt to non-standard resolutions and monitor aspect ratios. Because Windows 3.11 was designed around fixed, pixel-based rendering, handling non-standard displays—such as early high-resolution CRT monitors, dual-page portrait screens, or displays with non-square pixels—depended entirely on cooperation between hardware manufacturers and application developers.
The Role of OEM Display Drivers
Windows 3.11 abstracted graphics hardware through 16-bit monolithic
display drivers (files ending in .DRV). For any
non-standard monitor, whether it was an ultrawide full-page display used
in desktop publishing or a custom industrial panel, the hardware
manufacturer was responsible for shipping a dedicated driver.
Through the driver, the hardware communicated its physical and
logical characteristics to the Windows GDI using the
GetDeviceCaps API function. The driver reported parameters
including the horizontal and vertical resolution, the physical
dimensions of the display in millimeters, and the aspect ratio of the
pixels. If a monitor used non-square pixels—common in certain legacy
video modes like 320x200 or 640x400—the driver signaled this discrepancy
so GDI could adjust its calculations accordingly.
GDI Mapping Modes
To prevent graphics from appearing stretched or distorted on screens
with non-standard aspect ratios, Windows 3.11 provided several GDI
mapping modes. While most basic software simply drew using the default
MM_TEXT mode (a 1:1 mapping where one logical unit equals
one physical pixel), advanced graphical applications used mapping modes
such as:
- MM_LOENGLISH / MM_HIMETRIC: Mapped logical drawing units directly to real-world physical measurements (e.g., hundredths of an inch or tenths of a millimeter) based on the monitor dimensions reported by the driver.
- MM_ISOTROPIC: Ensured that a 1:1 aspect ratio was preserved regardless of screen geometry. Drawing a circle under this mode resulted in an actual circle on the physical screen, even if the monitor's pixels were rectangular.
- MM_ANISOTROPIC: Allowed developers to specify independent horizontal and vertical scaling factors, enabling custom scaling transformations relative to the monitor's dimensions.
If an application developer did not implement these mapping modes and relied strictly on pixel coordinates, the visuals would stretch or compress according to the physical geometry of the non-standard display.
System Font and UI Scaling
Windows 3.11 did not feature desktop virtualization, vector UI scaling, or arbitrary desktop magnification. Instead, UI elements scaled primarily through predefined system font sets.
The operating system provided two primary font metrics: "Small Fonts" (designed for standard 96 DPI displays, like standard VGA at 640x480) and "Large Fonts" (designed for 120 DPI displays, like 1024x768 or higher on larger CRTs). When configuring a driver for a high-density or unusually sized monitor, users selected the appropriate font profile in Windows Setup. System components, menus, and standard dialog boxes calculated their dimensions based on the average width and height of the selected system font, causing the UI to expand or contract. However, bitmap icons and custom interface controls remained hardcoded to fixed pixel sizes, resulting in visual inconsistencies when run on atypical display hardware.