The MKB subsystem covered message-loop (PostMessage) and polling (GetAsyncKeyState/GetKeyboardState/GetCursorPos) games. Add the two remaining read paths, both fed from the same synthesized state: - DirectInput: vtable-swap IDirectInputDevice8::GetDeviceState (a COM method -> vtable swap, not inline, per the x86 COM-prologue trap), reading the shared vtable from a kept-alive probe device (the game made its devices before we injected). Dispatch on cbData: 256 = keyboard BYTE[256] indexed by DIK scan-code (map VK->DIK via MapVirtualKey VK_TO_VSC); DIMOUSESTATE = mouse buttons + relative deltas from the forwarded cursor. - Raw Input: games get no WM_INPUT while unfocused, so mkb_pump synthesizes it (PostMessage WM_INPUT with lParam = one of our RAWINPUT slots) and the hooked GetRawInputData serves that slot back (RID_HEADER + RID_INPUT). Covers keys + buttons; relative raw-mouse movement isn't in the position-based MKB stream. Both detours use the DetourGate safe-unhook guard, and the mock_game_test storm exercises their install/remove. dinput_hook_test drives the real path end-to-end: forward a key + mouse button through the ring, then a real DI keyboard/mouse device's GetDeviceState returns them. The Raw Input round-trip is operator- validated against a real game (too brittle to assert in-process). vtable_hook.hpp factors the COM vtable-swap helper out for reuse. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
12 KiB
12 KiB