Changing Start Button to match Windows 11 logo

[krlvm]

Hello again,

I think that the current Start Button, which remains unchanged since Windows 10, looks out of place, so I've developed a very little application which replaces it - it is based on the fact that Start Button icon is stored in TaskbarPearl section of Win32 styles and behave exactly like Windows 10 Start Button behaved (e.g. it has accent color on hover, changes its color to dark when changing taskbar theme to light). The program works like StartAllBack "Colorize everything with accent color" option - it gets theme bitmap handle and modifies the bitmap, so it does not need to patch the msstyles file.

I've also found a program which replaces Start Button via hooking uxstyles API, but I think it's out of scope of the project.

It needs Explorer to be restarted after executing or to be executed before Explorer is started, so i think it would fit ExplorerPatcher since it injects into Explorer process and I think it can execute some code before taskbar is loaded. Can you incorporate it?

UPD: a pre-built binary for those interested, execute it at your own risk: StartButtonReplacement.zip

[valinet]

Hi

That's great, a lot of people also asked about this recently, so the timing is great. Thanks for the contribution and for letting me know about it.
I tried the code that you provided, and while it generally worked, we still have to iron some things out. There are 2 things that I think need to be taken care of:

• Only running it at startup means that it modifies the bitmap only for the DPI that was used at startup. If the user changes the DPI of the monitor, the Windows 10 orb will show. This scenario is not that uncommon - laptop computers are sometimes docked at a desk and undocked and taken on the go.
• Also, while this worked fine at 96 and 120 (100% and 125%) DPI, the Windows 10 orb is still shown at 144 (150%) DPI. I don't know why, it seems that explorer.exe gets some different bitmap, or it gets it from somewhere else etc.
• Also, what I haven't tested but I guess could be problematic with the current approach is having multiple taskbars on displays with different DPIs.

I also checked the project that you linked to, although indeed more complicated, it also provides a more complete implementation which gets around the issues I mentioned.

The first point above could be solved by monitoring for WM_DPICHANGED on some window, but that is racy. So, as done by WinLogo, we could instead modify the bitmap when explorer.exe calls OpenThemeDataForDpi. I already have hooks in place for that when using the advanced classic theme mitigations, it wouldn't be hard at all to extend those for this scenario as well.

Second point is more complicated. I mean, if this approach does not work, what's left is to see how explorer.exe actually paints the Start button: the class is called CPearl, the method is CPearl::_OnPaintInternal. At the end of the decompilation, there's an if check that decides whether to draw a "colorized" image (image when holding the mouse over the button, or when clicked), or a regular image. I have already done the regular image using StretchDIBits (although I also have to modify it a bit still to provide support for light theme), although the more complicated is the blended version... it would be really awesome if we found a way to make the bitmap method work, since it bypasses the need to reimplement these ourselves, with the drawback being that the bitmap is modified for the whole theme, so whoever else asks for that bitmap will receive our modified one.

Third point is solved by design with manual drawing, while even with bitmap is solved by only hooking OpenThemeDataForDpi, since there we can retrieve the DPI adjusted bitmap and edit that.

Also, another question, what thickness should be the "separator" between the logo tiles after all? In your code, it was 2px, while the Windows 10 logo uses 1px. Idk, I kind of like Windows 10 version, but I am wondering, is it officially 1 or 2...?

Thanks

[plofhaan]

Stay out of trouble, the Windows logo is protected by law...

[krlvm]

The Windows logo is blue or dark blue, and secondly, hardly anyone will dig into a non-commercial program that, moreover, does not contain the Windows logo - this code draws the logo at runtime.

[valinet]

Exactly.

[krlvm]

Thanks for the response.

The DPI problem seems solveable, we can call OpenThemeDataForDpi with multiple DPI values each time, I don't know is it a good solution though. I've also noticed this code works only for first two bitmaps of seven - this looks like a cause of the second problem.
EDIT: for bitmap index > 2 I get a bitmap with width and height equal to -858993460 and 52428 bits per pixel - obviously, there's no bitmap with that index I think, also tried on 150% and 200% scaling (I'm on 125%).
EDIT2: it's indeed depends on DPI you passed in OpenThemeDataForDpi. I've also noticed that GetDpiForWindow(HWND_DESKTOP) is always 0 because HWND_DESKTOP is 0.

EDIT3: source

The behavior of the returned theme handle will be undermined if the requested DPI value does not correspond to a currently connected display. The theming system only loads theme assets for the set of DPI values corresponding to the currently connected displays.

EDIT4: I've figured out, by passing 2 as PartID, I get bitmap of TABLETMODEPEARLICON, not PEARLICON, that's why it doesn't work with i > 2.
EDIT5: Start Button actually uses the one with PartID 2 (TABLETMODEPEARLICON)

I'd prefer modifying theme data as it is a more "cold" solution, while the one with hooks keeps a DLL in memory.

I picked 2 as separator value to get four equal rectangles: the sizes of bitmaps are 16x16, 20x20, 24x24, 32x32, 40x40, 48x48 and 64x64 - e.g. after dividing the width or height of the 48x48 one by 2 we'll get four 24x24 rectangles, to make they equal I subtracted 1 from each resulting rectangle, but may be I need to increase separator size for larger sizes.

[valinet]

Yeah, regarding EDIT4, me as well, but is it doable for all DPIs, that’s the problem… Indeed, you can confirm from the disassembly that the icon for Start used by explorer has either part id 1 or 2.

EDIT2, yeah, 0 is not a valid handle for GetDpiForWindow, there is a warning in the compiler as well regarding that. Anyway, one can provide some other HWND, like the one of Shell_TrayWnd.

EP is anyway resident in memory… for me, it’s not such a big deal. The problem is, even if I do what you mentioned in the code at each OpenThemeDataForDpi call that explorer issues for TaskbarPearl, when I get to 150%, it doesn’t work anymore, like, the changed bitmap is not the one that’s displayed… so yeah, idk, again, if that’s solvable somehow, I’d also prefer that, if not, I will have to manually draw probably which I do not like at all. Editing the bitmap is advantageous because then explorer uses that and does whatever it wants to do with it when it blends it with the accent color. Replicating that in my code is a whole endeavor.

I understood from the get go why you picked 2, as yeah, you divide an even number by 2, you get to equal halfs, to keep the symmetry, you take 1px from each. What I was more interested was visually, should we do it like this though? For the original Windows 10 button, explorer seems to take out only a 1px line, weirdly enough it seems to be constant with the DPI, so… should we do it like that as well, like take 1px out at the end of each section, instead of where they intersect…? The question is more, isn’t a 1px line over the middle preferable than a 2px one? Visually I mean. The implementation does not matter, it’s doable either way.

[valinet]

The primary advantage to modifying the theme bitmap is that then you keep benefiting from explorer doing the heavy lifting of performing the graphics operations on that, imo.

[krlvm]

Looks more like a bug in OpenThemeDataForDpi, but I'm not sure, GetThemeBitmap of theme handle obtained from OpenThemeDataForDpi always returns the first bitmap, which is suitable for 96 DPI.

This also sheds light on another problem - I was developing a replacement for SAB accent colorization feature, and my implementation didn't work with checkboxes - now I see their bitmaps are also DPI-aware, that's why it worked only on 100% scale, but SAB implementation is getting DPI-aware bitmaps somehow, even though it generally uses OpenThemeData instead of OpenThemeDataForDpi.

So, this information packs the three issues you've found into one - we just need to find a problem, because of which GetThemeBitmap always returns the first, DPI-unaware bitmap.

Taking 1px from each rectangle sounds like a good idea, the second bitmap of TABLETMODEPEARLICON is 25x25 though - it is not even, so we can just erase the 13th row. Also needs to be mentioned that Windows 10 logo is not symmetric.

[Mervinj82]

I've really been looking forward to this one but it doesnt work on my pc for some reason. I have the latest version of ExplorerPatcher also. I have 7+ Taskbar Tweaker and Taskbar X installed. Could one of these be the reason why it doesn't work. Thanks.

[knut32]

Hello.

I tested your binary, but nothing happen :( Can you explane how it works? Give us a tutorial please...

[vippium]

Just select the start style or orb in EP setup Taskbar option... Only available for win10 taskbar

[knut32]

Sorry I don't find the option

At start button style i only can chooce between win11 and win10 style.

[vippium]

Check in SS, there is a btn named start button style... Change it to win11

[knut32]

Do you mean this one:

But where can i change the button, example to this:

[vippium]

this can't be....if you want to do this, you have to use StartAllBack by uninstalling EP. As EP doesn't have this feature currently

[plofhaan]

But where can i change the button,

Here is a solution: https://github.com/Open-Shell/Open-Shell-Menu
The option to choose what pressing the Win key opens (on the Controls tab of the Start Menu Settings window) stopped working for the latest stable release (4.4.170) on Win 11 for me (I haven't checked on Win 10), but I grabbed the latest Pre-release build which fixed the problem for me. Here is the button I made with Gimp,