I’m using madCodeHook from madCollection to fix an ugly problem we (at the company I work for) have with some of the earlier versions of our products. We’ve been using JCL (the JEDI Code Library, an otherwise extremely useful and very well-written library), which used to have a bug in its CPU speed measuring code: it might cause a division by zero on faster computers. What makes things really bad is that this code is executed during initialization – which, if the division by zero occurs, prevents the applications from running.
The applications are running from CDs (and require the CDs to run). They have been working fine for years, because the bug does not reveal itself on slower CPUs, but now, as users start upgrading or buying new, faster computers, they find out that the applications won’t run anymore (they won’t even start). 🙁
The fix I’m working on injects a DLL into every newly started process as soon as it’s loaded (before initialization code is executed). The DLL inspects the process it has been injected into, and if (and only if) it positively identifies it as our application, it hooks the QueryPerformanceFrequency API call to return False, which solves the problem – the offending JCL routine will not attempt to measure the CPU speed in such case. The DLL will do nothing to any other process. Fortunately, we are able to identify our own applications’ processes fairly easily. Also, we know that our applications never use the API function anywhere else, so this seems to be an acceptable solution. The fixup program is designed to run as a service under system account on NT-based Windows – code hooking requires administrator privileges. It works as a normal (hidden) Windows application on Windows 9x systems.
I wouldn’t be able to do this without madCodeHook – madCollection is really a great library – in this case, a life saver. Thanks, Madshi, for your excellent work!