No, really, why is it 160×31?


When I discussed some time ago why minimized windows have an apparent size of 160x31, I explained that the minimized icon is a miniature title bar, but I managed not to explain why the values are exactly 160 and 31.

The width of the miniature title bar is determined by the iWidth member of MINIMIZEDMETRICS structure. You can retrieve and change this structure with the help of the SystemParametersInfo function. (Use the SPI_GETMINIMIZEDMETRICS and SPI_SETMINIMIZEDMETRICS flags, respectively.) Some people will mention the MinWidth registry value, but those people are wrong. Notice, for example, that messing with MinWidth requires a logoff cycle, whereas using SPI_SETMINIMIZEDMETRICS takes effect immediately. That's because SPI_SETMINIMIZEDMETRICS updates the internal state variables, whereas whacking the registry just change a value in a database that nobody pays attention to once you've logged on.

What about the height? That's just the height of a caption bar, which you can adjust from the Appearance tab of the Display control panel. (Programmatically, you can use that helpful SystemParametersInfo function, this time using the iCaptionHeight member of the NONCLIENTMETRICS structure.)

Comments (15)
  1. JeffCurless says:

    But that doesn’t tell us why THOSE values were chosen.  Why not 162×34?  Inquiring minds want to know!

    [The graphic designers chose the numeric value. -Raymond]
  2. D4rkMaster says:

    So is 160×31 like some kind of cool prime number or something?

  3. Miles Archer says:

    I have to ask – is it DorkMaster or DarkMaster?

  4. Stu says:

    Graphic designers!?

    Since when did graphic designers work on Windows??

    I thought the monstrosity called "Luna" was definitive proof that no graphic designer had any input whatsoever…

  5. Tim Dawson says:

    Most people like Luna.

  6. That one Ian guy says:

    Because everything that needed to fit fits.

  7. D4rkMaster says:

    I pity The fool that thinks its DorkMaster.  I like dark primes.

  8. Lon says:

    @ Dorkmaster

    160 x 31 = some kinda cool prime???

    Really.  Back to 5th grade math for you!

    Google will tell you why you are silly.

  9. Spire says:

    Granted, setting the MinWidth registry value directly may be "wrong", but it is a documented "wrong". Also, it’s the only way to do it non-programmatically — not everybody knows how to write a program that calls an API function, after all. Plus, the iWidth member of MINIMIZEDMETRICS is expressed in pixels; MinWidth is expressed in [negative] twips, which are not only device-independent but are also an order of magnitude more precise.

    I mentioned in the earlier thread that the width of a minimized window is determined not just by the minimized-window width value (i.e., iWidth) but also by the window border width. At 96 DPI, the default minimized-window width value is equivalent to only 154 pixels, not 160. The extra six pixels are accounted for by the left and right window borders.

    Similarly, the default minimized-window height of 31 pixels is arrived at by adding iCaptionHeight to the top and bottom window borders.

  10. RBL says:

    I would like to know what the significance of the number "1033" is. For years (decades, even?), folders with this name show up in many MSFT apps, including Office and Visual Studio. I’ve asked various high-ranking MSFT people, and to a one they shake their head. But it must be formalized somewhere, because it keeps showing up. Inside joke?

  11. William says:

    RBL: use the search box to the right and type in 1033 and you’ll find that oldnewthing already answered your question :)

  12. Damit says:

    I believe 1033 is the decimal representation of 0x0409, which is the LCID for "English (United States)".

    There are other common LCIDs as well that you can see around, and I think MSDN might actually have a list of them somewhere.

  13. Raymond II says:

    The [b]actual[/b] window is given magical, negative constants to place it off-screen when minimized.

    CreateWindow* does not check the X and Y values on the creation of a window, meaning that a lack of input validation [i]will[/i] place the window off-screen.

  14. Gabe says:

    Before you start thinking that there *should* be input validation on window coordinates, Raymond II, consider that virtual window managers rely on being able to have windows off-screen when not visible. Also it would be tricky to figure out when a window would be off-screen on configurations with multiple monitors that are of different sizes.

  15. Raymond II says:

    Gabe, look up Multiple Display Monitors on how to get the monitor associated with a virtual-screen coordinate, and have the window fall back to the primary display monitor in case it’s outside of any monitor, ensuring that the window shows up somewhere it can be seen rather than nowhere.

Comments are closed.

Skip to main content