Re^2: Class::MethodMaker, workplace politics, and patches

[lachoy]

Seconded. Depending on whether the next Algorithm::Dependency includes a patch from me something very similar to what you proposed will be making it into the next OpenInteract2 beta. Mine was very straightforward though (just adding a new method for some new functionality). But I don't think it's that risky since it's temporary -- once the new A::D comes out (and assuming it has my patch) I'll just bump up the version in Makefile/Build.PL and remove the workaround.

[BrowserUk]

It's a useful technique. We used to send out binary patches that attached themselves to the end of the afflicted executable and patched themselves into the load table.

When the executable loaded, they checked the embedded version in the 3rd party .dll that contained the bug we were working around, and if it was broken version, patched the dynamic link tables to redirect the broken API to the substitute that we had attached to the end.

When the 3rd party library was updated, the next time the executable ran, it unhooked itself from the loadtable, and became a redundant few dozen extra bytes on the end of the executable, and the program continued, now using the (hopefully fixed) API.

Of course, you wouldn't get away with this these days because every virus scanner within a million miles would scream bloody blue murder.

Such is progress.

That said. C::MM is kind of unusual as the code that needs to be patched never actually exists on disk anywhere. It jusy comes into being in memory at compile time. Kind of tricky to C&P.