Windows 3.x¶

Windows 3.0, 3.1 and Windows for Workgroups 3.11, 1990 to 1995; Win16. Gray faces, one-pixel frames, a bevel that lives in bitmap art rather than in an API, round-cornered push buttons, an X in the check box and a bold bitmap System font.

No first-party Microsoft document names this design language. "Windows 3.x" is a filing name, the same way "Windows 9x" is for its successor.

Principles¶

The Specification Is About Behavior¶

The era has exactly one normative design book, The Windows Interface: An Application Design Guide (June 1992)¹. It covers Windows 3.0 and 3.1 in one volume, and it is almost entirely about behavior: wording, ordering, layout and keyboard handling. It has four sentences about three-dimensionality in 228 pages, seven pixel values and not a single RGB value. Appearance is deferred to Control Panel and to the system's own drawing: "Colors and border thickness are based on the settings in the Windows Control Panel."

The chiseled gray look people remember as Windows 3.1 is therefore not in the guide. It is in the art the display driver ships (see Foundations). Both halves are true at the same time: the specification is flat and defers, the implementation is beveled and fixes it in bitmaps. Sourcing a bevel to the 1992 guide is a category error.

The Eight Principles¶

Chapter 1 of the guide lists eight principles, all prose, with no number in the whole chapter:

Windows 95's guide has seven principles, and the two lists are not interchangeable. Clarity and Awareness are 1992 only; Simplicity arrives in 1995.

The guide grades its rules as recommended, optional or suggested, with "no conformance requirement, expressed or implied." There is no "required" tier. Most rules carry no grade at all, and some grades are surprising: the always-on-top shadow and bold control labels are only suggested, while the 40 x 14 DU minimum OK/Cancel size and the button spacing table are recommended.

What the Era Deliberately Is Not¶

The Era's Own Vocabulary¶

Using a later word dates a claim to the wrong decade.

Foundations¶

Color¶

Windows 3.1 has a 21-slot system color table (19 in Windows 3.0), every slot user-settable in Control Panel and persisted as decimal R G B in WIN.INI [colors]². COLOR_BTNFACE and COLOR_BTNSHADOW are new in 3.0; COLOR_BTNHIGHLIGHT and COLOR_INACTIVECAPTIONTEXT are new in 3.1, behind the first #if (WINVER >= 0x030a) guard in the lineage. There is no COLOR_3DLIGHT, no COLOR_3DDKSHADOW, no COLOR_INFOBK and no COLOR_HOTLIGHT. There is no SPI_* for colors either: SystemParametersInfo arrives in 3.1 and never touches the color table.

COLOR_BTNHIGHLIGHT is documented as "Selected button in a control"³, a selection color, not a bevel highlight. The values line up with a bevel; the concepts do not. Naming the ramp is a Windows 95 act.

The 22 Shipped Schemes and the Missing Default¶

Windows 3.1's retail CONTROL.SRC⁷ carries 22 named color schemes in exact hex, recovered verbatim (Tier 1): Arizona, Black Leather Jacket, Bordeaux, Cinnamon, Designer, Emerald City, Fluorescent, Hotdog Stand, three LCD schemes, Mahogany, Monochrome, Ocean, Pastel, Patchwork, Plasma Power Saver, Rugby, The Blues, Tweed, Valentine and Wingtips. Each is 21 COLORREFs in Control Panel applet order, not COLOR_* index order.

"Windows Default", the out-of-box scheme, is not among them. It is not in CONTROL.SRC, WIN.SRC or SETUP.INF, and a byte sweep of USER.EXE and the drivers finds no table. The defaults are compiled into USER.EXE as immediates. What the 22 schemes do agree on is the buttons:

However lurid a scheme's desktop and title bars, the buttons stay silver: Hotdog Stand paints the desktop yellow and the windows red and leaves the buttons alone. Two independent Tier 1 routes, the scheme table and the driver art, agree on the button triad. This page calls this set the shipped-scheme consensus, never "the Windows Default".

Why These Grays¶

#C0C0C0 and #808080 are the two grays a stock 16-color VGA can paint solid; any other gray dithers. The driver's own 16-entry table and GDI's 20-entry static palette (complete with money green, sky blue, cream and medium gray in 3.1's GDI.EXE, two years before Windows 95) both contain them. The stock brushes match: LTGRAY_BRUSH is the face and GRAY_BRUSH the shadow. The bevel ramp is a hardware constraint made into a design decision, which is why it outlived the constraint by a decade. Schemes like Pastel, Patchwork, Tweed and Designer used off-palette values and were visibly dithered on the hardware of the day; the button triad never was.

Selection, and What Color Means¶

The guide's whole adaptive-color doctrine is one sentence: monochrome displays use reverse video (XOR), grayscale displays a shade of gray, color displays "a highlight color". The highlight has no name and no value in the guide. It also says: "Don't rely on color alone to provide essential information."

Relief: The Edge Grammar¶

This is the center of the era. VGA.DRV holds all 34 OBM_* chrome bitmaps as RT_BITMAP resources (ids 32734 to 32767)⁶, not USER.EXE. Every 4-bpp one uses exactly four colors in a fixed, asymmetric arrangement:

One pixel of white, two of gray. A symmetric bevel reads as Windows 95. The content inset is 2 px on the top and left and 3 px on the right and bottom, so content sits slightly up and left of center, which is why the pressed offset looks right rather than exaggerated.

The driver ships a separate bitmap per state, so each state is a measured fact:

The pressed state is not a mirrored bevel. It drops the white entirely and drops the bottom/right edge, leaving one gray edge on the top and left. The embossed disabled glyph is a Windows 3.1 invention: the four OBM_*ARROWI disabled scroll arrows are the only new chrome art in 3.1, and they arrive with LBS_DISABLENOSCROLL, CBS_DISABLENOSCROLL and EnableScrollBar.

All 30 Windows 3.0 chrome bitmaps are byte-identical to their 3.1 counterparts. The white highlight is in the 1990 art, two years before COLOR_BTNHIGHLIGHT exists as a slot, so Windows 3.0 applications could see a highlight on the system's scroll bars that no color slot let them match.

The split between beveled and flat art is exact. Chrome the user manipulates directly (caption buttons, scroll arrows, the Control-menu box) is 4-bpp color art. Glyphs that sit inside a control the system already colored are 1-bpp monochrome and inherit its colors:

All of this is per display driver. OBM_UPARROW is 18 x 11 on CGA, 17 x 14 on EGA, 17 x 17 on VGA and 21 x 22 on 8514/A, and CGA chrome is monochrome, so on CGA Windows 3.1 had no bevel at all. Heights track the vertical resolution while widths barely move: the art was hand-drawn per display so the chrome keeps its physical size. The VGA column is the one quoted everywhere here.

The window frame itself is flat. The guide describes a modal dialog frame as a 1 px black line with a thicker inner border in the title-bar color, and a modeless dialog as a single 1 px black line. Windows 3.x is flat where it is drawn by code and beveled where it is drawn by art.

Materials¶

There is no material system. Every surface is a flat, opaque fill: no alpha plane in any bitmap format, no AlphaBlend, no layered windows, no GradientFill. WS_EX_TRANSPARENT (3.1) is a z-order and clipping flag, not an opacity one. Icons and cursors use an AND/XOR mask pair, which is binary transparency.

Where a later era reaches for opacity, Windows 3.x draws a 50 % checkerboard of two solid colors: the disabled check box row of OBM_CHECKBOXES, GrayString disabled text, the DrawFocusRect focus box, the 50% Gray desktop pattern (170 85 170 85 ...). The stock LTGRAY_BRUSH, GRAY_BRUSH and DKGRAY_BRUSH are the era's three-stop opacity scale. At 1:1 a dither sparkles, and approximating one with 50 % alpha is visibly wrong.

Typography¶

There is no scalable UI type. Every character the interface draws comes from a hand-authored bitmap font, shipped per display resolution and picked by Setup from the display driver. TrueType arrives in 3.1 for documents, never for chrome. Every metric below comes from the FONTINFO header of the shipped .FON files⁹ (Tier 1).

There are two UI faces, and the chrome one is bold:

The System font's metrics are identical in the 1990 3.0 SDK and the 1992 retail files. Title bars and menus read semibold because the stock face is bold; a regular-weight caption is wrong at the font level.

MS Sans Serif is Helv renamed, with identical metrics at every size. WIN.SRC maps Helv=MS Sans Serif, and every dialog template in PROGMAN.EXE, MAIN.CPL and WINFILE.EXE carries DS_SETFONT at 8 pt "Helv", while USER.EXE's own dialogs say "MS Sans Serif". So MS Sans Serif 8 pt is the dialog font three years before Windows 95, which usually gets the credit. The guide's layout footnote assumes the bold face (bold labels "remain legible when dimmed"), while every shipped template uses the regular weight.

The trailing letter on a .FON file is a resolution axis, not a size axis: B is EGA (96 x 72 dpi), E is VGA (96 x 96) and F is 8514/A (120 x 120). Windows 3.1 ships only B, E and F.

No antialiasing anywhere. Every screen font is 1 bpp, TrueType in 3.1 rasterizes to 1 bpp with hinting, and font smoothing arrives with the Windows 95 Plus! pack. The faithful rasterization is aliased text snapped to device pixels.

Metrics and Layout¶

Dialogs are laid out in dialog units (DUs): one horizontal DU is the dialog font's average character width / 4, one vertical DU its height / 8. GetDialogBaseUnits() always uses the System font, while MapDialogRect() honors the dialog's own DS_SETFONT font, so it is the wrong number for almost every real dialog. The 4-and-8 divisors are already in the 1986 Windows 1.03 style guide¹⁰.

At VGA with MS Sans Serif 8 pt, one vertical DU is 13 / 8 = 1.625 px, so a 14 DU button is 22.75, about 23 px. With an average width of about 6 px a 50 DU button is about 75 px. The canonical 75 x 23 px "standard Windows button" falls out of Windows 3.1's own conventions. The vertical figure is solid; the horizontal one is an inference from the font file, since no GetDialogBaseUnits value was measured on a running system.

The guide gives no control heights at all. These come from counting 90 SDK sample resource scripts and the shipped shell's dialog templates (Tier 1):

And the button layout the guide does prescribe (graded recommended):

The default is a vertical stack at the right edge. A bottom row is mandatory only for message dialogs. The shipped product disagrees with its guide twice: the SDK samples mostly use 32 x 14 buttons, below the 40 x 14 minimum, and Program Manager's five dialogs ship 6 DU between groups where the guide asks for 8. The File Open common dialog follows the guide exactly: 50 x 14 buttons, 4 DU inside the OK/Cancel group, 8 DU before Help, 6 DU margins.

Motion¶

There is no motion design. No control fades, slides or cross-fades; it is repainted from a different bitmap. The guide mentions animation twice, both times as a caution, and gives no duration, rate or easing anywhere. What the era does have is a handful of thresholds and the input defaults Setup writes into WIN.INI⁸:

Move and resize drag a gray XOR "ghost" frame rather than a live preview. Auto-repeat on scroll arrows and auto-scroll past an edge exist, with no rate stated anywhere.

Focus and States¶

For command buttons, option buttons and check boxes the dotted focus box encloses the label, not the control. There is no focus-hiding policy; that is a Windows 2000 arrival. There is no hover state anywhere, and the guide argues against rollover feedback on control-bar buttons as distracting. Disabled is drawn three ways, chosen by what the art could express: COLOR_GRAYTEXT (new in 3.0) for text, a 50 % dither for monochrome glyphs, an embossed glyph for color chrome.

The keyboard model is the 1986 one: Tab moves between controls without operating them, Space operates the focused one, Enter chooses the default button, Esc chooses Cancel or Close, and Alt+mnemonic moves focus and operates in one keystroke.

Controls¶

Push Button¶

"The control is a round-cornered rectangle containing the given text"⁵. The driver confirms it: OBM_BTNCORNERS carries a 6 x 6 corner ring (1 px thick, one pixel cut from each corner), an 8 x 8 heavier ring (2 px thick, two cut) and a 4 x 4 fill mask. Corner shape, more than any color, is what tells a Windows 3.1 button from a Windows 95 one.

WM_CTLCOLOR explicitly "has no effect on a button with the BS_PUSHBUTTON or BS_DEFPUSHBUTTON style"⁴. A push button's look has two handles only: the system-wide COLOR_BTN* slots and BS_OWNERDRAW. Uniformity is enforced by the platform.

One caveat stays attached to every button claim. No OBM_* bitmap is a dialog push button: the button is drawn by USER.EXE code, which was not disassembled. The edge grammar is evidenced on scroll arrows and caption buttons, the only era chrome whose pixels survive.

The guide also names a "3-D button", and every passage about it is about toolbox and control-bar buttons, never OK and Cancel. There, "depressed" means latched: the property is in effect, the tool is selected, or the drop-down it owns is open. Up and depressed are the only two states named.

Check Box and Option Button¶

The checked check box is an X in the guide, in the BS_AUTOCHECKBOX reference and in the shipped bitmap, three independent sources. The menu check mark (OBM_CHECK) is a tick. Two marks for two jobs; Windows 95 collapses them into one. Arrow keys in a radio group move focus and select; in a group of check boxes they only move focus.

A value set, a group of adjacent rectangular option buttons with the labels inside, has no system control. Its selected cell is a depressed 3-D button or an outline in the highlight color.

Text Box and Spin Box¶

The sunken "well" people associate with the era is not documented in any source read; it came from applications drawing it themselves or from CTL3D. A spin box is a text box with an up arrow above a down arrow, working like scroll arrows over a hidden list sorted in descending order, so up increases. There is no spin control in base Windows 3.x; msctls_updown arrives in the Windows for Workgroups SDK's COMMCTRL.H¹¹.

List Box and Combo Box¶

The gap is the intended visual discriminator between the two drop-down forms; its width is never stated.

Group Box and Frames¶

"Group boxes consist of a rectangular one-pixel frame with a label at the upper left." A plain 1 px rectangle, with the label interrupting the top line. The etched groove is a Windows 95 convention. Between button groups the guide forbids rules outright and asks for white space instead. The era's only built-in frame primitives are six STATIC styles: filled rectangles or 1 px outlines in the window-frame, desktop or window color.

libwinui's GroupBox draws the 1 px COLOR_WINDOWFRAME frame with the label 7 px in breaking its top line, and insets the content as PROGMAN does: 7 DU across and 10 DU down.

Scroll Bar¶

libwinui draws this bar under Windows 3.x in a 17 px gutter, the VGA arrow's size: arrows and scroll box in the era's 1 : 2 edge, a held arrow pressed as its single dark top-left edge with the glyph nudged, a stemmed arrow (a 7 x 4 head on a 3 x 3 stem), a fixed 17 px square scroll box, and the flat shaft inverted under a held page click. Disabled, the arrows are embossed and the box goes.

A split bar is a double line with one blank pixel between: 1 px, 1 px gap, 1 px.

Menus¶

No menu metric is stated anywhere: bar height, item height and padding are all driver or USER.EXE values that were not observed. Menus have no shadow.

Windows and Dialogs¶

Modality is visible in the frame, and no later era does that. There is no close button in the title bar: closing is the Control menu or a double-click on the Control-menu box. The only shadow in the whole design language is a suggested gray shadow on the right and bottom of always-on-top windows, width unstated. It is the guide's one hint at a light source, and it agrees with the art: upper left.

Message dialogs have three types, Information, Warning and Critical; the question mark is discouraged because it is the Help symbol, even though the API defines MB_ICONQUESTION. The default action button says OK rather than a verb when the title already names the action. Dialogs have no tabs; the era's answer is the unfolding dialog (Options >>).

Controls That Do Not Exist¶

Tab control, property sheet, tree view, list view, toolbar as a system class, tooltip, progress bar as a control, rich edit, date picker, status bar as a system class. The Windows for Workgroups 3.1 SDK's COMMCTRL.H v1.0 does define a toolbar, msctls_statusbar, msctls_trackbar and msctls_updown, and three of those class strings survive verbatim into Win32, but nothing in the retail shell uses them. The guide's "slider" ("a bar containing notches or measurement markings, plus an indicator perpendicular to the bar") has no control class; an application owner-drew one or used a horizontal scroll bar.

Reproducing It Today¶

Windows 3.x is more computable than it looks. The edge is four flat colors in a fixed arrangement, not a ramp of hand-drawn bitmaps, so almost all of it can be drawn as geometry from the tables above. What stands in the way is the art that is genuinely art, the fonts that no longer ship, and a modern compositor that assumes antialiasing, rounded windows and shadows.

Exactly Reproducible¶

Approximated¶

Not a Theme¶

Some of what makes an application look like 1992 is layout, behavior or content, and a theme alone cannot give it: the button column at the right of a dialog, OK instead of a verb, the Cancel-to-Close relabeling, modality shown in the frame, the unfolding Options >> dialog instead of tabs, the focus box that is always visible, MDI and Program Manager. The default button's heavy ring cannot be sized from any source.

The window frame is non-client, and on current Windows DWM draws it. A libwinui window opened with Frame::Themed gets the era's sizing frame from the pack instead: two 1 px frame lines around the border color, notched where each corner's sizing zone ends, the Control-menu box, and the minimize and maximize arrow buttons sized from the VGA driver's caption art, with no close button. The black modal dialog frame is not drawn.

High Contrast¶

The era has no high-contrast concept and ships no high-contrast scheme. What it has is the mechanism without the intent: all 21 color slots are user-settable, and the guide tells applications to read them rather than hard-code colors, so a user who needed contrast set it by hand. The closest shipped scheme is Monochrome: black on white, silver buttons, black title bars. Resolving a modern contrast theme into the 21 slots and keeping the four-color edge is faithful to how the era worked. Accessibility features beyond that came from the Access Pack for Microsoft Windows, a Trace R&D Center (University of Wisconsin-Madison) add-on in the Windows Driver Library, not from Windows itself.

Sources¶