By submitting the demoscene-recomp project to HN, adunk is surfacing the argument that lifting DOS executables to an IR and re-emitting them as WASM is a legitimate preservation path. The 82-point score signals community agreement that this beats interpretive emulation for CPU-adversarial code.
The editorial argues static recompilation handles self-modifying code, cycle-timed loops, and direct hardware pokes more cleanly than DOSBox or v86-style full-system emulation. Translating CPU instructions once offline lets the browser's JIT optimize the actual hot loops instead of burning cycles decoding a pretend 486.
The editorial frames demoscene productions as the worst-case input for binary translation — self-modifying code, cycle-exact timing loops, protected-mode flips mid-frame, and undocumented hardware tricks. If static recompilation can handle Future Crew and Triton productions, it can handle almost anything from the DOS era.
A GitHub project called `demoscene-recomp` is making the rounds on Hacker News (82 points at time of writing) with a working demo page that boots classic PC demoscene productions directly in a browser tab. No DOSBox shim, no v86-style full-system emulator chewing cycles to pretend to be a 486 — the demos run as compiled WebAssembly, with the browser's JIT getting its hands on the actual hot loops.
The trick is static recompilation: take the original DOS executable, lift it to an intermediate representation, re-emit it as C (or directly as WASM), and compile that for the target platform. The CPU instructions get translated once, offline, instead of being decoded and dispatched millions of times per second at runtime. Everything the demo thought was BIOS, DOS, or VGA hardware gets stubbed out with a small host-side shim.
The demos on offer are a who's-who of the scene: productions from Future Crew, Triton, and other groups whose names still show up in "greatest demos of all time" lists. These are the ones that pushed 486s and early Pentiums past what their datasheets suggested was possible — texture-mapped tunnels, voxel landscapes, bump-mapped faces, all synced to a tracker-module soundtrack, all fitting in a few hundred kilobytes.
The demoscene is the most hostile input imaginable for a binary translator. These productions were written by people who treated the CPU as a personal adversary. Self-modifying code was routine. Timing loops were calibrated against the exact cycle counts of specific 486 variants. Code and data got mashed together to save bytes in size-coded intros. Protected-mode flips mid-frame, direct hardware pokes to the VGA DAC, Sound Blaster DSP commands written byte-by-byte to I/O ports — the whole surface area of PC-compatible hardware circa 1994, used in ways the hardware vendors never documented.
Static recompilation handles most of this cleanly in a way interpretive emulation never will, because once you've lifted the binary to IR, the browser's optimizer treats it as ordinary code — dead-code elimination, register allocation, inlining, the works. Interpreted emulators like v86 or JS-DOS burn most of their budget on the instruction-decode loop. Dynamic recompilers (DOSBox-staging, PCem's dynarec) do better but still pay for cold translation and have to re-verify when code pages get touched. Static recomp pays that cost once, at build time, on a developer's beefy machine, and ships the result.
There's precedent for this working. The N64 recomp project — which lifted Zelda: Majora's Mask and other titles into native PC ports with 4K textures and uncapped frame rates — demonstrated in 2024 that static binary translation is a viable preservation strategy for an entire console generation. Mario 64 famously got decompiled (a different, harder problem — recovering source), but recomp sidesteps that: you don't need the source, you don't need to understand what the code is doing, you just need to translate instructions faithfully and stub the hardware. The PC demoscene is a natural next target because the binaries are tiny, the hardware surface is better documented than any console, and the community cares deeply about keeping these works running.
The harder question is what happens when the translator meets something it can't lift. Self-modifying code is the classic landmine: if a routine rewrites itself before executing, a static translator doesn't know what the final instructions will be. Recomp projects typically handle this by falling back to an interpreter for marked regions, or by pre-identifying the mutations and generating all variants at build time. Timing-sensitive demos — the ones that assume a specific CPU speed — need either rescaled timing shims or a frame-rate target the host can hit. Not every demo will port cleanly, and the ones that don't will reveal interesting constraints.
Community reaction on HN is mostly "finally." One commenter notes they've been trying to get Second Reality running reliably in a browser for a decade; another asks when Farbrausch's `.kkrieger` is getting the treatment (a 96KB first-person shooter from 2004 that's basically a stress test for any emulation approach). The skeptics are focused on the obvious failure mode: binary translation handles the code, but the hardware shims are where correctness lives or dies, and getting the Sound Blaster FM synthesis bit-exact is its own multi-year project.
If you ship any software that needs to run user-authored binaries from a dead platform — retro gaming, financial legacy systems, scientific code locked to specific Fortran compilers, old CAD files tied to viewer executables — the recomp pattern is worth understanding. The template is: lift to LLVM IR or similar, re-emit as portable C, compile with your toolchain of choice, stub the environment. Tools like `remill`, `mctoll`, and Ghidra's p-code lifter make the lift tractable for x86. The hard engineering is in the environment stubs, not the CPU translation.
For web developers specifically, this is another data point that WebAssembly is quietly becoming the universal preservation runtime. We already have Flash via Ruffle, PostScript via emulators, old Java applets via CheerpJ, Windows XP via v86, and now native-speed x86 DOS code via static recomp. The browser is swallowing the back catalog of computing, one lift at a time. If you're building anything in the "interactive archive" space — museums, docs sites that want runnable code samples from old papers, retro game storefronts — the toolchain is maturing fast enough that "run this 1993 binary in a tab" has gone from research project to weekend hack.
The darker implication: the same technique that preserves old demos also makes it trivial to lift proprietary binaries whose vendors would rather you not. The legal frame around recompilation is murky — it's clearly a derivative work, but fair use for preservation purposes is well-established for abandoned software, less so for anything commercial. Expect this to get interesting the first time someone recomps a Windows 95 title whose rightsholder still exists.
The interesting frontier isn't the demos themselves — it's what the toolchain enables once it's robust. A general-purpose "ship this 90s binary as WASM" pipeline would unlock a huge amount of software currently trapped in emulator museums, and would do it with performance that makes the experience feel native rather than archival. The N64 scene proved the pattern works for a locked-down console with weird hardware; the demoscene is proving it works for the chaotic open platform PCs actually were. Next up is probably the Amiga, then early Windows, then — if anyone has the stomach for it — PlayStation 1. The 90s is slowly being compiled forward, one binary at a time, into whatever runtime will outlive us.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.