Thank you.

[duckduckdog]

This was making me crazy.

Have you heard of windhawk.net? I have a hunch you have plenty to add that doesn't justify a whole executable.

Thank you for not just making a fix, but packaging it so that it was painless to use.

[dechamps]

Thanks for pointing me to Windhawk, I didn't know about it. Impressive stuff!

That said… Windhawk is a Windows hook injection framework. While hooks are an extremely powerful approach and can be used to do pretty much anything, they have the downside of being brittle because they heavily rely on the undocumented internals of the code being hooked. Monkey patching in this way is extremely unsupported by the software vendor (in this case Microsoft), and can easily be broken by updates or incorrect assumptions.

Now, it is true that RudeWindowFixer also relies on undocumented Windows internals. But the crucial difference is, if RudeWindowFixer has a bug, the blast radius is very small as it is isolated in a single independent process - at worst, it simply doesn't work. In contrast, the blast radius of code monkeypatched into an application process is much worse - a bug can crash or corrupt the entire host process. When that process is explorer.exe (or the user's apps), things go downhill very quickly.

I'm not saying that hooking should never be used - there are some scenarios in which it is the only practical solution and nothing else will work. But that should only be a last resort solution due to the intrusive and brittle nature of the approach. Almost anything else is preferable.

This is why I don't believe it is necessarily a good idea to rewrite RudeWindowFixer around a hooking approach. The separate process approach, while less flexible and perhaps slightly less efficient, is nonetheless less intrusive, more robust and easier to implement and debug.