Why do minimized windows have an apparent size of 160×31?

Date:February 10, 2005 / year-entry #35
Tags:history
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20050210-00/?p=36483
Comments:    31
Summary:We discussed a few months ago the issue of where windows minimized to before the taskbar was invented. In the modern taskbar world, why do minimized windows have an apparent size of 160×31? The size isn't just apparent. That's really their size. You can see them, for example, if you fire up a program that...

We discussed a few months ago the issue of where windows minimized to before the taskbar was invented. In the modern taskbar world, why do minimized windows have an apparent size of 160x31?

The size isn't just apparent. That's really their size. You can see them, for example, if you fire up a program that uses the Multiple Document Interface.

Observe the appearance of the window "Book1". This is a minimized window (though minimized to its MDI host rather than to the desktop). With the introduction of Windows Explorer, which put files on the desktop in the form of icons, it became necessary to change the appearance of minimized windows in order to avoid confusing a minimized program icon from a desktop icon. A minimized program, therefore, took the form of a miniature title bar.

The programming interface to minimized windows remained the same, for compatibility reasons. (And please let's just agree to disagree on whether backwards compatibility is a good thing or not.) That's why the function to tell whether a window is minimized continues to be called IsIconic, the message you receive when someone tries to restore a minimized program is still called WM_QUERYOPEN, and the OpenIcon function can still be used to "open" a minimized "icon". All even though minimized windows haven't looked like icons for nearly ten years.

The OpenIcon function is just an old-fashioned way of saying ShowWindow(hwnd, SW_NORMAL), in the same way that the CloseWindow function (dating back to Windows 1.0) is an extremely old-fashioned way of saying ShowWindow(hwnd, SW_MINIMIZE).


Comments (31)
  1. J. Edward Sanchez says:

    "With the introduction of Windows Explorer, which put files on the desktop in the form of icons, it became necessary to change the appearance of minimized windows in order to avoid confusing a minimized program icon from a desktop icon."

    Except that when you’re using Explorer as the shell, you never get to see any minimized windows at all. Explorer silently moves minimized windows to some far off-screen position so that they can’t be seen. Instead, the user gets Taskbar buttons, which somewhat resemble the minimized windows they represent.

    If you want to see the actual minimized Windows, you can kill Explorer, or shut it down using the old Ctrl+Alt+Shift+Cancel trick in the "Shut Down Windows" dialog box. You’ll then have to restore and re-minimize the windows to reset their minimized positions back on-screen.

    Given this, I suspect that the appearance of minimized windows was redesigned primarily for the benefit of MDI.

  2. PatternGuru says:

    Right. This set of blog posts if normally really great, and even though this one is too, I’m a bit disappointed that it does not answer the question it posed itself. (Which I have come to expect of them.)

    "In the modern taskbar world, why do minimized windows have an apparent size of 160×31?"

    Indeed: why exactly 160×31 and not a slightly different size? ;-)

  3. Raymond Chen says:

    Even if you use Explorer as your shell, you can get one of these little gizmos on your desktop: Minimize a window whose window styles say "Don’t put me on the taskbar".

  4. "The programming interface to minimized windows remained the same, for compatibility reasons. (And please let’s just agree to disagree on whether backwards compatibility is a good thing or not.)"

    I’m getting to be more than a little annoyed, Raymond, at the legions of programmers out there that think it’s ok to just break every app out whenever they come up with a new idea. What is the basis for this mentality?

    James

  5. asdf says:

    Isn’t it something other than 160×31 if you play with your font/dpi settings?

  6. Pierre Gersöne says:

    Hey Raymond,

    why is OpenIcon and CloseWindow not on the "Obsolete Windows Programming Elements" list?

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winprog/winprog/obsolete_windows_programming_elements.asp

  7. J. Edward Sanchez says:

    “Isn’t it something other than 160×31 if you play with your font/dpi settings?”

    Yes. Additionally, you can adjust the width to your liking by editing the “MinWidth” value in the following registry key:

    HKEY_CURRENT_USERControl PanelDesktopWindowMetrics

    Explorer also uses this setting to determine the default width of Taskbar buttons. One of the first things I do after a fresh Windows install is to increase this value to give me nice, wide Taskbar buttons that don’t needlessly cut off the caption text.

    [Do not modify the registry directly. Use the documented API. -Raymond]
  8. Mike Dunn says:

    Funny, I was just thinking about this a couple days ago. I had been working in VC for a while, and I went to switch to an Explorer window that had been minimized for a while (and thus swapped out to disk). Explorer did its little animated title bar thing, and when the window first painted, it was clearly just a little chunk of the title bar. Now I know it was exactly a 160×31 chunk.

    Then about a second later, enough stuff was swapped back in to let the window resize & repaint in its restored size, and I got back to work. ;)

  9. J. Edward Sanchez says:

    "why is OpenIcon and CloseWindow not on the ‘Obsolete Windows Programming Elements’ list?"

    I’m not Raymond, but I think it’s because the functions have not been superseded. Although the names are now anachronistic and misleading, the functions still work just fine.

  10. Jerry Pisk says:

    James, nobody thinks it’s ok to break applications willy nilly. But a lot of us think it’s ok to break applications that rely on undocumented or even flat out buggy behavior.

  11. Vorn says:

    Idunno, I like breaking AOL CDs in half. :P

    Vorn

  12. mb says:

    If I use ShowWindow(hwnd, SW_MINIMIZE) on some windows (i.e. VS.Net 2002 or some Delphi apps) they are not minimized to the taskbar but they become 160×31 windows on the desktop. The minimize button works correctly. Why?

  13. Raymond Chen says:

    mb: You’ll have to debug those programs to see what it’s doing. My guess: They have custom behavior for WM_SYSCOMMAND/SC_MINIMIZE.

  14. Jerry,

    I see your point. The part that really puts me on life support is how we just can’t seem to do anything about it.

    James

  15. Anonymous Coward says:

    <a href="http://weblogs.asp.net/oldnewthing/archive/2004/10/28/249044.aspx#249067">I intend to discuss this further on February 10th, 2005.</a>

  16. Edward says:

    Now thats forward planning.

  17. Cooney says:

    But a lot of us think it’s ok to break applications that rely on undocumented or even flat out buggy behavior.

    The problem is that a lot of places depend on those apps and, in many cases, the company no longer exists. If upgrading will break an app that company A depends on, do you think they’ll upgrade?

    The only real reason to break an app is if it’s necessary for security/system stability. Bugs and misfeatures are ugly, but the point of windows is not to be pretty. The point is to get work done.

  18. Cooney,

    Well said!

    James

  19. Scott says:

    I think backwards compatibility is a GREAT thing. A lot of the data I collect in various programs is like a part of my brain now, and I’ll really need it in 50 years when I start losing my memory. So I want my 2005 programs to keep running on Windows 2050.

  20. olsson says:

    About the Delphi minimizing thing.

    Delphi applications have (or used to have) actually two windows open. One very small, placed outside the visible screen and the actual, usable window.

    The reason is, if I remember correctly, that the Delphi TApplication class needs it as a specific basewindow.

  21. Dave says:

    If you want great backwards compatibility, try Unix or Linux. C programs I wrote in 1978 still compile today. They still don’t do anything useful though…

  22. "That’s why the function to tell whether a window is minimized continues to be called IsIconic, the…"

    windowsx.h helps with this "mess":

    #define IsMinimized(hwnd) IsIconic(hwnd)

    #define IsMaximized(hwnd) IsZoomed(hwnd)

    #define IsRestored(hwnd) ((GetWindowStyle(hwnd) & (WS_MINIMIZE | WS_MAXIMIZE)) == 0L)

    :-)

  23. Reader says:

    If you want great backwards compatibility,

    > try Unix or Linux. C programs I wrote in

    > 1978 still compile today.

    The C programs that I wrote in 1978 still compile for me too…on Windows.

  24. J says:

    Regardless of whether or not open source is a viable business practice, there is probably something to be said for the release of source code when a product is no longer supported.

  25. MJP says:

    Dave: Many businesses have old but business-critical apps which they can’t recompile because they haven’t got the source (quite likely the vendor is no longer in business). New versions of Windows have to be compatible with the *binaries* of old apps, not just the source.

  26. Dave says:

    "New versions of Windows have to be compatible with the *binaries* of old apps, not just the source."

    My 1978 binary would work too if I still had a VAX 11/780. That’s where having the source comes in handy, I can run it on a Pentium instead.

    My point in saying "still compiles" was that the APIs that Unix (and Linux) supplied in 1978 are still availble and work today. But the ability for Unix to change hardware platforms certainly has come in handy from then to now. Given how much code is locked into x86 architectures today it’s probably not much of an issue for the future though.

  27. Norman Diamond says:

    2/10/2005 7:26 AM J. Edward Sanchez

    > Except that when you’re using Explorer as

    > the shell, you never get to see any

    > minimized windows at all. Explorer silently

    > moves minimized windows to some far off-

    > screen position so that they can’t be seen

    In addition to the intended exceptions mentioned by one or two others, there are also the exceptions that came up daily in Windows 98 and a few random times in XP. When clicking on a button in the taskbar fails to properly restore a window, the window remains off-screen but can be moved back on-screen by moving it. At that time its size looks like 160×31, and it is drawn upside-down and/or backwards. Resizing can restore its size from negative to positive. Usually the corrupted window was Internet Explorer, but not always.

  28. The blot says:

    Does this got anything to do with the bug of remaining taskbar buttons (e.g. of the screensaver)

    PS I can’t find the MinWidth value on XP registry

  29. J. Edward Sanchez says:

    The blot: If you don’t have the "MinWidth" value, you can create it yourself. It should be of type REG_SZ, and contain the desired value expressed in negative twips. (A twip is 1/1440 of a logical inch.)

    For example, if you have your display set to "Normal size (96 DPI)", and you want your taskbar buttons to be 512 pixels wide, you should set "MinWidth" to "-7680". (Take 512, divide by 96, and then multiply by -1440.)

    Log off and back on for it to take effect.

    I haven’t tested this, but I believe that if you set "MinWidth" to a positive value, it is simply interpreted as the desired width in pixels. Even if this is true, however, it’s still more elegant to specify it in twips, which are device-independent.

    "MinWidth" is briefly documented here:

    http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/regentry/58825.asp

    Note that the default value given on that page is clearly erroneous. A value of "-154" (154 twips) works out to just ten pixels at 96 DPI, which is absurdly low. The default value is actually "-2310" (2310 twips), which works out to exactly 154 *pixels* at 96 DPI.

    BTW, the apparent discrepancy between 154 and the 160 that Raymond quotes can be accounted for by the window border, which is three pixels wide on each side by default. In the screen shot above, the dark gray portion of the "Book1" minimized document window is exactly 154 pixels wide.

  30. It’s the size of a caption.

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index