Proposal to fix UIRibbon extraneous titlebar margin

[kawapure]

Background

This isn't particularly a priority issue, but it's a small bug with some default Windows programs that can be corrected.

In UIRibbon applications, there is a visual error that can be seen on NTStyle (from the README.md document):

Explanation

This bug occurs due to UIRibbon expecting extended frames under DWM. Because NTStyle forcefully disables DWM on the application, extended frames don't work correctly and the extra allocated space is clearly seen in the client area for the window. This bug also occurs on Windows 8+ versions of UIRibbon, regardless of whether or not DWM is running. It is also observed with official implements of client-side decorations, such as Win32k (classic theme) and UxTheme (XP/Aero Basic theme engine).

To recap, here are the following cases this may occur:

• Under Windows Vista or 7 (or its respective UIRibbon version) when DWM composition is enabled system-wide, the application is not lied to about the DWM composition state via dwmapi hooking, and the window is forced to not use DWM system frames via DwmSetWindowAttribute.
• Under Windows 8+ when the window is forced to not use DWM system frames via DwmSetWindowAttribute.

Proposal

Since you can detect the presence of UIRibbon in an application easily (via current application image name, loaded module image names, child window class name searching, or even a combination of all three), and because the extraneous space is highly predictable (it's the same size as DWM titlebars), a hack can be used for UIRibbon applications to crop this space from the window via custom handlers for window messages like WM_NCCALCSIZE, WM_NCHITTEST, and WM_NCPAINT.

The following information may useful for implementing a system to detect the presence of UIRibbon in a program or window:

• EnumProcessModules from psapi.h can be used to search for UIRibbon.dll in all supported operating systems (Windows NT 4.0+, not supported in 9x).
• UIRibbon creates several windows with the class name UIRibbonCommandBarDock for its UI.
• The following default Windows programs use UIRibbon by default since Windows 7:
  • Paint %SystemRoot%\System32\mspaint.exe (+ x86 copy in SysWOW64)
  • Windows Wordpad Application %ProgramFiles%\Windows NT\Accessories\wordpad.exe (+ x86 copy)
  • Windows Explorer %SystemRoot%\explorer.exe (since Windows 8, only for some windows)

This may not seem a desirable solution (it is really hacky, after all), but it's the easiest solution that I can think of for this case. Another solution is to hook UIRibbon, but this is:

1. The hardest thing in the world. I have not figured out how to do this myself.
2. Requires downloading debugging symbols from Microsoft, which may not be available in some areas of the world.

[freedom7341]

It'll be interesting to come up with a solution for this. I really like the proposal you came up with and searching for UIRibbon using enumprocessmodules seems to be the best way to do it, especially considering I don't intend to support anything older than Server 2003/XP x64. Eventually I want NTStyle to be on the level of Windowblinds, where it can run alongside DWM and still draw over the glass frames, so any solution to fix this should ideally be temporary. If it takes me too long to find my holy drawing procedure, then I'll implement a hack for this. It's worth testing to see if this happens with a Windhawk mod called... DWMUnextendFrames? If I end up wrangling DWM further then that's the method I will follow.

[kawapure]

The exact same behaviour can be seen in classic theme or basic theme with 9200+ UIRibbon and no DWM.

All that Windhawk mod does is hook public DWM APIs (like DwmIsCompositionEnabled, DwmExtendFrameIntoClientArea) and forces them to not call out to the real module. This basically forces applications to act as they would without DWM enabled. You can technically see the same thing if you force DWM to be killed on Windows 8 or 10 and open mspaint.

The latest UIRibbon binary I know of that handles DWM-less situations correctly is from the Windows 8 beta build 8032, which looks exactly like the Windows 7 version, but works in Explorer.

Of course, drawing over glass frames would work too, but be careful to not overdo it. DWM draws the entire window client area over its server-side decorations, which allows applications to draw any content over them (even custom titlebars). Many popular programs today use this approach (Discord, Visual Studio Code, Google Chrome, Mozilla Firefox, etc.), which could cause flickering or draw over application titlebars (sometimes this isn't desirable, particularly when they have custom buttons in the titlebar, think Office 2007).

Speaking of Office, I guess Office 2010 should be checked. Even though the UIRibbon code in Windows is directly taken from Office 2007, Office 2007 does use Office-specific naming for its module and window classes. This is probably also the case with Office 2010, but I don't have it installed to check.