Luna¶

Windows XP, 2001 to 2006; Win32 (common controls version 6) and WinForms.

Luna is the default look of Windows XP and Windows Server 2003: rounded window tops, saturated blue captions with a "soft plastic" gradient, an amber hot state on the controls you press, green check marks, Tahoma with three companion faces, and three hand-authored color schemes (Blue, Olive Green, Silver) locked behind a signature check. Microsoft never shipped the name "Luna". Users saw "Windows XP style", pre-release documents said "the Whistler style", and the internal codename stuck.

This page is unusual among the era pages in one respect: the shipping artifact itself is the primary source. The values below are either a declaration in luna.msstyles' own INI sections or a pixel measured out of its 558 lossless bitmaps, corroborated by the 2001 design document and by Microsoft's own later reimplementations. What the style file cannot show is what the theme engine computed at paint time (the nine-grid stretch, an alpha blend over an arbitrary backdrop). Those values are derived arithmetic, not observations of a running Windows XP.

Principles¶

A Skin Over Windows 2000's Behavior¶

Luna has no interaction guidelines of its own. The only first-party design document of the era is 49 pages of appearance: colors, fonts, icons, control art, folder layouts. It has no keyboard model, no control-selection advice, no writing style, no motion and no accessibility chapter. The behavioral specification for the whole XP era stays the 1999 Microsoft Windows User Experience,⁷ the same book that governs the Windows 9x era.

The architecture enforces the same split. Comctl32 version 6 does not change what a button is, it changes who paints it. The class stays BUTTON, the messages stay BM_*, the styles stay BS_*. An application opts in with a manifest and gets identical behavior with different pixels. An earlier plan with new control classes (UxButton in a separate UXCTRL.DLL) failed because programs find controls by class name.¹⁰ So Luna is a renderer, not a control library.

The Four Adjectives¶

The Guidelines' "About the Design" chapter names four: fresh, desirable, colorful, simple.

The Controls chapter sums it up in one line: controls are characterized by "round corners, subtle dimensionality, and color to help distinguish states". The classic era carried state by bevel direction. Luna carries it by hue.

The One Normative Color Rule¶

Everything else in the Guidelines describes appearance. The Navigation Buttons section is the one place that prescribes meaning:

With a hard scope limit on the same page: "They should not be used for command buttons." This is the first time "destructive is red" appears in Windows as a stated principle, and it is scoped far more narrowly than any later era scopes it. An ordinary XP dialog's OK button is never red.

What Luna Deliberately Is Not¶

Each of these is a checked absence, read in the sources, not an assumption:

• No motion system. Zero duration, easing or timing content anywhere.
• No elevation model. Modeled light (gradients, specular bands, a fixed upper-left light source) but no height scale and no shadow tokens.
• No accent color. The user picks one of three complete schemes. Nothing is derived from a seed hue, and Olive Green is not Blue with the hue rotated.
• No translucency. TransparentColor in the style format is a color key (magenta #FF00FF), not alpha. Real alpha exists only in icon art and shell watermarks.
• No scalable geometry. Chrome is bitmaps stretched through nine-grid sizing margins, with DPI handled by picking one of several pre-drawn images.
• Not open to third parties. The FAQ says "At this point in time we are not allowing additional themes to be created for Windows XP", and "you should never use any of the theme bitmaps directly, you should always render the theme images using the theme API's". Microsoft Learn still says "Microsoft does not support the authoring of .msstyles files".¹²

Microsoft's own user research on the reception is worth one line, because it explains the "Fisher-Price" criticism that followed Luna from day one: "People want Luna for others, but they want Aero for themselves."¹¹ Windows Classic was selectable from the start, and Classic is not a second code path but the absence of a theme, so Luna is the first Windows look that is optional by construction.

Foundations¶

Color¶

Luna's COLOR_* values are style content, not OS constants. The style's [SysMetrics] section defines 19 of the 31 slots and leaves the rest to the classic defaults. The values are identical across the three size variants.

What the table settles:

• #316AC5 is COLOR_HIGHLIGHT and COLOR_MENUHILIGHT both, so in Blue the menu highlight and the selection highlight are one color.
• COLOR_BTNSHADOW is #ACA899. WPF's #CBC7B8 is a real Luna color, a mid-tone in its reconstructed gradients, but it is not the shadow slot. The style states the same five-stop ramp a second time in [globals] (EdgeLightColor, EdgeHighLightColor, EdgeShadowColor, EdgeDkShadowColor, EdgeFillColor) and the two agree exactly.
• Luna recolors surfaces, not text. MenuText, WindowText and BtnText are all absent, so every piece of enabled text is the system's black.
• MENUHILIGHT (29) and MENUBAR (30) are XP additions, guarded by WINVER >= 0x0501. They exist because XP's menus were not drawn through the theme engine at all (see Menus below).

Next to its neighbors, the ramp shows the whole of "say goodbye to Windows gray":

Luna is the first era whose dark shadow is not black or near-black: #716F64 is a warm brown-gray that matches the face.

Two Disabled Grays¶

COLOR_GRAYTEXT is #ACA899, but the Guidelines and the style's own per-part TextColorDisabled give #A1A192 for disabled control text. They are not in conflict. A themed control draws disabled text from its part (#A1A192); a control drawing itself the classic way calls GetSysColor(COLOR_GRAYTEXT) and gets #ACA899. Menus use a third value, neutral #808080, on their white background. Using one where another belongs is the easiest color mistake to make in a Luna reproduction.

What the Schemes Change¶

About two thirds of the theme is scheme-invariant. The check-box and radio glyphs, the amber interaction accent, the tab-pane gradients and the menu, tooltip and text-box colors are the same in all three. The values a scheme actually changes:

The amber accent survives every scheme because Blue shipped first: Olive Green and Silver were added during development as re-hues of an existing Blue design, and the re-hue touched the chrome and left the interaction accent alone. The hot-state family in WinForms' three Luna tables is byte-identical across all three (hover #FFFFDE/#FFE1AC/#FFCB88, pressed #FE803E/#FFB16D/#FFDF9A). Royale, the same engine one product cycle later, replaced it wholesale with blue-gray, so orange-on-blue hover is a Luna decision and not a Windows convention.

Type¶

Luna is the first Windows design language with more than one typeface as a matter of policy. Three of the four role statements contain the word "only":

The shipped style confirms Trebuchet MS Bold 10 exactly, and adds what the document never published: the full system font table, in three size variants.

Four things follow. Verdana is not in the style at all: the small-caption slot that actually paints palette titles is Tahoma 8 bold, so Verdana was advice to application authors, never a system font. Franklin Gothic is reachable by exactly two Start-panel parts and no system metric. Application chrome needs Tahoma and Trebuchet MS, nothing else. The color schemes never change the type. And Tahoma is not a Luna change: it became the Windows UI font in Windows 2000, reaching applications through the MS Shell Dlg 2 pseudo-font.⁸ Luna inherited it and added the other three faces.

The ramp is a short list, not a scale: Tahoma 8 (everything), Tahoma 8 bold (task-pane headers), Tahoma 9 (help body), Trebuchet MS Bold 10 (captions), Tahoma 11 (legal, never shown), Franklin Gothic Medium 14 and 21 (shell pages). There is no 12, 16 or 18, and no ratio between steps.

A disabled Luna label is a flat recolor to a single gray. The classic era's embossed DSS_DISABLED double-draw is gone. The Guidelines never mention ClearType; Luna's typography as documented is a grayscale-antialiased design. ClearType is widely reported to have shipped off by default on XP, but no first-party source states it.

Metrics¶

Luna did not change the layout system. Dialog-unit counts carry over from the classic era; the pixel value of one DLU moved because the font changed. The Vista/7 UX Guide states the Tahoma 8 pt conversion outright:

Half a pixel rounds down ("unlike other contexts, .5 is rounded down to 0 instead of up to 1"). The XP Guidelines state the button in both units at once: "75 pixels wide (50 dialog units) by 23 pixels tall (14 dialog units)". 50 × 1.50 = 75 and 14 × 1.625 = 22.75, rounded to 23. Two first-party documents nine years apart agree to the pixel. The same button measures 73 × 21 when painted, because "some controls have a one pixel invisible border", which is the Guidelines' "the curve of a command button is a 1 pixel indent" seen from the layout side.

Every other layout rule (7 DLU spacing, 4 DLU minimum, dialog maximums) is inherited from the classic era without restatement. Luna's own geometry lives per part, in the style:

[SysMetrics] adds the non-client metrics, identical across schemes: scroll bars 17 px, caption bar 25 px, small caption 17 px at Normal Size (19/29/19 and 21/35/21 in the two larger sizes). The window frame border is 5 px and never scales.

DPI is a set of discrete buckets, and they are per part. The check box and radio button pick 13, 16 or 25 px art at 96, 118 and 185 DPI; the tree expander uses 96, 133 and 150. There is no correct Luna at 150 %: the design supplies art for three buckets and stretches within them. The three size variants are a separate axis, and they change almost nothing but type: every SizingMargins, ContentMargins and image is byte-identical across them.

Material, Depth and Edges¶

Luna has exactly one material, and Microsoft named it four times: soft plastic. A multi-stop vertical gradient from a lighter top to a saturated bottom, a brighter band near the top as a specular highlight, a darker line at the bottom edge. On the caption and taskbar it runs full width; on a push button it is a soft lightening of a near-white face.

The format can declare gradients natively (five stops, positioned by ratios that sum to 255), but Luna declines: of 174 sections that declare a background type, 151 are bitmaps, and exactly one part in the whole style ([ExplorerBar], the task-pane background) declares a gradient. Every other gradient in the era is pixels in a bitmap, stretched by the nine-grid.

Rounding follows one rule: field surfaces are square, chrome is rounded. The five field classes (edit, combo, list box, list view, tree view) are 1 px BorderFill parts with no border type, so square. Everything with a curve is a bitmap part. The style declares no radius anywhere; every curve is painted. The measured ones: the push button runs one antialiased arc of about 3 px, the group box about 2 px, the tab's top about 2 to 3 px, and the window's top corners are a 5-row magenta mask, not a radius at all. A maximized window loses them.

The classic bevel survives inside the engine (DrawThemeEdge is DrawEdge with part colors) but no Luna control's identity depends on it. Two one-pass tricks replace it: a translucent one-sided overlay that darkens one edge and lightens the opposite, and the engraved highlight, a glyph drawn twice in white and in the dark color offset by (+1, +1), used on the scroll-thumb gripper, toolbar gripper, overflow chevron and resize grip.

The era's two real shadows: SPI_GETDROPSHADOW, new in XP, a boolean with no exposed geometry, under menus and drop-downs; and a Photoshop recipe for icon art (angle 135°, distance 2, size 2, black at 75 %), which is content, not chrome. WPF's Luna supplies the only popup-shadow numbers: #71000000 (44 % black), offset +5, +5, with a 5 px fall-off inside the displaced rectangle, in a SystemDropShadowChrome class that Luna's and Aero's WPF themes compile from the same shared file. So the Luna and Aero popup shadows are one renderer.³

Motion¶

None designed. The Guidelines contain no duration, easing or transition. The era's effects are SystemParametersInfo booleans, and reading the version guards in winuser.h dates them: every fade, menu animation, gradient caption and hot-tracking flag sits under WINVER >= 0x0500, which is Windows 2000. XP added exactly two visual toggles: SPI_GETFLATMENU and SPI_GETDROPSHADOW.⁵

Hot and pressed states switch instantly, and that is provable from two artifacts. Tmschema.h reserves the TMT_INTLIST range from 2801 and declares nothing in it (Vista later puts TMT_TRANSITIONDURATIONS there), and GetThemeTransitionDuration is a Vista-only export. An XP visual style could not express a transition. A hot Luna control is a different bitmap cell selected on the next paint.

Controls¶

The state model is the same everywhere: one bitmap strip per part, one cell per state, indexed by the Tmschema.h state number. Hot is four different things, measured from the art, and "amber on everything" is the tempting wrong generalization:

Pressed dims and moves the light source, where Windows 95 inverted a bevel. Disabled is a flat recolor. Focus is the classic dotted rectangle, unchanged.

Push Button¶

75 × 23 px recommended, painted 73 × 21. BUTTON.BMP is five 20 × 23 cells, SizingMargins = 8, 8, 9, 9, so the stretchable center is only 4 × 5 px.

The face ramp, measured down the center column (rows 4 to 18), is monotone but not linear: it falls fast over the first four rows, crawls through the middle and drops four levels at the last row. A three-pixel darkening down the right edge, held in the fixed right band, is the face's inner shadow.

Hovering a Blue or Olive button does not change its face. In the shipping art the hot cell's interior is pixel-identical to the normal cell's; only the amber ring is added. Silver is the one scheme whose face shifts on hover. This is the most commonly mis-reproduced Luna behavior.

No state combines defaulted with hot or pressed, so a strip-based renderer must pick one; WPF's precedence picks hot. WPF also binds keyboard focus to the defaulted appearance, following the classic rule that "any command button becomes the default when users tab to it", so a focused Luna button shows both the dotted rectangle (inset 3) and the blue glow. A checked toggle button renders identically to a pressed button: Luna has no separate checked look for it.

WPF's reconstruction draws the button as eight stacked layers with a fill radius of 4 inside a border radius of 3. The shipping art has one arc; the "fill rounder than the border" bulge is WPF's own.

Check Box and Radio Button¶

The largest authored state sets in the design: 12 check-box cells (three values × four states) and 8 radio cells. 13 px at 96 DPI, 16 px from 118, 25 px from 185, all three shipped with distinct art, despite the Guidelines' "only the 16x16 size is available".

Three things are worth keeping. The glyphs are green in all three schemes; the classic era drew them in COLOR_WINDOWTEXT black. The border is #1C5180, not the button's #003C74: the INI's own color hints distinguish the two, one unit apart, and no source explains why. And hot is not purely additive here: the well under the ring flattens and lightens too. The shipped tick is a 2 px stroked polyline (3,5) → (5,9) → (9,3), smaller than WPF's filled six-point path.

Text Box, Combo Box and Spin Control¶

Luna turns the classic two-tone sunken bevel into a flat 1 px border.

#7F9DB9 is Luna Blue's single "sunken field edge": the five field classes carry the identical value, and the 2001 Guidelines, WPF and WinForms agree on it to the byte. In Silver only the text box moves to #A5ACB2; lists and combos keep Blue's value. A read-only text box is an authored appearance, a disabled look with live black text. A focused text box shows no chrome change at all, only the caret: no hot state, no focus rectangle. The Guidelines transpose the disabled combo's two colors; the style has them the right way round, matching the disabled push button's pair.

The combo's frame never reacts to the pointer; hot and pressed reach only the drop button, which is a stretched background plus a separate chevron glyph. The spin buttons measure normal #C0D2FB, hot #D1E9FE, pressed #95ACF3, disabled #EDEDE6.

Lists, Trees and Column Headers¶

Lists share the field frame: 1 px #7F9DB9, square, white. Items highlight on selection only, never on hover, in COLOR_HIGHLIGHT #316AC5 with white text. An unfocused list keeps a separate inactive-selection color.

The tree expander is a 9 × 9 box with radius 1 inside a 19 × 13 hit area, border #7898B5, a diagonal white → #C0B7A6 fill, and a black 5 × 5 plus or 5 × 1 minus. The indent is one 19 px column, kept for leaf nodes so they line up with expandable ones. Tree items draw no focus visual.

The column header's hot state is a 3 px amber bar along its bottom edge, a left-to-right ramp ending near brown (#FCC247 hint). It is a different amber from the tab's, with no stroke. The header face is #EBEADB on a #EEEAD8 strip, not the #ECE9D8 dialog face. The Guidelines' "sort" state is really a gray tint down the sorted column's cells, not a header state.

Menus¶

Menus are the one control with a complete color set in the Guidelines, and there is a structural reason: XP's menus were not themed. Vista's Tmschema.h says so in a comment, "Menu was not using theme feature in Windows XP". USER32 drew them from system colors, which is why XP needed two new color slots.

The drop-down is white and the bar is the dialog face; the style states both. Menus are flat: FlatMenus = true is in the style itself, so choosing Windows Classic restores beveled menus without touching the Effects tab. The highlight is a filled rectangle edge to edge.

Toolbars and Tabs¶

The toolbar is the cheapest interactive surface in Luna. Icons have two states, default and hot, and hot is a gamma 0.75 Levels move on the same artwork. The button strip has six cells:

That keyed-out rest cell is the real reason XP toolbars read as flat. The toolbar separator is a single 1 px #CAC6AF rule (#BFBFC5 in Silver).

On a tab, the body never changes. The selected tab and the hovered tab carry the same 3 px amber cap: a #E68B2C stroke row over #FFC83C and #FFC73C fill rows. The body is a near-white ramp #FCFCFE → #F4F3EE, the pane frame #919B9C, and the top corners round at about 3 px. A focused tab looks like a hovered one.

Scroll Bar, Group Box, Status Bar and Tooltip¶

libwinui draws this bar under Luna, after WPF's Luna ScrollChrome (Blue): a permanent 17 px gutter that ui::Scroll gives up, the track above, its held half pressed, arrow buttons with a diagonal blue gradient inside a white ring and a soft shadow line, lit on their own hover, and a thumb with four 1 px gripper bars. Disabled, the arrows go gray and the thumb goes.

libwinui's GroupBox draws the Luna frame with the same geometry as Aero's (themed comctl32's: the title 12 px in, a 2 px gap either side, the content 16 px down and 9 px in), in #D0D0BF rounded at 2 px, with the #0046D5 title.

The group box's blue title is the one place an ordinary Luna dialog shows a colored label. The status bar is the one place Luna kept the classic etched separator. The tooltip is the clearest case of Luna leaving something alone: InfoBk, InfoText and WindowFrame are among the twelve slots the style does not set, and its only themed part is the balloon's close button, which has a genuine amber hot state. That button's art (BalloonClose.bmp) is authored on #FFFFE1, which backs the classic fill from inside the style itself.

The scroll track's own FillColorHint (#C6D5FD) is the thumb's value copied onto the wrong part. Measure the track, do not read it.

Slider (Trackbar) and Progress Bar¶

The slider thumb is 11 × 21 at 96 DPI (13 × 26 and 21 × 44 in the higher buckets; the "13/16/25" in its file names is a borrowed convention, not its size). Its body and its 1 px bevel never change; two 2 px accent bands carry the state.

The body is #F3F3EF (disabled #F5F4EA), the bevel #B5C4CD above and left and #778892 below and right, with a one-pixel corner cut. The focused cell is byte-identical to the hot one, so on a Luna slider focus and hover look the same. The groove is 4 px, #F2F1E9, sunken with a #9D9C99 rule above and white below, and never filled behind the thumb. Tick marks are #A1A192, the disabled-text gray reused as decoration, and the only color the trackbar class states as a plain property. Olive Green is the one scheme that recolors these bands; Blue and Silver share them.

The progress indicator is "the green square that fills the progress track": 6 px chunks with a 2 px gap on a white track with a #686868 border. Blue's fill is a glossy #ABEDAC → #2ED331 → #8EE790 pipe, Olive Green's is orange, Silver's a duller green with a hard metal highlight. This is one of the few places a scheme changes a semantic color. There is no marquee mode in any Luna document.

Window Frame¶

The frame is non-client chrome, drawn by the system rather than by any control, but it sets the colors an application's content sits against. At Normal Size the caption bar is 25 px plus a 4 px resize grip, Trebuchet MS Bold 10, white text with a 1,1 shadow in #0A1883. The active caption is not a two-stop gradient: it rises from #0055E5 to a peak of #026AFE about two thirds down and falls to #0043CF. Caption buttons are 21 × 21 at a 4 px right inset with 3 px gaps, in eight cells (four states, active and inactive). The frame border is 5 px of painted art that never scales, darker on the right because the window is lit from the upper left.

Reproducing It Today¶

Luna is unusually well documented for a re-creation, because the style file states most of its own values. What it does not give away is its art. About half of Luna is continuous-tone surfaces that a modern 2D renderer can generate from measured numbers; the other half is hand-drawn pixel glyphs, and all of it is Microsoft's copyrighted artwork. The two questions to settle are how closely a gradient can stand in for a stretched bitmap, and where measuring ends and copying begins.

Exactly Reproducible¶

Text is grayscale-antialiased, which is how the Guidelines present it.

Approximated¶

Embedding the art instead is not an option. luna.msstyles carries its own notice, "Copyright © Microsoft Corporation, 2000", and no redistribution license exists for it. Size is not the obstacle: all 558 bitmaps come to about 440 KB as optimized PNG. A workable line runs inside "procedural", not around it:

Parametric descriptions and small measured tables of continuous tone: yes. Per-pixel reproductions of authored shapes: no.

Colors, margins, state counts and part names are facts about an interface. A per-pixel table of the 13 × 13 check mark is the bitmap in a different encoding. Luna's own structure supports that split: its 186 distinct parts divide into 91 surfaces, 91 glyphs and 4 icons, and a glyph such as a caption symbol or a chevron is stored as a separate resource from the face it sits on. The four genuinely irreducible parts are all Start-panel chrome that an application never draws. The Start button itself is not among them: it is a plain green pill, and Explorer composites the Windows flag from its own resources.

For byte-exact chrome, the one clean route is the one Wine and ReactOS took: parse a .msstyles the user already owns instead of shipping one.

Three things are out of reach for any re-creation, because only a running Windows XP could show them: what the engine's nine-grid stretch put on screen, the push button's corner pixels (the style declares no transparency there, and the sheet's corner holds scheme-dependent residue), and the menu animation, which XP exposes as a pair of booleans with no timing.

Not a Theme¶

Some of what makes an application look like XP is layout, behavior or content, and a theme alone cannot give it: dialog layout in dialog units (a 50 × 14 DLU button, 7 DLU margins), the keyboard model and the rule that the focused command button becomes the default, both from the classic era's behavioral guide, the colored navigation-button convention (a meaning, applied only to navigation buttons), the task panes and Franklin Gothic shell pages, the icon style, and the menu and drop-down animations, which are the user's SystemParametersInfo switches applied by the system rather than a property of the style.

High Contrast¶

Luna has no high-contrast scheme, by design. The "Designed for Microsoft Windows XP" specification states it: "When High Contrast is enabled, Windows automatically switches the user to the Windows Classic Style."⁹ The high-contrast look of the era is therefore the classic beveled construction in the system's contrast colors, and a faithful re-creation stops being Luna while high contrast is on. The same specification separates the High Contrast color scheme, a palette the user picks, from High Contrast mode, the SPI_GETHIGHCONTRAST flag applications are asked to respond to; the flag dates from Windows 2000.

Sources¶

The values on this page come from the primary sources below.

Further first-party background: Kyle Marsh, Dave Massy and John Boylan, Microsoft Windows XP: What's in It for Developers?, February 2001 (https://learn.microsoft.com/en-us/previous-versions/ms997638(v=msdn.10); the hot state "in much the same way as hot spots on a Web page"), and Paul Hellyar, Using Windows XP Visual Styles and PrintWindow in Windows Applications, 25 October 2001 (https://learn.microsoft.com/en-us/previous-versions/ms997649(v=msdn.10)).