Another way to disable rounded corners without patching system files

[oberrich]

There is another way to disable the rounded corners without patching the binaries: win11-toggle-rounded-corners

[valinet]

Finally, so people can stop using this. Tbh, I never expected this to be such a hit.

In the mean time, I also implemented a run time patch for dwm that restores sharp corners: https://github.com/valinet/ep_dwm. It’s integrated in ExplorerPatcher as well. My approach was to patch the instructions that set the radius of the corners. I found that to be relatively easy to match by pattern.

I personally like your idea more. It occurred to me where the flag for rounded corners is stored as well, by studying the disassembly, but never thought of identifying the address of the desktop manager instance from the exported startup function by matching against a certain mov instruction which corresponds to working with the address of that. Neat patch, I hope it lasts through, and that the compiler doesn’t mess with the specific register on future versions (it shouldn’t). Once you get the g_pdmInstance, it is indeed a piece of cake to go and change the flag in the structure (class) directly.

But anyway, great idea, nice find and work. It’s also a good example of writing modern C++, a nice change from my usual archaic C code. I will look into integrating your mod into ExplorerPatcher as well, it’s easier to maintain and fix going forward I believe, so maybe it’s time to deprecate my second method as well (ep_dwm). As for this repo, yeah, I always recommended ExplorerPatcher since I implemented ep_dwm and integrated it there.

Again, thanks for the heads up and neat code. Looking forward to more of your contributions, maybe in the ExplorerPatcher area as well :D

[valinet]

One mention: I’d appreciate a less aggressive tone. I know patching files is not a good idea, this was more of a proof of concept rather than a full implementation, developed just as Windows 11 released, like a year ago or so. In the mean time I also developed, as I said, a memory based solution, so yeah, I don’t know if calling this project out indirectly both in your project’s description and in this issue’s title here is that necessary.

[oberrich]

Thanks for the feedback, I've toned it down a notch.
I didn't realize you were the guy behind Explorer Patcher, I've seen that repo before.
You've definitely collected a lot of neat little patches there. I'm totally gonna get me a different Window Switcher cause this new rounded thing is obnoxious.

[valinet]

Thanks. Indeed, and quite a ton of work maintaining it, so as I said, every helping hand is more than welcome. Take a look on https://github.com/valinet/sws if you want, for example, there are definitely things to improve and optimize.

[valinet]

I took the time to study this more in-depth, since I was looking at integrating your code in the ep_dwm project as well, as an option.

Basically, this structure of g_pdmInstance that you describe in the code:

struct desktop_manager_proto
{
    void *unknown0[3];
    uint8_t unknown1[2];
    bool rounded_shadow_enabled;
    bool enable_sharp_corners;
    bool enable_rounded_corners;
};

I already described it in my blog post here as well, I suggest taking a look at it if you haven't already:

• enable_sharp_corners actually describes to dwm whether the software (WARP) graphics adapter (Microsoft Basic Display Adapter) is used (*((_BYTE *)CDesktopManager::s_pDesktopManagerInstance + 27) in my write-up)
• enable_rounded_corners actually describes whether the rounded corners effect is forced by user setting of ForceEffectMode to 2 in HKLM\Software\Microsoft\Windows\Dwm (!*((_BYTE *)CDesktopManager::s_pDesktopManagerInstance + 28) in my write-up) - you can set that registry entry under a Vm/system without graphics drivers installed, which shows sharp corners, to force it to draw rounded corners for windows in software
• there is also this: *((int *)CDesktopManager::s_pDesktopManagerInstance + 8) >= 2 which is a flag which indicates the user is under some remote desktop scenario

All these flags are checked against when determining what corner style to use in CTopLevelWindow::GetEffectiveCornerStyle.

Also in the blog post, I already experimented with overriding enable_sharp_corners (having it think the WARP adapter is always in use) or CDesktopManager::s_pDesktopManagerInstance + 8 (same thing, either side of the || in the if from GetEffectiveCornerStyle). The effect can be seen "naturally" when you do not have display drivers installed as well, and is also indeed achieved by your program: the corners are indeed sharp, yet context menus and some windows (like the UAC prompt, or the Windows Security boxes that appear, for example, when entering a user name for Remote Desktop Connection) lack a drop shadow which may make them look unnatural. This, while context menus do indeed get a solid black or white border depending on their color:

win11-toggle-rounded-corners on the left, ep_dwm on the right

I think this is important to note, as it makes some things hard to distinguish under certain scenarios. My ep_dwm patch is based on the idea of tricking the "rounded corners code path" into using a very small radius for the corners, so small that it looks basically square/sharp. The blog post, again, describes how I achieved that in 22000-based builds, while the code shows the updated patterns for 22621+-based builds.

I don't know, maybe it's worth considering this approach as well, what do you think? It's a completely different logic indeed, but it seems to provide a more robust effect when it comes to all scenarios. In the mean time, I will also think on whether to compile in your code in ep_dwm as well and have it as an option behind some registry flag. I already have it compiled in on my local machine and it seems to work just fine, with the caveats mentioned above.

But yeah, your approach is nevertheless better than the original "Win11DisableRoundedCorners" project.

[oberrich]

I've looked into the functions you mentioned in your blog post, seems like the best way for proper edges/shadow could be to just modify the floats in .rdata

CTopLevelWindow::UpdateWindowVisuals

FLOAT_4_0 = 0.001, FLOAT_8_0 = 0.001

If we could just write to the CTopLevelWindow fields that would of course be ideal but I'm guessing every window has its own instance of the class and we'd probably have to go through a bunch of internal structures to get to them.

[oberrich]

I have implemented this method on the 'patching' branch in my repo: https://github.com/oberrich/win11-toggle-rounded-corners/blob/patching/main.cpp#L107

[valinet]

All right, nice. Have you looked on the disassembly for uDWM though? I don’t know if I recall correctly, but I think those floats were not used solely for these calculations, but for some others as well. Are we sure changing them doesn’t break or alter some other behavior in the compositor? Again, I don’t know, maybe I don’t remember well or maybe it changed between versions, but I think that’s why I didn’t patch it like this in the first place. I think this aspect has to be taken into consideration when considering a patch like this one. Thanks.

…

On 1 Sep 2022, at 01:37, oberrich ***@***.***> wrote:  I have implemented this method on the 'patching' branch in my repo: https://github.com/oberrich/win11-toggle-rounded-corners/blob/patching/main.cpp#L107 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[oberrich]

Almost all of it is related to the window borders:

The only unrelated thing that gets modified is inside CDesktopWindowReplacement::_AddPPIRectangleInstruction

This doesn't have any drawbacks on my machine as the code path only gets executed for machines with product type 0x77

[m417z]

Hi guys, FYI I ported this project to a Windhawk mod due to a user's request, such that no file patching is necessary:
https://windhawk.net/mods/disable-rounded-corners
I thought you might find this interesting.