[arghwhat]

Note that there is a hell of a difference between changing existing instructions or even managing to squeeze a minor fix into some broken logic, and implementing new logic entirely.

There's a whole lot more reverse-engineering required to understand the working input handling, followed by more reverse-engineering to understand the broken input handling. The code might also be missing altogether if it was just ifdef'd out at compile-time or lacked initialization against the Windows input handling.

Trying to extend the input handling that never had this handling, unless the original is 50% NOPs, mean writing a new implementation at the end, and having the old implementation jump out and back.

Sure, it's possible, but on an entirely different level than patching conditions in place like done here. I feel like being disappointed at this is like going through a hello-world tutorial for a language and end up disappointed that it didn't teach you to write a fully functioning game.

[boricj]

> Trying to extend the input handling that never had this handling, unless the original is 50% NOPs, mean writing a new implementation at the end, and having the old implementation jump out and back.

While traditional in-place binary patching does require contorting the modifications within the original program's memory layout, it's not the only option. If you have the ability to make the program's code and data relocatable again, you can leave out the parts that you want to modify, write replacements in source code form and let the toolchain mend everything back together.

That technique has a higher upfront cost (the reverse-engineering work still has to be done on top of this), but it's far less finicky to perform. Personally, I've developed this capability with a Ghidra extension that exports object files, but that patching technique is so esoteric I don't even know if it has a name.