Theseus: translating win32 to wasm

Summary

This post is part of a series on Theseus, my win32/x86 emulator. Theseus now can produce WebAssembly output, allowing it to translate a .exe file into something that runs on the web. Try it out here, but note it is full of bugs (e.g. Minesweeper crashes if you win). This was pretty straightforward to get working, with the exception of one major detail that this post will go into. The x86 emulation part of this is just recompiling the existing Theseus output with a different CPU target. This is one of the main benefits of this binary translation approach. The translated code is almost (with the exception of how main gets invoked) wholly agnostic to the environment it eventually runs in. In principle I now get optimized wasm compiler output for relatively free. The main challenge was figuring out the code layout to get Cargo to cooperate with my weird requirements. The win32 part was changing things to abstract over a "Host" API that is able to do things like fetch mouse events and render pixels. That is now implemented once for SDL and once for the web. This was also relatively straight forward, at least in my first pass. So what was hard? It comes to a part of the design space I hadn't previously explored well: whether the emulator is allowed to block. To block or not to block In retrowin32, the emulator was designed to be able to step through some instructions and then return control to the caller. This is critical for the web version in particular, where you cannot block the main thread. In my earlier post "threading in two ways" I went into some detail on the various tradeoffs on how I could emulate threads in a browser, ultimately choosing a single thread. This has its advantages, but is unsatisfying in a few important ways: The main thread must repeatedly call into the emulator in a loop that yields control back to the browser. Any Windows API implementation that might transfer control to the emulator must be made async, so that it can be suspended and resumed....