> Raymond's posts are always fun to read, but it sometimes he focuses more on the "proper" methods, and does not even acknowledge that there are hacky workarounds.

Nor should he, IMO. Hacky workarounds are almost always a terrible idea that will bite you in the ass someday.

As a hacker, I'm sorry, reverse engineer hacky workarounds is what I do. When I want to read stdout of a malware process I'm not going to ask a developer nicely, in going to grab my trusty debugger or API monitor.

But yeah, for production quality software hacks are the very last resort. It's still fun and enlightening to know them, though.

Hacky workarounds aren't rare exceptions; they're the plumbing of modern software. Anti-cheat and antivirus tools only work because they lean on strange kernel behaviors. Cloud platforms ship fixes that rely on undefined-but-stable quirks. Hardware drivers poke at the system in ways no official API ever planned for.

Yeah, they're ugly, but in practice the choice isn't between clean and hacky; it's between shipping and not shipping. Real-world software runs on constraints, not ideals.

Had a WPF touch interface application that would latch on when a person; presses, holds, and slides their finger off the screen. Highly unacceptable when it controls a machine that could remove a limb.

Only fix was to write a custom touch screen event handler that overrides the built in one by Microsoft.

I would love to have a _proper method_ and pull out my _hacky_ method that prevents the removal of a person's limb.