A per-step recorder fits in the code section's mapped slack

What to know

2026-10-24, Hardwar's patch_recorder.py.

To record every flight step (the step's dt_ms, the world clock, the seeds, the input state) a sampler from outside is not enough: it misses most frames and is not atomic (GameFrame docs/observe/recording.md, "What a recording from outside cannot see"). A hook inside the step is.

Where to put it: Watcom's linker left BEGTEXT with a virtual size of 0 and a raw size of 0x116e00, so the loader maps it to the next section alignment (0x10000), up to 0x530000. Only 0x83 bytes at the end of the raw data are free, but 0x526e00-0x530000 is mapped and executable. Growing the section's raw size by 0x1000 and moving the later sections down in the file (their addresses stay) puts a 4 KB hook there without moving any code. The section was made writable too, so the hook keeps its file handle and buffer beside its code.

The hook replaces one call (call controls_read at 0x43ac72 in flight_frame), calls it, and then writes with the game's own imports (CreateFileA, WriteFile, Sleep). It saves every register and the flags. The step it records is the one the game used; the time the write takes is counted by the game's timer in the next step and recorded there.

Pitfall: pkill -f NAME run over SSH kills the SSH command itself, since its command line contains NAME (GameFrame knowhow vm-ssh-pkill-matches-itself, seen again here). Stop the game with its own prefix's wineserver -k (Hardwar's vm_run.sh stop`).

For GameFrame: the technique (grow a Watcom section into its mapped slack, hook one call, write with the game's own imports, hold the game between steps for a whole-process snapshot) would serve any 32-bit Windows game; probegen could gain a sibling that writes such hooks.