Added new features like Partial Toolbar support

[babamohammed2022]

Changelog

If this pull request updates an existing mod, describe the changes below:

• Window should now use native system colors
• Removed hard-coded color values
• Added toolbar warning message when enabling classic toolbars
• Fixed Window colors
• Patially implemented toolbars (Address and Links)
• Added taskbar rotation (only bottom and top)
• Code cleanup

Mod authorship

If this pull request introduces a new mod, please complete the section below.

This mod was created by:

• • The submitter, without AI assistance
• • The submitter, with AI assistance
• • Claude
• • ChatGPT
• • Gemini
• • Another AI (please specify): Deepseek
• • Other (please specify):

Please select the options that best apply. Your selection does not affect the acceptance criteria, but it helps reviewers understand the context of the code and provide relevant feedback.

[Anixx]

No change, neither with fonts, nor with colors.

[Anixx]

If you are using DeepSeek, we will debug this for a long time!

[babamohammed2022]

No change, neither with fonts, nor with colors.

While I understand your perspective, I cannot be 100% sure if the fix is correct or not as the mod looks (almost) correct on my setup.

Apart from this, I use Claude as main model and Deepseek as an alternative. If you know any better AI models that could help with fixing the issue (or if you want to help investigate the code even briefly) feel free to let me know.
The main issue is that I can't see if it's correct since you're using a classic theme and I currently don't have time to gather a specific environment with also a classic theme applied. If you know any AI/documentation/useful functions feel free to tell them and I will try to fix it

[Anixx]

I recommend to use the site arena.ai. There, choose claude-sonnet-4.6 or claude-sonnet-4.5. Once one ends, you can choose the other in the same conversation. They are about at the same level. If the usage of the both is exhausted, you can switch to claude-sonnet-4.5 thinking.

Consecutive use of these three models should take enough time for the first one (say, claude-sonnet-4.6) to reset (about an hour). If you are in hurry or the task is easy/mechanical (add needed headers, remove comments, etc), you can use other models as a fallback, but I do not recommend that:

• claude-haiku-4.5
• claude-sonnet-4
• claude-sonnet-4-thinking
• gpt-5.5-instant
• gemini-3.1-pro-preview

Do not ever use such crap as Deepseek or Gemini Flash. They will break even your working code where u did not ask to do any change.

[babamohammed2022]

I recommend to use the site arena.ai. There, choose claude-sonnet-4.6 or claude-sonnet-4.5. Once one ends, you can choose the other in the same conversation. They are about at the same level. If the usage of the both is exhausted, you can switch to claude-sonnet-4.5 thinking.

Consecutive use of these three models should take enough time for the first one (say, claude-sonnet-4.6) to reset (about an hour). If you are in hurry or the task is easy/mechanical (add needed headers, remove comments, etc), you can use other models as a fallback, but I do not recommend that:

* claude-haiku-4.5

* claude-sonnet-4

* claude-sonnet-4-thinking

* gpt-5.5-instant

* gemini-3.1-pro-preview

Do not ever use such crap as Deepseek or Gemini Flash. They will break even your working code where u did not ask to do any change.

OK thank you for informing me, I'll check them later. For now, I'll use Claude and post an attempt to address the issue then I will check soon

[babamohammed2022]

I recommend to use the site arena.ai. There, choose claude-sonnet-4.6 or claude-sonnet-4.5. Once one ends, you can choose the other in the same conversation. They are about at the same level. If the usage of the both is exhausted, you can switch to claude-sonnet-4.5 thinking.

Consecutive use of these three models should take enough time for the first one (say, claude-sonnet-4.6) to reset (about an hour). If you are in hurry or the task is easy/mechanical (add needed headers, remove comments, etc), you can use other models as a fallback, but I do not recommend that:

* claude-haiku-4.5

* claude-sonnet-4

* claude-sonnet-4-thinking

* gpt-5.5-instant

* gemini-3.1-pro-preview

Do not ever use such crap as Deepseek or Gemini Flash. They will break even your working code where u did not ask to do any change.

I've used Claude Sonnet 5 to address the issue and it seems to work better. If you still have the issue, please send a screenshot.
For reference, this is how it looks on my environment

[Anixx]

The color is fixed, but the font size is still not the one specified in the system.

For the reference:

[babamohammed2022]

the font size is still not the one specified in the system.

I understand what you mean. However, the issue is that many texts are hardcoded and changing the font size could accidentally cause some texts to be cut off

[babamohammed2022]

The color is fixed, but the font size is still not the one specified in the system.

For the reference:

I think that for semplicity it's better to keep the fonts as they are right now. Anyways, I've tried to implement toolbars (this is not finished yet and I'm continuing to improve it) including a re-implementation in the mod and currently the only working one is the Address one. If possible, try it and tell me if you find any issues (keep in mind that it's still work in progress but feedback is appreciated).

[Anixx]

The toolbars are accessible via the right-click menu:

[babamohammed2022]

The toolbars are accessible via the right-click menu:

This should be a standard Windows behavior, what I meant to ask is if this functions correctly (especially the first toolbar)

[babamohammed2022]

Major change to simplify the code

• Removed companion bars for complexity
• Removed the Windows 8.1 skin as it is largely reduntant and most of the settings were purely there for aeshetic reasons (the most known "Classic Taskbar Properties" is Windows 7 anyways)
• Added working "Links" toolbar
  The start menu settings could work, but since start menus are largely dependent on the user configuration I can't test them directly
  This is a screenshot of what doesn't work (the red circles mean that they do not work and I'm currently working on an implementation)

Unfortunately, I don't know if I will be able to implement the desktop toolbar as I've been trying to do so for the last 3 hours without major results (apart from an alternative approach that forced clicks on the taskbar context menu but it is not the right approach). If I find a solution I will post another update

[babamohammed2022]

@Anixx Hi, could you tell me if the Links and Address toolbars are functional? Furthermore regarding the Desktop toolbar, as I mentioned, I've been stuck on the implementation for hours. Given your knowledge of the classic Windows environment, do you have any technical documentation, references or even just a hint on how the desktop toolbar is properly instantiated or what interfaces it relies on? Any suggestion would be helpful to add this functionality

[Anixx]

I do not see why this function would be needed. One can manage the toolbars from the right-click menu, plus it allows to add any custom toolbar.

[babamohammed2022]

I do not see why this function would be needed. One can manage the toolbars from the right-click menu, plus it allows to add any custom toolbar.

Alright then, the Desktop toolbar is out of scope as suggested. The only remaining feature that isn't working yet is the taskbar rotation (that is, docking it to the top, bottom, left, or right of the screen). Do you have any documentation or suggestions on how to implement it correctly?

[babamohammed2022]

I do not see why this function would be needed. One can manage the toolbars from the right-click menu, plus it allows to add any custom toolbar.

I've added taskbar rotation at bottom and top, could you tell me if it works for you? Thank you if you do

[Anixx]

With the new version, the taskbar properties open Settings app. Plus, Explorer crashed soon.

[babamohammed2022]

With the new version, the taskbar properties open Settings app. Plus, Explorer crashed soon.

OK, thanks for telling me. I will try to fix these issues

[babamohammed2022]

With the new version, the taskbar properties open Settings app. Plus, Explorer crashed soon.

Hello @Anixx if you can, try the new version and tell me if it works properly now

[sebastian08dm08-cpu]

Tested on Windows 10 1809 and the mod works with the redirect and the limitations are confirmed but the experience is overall improved compared to the first version. Good work Brother

[babamohammed2022]

Tested on Windows 10 1809 and the mod works with the redirect and the limitations are confirmed but the experience is overall improved compared to the first version. Good work Brother

Thanks for the comment

[m417z]

Submission review

Note: This review was done by Claude, and then refined manually. Due to the amount of submissions, doing a fully manual review for each pull request is no longer feasible. Thank you for understanding.

Please address the following issues. The items in the collapsed sections are optional, so it's your call whether to address them.

---

The taskbar-rotation feature introduces a crash-on-unload that can take the whole shell down, and most of the machinery behind it doesn't actually run for the positions the mod supports. That's the main thing to fix.

1. Taskbar subclasses are leaked on unload → dangling WndProc → explorer crash (blocking).
Wh_ModInit installs subclasses on the taskbar windows unconditionally — SubclassExistingTaskbars() (line 2750) plus the CreateWindowExW hook that subclasses Shell_TrayWnd / ReBarWindow32 / TrayNotifyWnd / MSTaskSwWClass as they are created (lines 2186-2201). These are Win32 subclasses, not Windhawk hooks, so Windhawk does not remove them for you — the mod must. But the teardown is wrong in two ways:

• It's gated: UnsubclassExistingTaskbars() sits inside if (g_taskbarPosHooksInstalled && g_lastEdge != 3) in Wh_ModUninit (lines 2769-2780). With the default bottom taskbar (edge == 3, the common case), the subclasses are never removed at all.
• Even when it does run, UnsubclassExistingChildrenProc / UnsubclassExistingTaskbarsEnumProc use raw RemoveWindowSubclass (lines 2224-2228, 2249). RemoveWindowSubclass only works from the window's own thread, and Wh_ModUninit runs on an arbitrary Windhawk thread, so the call fails and the subclass stays installed.

Either way, after the mod is disabled/updated/reloaded the DLL is unmapped while Shell_TrayWnd (and friends) still point their subclass proc into the freed image. The taskbar receives WM_SIZE constantly, so it will call the dangling pointer almost immediately → explorer crash. The WM_NCDESTROY RemoveWindowSubclass handlers don't help here, because on unload the windows aren't destroyed.

Fix: remove the subclasses unconditionally at teardown, and use WindhawkUtils::RemoveWindowSubclassFromAnyThread (declared in windhawk_utils.h, line 137) so it works from the uninit thread. See taskbar-empty-space-clicks.wh.cpp for the pattern (RemoveWindowSubclassFromAnyThread called from Wh_ModUninit).

2. The whole vertical-layout / icon-rotation / custom-draw subsystem is unreachable for Top/Bottom — consider removing it.
The position combo only offers Top (edge 1) and Bottom (edge 3) — see lines 2434-2435 and ApplySettings (edge = (locSel == 0) ? 1 : 3, line 2341). Both are horizontal edges. The subclass-driven code — HandleTaskSwCustomDraw, GetOrCreateRotatedIconBitmap/RotateDib90, the vertical branch of DoApplyVerticalTaskbarLayoutAtomic, ForceToolbarVerticalColumn, ApplyTrayNotifyInternalLayout(…, vertical=true, …) — is only entered when IsEdgeVertical(edge) is true, i.e. edge == 0 || edge == 2 (Left/Right, line 1684), which the UI explicitly disables. Top/Bottom positioning is already fully handled by the TrayUI::GetStuckInfo / GetDockedRect / MakeStuckRect symbol hooks on their own.

So roughly ~700 lines of always-installed subclassing exist purely to service Left/Right, which don't ship — and that subclassing is exactly what causes the crash in item 1. Removing the subclass subsystem entirely (keeping just the TrayUI hooks that do the actual Top/Bottom work) both simplifies the mod substantially and eliminates the crash. If you intend to keep it for a future Left/Right implementation, at minimum only install it when a vertical position is actually selected, and note that the shared caches (g_rotatedIconCache, g_trayChildSizes) are touched from the taskbar UI thread and cleared from Wh_ModUninit on another thread with no synchronization.

Optional improvements

Minor polish — none of this affects users, so it's your call.

• Dead child-process redirect machinery. BuildChildEnvironment() (line 303), g_childEnvBlock, and IsChildProcess() (line 324) are leftovers from the settings-to-control-panel base. g_childEnvBlock is built in Wh_ModInit (line 2742) but never passed to any CreateProcess, so IsChildProcess() is always false and the guards at the top of the ShellExecute* hooks are dead — the hooks now open the dialog in-process. This can all be deleted.
• Unused symbol hook. TrayUI::_StuckTrayChange is resolved into TrayUI__StuckTrayChange_Original (line 1657) but never called — drop it from explorer_exe_hooks.
• Dead registry write. RotateTaskbarPosition writes TaskbarSide under …\Advanced (line 2295), but the mod reads the edge from StuckRects (GetTaskbarEdge), never from TaskbarSide. The write has no effect.
• Use the typed hook helper for the ShellExecute* hooks. They use raw Wh_SetFunctionHook with void* casts (lines 2754-2761) while CreateWindowExW already uses WindhawkUtils::SetFunctionHook. Consistent, type-safe form is preferable.
• Stray formatting. The monitor-positioning block at lines 2490-2500 loses its indentation and carries a leftover Italian comment (// rimossa la variabile ww).

Functionality notes

Non-critical observations about the feature behavior itself.

• Unload forces the taskbar to Bottom instead of restoring the previous position. RotateTaskbarPosition rewrites the native StuckRects2/3/Legacy blobs (UpdateAllStuckRects), and Wh_ModUninit hard-resets them to edge 3 (bottom) whenever g_lastEdge != 3 (lines 2769-2771). The mod never snapshots the user's pre-mod edge, so a user whose taskbar was legitimately at the Top before enabling the mod ends up at the Bottom after disabling it. Consider recording the original edge on init and restoring that.
• The "Desktop" toolbar row is interactive but a no-op. InitToolbarsList adds a Desktop item with a live checkbox (lines 1250-1284), but ApplySettings hardcodes desk = false and never reads that checkbox (lines 2364-2365). Toggling it silently does nothing. Since the README already says the Desktop toolbar isn't functional, either disable/grey that row or drop it, rather than showing a control that appears to work.
• The Address/Links toolbars rely on an undocumented ITrayDeskBand COM interface with hardcoded CLSID/IID plus the …\Internet Explorer\Toolbar registry — it works, but expect it to be fragile across future Windows builds (you already flag partial support in the README).

[babamohammed2022]

Submission review

Note: This review was done by Claude, and then refined manually. Due to the amount of submissions, doing a fully manual review for each pull request is no longer feasible. Thank you for understanding.

Please address the following issues. The items in the collapsed sections are optional, so it's your call whether to address them.

The taskbar-rotation feature introduces a crash-on-unload that can take the whole shell down, and most of the machinery behind it doesn't actually run for the positions the mod supports. That's the main thing to fix.

1. Taskbar subclasses are leaked on unload → dangling WndProc → explorer crash (blocking). Wh_ModInit installs subclasses on the taskbar windows unconditionally — SubclassExistingTaskbars() (line 2750) plus the CreateWindowExW hook that subclasses Shell_TrayWnd / ReBarWindow32 / TrayNotifyWnd / MSTaskSwWClass as they are created (lines 2186-2201). These are Win32 subclasses, not Windhawk hooks, so Windhawk does not remove them for you — the mod must. But the teardown is wrong in two ways:

* It's gated: `UnsubclassExistingTaskbars()` sits inside `if (g_taskbarPosHooksInstalled && g_lastEdge != 3)` in `Wh_ModUninit` (lines 2769-2780). With the default **bottom** taskbar (`edge == 3`, the common case), the subclasses are never removed at all.

* Even when it does run, `UnsubclassExistingChildrenProc` / `UnsubclassExistingTaskbarsEnumProc` use raw `RemoveWindowSubclass` (lines 2224-2228, 2249). `RemoveWindowSubclass` only works from the window's _own_ thread, and `Wh_ModUninit` runs on an arbitrary Windhawk thread, so the call fails and the subclass stays installed.

Either way, after the mod is disabled/updated/reloaded the DLL is unmapped while Shell_TrayWnd (and friends) still point their subclass proc into the freed image. The taskbar receives WM_SIZE constantly, so it will call the dangling pointer almost immediately → explorer crash. The WM_NCDESTROY RemoveWindowSubclass handlers don't help here, because on unload the windows aren't destroyed.

Fix: remove the subclasses unconditionally at teardown, and use WindhawkUtils::RemoveWindowSubclassFromAnyThread (declared in windhawk_utils.h, line 137) so it works from the uninit thread. See taskbar-empty-space-clicks.wh.cpp for the pattern (RemoveWindowSubclassFromAnyThread called from Wh_ModUninit).

2. The whole vertical-layout / icon-rotation / custom-draw subsystem is unreachable for Top/Bottom — consider removing it. The position combo only offers Top (edge 1) and Bottom (edge 3) — see lines 2434-2435 and ApplySettings (edge = (locSel == 0) ? 1 : 3, line 2341). Both are horizontal edges. The subclass-driven code — HandleTaskSwCustomDraw, GetOrCreateRotatedIconBitmap/RotateDib90, the vertical branch of DoApplyVerticalTaskbarLayoutAtomic, ForceToolbarVerticalColumn, ApplyTrayNotifyInternalLayout(…, vertical=true, …) — is only entered when IsEdgeVertical(edge) is true, i.e. edge == 0 || edge == 2 (Left/Right, line 1684), which the UI explicitly disables. Top/Bottom positioning is already fully handled by the TrayUI::GetStuckInfo / GetDockedRect / MakeStuckRect symbol hooks on their own.

So roughly ~700 lines of always-installed subclassing exist purely to service Left/Right, which don't ship — and that subclassing is exactly what causes the crash in item 1. Removing the subclass subsystem entirely (keeping just the TrayUI hooks that do the actual Top/Bottom work) both simplifies the mod substantially and eliminates the crash. If you intend to keep it for a future Left/Right implementation, at minimum only install it when a vertical position is actually selected, and note that the shared caches (g_rotatedIconCache, g_trayChildSizes) are touched from the taskbar UI thread and cleared from Wh_ModUninit on another thread with no synchronization.
Optional improvements

Functionality notes

Thanks for the review, I've tried to address some of the reported issues. Please let me know if other fixes are required