# Measure a library's calls that lock mutexes, under the emulator

## What to know

A sound or input library's entry points often wrap their work in `WaitForSingleObject` and
`ReleaseMutex`, and report errors with `MessageBoxA`. Under a bare emulator those calls jump
to the import table's unresolved entries and crash. Write a few bytes of stub for each into
scratch memory and point the import slots at them: `xor eax, eax; ret 8` for
`WaitForSingleObject` (`WAIT_OBJECT_0`), `mov eax, 1; ret 4` for `ReleaseMutex`, `ret` for
`DebugBreak`, `xor eax, eax; ret 16` for `MessageBoxA` and `PostMessageA`. A game may import a
function twice (POD has two `ReleaseMutex` slots); stub every slot. Get the slots with
`pefile` (`DIRECTORY_ENTRY_IMPORT`, `imp.address`).

Then the library's own calls can be run in random sequences against its own tables, and the
port checked after every call (`measure/sound_channels.py`: play, update, stop, pause and mix
in any order). Two things make such a measurement worth its keep:

- Make sure the random sequences reach the rare paths. In POD a slot index that wraps on the
  eighth update went untested until a third of the cases kept to two looping channels.
  Break the port on purpose and see the test fail.
- Keep inputs the original cannot survive out of the cases, and note them: a loop shorter than
  one step never ends in POD's mixer, and the emulator's instruction limit hides the hang.