Dulappy
Freshman Member
Posts: 30
OS: Windows 10
Theme: Custom
CPU: Ryzen 5 2600
RAM: 16GB DDR4 3200MHz
GPU: GeForce GTX 1650 SUPER
|
Post by Dulappy on Jan 5, 2023 16:39:02 GMT -8
I've wanted to customize Windows 10 to look like Windows 7 for a while now, and one of the biggest obstacles are the massive close, minimize and maximize buttons at the top right of every window (see attachment below). As far as I'm aware, there is no publicly available tool that can change the size of these buttons natively (unless we're talking about changing the size of the titlebar, which does not solve my issue) nor could I find any information about it online, so that's why I'm asking here if anybody knows how exactly DWM handles the size of these buttons. IIRC, in Windows 7 the size was stored in a RAM address, which allowed tools like this to exist, but that doesn't seem to be the case from Windows 8 onwards. Windows 10 Buttons:  Windows 7 Buttons:  |
|
|
|
Post by OrthodoxWin32 on Jan 6, 2023 2:08:19 GMT -8
I've wanted to customize Windows 10 to look like Windows 7 for a while now, and one of the biggest obstacles are the massive close, minimize and maximize buttons at the top right of every window (see attachment below). As far as I'm aware, there is no publicly available tool that can change the size of these buttons natively (unless we're talking about changing the size of the titlebar, which does not solve my issue) nor could I find any information about it online, so that's why I'm asking here if anybody knows how exactly DWM handles the size of these buttons. IIRC, in Windows 7 the size was stored in a RAM address, which allowed tools like this to exist, but that doesn't seem to be the case from Windows 8 onwards. Windows 10 Buttons: Windows 7 Buttons: Hello Dulappy, and welcome to the WinClassic forum! I don't know much about how DWM works, but I've read many times that DWM is poorly documented, which makes it difficult for developers to interact with it. There are a few successful hanging projects (like MicaForEveyrone, WinCenterTitle or LeftSider), which prove that it is possible, but obviously difficult. It may be good to ask the developers of the corresponding project. |
|
|
|
Post by anixx on Jan 6, 2023 18:02:41 GMT -8
The buttons are not drawn by DWM: one can enable and disable DWM without the theme changed. The buttons of visual styles are drawn by theming engine, the buttons of Windows Classic theme are drawn by GDI.
|
|
Dulappy
Freshman Member
Posts: 30
OS: Windows 10
Theme: Custom
CPU: Ryzen 5 2600
RAM: 16GB DDR4 3200MHz
GPU: GeForce GTX 1650 SUPER
|
Post by Dulappy on Jan 9, 2023 10:23:11 GMT -8
The buttons are not drawn by DWM: one can enable and disable DWM without the theme changed. The buttons of visual styles are drawn by theming engine, the buttons of Windows Classic theme are drawn by GDI. I know that themes are separate from DWM, but doesn't DWM handle drawing the entirety of the non-client area when it's on? I thought that every element listed in the DWMWindow class in .msstyles files was drawn by DWM. Either way, if DWM is not the one responsible for drawing buttons, what needs to be modified in order to change the size of the caption buttons? |
|
|
|
Post by leet on Jan 9, 2023 13:21:01 GMT -8
Dulappy It's weird. Contrary to what anixx says: DWM does draw the non client area. It is the theming engine. DWM makes sure GDI has separate buffers for all windows and it composites them in a way where stuff like transparency is supported. DirectX is used internally here for better hardware acceleration, not GDI. The sad thing is that DWM is completely undocumented, like OrthodoxWin32 said. Windows 8+ can actually draw hardware-accelerated themes without any real hardware acceleration. This is due to the DirectX version used (10.1) having support for WARP. EDIT: This is incorrect, rather Microsoft Basic Display adapter can pretend to be a WDDM-compliant adapter, using software rasterizing in the background. Without DWM, all Windows are drawn to the same buffer, with Z-order in mind. So the back windows are drawn first, and the top windows are just drawn on top of it. This is the only instance where GDI can draw window frames, although it can only draw non-accelerated themes like Basic and Classic. Those drawing routines are exposed through functions like DrawFrameControl and some other internal functions. However, because Windows is Windows, some things lie in ancient old functions that no one at Microsoft dares to touch. Window metrics are one of those ancient quirks. They are stored in the same settings that GDI uses for rendering its window frames when DWM is off. The values are stored in HKEY_CURRENT_USER\Control Panel\Desktop\Window Metrics
The values you are looking for are CaptionWidth and CaptionHeight. The stored value is multiplied by 15 and negated, so 22 becomes -(22*15) = -330 (the default value). Note that you should also change the CaptionFont to be sized to the CaptionHeight. Otherwise all icons will appear small. The nice thing about this approach is that it will work for both DWM and non-DWM windows, although non-DWM windows almost don't exist anymore. Changing the values to 11 (-165 in registry) gives this:  EDIT: I should probably add, the CaptionFont registry is stored as a LOGFONTW structure. Docs on that can be found here: learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-logfontw
|
|
Dulappy
Freshman Member
Posts: 30
OS: Windows 10
Theme: Custom
CPU: Ryzen 5 2600
RAM: 16GB DDR4 3200MHz
GPU: GeForce GTX 1650 SUPER
|
Post by Dulappy on Jan 10, 2023 13:16:52 GMT -8
Dulappy It's weird. Contrary to what anixx says: DWM does draw the non client area. It is the theming engine. DWM makes sure GDI has separate buffers for all windows and it composites them in a way where stuff like transparency is supported. DirectX is used internally here for better hardware acceleration, not GDI. The sad thing is that DWM is completely undocumented, like OrthodoxWin32 said. Windows 8+ can actually draw hardware-accelerated themes without any real hardware acceleration. This is due to the DirectX version used (10.1) having support for WARP. EDIT: This is incorrect, rather Microsoft Basic Display adapter can pretend to be a WDDM-compliant adapter, using software rasterizing in the background. Without DWM, all Windows are drawn to the same buffer, with Z-order in mind. So the back windows are drawn first, and the top windows are just drawn on top of it. This is the only instance where GDI can draw window frames, although it can only draw non-accelerated themes like Basic and Classic. Those drawing routines are exposed through functions like DrawFrameControl and some other internal functions. However, because Windows is Windows, some things lie in ancient old functions that no one at Microsoft dares to touch. Window metrics are one of those ancient quirks. They are stored in the same settings that GDI uses for rendering its window frames when DWM is off. The values are stored in HKEY_CURRENT_USER\Control Panel\Desktop\Window Metrics
The values you are looking for are CaptionWidth and CaptionHeight. The stored value is multiplied by 15 and negated, so 22 becomes -(22*15) = -330 (the default value). Note that you should also change the CaptionFont to be sized to the CaptionHeight. Otherwise all icons will appear small. The nice thing about this approach is that it will work for both DWM and non-DWM windows, although non-DWM windows almost don't exist anymore. Changing the values to 11 (-165 in registry) gives this: EDIT: I should probably add, the CaptionFont registry is stored as a LOGFONTW structure. Docs on that can be found here: learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-logfontw While that is a solution to the massive tablet-optimized caption buttons that Microsoft decided would be a good idea to implement, it still isn't exactly what I'm looking for (plus it makes the window sizing all wonky). See, Windows 7 had a completely different scaling algorithm for the buttons, where they would always be almost the same height as the titlebar metric (unlike Windows 10/11 where they are equal to titlebar + border size), and the X button would be larger than the other two in width. I'm looking to somehow replicate that Windows 7 behavior on Windows 10, not only shrink the buttons down, I just have no idea where to look. Windows 7 behavior for reference:   |
|
Dulappy
Freshman Member
Posts: 30
OS: Windows 10
Theme: Custom
CPU: Ryzen 5 2600
RAM: 16GB DDR4 3200MHz
GPU: GeForce GTX 1650 SUPER
|
Post by Dulappy on Jun 4, 2023 8:42:21 GMT -8
About 5 days ago, I started looking into uDWM.dll's code, checking the functions that seem to do something related to the caption buttons. Since then, I have made useful discoveries about the titlebar and how its elements are rendered (mainly how their position and sizes are calculated). The caption buttons are definitely the most difficult part of all to figure out, mainly because their width (and sometimes their height apparently?) is calculated using xmm registers, something which I don't have a clear understanding of.
Either way, I'd like to share some screenshots of what my testing VM looks like at the moment (altered metrics to better display the rendering process):
I won't try to get an accurate result by just patching the bytecode, that would be too much effort. I'm planning on learning C in the following months, so maybe then I can try to write a program to hook uDWM.dll (something like WinCenterTitle and AeroGlass). If anyone's interested, I can provide a more in-depth explanation of what I've edited and what I got out of editing specific things, as well as deobfuscating whichever parts of code I managed to understand.
I hope this will be useful information to the community.
|
|
aubymori
Sophomore Member
👅👅👅👅👅
Posts: 160 
OS: Windows 10 IoT Enterprise LTSC 2021
Theme: Windows 10 Default
CPU: Intel Core i5-9300H
RAM: 8GB
GPU: Intel UHD Graphics 630 / NVIDIA GeForce GTX 1650
|
Post by aubymori on Jun 4, 2023 10:16:10 GMT -8
About 5 days ago, I started looking into uDWM.dll's code, checking the functions that seem to do something related to the caption buttons. Since then, I have made useful discoveries about the titlebar and how its elements are rendered (mainly how their position and sizes are calculated). The caption buttons are definitely the most difficult part of all to figure out, mainly because their width (and sometimes their height apparently?) is calculated using xmm registers, something which I don't have a clear understanding of.
Either way, I'd like to share some screenshots of what my testing VM looks like at the moment (altered metrics to better display the rendering process):
I won't try to get an accurate result by just patching the bytecode, that would be too much effort. I'm planning on learning C in the following months, so maybe then I can try to write a program to hook uDWM.dll (something like WinCenterTitle and AeroGlass). If anyone's interested, I can provide a more in-depth explanation of what I've edited and what I got out of editing specific things, as well as deobfuscating whichever parts of code I managed to understand.
I hope this will be useful information to the community.
Hello. You should check out x64dbg. With it, you can download the symbols of uDWM.dll directly from Microsoft. This exposes the names and addresses of functions. This helped my to patch Windows 7's explorer.exe to remove the glow effect (I was making a Windows Vista transformation). The function was called CTaskBtnGroup::_DrawHotTrackingLight, and the symbols exposed that! Also check out Windhawk, it makes it very easy to patch functions (although I think you need to enable an option to let it patch DWM, I'm not sure). Anyways, best of luck to you on this endeavor! |
|
aubymori
Sophomore Member
👅👅👅👅👅
Posts: 160
OS: Windows 10 IoT Enterprise LTSC 2021
Theme: Windows 10 Default
CPU: Intel Core i5-9300H
RAM: 8GB
GPU: Intel UHD Graphics 630 / NVIDIA GeForce GTX 1650
|
Post by aubymori on Jun 4, 2023 10:24:19 GMT -8
Also: I recommend hooking into the dwm.exe process rather than individual applications; anti-cheat HATES games being hooked into.
|
|
Ittr
Freshman Member
👅👅👅👅👅
Posts: 49
OS: Windows 10
Theme: 👅
CPU: Intel Core i3-1005G1
RAM: 8GB
GPU: 👅
Computer Make/Model: 👅
|
Post by Ittr on Jun 4, 2023 10:29:19 GMT -8
About 5 days ago, I started looking into uDWM.dll's code, checking the functions that seem to do something related to the caption buttons. Since then, I have made useful discoveries about the titlebar and how its elements are rendered (mainly how their position and sizes are calculated). The caption buttons are definitely the most difficult part of all to figure out, mainly because their width (and sometimes their height apparently?) is calculated using xmm registers, something which I don't have a clear understanding of.
Either way, I'd like to share some screenshots of what my testing VM looks like at the moment (altered metrics to better display the rendering process):
I won't try to get an accurate result by just patching the bytecode, that would be too much effort. I'm planning on learning C in the following months, so maybe then I can try to write a program to hook uDWM.dll (something like WinCenterTitle and AeroGlass). If anyone's interested, I can provide a more in-depth explanation of what I've edited and what I got out of editing specific things, as well as deobfuscating whichever parts of code I managed to understand.
I hope this will be useful information to the community.
Might be interesting to hear more on what you did with the editing - obviously this isn't a permanent way but mainly because I'd be interested in seeing how possible it would be to write a version that hardcodes the Windows 7 caption sizes before trying to reimplement the behaviour in a more robust way (e.g. by patching the program dynamically using Windhawk). |
|
Dulappy
Freshman Member
Posts: 30
OS: Windows 10
Theme: Custom
CPU: Ryzen 5 2600
RAM: 16GB DDR4 3200MHz
GPU: GeForce GTX 1650 SUPER
|
Post by Dulappy on Jun 4, 2023 11:02:41 GMT -8
Hello. You should check out x64dbg. With it, you can download the symbols of uDWM.dll directly from Microsoft. This exposes the names and addresses of functions. This helped my to patch Windows 7's explorer.exe to remove the glow effect (I was making a Windows Vista transformation). The function was called CTaskBtnGroup::_DrawHotTrackingLight, and the symbols exposed that! Also check out Windhawk, it makes it very easy to patch functions (although I think you need to enable an option to let it patch DWM, I'm not sure). Anyways, best of luck to you on this endeavor! The IDA disassembler already automatically tries to download/find the symbols (and succeeds with Windows files) for any program that has a .pdb file linked, so I already had the symbols for the function names for both Windows 10's and Windows 7's uDWM.dll. Thanks for recommending Windhawk, I actually use it to tweak a couple of things in my OS, but I'd never thought to use it for this. My speculation for DWM hooking potentially being a separate option in Windhawk is because according to Valinet, DWM runs under the SYSTEM account, therefore whatever's patching it also needs to run under SYSTEM (Which is why you need a special setup to run WinCenterTitle). Might be interesting to hear more on what you did with the editing - obviously this isn't a permanent way but mainly because I'd be interested in seeing how possible it would be to write a version that hardcodes the Windows 7 caption sizes before trying to reimplement the behaviour in a more robust way (e.g. by patching the program dynamically using Windhawk). I'll post some screenshots where I've commented some parts of the code once I finish studying (yes I'm doing this during finals), but the editing part is more about principle than anything. Obviously it's not permanent, but if someone wants to continue where I left off, the resources will be here, and they'll know where to look. Now for the hardcoding, that actually seems incredibly easy if you're just doing it for a single titlebar height (eg. W7's default 21 pixels). All you really have to do is subtract/add the difference between 10's and 7's button width. I might even have a go at it later tonight. One issue I've noticed is that the buttons are 1 pixel too far to the left, but that also seems like an easy fix, I'll try to figure that out later too. Actually, here's a fun fact about the code that sets the buttons' width and height: There are two 7 byte long instructions that are completely useless, which means that by removing them, you can free up 14 bytes for whichever instructions you may need (ie. subtraction) for each button. I'll include that in the screenshots later tonight.
|
|
|
|
Post by OrthodoxWin32 on Jun 4, 2023 11:56:45 GMT -8
By the way, it's not just about Windows 7's DWM. It's also the case in Windows Vista, 8 and 8.1 (the differences between the Aerolite style of Windows 8 and Windows 10 are interesting, because it's the same style, except for the title bars).
Good luck with your project in any case, it would be great if you succeed.
|
|
Dulappy
Freshman Member
Posts: 30
OS: Windows 10
Theme: Custom
CPU: Ryzen 5 2600
RAM: 16GB DDR4 3200MHz
GPU: GeForce GTX 1650 SUPER
|
Post by Dulappy on Jun 4, 2023 13:43:59 GMT -8
As promised, I have hacked in the Windows 7 caption buttons for a titlebar height of 21:
One thing I've noticed is that inactive windows seem to have faded caption buttons. I'm not sure if that behavior is caused by DWM or msstyles to be frankly honest, though I'm leaning towards DWM. Anyway, here's some more screenshots using the default theme and the Aero Lite theme:
Now, onto explaining some stuff about the modifications that I've made. Firstly, let's go over the simplest modification, aligning the icon and text with the very start of the titlebar. In Windows 10, due to the removal of the window border, DWM takes the size of the border, doubles it, and uses that as the margin when a window isn't maximized, as opposed to just using the border width itself. When it is maximized, it just takes the size and adds 2 to it. Here's the code that handles that: All I did in this case was remove the "add r14d, r14d" instruction, which made everything function like it did in earlier versions of Windows.
Now, onto how the height of the caption buttons is calculated. Again, this is quite simple; DWM takes the border's size, and moves it into a register, then adds the height of the titlebar to that, meaning that the buttons will take up the full combined height of the titlebar. Here's the code: In order to make the buttons only take into account the titlebar's height, all that really needs to be done is to remove the border width from the equation. The simplest solution for that would be to change the "add edi, eax" instruction to "mov edi, eax". Bonus points if we also remove the instruction above, but since we're overwriting edi anyway, that's not necessary.
To conclude this brief explanation, let's go over the redundant instructions I mentioned in a previous post: (Notes: eax is the lower 32 bits of rax, right operand is the source, left operand is the destination) As you can see, in the topmost block, eax is moved into the button's width variable, then eax is overwritten inside the function that's called right after, which is fine since it doesn't need to have the width value anymore. In the last block however, the width value is placed back into eax, which would be fine if we needed to use it, but that is not the case. Instead, for whatever reason, it's moved back from eax into the width variable, which already contained the exact same value as eax, and then rax is overwritten, rendering the last two green instructions completely pointless. I'm curious to see what the original C source code looks like.
That's it for this brief showcase and explanation. I'll go over more things over the coming weeks as I discover more about DWM and especially the caption buttons, and hopefully start working on a program/Windhawk mod which properly configures the button sizes by hooking DWM instead of cold patching it (mainly for Windows Update resilience).
For anyone that wants to take a look on their own, everything I've done so far was by modifying just two functions, CTopLevelWindow::UpdateNCAreaPositionsAndSizes(CTopLevelWindow *__hidden this), and CTopLevelWindow::UpdateNCAreaButton(CTopLevelWindow::ButtonType,int,int,int *). Fun fact about the second function, in Windows 7 it was used to create/update every caption button, but in Windows 10 the minimize and restore-maximize buttons have been moved to the former, with only the X button remaining in the latter.
|
|
|
|
Post by Taniko Yamamoto on Jun 4, 2023 14:05:48 GMT -8
I second using Windhawk. It has a protection on by default, you need to go into the advanced settings and allow it to inject into system processes, but it will inject into DWM.exe just fine. Be careful with this though, as if you create a DWM reboot loop, you will need to use another OS to delete the compiled DLL every time.
This is incredibly good work and I hope you continue with this project. Aside from Valinet, I know some other people who have looked into reverse engineering DWM before. I myself have, although I am nowhere near as good as you at this point. I thought that the metrics would have been stored in the static data segment for starters, but I never got around to making a VM to experiment directly.
By the way, did you know about the TopLevelWindow3D animation? It can be controlled by msstyles directly, although no editor is public that supports this at the moment. This person on Twitter claims that their WIP software can change it, though:
|
|
aubymori
Sophomore Member
👅👅👅👅👅
Posts: 160
OS: Windows 10 IoT Enterprise LTSC 2021
Theme: Windows 10 Default
CPU: Intel Core i5-9300H
RAM: 8GB
GPU: Intel UHD Graphics 630 / NVIDIA GeForce GTX 1650
|
Post by aubymori on Jun 4, 2023 14:12:35 GMT -8
As promised, I have hacked in the Windows 7 caption buttons for a titlebar height of 21:
One thing I've noticed is that inactive windows seem to have faded caption buttons. I'm not sure if that behavior is caused by DWM or msstyles to be frankly honest, though I'm leaning towards DWM. Anyway, here's some more screenshots using the default theme and the Aero Lite theme:
Now, onto explaining some stuff about the modifications that I've made. Firstly, let's go over the simplest modification, aligning the icon and text with the very start of the titlebar. In Windows 10, due to the removal of the window border, DWM takes the size of the border, doubles it, and uses that as the margin when a window isn't maximized, as opposed to just using the border width itself. When it is maximized, it just takes the size and adds 2 to it. Here's the code that handles that: All I did in this case was remove the "add r14d, r14d" instruction, which made everything function like it did in earlier versions of Windows.
Now, onto how the height of the caption buttons is calculated. Again, this is quite simple; DWM takes the border's size, and moves it into a register, then adds the height of the titlebar to that, meaning that the buttons will take up the full combined height of the titlebar. Here's the code: In order to make the buttons only take into account the titlebar's height, all that really needs to be done is to remove the border width from the equation. The simplest solution for that would be to change the "add edi, eax" instruction to "mov edi, eax". Bonus points if we also remove the instruction above, but since we're overwriting edi anyway, that's not necessary.
To conclude this brief explanation, let's go over the redundant instructions I mentioned in a previous post: (Notes: eax is the lower 32 bits of rax, right operand is the source, left operand is the destination) As you can see, in the topmost block, eax is moved into the button's width variable, then eax is overwritten inside the function that's called right after, which is fine since it doesn't need to have the width value anymore. In the last block however, the width value is placed back into eax, which would be fine if we needed to use it, but that is not the case. Instead, for whatever reason, it's moved back from eax into the width variable, which already contained the exact same value as eax, and then rax is overwritten, rendering the last two green instructions completely pointless. I'm curious to see what the original C source code looks like.
That's it for this brief showcase and explanation. I'll go over more things over the coming weeks as I discover more about DWM and especially the caption buttons, and hopefully start working on a program/Windhawk mod which properly configures the button sizes by hooking DWM instead of cold patching it (mainly for Windows Update resilience).
For anyone that wants to take a look on their own, everything I've done so far was by modifying just two functions, CTopLevelWindow::UpdateNCAreaPositionsAndSizes(CTopLevelWindow *__hidden this), and CTopLevelWindow::UpdateNCAreaButton(CTopLevelWindow::ButtonType,int,int,int *). Fun fact about the second function, in Windows 7 it was used to create/update every caption button, but in Windows 10 the minimize and restore-maximize buttons have been moved to the former, with only the X button remaining in the latter.
Bravo. I think something else to work on would be the way the caption buttons glow when you hover over them in Vista/7. This effect is gone as far back as 8.0, so it'd be amazing to see it come back without Windowblinds. |
|
Souper
Freshman Member
Posts: 63
OS: Manjaro | Windows 10 (2021)
Theme: Placeholder | Aero / Luna
|
Post by Souper on Jun 4, 2023 14:44:08 GMT -8
Think you could also restore the color/glass intensity calculation stuff regarding DWM titlebars? I think that got removed at some point during 10's lifespan.
Opening up the legacy Color and Appearance Control Panel page has the slider for that.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jun 4, 2023 14:51:43 GMT -8
Would visual styles need any modification to work with any future mods that change the caption buttons?
|
|
Dulappy
Freshman Member
Posts: 30
OS: Windows 10
Theme: Custom
CPU: Ryzen 5 2600
RAM: 16GB DDR4 3200MHz
GPU: GeForce GTX 1650 SUPER
|
Post by Dulappy on Jun 4, 2023 15:15:10 GMT -8
I second using Windhawk. It has a protection on by default, you need to go into the advanced settings and allow it to inject into system processes, but it will inject into DWM.exe just fine. Be careful with this though, as if you create a DWM reboot loop, you will need to use another OS to delete the compiled DLL every time. This is incredibly good work and I hope you continue with this project. Aside from Valinet, I know some other people who have looked into reverse engineering DWM before. I myself have, although I am nowhere near as good as you at this point. I thought that the metrics would have been stored in the static data segment for starters, but I never got around to making a VM to experiment directly. By the way, did you know about the TopLevelWindow3D animation? It can be controlled by msstyles directly, although no editor is public that supports this at the moment. This person on Twitter claims that their WIP software can change it, though: I'm not very good at reverse engineering. I barely even know what most of the code I look at does, especially those xmm registers. I'll try making a Windhawk mod and figuring out how I can properly calculate the button sizes, without having to resort to offsetting the calculated Windows 10 values. I believe that if we had a proper community, even one with less than ten people, focused on reverse engineering DWM on their spare time, we would already have near perfect Windows Vista/7/8 themes for Windows 10/11. Also, that animation editor would be an amazing thing to have. Actually, that entire project would change theming for the better, but sadly it doesn't seem like it's getting released any time soon. Bravo. I think something else to work on would be the way the caption buttons glow when you hover over them in Vista/7. This effect is gone as far back as 8.0, so it'd be amazing to see it come back without Windowblinds. I'll definitely look into that at some point, but assuming there's no dormant code to handle that leftover in modern DWM, that would be a massive task to undertake, especially for someone as inexperienced as me. Plus, the parts for the glow have been removed from the msstyles file, at least the default one, so without a proper way to build one from scratch (I'm not sure if it would even be possible then) I don't think it's very possible. Then again, there's a chance that it's the easiest thing ever and I just don't know how to do it.
Think you could also restore the color/glass intensity calculation stuff regarding DWM titlebars? I think that got removed at some point during 10's lifespan. Opening up the legacy Color and Appearance Control Panel page has the slider for that. Considering similar things have been done in the past (glass8, WinCenterTitle glass branch on github), it may be possible, but don't expect anything any time soon. Would visual styles need any modification to work with any future mods that change the caption buttons? Most likely, no. It's a very small tweak, so I doubt they would need any modification. The only thing this would do is make styles designed with Windows 10's buttons in mind to look kinda wonky, if they're stylized enough. |
|
Windows 10-7
Sophomore Member
Posts: 233 
OS: Windows 11 22H2
Theme: Aero7 - WindowsBlinds 11
RAM: 16gbs
|
Post by Windows 10-7 on Jun 4, 2023 15:27:12 GMT -8
Well definitely consider joining the windhawk discord server, sure there could be some helping hands (assuming you aren't already in it lol)
|
|
Alcatel
Freshman Member
Posts: 89
OS: Windows 10 Enterprise LTSC IoT 2021
Theme: Windows 7 Aero
CPU: i9-8950HK
RAM: 32GB DDR4
GPU: Nvidia Quadro P3200
|
Post by Alcatel on Jun 5, 2023 8:11:14 GMT -8
May you make a version of this for 1809? Since it's supported until 2029 and supports Aero Glass by Big Muscle  |
|
