Restoring DWM borders, shadows and acrylic (Windows 11 22H2+)

Last updated 20/02/2025 - Extra information in FAQ

22621.1 with the modified uDWM.dll library

You should only follow this guide if you are experienced in conducting system file modifications. Mistakes whilst patching can result in the Desktop Window Manager entering into a crash loop, rendering your system unusable. Proceed with caution.

I cannot be held responsible for issues that may occur with your system resulting from following this guide incorrectly.

It is highly advised to test file modifications inside a Virtual Machine (VM) first before applying them to your host install.

This does not restore the old window animations, Aero Snap, or BlurBehind accent policy.


This guide documents the initial patching process for restoring the old window frame system, as applied to builds 22621.1 (22H2), 22631.4830 (23H2), and 26100.1742 (24H2). There may be differences in other versions with the way values look, but the steps should be similar.
Users on Cobalt-based releases (build 22000) should instead use a copy of uDWM.dll from build 21390.
Users on earlier versions of builds 22621 and 22631 (e.g. 22631.2361) should use instructions written for 22621.1 over ones written for 22631.4830, depending on the disassembled code instructions. You should be technically competent enough to determine this.

On February 18th 2025, a method of restoring the classic Desktop Window Manager (DWM) borders and shadows for Windows 11 was finally uncovered.

This guide covers what patches to the uDWM.dll library are required. These are organised by a descriptor of what each modification does, and within this, they are separated by the production versions of Windows 11 that they need to be applied to (where applicable.. Some patches are universal and are marked as such. I have listed these by sections that you can jump to below for specific patches.

Whilst the main objective here is to restore the old DWM frame behaviour, some of the modifications listed will allow you to unlock or roll back additional functional changes.

To carry out these patches, you will need suitable decompilation software (e.g. IDA, Ghidra) and the uDWM.dll from your operating system version, as well as an appropriate PDB symbol file. I cannot reiterate enough that you should have the necessary experience before attempting this on your main system.


Contents

  1. Disabling backdrop effects
  2. Restoring window borders
  3. Fixing border colorization
  4. Restoring shadows
  5. Disabling luminosity for Acrylic
  6. Finished product
  7. FAQ
  8. Notes

Disabling backdrop effects

Prior to restoring anything else, it is essential to disable the Mica effect that gets drawn starting from Windows 11 build 22557 on the titlebar. The reasoning for this is because it doesn't play nicely with the old border system, and can lead to inconsistencies with border margins.

To begin with, once the uDWM.dll file has initialised, you will need to browse to the function called
CTopLevelWindow::CalculateBackgroundType

The assembly code generated for the function should, for all Windows 11 versions to date look something like this. Expect some of the bytes and numbers to look different.

Base assembly for CTopLevelWindow::CalculateBackgroundType

When making permanent adjustments to these functions, it is important to preserve the function start and end points, e.g. the sub rsp, 28h, add rsp, 28h, and retn calls as these are critical for the function to actually work in the first place. As such, you have to work around this limitation within all patches that we are applying here.

A lot of conditional jumps exist here for different purposes, but what we want to happen is simple - we want none of the new background calculations to be used in the first place. Conveniently, a code location is defined that clears the register eax, meaning that it gets set to zero. To achieve this, in your assembler, you will need to assemble the first instruction below sub rsp, 28h (or equivalent) to read jmp loc_18003ABC3. In this case, this is mov rbx, rcx that will need to be replaced. Leftover bytes should then be assembled to nop as necessary, to prevent buffer overflow issues. Your updated function should look something like the below:

Updated assembly for CTopLevelWindow::CalculateBackgroundType

To explain what is happening here, we are clearing the register eax, meaning that it contains value zero, and then forcing the function to return that, rather than returning a series of different values depending on a series of conditions. In this case, zero is equivalent to traditional colorization, without extra effects such as Mica or Acrylic. After applying this patch alone, your desktop will look something like this, where you can see that the Mica titlebar effect is no longer present.

26100.1742 with uDWM.dll backdrop effects disabled

Aside from this, you can patch this function to return other values instead for other use cases, but I wouldn't personally recommend doing this. For example, you could choose to enable Acrylic on titlebars rather than Mica (I'm not going to go into more detail here, though). For purposes of this guide, you should avoid that unless you want clipping issues with the old-style borders.

Restoring window borders

This is a particularly contentious one - people have been in receipt of methods for restoring "normal" window frames in some form since as early as June 2023, but these have, to date, relied on strange hacks involving the partial use of Windows 11's high contrast mode. Arguably, these have been of very little use and have left the operating system's capacities for visual customisation far behind those of its immediate predecessor.

The artifacting on the default visual style alone (let alone many others) leaves a lot to be desired, and is rather unsightly. You can see that the old borders are present, but are clipped inside a more padded-out version of the modern window border. This is symptomatic of the way that the new border frames work, clipping the window at a fixed point; the only change that high-contrast mode makes is that they gain extra padding.

26100.1742 with the 2023 border methodology

So, let's do this a completely different way. This time, we will need to browse to the function called
CTopLevelWindow::UpdateWindowVisuals

The instructions for patching this function vary slightly depending on your Windows version, due to compiler optimisations commonly referred to as code inlining.

The assembly for the function is quite lengthy, so you may need to browse through decompiled pseudocode to help.

22621.1 (22H2)

This looks confusing (compared to 24H2) in theory, but in practice it shouldn't be, as long as you follow the instructions carefully. The substance of what you're doing here is very similar.

Inside the function, the base assembly should look something like this:

Base assembly for CTopLevelWindow::UpdateWindowVisuals

It's not particularly clear at first glance, but what happens is there are a number of conditional jumps to blocks of code that will carry out different things. In our case, we want to disable the modern border rendering system and restore the classic one. Achieving this is simpler than it seems - we just need to replace one of these comparisons with an unconditional jump to loc_18001CEF7. Assemble the instruction cmp [rbx+360h], dil and change the instruction accordingly to jmp loc_18001CEF7, making sure to assemble leftover bytes as nop instructions.

The modified assembly should look something like this:

Updated assembly for CTopLevelWindow::UpdateWindowVisuals

At this stage, the modern borders and shadows will no longer render, but neither will the old borders. This gives you something of a mess visually, as what is happening here is that neither the modern nor the legacy code is running.

22621.1 with the modern borders removed

We can do better than this.

To restore the old border drawing code, we need to remove the check for high contrast mode that occurs later in the function. To do this, you need to scroll down to the assembly of this same function that looks like this:

2nd part of the assembly for CTopLevelWindow::UpdateWindowVisuals

Here, what needs to happen is the removal of the conditional check for high contrast mode, which will allow the borders to render. This is fairly simple in nature - we just need to assemble call ?IsHighContrastMode@CDesktopManager@@SA_NXZ, test al, al and the second jz short loc_18001CFEA to instead be filled with nop instructions for all applicable bytes.

The updated assembly should look something like this:

Patched 2nd stage assembly for CTopLevelWindow::UpdateWindowVisuals

At this stage, after applying these changes, you should notice that the border is now being rendered, however shadows are still absent.

22621.1 with CTopLevelWindow::UpdateWindowVisuals border patch

Moreover, border colorization is also missing, which is more apparent when using different visual styles.

22621.1 with CTopLevelWindow::UpdateWindowVisuals border patch and alternate visual style

To save you having to scroll through instructions for 23H2 and 24H2, you can skip to the next part by clicking here.

22631.4830 (23H2)

The main thing with this build range is that there are some differences in the base assembly. Whilst you could probably figure them out yourself, I felt it better to document any drastic differences that I encountered during testing.

Anyway, inside the function, the base assembly should look something like this:

Base assembly for CTopLevelWindow::UpdateWindowVisuals on 22631.4830

Much like on 22H2, what we need to do here is disable the modern border rendering system by ensuring that its associated code instructions are not executed. We need to create an unconditional jump to loc_18003D289, by simply assembling the comparator cmp [r15+360h], r14b and replacing the instruction with jmp loc_18003D289 to ensure that this code does not render.

The modified assembly should resemble the following:

Updated assembly for CTopLevelWindow::UpdateWindowVisuals on 22631.4830

After doing this, as per 22621.1, we need to actually re-enable the code that draws the window borders from the visual style atlas, as otherwise we will have no borders at all. To do this, we need to scroll down to the assembly of the function that looks like this:

2nd part of the assembly for CTopLevelWindow::UpdateWindowVisuals on 22631.4830

As with 22H2, we just need to assemble call ?IsHighContrastMode@CDesktopManager@@SA_NXZ, test al, al and the jz loc_18003D329 instructions to instead be filled with nop instructions for all applicable bytes.

The modified assembly should resemble the following:

Patched 2nd stage assembly for CTopLevelWindow::UpdateWindowVisuals on 22631.4830

The window border should now be rendered, but border colorization and shadows remain absent at this stage.

To save you having to scroll through instructions for 24H2, you can skip to the next part by clicking here.

26100.1742 (24H2)

Arguably, the instructions for this version are somewhat clearer.

Inside the function, you are looking for assembly code that resembles the following:

Base assembly for CTopLevelWindow::UpdateWindowVisuals on 26100.1742

There are a number of conditional checks that determine which blocks of code should be executed and when. By default, this runs through to the code responsible for the enablement of the modern window border system. We need to assemble the code so that we are always skipping these instructions and can run through to enabling the old border system without interruption.

To do this, we need to add an unconditional jump to loc_180019925. We can do this by replacing the cmp [r15+340h], r14b instruction with jmp loc_180019925, and filling any leftover bytes with additional nop instructions as needed. We don't actually replace the jump in this case, but instead the comparator that is applied immediately before it. Be careful not to patch the wrong instruction here as doing so can soft-brick your system. The instructions we need to modify are located shortly after the call to IsOpenThemeDataPresent.

Updated assembly for CTopLevelWindow::UpdateWindowVisuals on 26100.1742

After that, we need to actually enable the code that draws the old borders. Otherwise, you won't have anything other than the colorization that gets applied to the top border frame. Proceed by going to the part of the function that resembles this:

2nd part of the assembly for CTopLevelWindow::UpdateWindowVisuals on 26100.1742

This section of code is responsible for setting the conditions of whether to render the old window borders. Whilst it does check for highcontrast mode here, enabling that in full does cause other side effects. In this case, we just want to remove the conditional jump and associated check. Assemble the code to nop for the high contrast mode call, as well as for the test al, al and jz loc_180019982 instructions. What you end up with should look like the following:

Patched 2nd stage assembly for CTopLevelWindow::UpdateWindowVisuals on 26100.1742

It may not be immediately obvious given the nature of the default visual style, but we have in fact enabled the old window border system. This is more obvious when using a visual style with larger borders. As you can see though, we no longer have the artifacting seen in previous border "fixes". However, it is also clear that there are some issues that remain at this stage - the borders are not appropriately coloured, and the shadows are missing.

26100.1742 with modern borders reverted

Fixing border colorization

Restoring border colorization is necessary to ensuring that you have a good user experience, or at the very least, one that is on par with how Windows has behaved historically. This is another area that has historically only been partially resolved, with the use of solutions of varying quality that struggled to achieve a good result. Now, it can be properly restored.

The patches required here are also version-dependent and have to be done in different places.

22621.1 (22H2)

On this version, restoring colorization takes a few patches to restore.

To begin with, browse to the function inside your uDWM.dll called
CTopLevelWindow::UpdateNCAreaGeometry

You may have to scroll quite some distance from the top of the function to reach the desired section of assembly code. This is what you want to look for:

Base assembly for CTopLevelWindow::UpdateNCAreaGeometry

The instructions highlighted in green are the ones that are the most important to us here. In effect, if a certain condition (likely to be related to high contrast, but the code is inlined in a strange way) is not met, a conditional jump ends up being skipped and the border region will be cleared. This runs contrary to our desired outcome.

To fix this, we need to prevent this conditional jump from ever running, by assembling the bytes of the three instructions highlighted in green to simply nop, which in effect means that these bytes will not do anything. This should look like the following:

Updated assembly for CTopLevelWindow::UpdateNCAreaGeometry

However, this is not the only patch required to force borders to appear; there is an additional function preventing border colours from rendering that we need to remove. In order to do this, browse to the function called
CLegacyNonClientBackground::SetBorderColor

You will need to look for assembly code that looks like this, at the start of the function:

Base assembly for CLegacyNonClientBackground::SetBorderColor

Ultimately, the code checks for whether the window is one with an extended frame client area, or whether high contrast is enabled. Skipping both checks and adding an unconditional jump to loc_180062263 is how we can ensure that border colorization is set. However, you need to be careful - the first two statements highlighted here in green must remain intact in order for register values to be correct. As such, assemble the instruction mov rcx, [rcx+120h] and rewrite the instruction to jmp loc_180062263, making sure to fill any leftover bytes with nop instructions as usual.

After making these changes, your assembly code should look like this:

Updated assembly for CLegacyNonClientBackground::SetBorderColor

Once you have made this modification, window frames will now have the correct colorization as appropriate.

22621.1 with restored colorization and alternate visual style
Inactive border colorization inconsistencies have always been present in this visual style. This is not caused by this patch.

Additionally, on the default visual style, frames are now more appropriately filled in. However, shadows are still missing at this stage.

22621.1 with restored colorization

To save you having to scroll through instructions for 23H2 and 24H2, you can skip to the next part by clicking here.

22631.4830 (23H2)

There are some notable differences in one of the functions that we need to account for here, compared with 22H2.

To begin with, browse to the function inside your uDWM.dll known as
CTopLevelWindow::UpdateNCAreaGeometry

From the top of the function assembly, scroll down until you reach this region of code. It should look something like this:

Base assembly for CTopLevelWindow::UpdateNCAreaGeometry on 22631.4830

The code here indicates that if high contrast mode is not enabled, a conditional jump is skipped and we pass through to a series of code statements which clear the border region. As such, a patch is required in order to prevent this from happening.

Unlike other versions, we have to be very specific about how we apply this patch - the xor r9d, r9d function or equivalent must remain untouched, meaning that we can't just re-assemble the high contrast mode call to an unconditional jump. Instead, we have to re-assemble the call to a series of nop instructions. Then, below the xor r9d, r9d instruction, we can insert the unconditional jump to loc_18007C05A without much further issue. As usual, leftover bytes will also need to be assembled to nop instructions.

The modified function assembly should look like this:

Updated assembly for CTopLevelWindow::UpdateNCAreaGeometry on 22631.4830

We also need to patch an additional check out in the function
CLegacyNonClientBackground::SetBorderColor

Within this function, you will need to scroll to the assembly that resembles this:

Base assembly for CLegacyNonClientBackground::SetBorderColor on 22631.4830

The instructions consist of a series comparative checks to determine whether to allow the border color assignment code to run or whether the value zero should be returned. We want the former to take place at all times, so we need to assemble the instruction of the first comparison cmp dword ptr [rax+60h], 0 to instead be an unconditional jump, in the form of jmp loc_18007BF70 which will ensure our desired outcome.

The modified function assembly should look something like this:

Updated assembly for CLegacyNonClientBackground::SetBorderColor on 22631.4830

After applying these modifications, window frames will contain the appropriate colorization. At this stage, however, shadows are still missing.

To save you having to scroll through instructions for 24H2, you can skip to the next part by clicking here.

26100.1742 (24H2)

Differences in code inlining once again mean that the patch is, once again, slightly different to administer on this version.

To begin with, browse to the function inside your uDWM.dll that is called
CTopLevelWindow::UpdateNCAreaGeometry

From the top of the function assembly, you will need to scroll until you reach this region of code. It should resemble the below:

Base assembly for CTopLevelWindow::UpdateNCAreaGeometry on 26100.1742

We are the most interested in the code statements that are highlighted here in green. What happens here is that if high contrast mode is not enabled, a conditional jump is skipped and we pass through to a series of code statements which clear the border region. Obviously, we don't want that to happen. As such, we need to switch out and assemble the call to check the high contrast mode value to instead point to an unconditional jump to loc_18001CBC5, which will avoid clearing the borders. As ever, fill the leftover bytes for the call with nop statements.

The updated assembly should look like this:

Updated assembly for CTopLevelWindow::UpdateNCAreaGeometry on 26100.1742

We then need to ensure that the border colour can actually be applied - there is an additional function that tries to prevent border colours from rendering. Thankfully, it's fairly easy to get rid of this conditional check. Head to the function called
CLegacyNonClientBackground::SetBorderColor

Base assembly for CLegacyNonClientBackground::SetBorderColor on 26100.1742

All we need to do here is ensure that an unconditional jump is applied to ensure that, rather than returning zero, the code to set border colours executes as desired. You will need to assemble the first comparator instruction cmp dword ptr [rax+60h], 0 to instead contain jmp loc_18001D802, followed by a series of nop instructions on any leftover bytes.

The updated assembly should resemble the following:

Updated assembly for CLegacyNonClientBackground::SetBorderColor on 26100.1742

After applying these patches, borders will now behave in a more predictable way, leaving just window shadows to need to be restored. You can see that the window frame is 1 pixel larger on the active File Explorer window with the default visual style, whilst the coloured border is now restored for others, as you can see below.

26100.1742 with border colorization restored
Inactive border colorization inconsistencies have always been present in AeroLite. This is not caused by this patch.

Restoring shadows

This has been something of a mystery for years, not least because it has long since been assumed that Windows 11 removed the old shadow behaviour entirely, in favour of the new system of drawing shadows based on a projection of the window. Prior to this discovery I was beginning to lose hope that the implementation was still present - in the days leading up to this, I had been testing to see how far you could get when making use of the uDWM.dll from build 21390 (the latest known build by date to use the old behaviour). If anyone's wondering, 22483 is as far as you can go with that method.

More to the point, when making comparisons between various versions of functions (after establishing that there was no way to run 21390's version on 22489 or later), I eventually found that the offset calculations for the shadow parts in CTopLevelWindow::UpdatePinnedParts were still present to this day. It still took an additional day or so after this discovery to locate the cause as to why they weren't rendering with the old border system, and the explanation is simpler than you would expect - the relevant code had been inlined, to the point that it was extremely difficult to find. Strangely, despite being a newer version of Windows 11, this code was not inlined to the same extent in 24H2, which finally allowed for the shadows to be patched back in, in all their glory.

The patch itself is fairly simple, and requires returning to the function called
CTopLevelWindow::UpdateWindowVisuals

Make sure that you follow the instructions relevant to your Windows version.

22621.1 (22H2)

In this case, given that the code is inlined, it may be harder for you to locate it. However, it is in roughly the same position as the non-inlined variation.

You will need to scroll through the assembly code until you see instructions resembling the following:
Base assembly for CTopLevelWindow::UpdateWindowVisuals - shadow restoration

In this case, a conditional jump takes place that only allows for the non-shadow atlas parts to be loaded as part of the window frame. For our desired behaviour, we need to modify this accordingly to an unconditional jump, so that all of the non-client parts are treated the same. To achieve this, we can assemble the lea eax, [rbp-12h] instruction and replace it with jmp loc_18001D03C, which will skip this check and ensure that shadow parts are rendered. Leftover bytes should be assembled to nop instructions as necessary.

Your modified assembly instructions should look something like this:

Updated assembly for CTopLevelWindow::UpdateWindowVisuals - shadow restoration

After applying these changes, your window frames should now behave the same way they did prior to the changes made by Windows 11.

22621.1 with window shadows restored

To save you having to scroll through instructions for 23H2 and 24H2, you can skip to the next part by clicking here.

22631.4830 (23H2)

The basic steps should be similar. However, be mindful of some differences in the assembly code. You will need to navigate to the assembly within the function that looks like this (in this case, use of pseudocode decompilation if available might help you navigate here more quickly):

Base assembly for CTopLevelWindow::UpdateWindowVisuals on 22631.4830 - shadow restoration

We are particularly interested in the instructions highlighted here in green. What's happening here is that a check is being applied to the window frame atlas parts - if they are the shadow parts, then the condition specified is not met and the code continues running without assigning the relevant atlas parts. To reverse this, we need to replace this check with an unconditional jump to ensure that all non-client atlas parts are loaded. This is fairly simple - we just need to assemble the lea eax, [rdi-12h] instruction and replace it with jmp loc_1800809B4 (this being the code location used for the conditional jump) to ensure that the desired code-path is always used. As ever, assemble any leftover bytes to nop instructions as needed.

The updated assembly should look like this:

Updated assembly for CTopLevelWindow::UpdateWindowVisuals on 22631.4830 - shadow restoration

Once you have applied these changes, window frames should behave as they did prior to Windows 11.

To save you having to scroll through instructions for 24H2, you can skip to the next part by clicking here.

26100.1742 (24H2)

Given the code is far less inlined here, the check is far easier to locate. You will want to navigate the assembly of the function until you reach the point where you can see a call to CTopLevelWindow::IsShadowNCAreaPart. The assembly should resemble the following:

Base assembly for CTopLevelWindow::UpdateWindowVisuals on 26100.1742 - shadow restoration

This code may look familiar, because we have already applied patches to ensure that CTopLevelWindow::GetWindowFramePart and the rest of the classic window frame code is running. However, seemingly to prevent additional artifacts under high contrast mode (which is the only situation ordinarily in Windows 11 where the frame atlas code is used), an additional check is carried out to filter out the shadow parts. Obviously, we don't want this to be happening.

To restore the shadows, all we need to do is essentially remove this check and conditional jump that gets applied so that the shadow parts are treated like the frames and are therefore rendered. How we do this is fairly simple - assemble the mov ecx, ebx, call instruction, test al, al and jnz loc_1800199AA or the equivalent in your uDWM.dll to instead be filled with nop instructions. This, in effect, removes the check. Your assembly should look like the following:

Updated assembly for CTopLevelWindow::UpdateWindowVisuals on 26100.1742 - shadow restoration

At this stage, if your visual style contains window shadows, these will be rendered accordingly. Obviously, ones that don't have them will not use them.

26100.1742 with window shadows restored

Disabling luminosity for Acrylic

This is an additional tweak that you will need to make if you want Win32 composited window effects to look like they did prior to Windows 11. This will only revert the changes for surfaces that draw the Acrylic effect using Win32 APIs, such as SetWindowCompositionAttribute, or DwmSetWindowAttribute (this includes the taskbar, until 22621.1344).

Starting with Windows 11, the Acrylic effect now features additional blending based on a luminosity opacity value that is calculated from various inputs within DWM. However, this means it responds to colour inputs rather differently - in some cases, light windows will look dark behind an Acrylic-rendered surface.

Thankfully this is fairly simple to dispense with, and only requires patching out one block of code.

Inside your uDWM.dll library, browse to the function called
CAccentAcrylicBlurBehind::UpdateAcrylicBlurBehind

You will then want to scroll down to the series of instructions in assembly that resemble something like this:

Base assembly for CAccentAcrylicBlurBehind::UpdateAcrylicBlurBehind

Strangely, both types of Acrylic effect are still present. What happens here is fairly straightfoward - a condition is checked and then a conditional jump takes place if that condition is not met. In this case, the conditional jump takes us to the section of code that handles the old Acrylic effect. Therefore, the solution to this is clear - we must replace the test condition with an unconditional jump. In this case, we need to assemble the instruction test byte ptr [rbp+4], 2 and overwrite it with the instruction jmp loc_18005CF50, making sure to assemble leftover bytes as nop instructions as required.

Depending on your operating system version, the jump may be the other way around. You should still be able to create an unconditional jump to the code used for the regular Acrylic.

The modified assembly should resemble the following:

Updated assembly for CAccentAcrylicBlurBehind::UpdateAcrylicBlurBehind

After making these modifications, surfaces that apply Acrylic using Win32 APIs should now behave as expected. For example, the taskbar prior to 22621.1344 will now have a more visible blur effect, the same as you would see when using uDWM.dll from build 21390 on Windows 11 21H2.

22621.1 taskbar with original Acrylic effect enabled

Finished product

If you have followed this guide successfully to patch uDWM.dll manually, you should find that window borders and shadows should behave identically to how they do on Windows 10.

22621.1 desktop, taskbar, and windows with all patches applied

An interesting side-effect of these changes is that extended Mica backdrop interface areas (such as those seen in modern Task Manager and File Explorer) will be treated like classic extended DWM frames, meaning that they will render the background from your visual style. This makes for interesting results.

22631.4830 File Explorer with a Windows Vista visual style

22631.4830 Task Manager with a Windows Vista visual style

Moreover, the only real issue that I've encountered here is that certain dialogs that apply some of the hacky newer attributes end up with an extra window bar on the top frame. This shouldn't affect your ability to use them, though.

OpenWith dialog on 22631.4830 showing the additional window bar

FAQ

Do I have to do these manual patches? I've never used disassembler tools before!

No. These are provided by way of documentation and for more technically-advanced users to study. I would strongly recommend using the pre-made files that have been shared in the WinClassic thread.

Why doesn't this include patches for achieving better Windows 7/8.1 styles?

This is not the goal of this guide: all this seeks to do is restore the Windows 10-era behaviour, which in itself drastically widens the scope for other modifications such as those which you desire. What you seek lies right infront of you.

Why not enable high-contrast mode globally, like the earlier methods?

Because doing so is a shit-quality hack that causes many other rendering issues. Whilst I don't really want to go through them individually, to put it simply, it is referenced in many other functions, and enabling it changes a series of other behaviours (i.e. window snapping) for the worse.

Will these changes on their own restore compatibility with modification tools like OpenGlass and Aero Window Manager?

No. What we're doing here is simply restoring the behaviour for borders, shadows, and Acrylic to how it was previously. The reason this doesn't restore compatibility for these tools is because the functions and byte offsets that they are looking for are still different compared to what they are on Windows 10.

Therefore, for such tools, it is the responsibility of their developers to add Windows 11 compatibility.

Notes

If you've made it this far down and everything's worked, well done. Quite honestly, only a few days ago I believed that a good portion of what has been achieved was impossible. Funny the things you find, when code inlining behaviour varies between releases.

Ultimately, I will attempt to update this as and when new major Windows releases come through, but I cannot promise that these changes will ever be immediate as I do have other priorities.

Hopefully you've learned something from implementing these fixes.

~Ittr

Edit
Pub: 20 Feb 2025 14:17 UTC
Edit: 20 Feb 2025 23:18 UTC