Replace SourceHook and CDetour with KHook#2403
Conversation
SourceHook and CDetour with KHook`SourceHook and CDetour with KHook
|
Are we still concerned about using STL on public interfaces? things will get weird with gcc vs clang extensions. |
That's a good point. I've mainly stripped every instances of the word That said, looking at the two interfaces affected Core & bridge are built as a package deal so we probably don't have to worry about diverging STL implems. Unless we want to preserve that flexibility in hot swapping core and bridge libs, in which case I can just bring |
48b5f88 to
56f811c
Compare
5ebea47 to
d0d342a
Compare
ef3a114 to
ff8cc50
Compare
9e63d38 to
871a86b
Compare
* Fix dhooks float arguments on x64 * Fix inverted check in DynamicDetour.Disable * Fix re-entrant callback removal on plugin unload * Adapt sdkhooks/sdktools/dhooks to KHook * Fix SendFile hook signature on L4D2 engine * Fix dhooks corrupting bool object pointers * Fix sdkhooks vtable hooks leaking on bulk unhook * Fix dhooks return value leak in hook callbacks * Fix later dhooks callbacks overriding a supersede * Save the first float argument register on x64 * Zero-initialize dhooks register save arrays * Defer sdkhooks vtable hook deletion out of hook callbacks * Fix dhooks thiscall argument count * Allow nulling a dhooks entity return value with -1 * Remove leftover dhooks debug class and printf * Fix dhooks dynamic hook ownership and teardown leaks * Fix dhooks dynamic hook teardown leak * Remove unused JIT page protection call in dhooks * Different approach to deferred vtable deletion * Fix sdkhooks always blocking EndTouch * Fix DHookGetReturnString null check * Fix sdkhooks overriding OnTakeDamage return * Additional hardening on hook teardown just to be safe
In the continuity of alliedmodders/metamod-source#223. This PR strips
SourceHookandCDetourfrom SourceMod.Marked as a Draft until I finish writing the x86 assembly for dhooks on windows, and I'd like to have some unofficial builds tested around first. Local testing looks good though!
Breaking changes
Benefits
Those breaking changes are definitively not ideal, and I went in working on this knowing full well the PR might die at the finish line.
In the PR's defense, I have worked on this x86_64 support project (MM:S, SM, KHook) on and off for nearly 2 years, and in that timespan nobody has offered something close to a working alternative. I believe this is as good as it will ever get..