http://shellrevealed.com/blogs/shellblo ... frame.aspx
Regards, RomanWhy isn't the Close button oversized compared to the Minimize and Maximize buttons, like in Aero?
In pre-DWM Windows, all buttons must have the same size, because there's only one set of metrics to query the size of a button (SM_CXSIZE and SM_CYSIZE, see GetSystemMetrics()). If you look at the TITLEBARINFO structure returned by GetTitleBarInfo(), it says nothing about the size of the individual buttons.
A lot of applications draw their own buttons or even their own captions. Lots of accessibility tools report the position of the caption buttons. Some applications trigger actions by simulating a mouse click to a precise position. All those applications compute the position of buttons based on a multiple of SM_CXSIZE (plus delta), so if the Close button was bigger than SM_CXSIZE, those applications would get all their button positions wrong, so they could draw a new button right in the middle of existing buttons, or click on the Close button when thinking clicking on the Maximize button.
For Vista we fixed this by exposing a new API, WM_GETTITLEBARINFOEX, but of course no application outside of Windows is using it yet. The Accessibility framework has been updated to use it.
Then how is the DWM getting away with it?
The DWM doesn't have any legacy worries because applications cannot draw inside the glass frame, since it's rendered and managed by a totally different process. If an application tries to do it, Windows will detect it and remove the glass frame entirely (and therefore revert to the Basic frame), so that the application can draw what it wants to draw.