Windows Classic theme on Windows 8.1 via task scheduler

Delete the Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes\DefaultColors. (Credits to Mr. GRiM)



Workaround idea: In your AutoHotkey script, use a shellhook to store the hwnd of the Classic Shell settings window when it appears and then when your message handler receives HSHELL_WINDOWDESTROYED, compare HWNDs and have the script rerun fixstrip automatically.

Ah, yeah, that makes sense.

---

Personally, I'm looking to combine your method with some of the tricks w8classic performs (which requires a resident component of some sort) so that I can do away with some of the (as you already noted) processor-time consuming hacks w8classic performs currently, but still keep the compatibility hacks it performs, like calling SetProcessDPIAware in every process (though without ClassicTheme.exe scanning for new processes every two seconds). Since we can workaround C-A-D messing up the colours by deleting that Registry key, there's no need for the ClassicTheme service to save the colours locally and create a new thread in Explorer.exe to monitor the desktop switching. Replacing dwmapi.dll as w8classic currently does won't survive Windows Update. I'm hoping AppInit_DLLs with a DLL that just hooks dwmapi functions works instead.

I'm currently working my way through this to produce a small program that just closes the ThemeSection handle. (I know ClassicShellA.exe does this, but I'm looking for something lighter to run with UserInit, as per your post). (Maybe not. Winlogon is a protected process (duh). ClassicTheme opens the winlogon process by running as a service as a System user. Sysinternals' Handles uses a driver. I'll just sit my ass down and use the latter.) I'd like to look at other things, like seeing if I can work out a way to replace the network selection screen that appears with single-click on the network tray to run something of my own choosing. I'm not well-versed in Windows programming though in the slightest, and my reversing knowledge is really, really limited, so I probably won't do anything that'll amount to much, but my nostalgia is running high and I'm wishing I had a laptop around that could run Windows 2000. Windows 8.1 will have to do (except for the OpenWith.exe - while Windows 7's is the best, Windows 10's isn't bad, but the 8 one is an abomination. Since OpenWith Enhanced is buggy for me, I'm going to try and make my own replacement if time allows)...

I'm probably not able to answer that fairly because I'm going wrong somewhere and I can't get rid of the glow on the taskbar when using the non-resident method - when explorer.exe starts, it resets the colour back in the Registry. Maybe I'll have better luck when I install into a VHD instead of using VMware. (So I don't misrepresent anything: I've not actually installed the non-resident method yet because I'm too lazy to run Task Scheduler - I'm logging in, killing explorer, importing the glow fix reg file, running ClassicThemeA, reloading Explorer and running fixstripes)


IbmPad said that calling SetProcessDPIAware in every process was done to help with fixing rendering of some applications' title bars. Though I can't find any examples of what that's meant to fix though...

For me, it's not necessarily running w8classic resident that's a must, but the idea of having a hook DLL resident in most processes is, to me (and maybe that's just me being extra pedantic - your method does produce a mostly usable desktop, no worse than w8classic in resident mode). With applications like Internet Explorer* and the Aero wizards (as used by Extract All - w8classic when installed actually causes Explorer to crash there - and Windows' troubleshooters) assuming compositing is active and enabling transparency in the title bar area, the only way I see those getting fixed is with something resident (it doesn't have to be something heavy like w10classic with its threads - I'm hooking Chrome with one of my own DLLs so that I can specify a consistent set of command line arguments and do things like show a close prompt if I press Alt+F4 on a Chrome window and there's more than one tab open. ProcessHacker is saying my hook occupies 230 Kb, and the hook doesn't introduce code that causes the CPU to fire up when idle).
In my case, I'll undoubtedly need to hook Explorer like w8classic does anyway so that I can workaround problems of my own. On a laptop, being able to quickly connect to Wi-Fi networks is a must, and the Windows 8 manager doesn't work (I've looked at the DLL and the WinRT/Metro stuff is so far beyond me). If I can figure out how to intercept the call to display the non-working Wi-Fi manager, I can keep the default network icon (handles the most cases WRT networks and I'm sure the updating of its signal strength indicator is the most optimised implementation, battery wise) but show something else, like Portlock WiFi Manager (or SwissCom's Unlimited Data Manager).

* Internet Explorer is a bad example, I must admit. w8classic replaces the manifest file to get Windows itself to load the patched dwmapi.dll into Internet Explorer (actually, I have no idea why Windows requires this be done - w8classic replaces dwmapi.dll and so it should be loaded regardless)

What is this "Taskbar glow"?

Oh, okay :U

Huh...so have you guys had any luck with the titlebar overbrightening on applications which use DwmExtendFrameIntoClientArea?

Well it also applies to Google Chrome, paint.NET, etc. ._.

Well by that logic maybe we should just do this:

and drop this entire project .-.

Well it is possible to edit Chrome's .PAK files, so...a Chrome skin which looks like the Classic Theme? Idk... .-.

This problem disappears with Classic Shell 4.3.0 if the taskbar is set to be non-transparent. So one can enter the settings sheet and apply settings without the black strips appearing now.