Why does a maximized window have the wrong window rectangle?

Commenter configurator wonders why the maximum size for a form is the screen size plus (12,12). Somebody else wonders why it’s the screen size plus (16,16).

Let’s start by rewinding the clock to Windows 3.0.

When you maximize a window, the default position of the window is such that all the resizing borders hang “off the edges of the screen”. The client area extends from the left edge of the screen to the right edge of the screen, and also goes all the way to the bottom. It doesn’t go all the way to the top, since it needs to leave room for the caption, but the resizing border that sits above the caption area is not visible either.

The reason for this should be obvious: Since the window is maximized, there’s no point wasting screen real estate on the resizing borders. You want the client area to be as large as possible; that’s why you maximized the window.

The result of this window positioning is that the window rectangle itself is slightly larger than the screen. The parts that “hang off the edges of the screen” are not visible because, well, they’re off the screen. (Of course, if your window had a maximum size smaller than the screen, then those borders stay visible.) The size of these borders might not be 12 pixels, mind you.

This is how things stood for a long time. Even the introduction of multiple monitors in Windows 98 didn’t affect the way maximized windows were positioned. Multiple monitors, however, altered one of the assumptions that lay behind the positioning of maximized windows, namely the assumption that edges beyond the screen were not visible. I mean, they weren’t visible on the screen that held the maximized window, but they were visible on the adjacent monitor. As a result, when you maximized a window, its borders appeared as a sliver on the adjacent monitor.

Why didn’t Windows get rid of the sliver when multiple monitors were introduced? You probably know the reason already: Because there are applications which relied on the sliver. For example, an application might detect that it is maximized by checking whether its edges hang off the screen, rather than checking the WS_MAXIMIZED style. Why would they do it that way? Probably because they fumbled around until they found something that seemed to work, sort of like the people who detect whether the mouse buttons are swapped by calling SwapMouseButton instead of GetSystemMetrics(SM_SWAPBUTTON). (Or maybe because they wanted to treat as “logically maximized” windows which the user had manually resized to be larger than the screen.)

The introduction of the Desktop Window Manager in Windows Vista gave the window manager team a chance to solve the problem without impairing compatibility: The Desktop Window Manager controls how windows appear on the screen, which can be different from the actual window properties. For example, the Desktop Window Manager typically animates a window into position when it becomes visible, yet if an application calls GetWindowRect, it will just see the window at its normal position with no animation.

This decoupling of logical and physical characteristics permits all sorts of visual tricks. The visual trick relevant here is the removal of the overhang borders from a maximized window. The borders are still there: If you call GetWindowRect, you will get the same coordinates you always did. But they don’t appear on the screen. The sliver is gone.

Comments (22)
  1. "Let's start by rewinding the clock to Windows 3.0."

    I love posts that start like this.  Maybe because that's the time period I first started using and learning about computers.  Nice little reminders about the past from a simpler time.  Keep them coming!

  2. Joshua says:

    The desktop window manager didn't fully solve the problem because it is incompatible with certain accessibility settings.

  3. @Joshua, can you provide more details or a pointer to more information on the incompatibilities?  Thanks.

  4. Abso says:

    I'm running XP with two monitors, and I don't see a sliver on my second screen when I maximize something on my primary display, so now I'm curious about how the border hiding was done before the Desktop Window Manager.

    [You found a gap in my memory. Windows XP did address this, but only if you had visual styles enabled, by having the visual styles engine apply a clip region to maximized windows. -Raymond]
  5. Derlin says:

    Abso, I was just wondering the same thing.  I never used multiple monitors till Windows XP, so the history of such support was interesting.

  6. DWalker59 says:

    Right, if we could do it over again, we might not "hang the resizing borders off the edge of the screen", we might re-draw the client window to not have the resizing borders at all.  But that might have been more work.

  7. Joshua says:

    @Chuck Op: Loading arbitrary color schemes confuses the desktop manager. Because I need to do this (I know of nobody else who requires lime green on black) I would have an easy time finding out.

  8. Anonymous Coward says:

    This is related to an issue that you sometimes have to watch out for when developing your own applications. When your window has a client window that has a border, you may need special casing that turns off (some of) the border(s) or moves them out of sight when the window is maximised. This is especially important when the client window may have scroll bars.

  9. @Abso et al.:

    Having the logical borders doesn't mean the default NCPAINT handler has to draw them.

  10. James Lin says:

    Another reason for hiding the resizing borders when maximizing is to allow controls (particularly the titlebar buttons) to be flush against the edges of the screen to take advantage of Fitt's Law.

    Hopefully it's not true in Vista and later now, but an annoying side effect of the overhang is that in XP, maximized windows sometimes ended up with resizing borders anyway, such as when the window manager needs to move maximized windows off of a secondary monitor that's become disabled.  And when enabling secondary monitors, sometimes the overhang from maximized windows on the primary monitor would appear on the secondary ones.

    That raises a question, though: this article says that the DWM allowed the sliver problem to be solved, but wasn't it sort of solved already?  In 2000/XP, the sliver wasn't normally visible (aside from unusual cases like I mentioned above), so the visual and logical characteristics already seemed somewhat decoupled.  Is it that the DWM allows the decoupling to be done in a cleaner, more reliable way?  How did it work before the DWM?  I always figured that the window manager could just set a clipping rectangle for maximized windows.

  11. A certain major 3rd party photo-editing application trashes a strip of pixels on the side of one monitor when you maximize it on another, and also swallows clicks on that unpainted region.

    People who re-invent the standard window-border code to provide their own "cool" (horrendous) alternatives almost always seem to miss several of the cases they are supposed to handle. I wish people would stop doing it.

  12. PastorGL says:

    Hmmm, some applications that are pretending to reinvent window management on their own (I really hate you, Eclipse!) doing this not right, and in result fricking sliver is clearly present on my second monitor even on Windows 8.

  13. I often find myself thinking unfriendly things towards those who feel a "need" to replace chunks of standard functionality. I'm sure you do think your music player is the most wonderful application in the world, and those flashing neon strips with animated LOLcats for window controls are much, much prettier than the standard Windows ones – but if I actually wanted windows that looked like that, I'd have installed that theme. I didn't, so please don't assume it's an oversight and "correct" it for me!

    @James Lin: back in the single-monitor days, "drawing" it off-screen would be harmless since it would be outside the clipping region. I don't recall ever seeing the resize border on the next monitor, I always assumed there was just a special case ensuring they didn't do that, as indeed we're told there is for DWM. I have a feeling my WinXP and Win2k test virtual machines support multiple virtual monitors, so I'll give it a try soon to be sure. Could the Themes mechanism in XP be doing something similar to DWM?

  14. Joshua says:

    @jas88: I've seen it. It tends to sink below other windows in most cases so it's difficult to see unless the other monitor has no windows on it.

  15. Henke37 says:

    Yeah, drawing outside of the screen buffer sure worked fine, if you were using an API that automatically performed clipping for you. Not all APIs do. It is mostly the ones that hand you a big pile of bytes and expect you to do everything yourself that lack this.

  16. q says:


    Are you sure? I have Eclipse. I have Windows XP. I have two monitors. My Eclipse is always maximized. I DON'T have any slivers on the other monitor.

  17. Marcel says:

    [You found a gap in my memory. Windows XP did address this, but only if you had visual styles enabled, by having the visual styles engine apply a clip region to maximized windows. -Raymond]

    Sitting at a multi monitor XP machine right now that has never ever executed the visual styles code ;) I can attest that there must be some special handling, too, because there definitely is no sliver whatsoever. Anything else would be hugely annoying I guess.

  18. D. Garlans says:

    I used to be rabidly anti-Apple and OSX, for a long, long time, but I finally got over myself and crystallized my feelings into this one single gripe, which Raymond summarized perfectly and succinctly:

    "You want the client area to be as large as possible; that's why you maximized the window."

    Thank you Raymond and Microsoft and the whole UI team for understanding such a basic concept and sticking with it.

  19. ender says:

    @Joshua: while I don't use lime green on black, my colour scheme is greyish green on black.

    And as far as clipping maximized windows is concerned, at least on Windows 7, they're clipped to monitor even when using classic theme.

  20. JK says:

    Using a dual-monitor virtual machine running Windows XP, I maximized a window into a secondary monitor and didn't see the sliver on the primary one. What happened there?

  21. @James Lin:  "Hopefully it's not true in Vista and later now, but an annoying side effect of the overhang is that in XP, maximized windows sometimes ended up with resizing borders anyway, such as when the window manager needs to move maximized windows off of a secondary monitor that's become disabled."

    Hate to tell you this, but I have that problem on my two-month-old Windows 7 laptop.  I notice it when plugging/unplugging an external HDMI TV.  Keyboard combination Fn+F7 brings up a pop-up window offering to disconnect projector, disconnect internal display, or extend onto both displays.  Changing between these options often triggers this exact problem, where the overhangs on maximized windows are no longer placed outside the visible area, exactly like you complain about.  I have to restore and then maximize each window to to get rid of the unwanted borders.  Really annoying bug.

    My guess is the window manager detects that the screen resolution changed, so it resizes each window to fit within the visible areas of the screen, including the maximized ones.  The code that does this probably doesn't provide the special handling needed for maximized windows.  Oops.

  22. voo says:

    @PastorGL You must be doing something special. There's no sliver anywhere near my second monitor with eclipse maximized on the other (win7 x64)

Comments are closed.