I have basically no background writing applications on Windows outside of .Net but I love reading posts by Raymond Chen. I always enjoying learning about things that seem crazy from the outside from have a real purpose that you're just missing information to understand. That's pretty much what looking at someone else's code is often like so it's helpful to remember that even seemingly crazy things have a purpose.<p>I feel like I've learned a lot from reading his blog over the years. I even bought his book years ago because I felt like I was getting a lot of value from the blog.<p>It's really too bad Microsoft doesn't seem to value backwards compatibility as much as they did during the times Chen often writes about. It seems like an interesting challenge that they've pretty much given up on. I can't even count how many conversations I've been in where people complained on one hand that Microsoft focused on that backwards compatibility too much and on the other that their driver from 2001 doesn't work right in Windows 7. Often these statements happen moments apart.
If you're never had a chance to play with it, Detours, the more complex alternative to the hot-patch strategy Chen is talking about, is really slick.<p>What you do in Detours is, freeze the process, disassemble the first several instructions of the function you want to hook, copy out enough of them to make room for a full jump instruction, copy in your hook function somewhere in memory, followed by the instructions you stole to make room for the jump, followed by a jump back to the original function. Then you patch in a jump to that location and unfreeze the process.<p>The example programs for Detours do this, for instance, on every libc function to implement library tracing.<p>That this "just works" with Microsoft's Detours package is kind of mindboggling.<p>This is a great project to tackle if you want to write programmable debuggers. We've done it for Win32 (you need a full build environment to use Detours; we have the whole thing in Ruby), OS X, and Linux. It's crazy useful.
For those that are interested, the Linux kernel does almost the same thing (if compiled that way):<p><a href="https://lwn.net/Articles/264029/" rel="nofollow">https://lwn.net/Articles/264029/</a><p>The mcount feature piggybacks on the profiling instruction added into every function when you use the gcc -pg option.<p>Edit: better link is probably this one:
<a href="http://www.mjmwired.net/kernel/Documentation/trace/ftrace.txt#1563" rel="nofollow">http://www.mjmwired.net/kernel/Documentation/trace/ftrace.tx...</a>
NOOP sequences in x86 are a fun subject. There's an interesting section in Intel's optimization guide somewhere (I'm too lazy to find it) that details "best practice" noop instructions of 1, 2, ... up to something like 9 bytes. These are used for alignment puposes too, where you need a few bytes of padding to make a loop-back target cache-line aligned or whatnot.
Okay I have two questions that might be very clueless but I don't know the answer to them so I will ask them anyway.<p>1) In the comments Raymond says, <i>"Hot-patching is not an application feature. It's an OS internal feature for servicing."</i> Then why does the compiler put hot-patch points in my code? Why not use a special compiler flag when building Windows DLLs?<p>2) Why do we need a special hot-patch point at all? What's wrong with just overwriting the first few bytes of the function you want to hot-patch?
Wow awesome explanation - about 6 years ago while hacking gtk+ and Mozilla I used those instructions to hack into the main event loop to get gtk+ embedding gecko 1.7 and had no idea that those my perceived hacks where actually some what valid method for doing what I needed to do - modify how window events from gecko where propagated to gtk+ event loop and vice versa. I think that my bug report is probably still open and might even be worth revisiting if anyone is still interested in gtk+ with Mozilla embedded - would likely need to make lots of changes... Latest gecko is 1.9?? Anyways awesome explanation