How to Run Legacy Software in a Browser: v86, Ruffle and More

How can you run legacy software in a browser?

You can run almost any piece of old software, from Windows 95 to Adobe Flash games to firmware pulled off a dead vape pen, directly in a browser tab. Compile an emulator or a reimplemented runtime to WebAssembly, and you get the old software back with no installer, no native binary, and no dependency on the original hardware ever existing again.

The tools for this already exist and are improving fast, partly because AI-assisted reverse engineering just made the hardest step, figuring out what an undocumented binary actually does, dramatically cheaper.

That matters more than it sounds like it should. Most software you've ever used is already gone in every practical sense.

Why is most old software already gone?

The Video Game History Foundation ran the numbers on commercial availability and found that 87% of classic video games released in the US are critically endangered: out of print, with no legal way to buy them. No era of video game history, across any console generation studied, cleared even 20% availability. Only 13% of that history is represented in today's marketplace.

The institutional fix is also closed, at least for now. In October 2024 the US Copyright Office rejected a renewed DMCA Section 1201 exemption that would have let libraries and archives remotely share digitally preserved games with researchers. On-premises-only access remains the baseline. If you want to actually play or study that software, you need your own copy, your own tools, and increasingly, your own emulator.

It's the same problem the hardware world has, just with a different vendor cutting you off. We've written before about why cloud-dependent hardware means you don't really own it; abandoned software is the same story minus the remote kill switch. The vendor didn't brick it. It just stopped existing.

Here's what's filling the gap.

How does v86 run a full x86 PC, JIT-compiled to WebAssembly, in a tab?

v86 is an open-source emulator that recreates an x86-compatible CPU and its supporting hardware entirely in software. It doesn't interpret machine code line by line. It compiles the guest OS's x86 instructions into WebAssembly modules at runtime, a just-in-time compilation step that gets you close to native speed inside a browser's sandbox.

The practical result: Windows 95, Windows 98, Windows 2000, ReactOS, and various Linux distributions all boot from a static web page with zero client installs. You load a URL, the virtual BIOS posts, and you're looking at a desktop that technically does not exist on any physical machine anywhere. That's the whole point. The hardware died years ago. The software didn't have to.

How does Infinite Mac stream a classic Macintosh (and NeXT) off a CDN?

v86 proves the concept works for x86. Infinite Mac shows what happens when someone takes it seriously as a product. Built on an in-browser port of the Basilisk II and SheepShaver emulators, it delivers a persistent, full classic Macintosh experience, and a NeXTSTEP one too, straight from a CDN.

The engineering is the interesting part. Disk images are broken into fixed-size, content-addressed, Brotli-compressed chunks and streamed on demand, so a Quadra-class Mac shows its boot screen in about a second and is fully usable in roughly three, even on a cold cache. The emulator idles at around 13% CPU. It supports drag-and-drop file transfer in and out of the emulated machine, and it embeds cleanly in an iframe, which is why you'll find it quietly running inside other sites' blog posts and museum exhibits. That's the difference between "an emulator exists" and "a stranger with no technical background can use this in ten seconds."

How does Ruffle rebuild a dead proprietary runtime from scratch in Rust/Wasm?

v86 and Infinite Mac emulate hardware and let the original OS and apps run unmodified on top. Ruffle takes a different approach: it reimplements the runtime itself.

Ruffle is a Flash Player emulator written in Rust and compiled to WebAssembly, targeting both desktop and the browser. Instead of virtualizing a machine and installing Adobe's actual Flash Player on it, Ruffle's authors rebuilt the SWF player from the ground up, replicating Adobe's discontinued, closed-source runtime well enough that the content it was built for still plays. Newgrounds funded early development, and the Internet Archive now uses Ruffle to keep millions of SWF files playable years after Flash's 2020 end-of-life.

This is the harder, more durable version of preservation. You're not keeping an old proprietary player alive in a sandbox. You're replacing it entirely with something open that nobody can discontinue twice.

How is AI speeding up reverse engineering?

Reverse engineering, historically the bottleneck in all of this, is being automated. That's what changed recently, and it's why this entire category just got faster.

The clearest example is a security firm, Faraday Security, that used a hybrid pipeline, deterministic code plus LLM calls, to recover an entire undocumented instruction set architecture, "pi32v2," from a vape pen's firmware. They generated a working Ghidra processor spec, the kind of thing that used to take a specialist weeks of manual disassembly, in about 2.5 hours for roughly $25 of compute. On a known-answer MIPS test, the pipeline hit 98% instruction recovery, and notably, 91% of that work happened with zero AI calls at all; the LLM filled gaps that deterministic analysis couldn't close on its own. That ratio is the real story: AI isn't replacing the engineering, it's finishing the long tail of it.

Game decompilation projects show the same curve. A hobbyist decompiled and recompiled the 20-year-old puzzle game Chromatron from its original Windows XP and PowerPC Mac binaries into a pixel-perfect Rust rewrite, using Ghidra alongside Claude Opus and GPT-5-series coding agents, succeeding on the fourth distinct toolchain attempt after three partial failures. A separate developer rewrote the 2003 shooter Crimsonland from a symbol-less Windows binary into a full C++/Rust reimplementation in about two weeks and 1,666 commits, using Ghidra, WinDbg, Frida, and GPT-5.2-Codex. The original studio's own ported rewrite, done in 2014 with actual source access, took over a year.

It's not magic, though. An N64 decompilation effort on Snowboard Kids 2 stalled at 157 unmatched functions, because current models still choke on very large functions, graphics microcode, and dense matrix math. AI compresses the timeline. It doesn't eliminate the wall.

If your team is already running coding agents on infrastructure you control, this is the same muscle. We covered the mechanics of that in how to self-host AI coding agents, and the same sandboxed, tool-wired agent pattern, Ghidra or Binary Ninja exposed to an LLM via MCP, is what's driving these decompilation wins.

How do you go from decompiled C to a Wasm binary and ship the rewrite everywhere?

Decompilation on its own gets you readable source. The ownership payoff comes next: once an LLM-assisted pipeline produces clean, buildable C or Rust from a stripped binary, compiling that to WebAssembly, via SDL2, Emscripten, or a native Rust toolchain, is almost a formality.

Before you ship it, though, you still have to confirm the rewrite matches the original binary's behavior, not just its appearance. Reading the output harder doesn't settle that question; that's the whole argument behind I don't want to read what your AI didn't write.

That's exactly what happened with Chromatron: the same rewrite that compiles natively for Windows, Linux, and macOS also compiles to Wasm for browser play. Once source exists, the binary stops being tied to the operating system it was born on. It becomes portable in the way modern software is supposed to be: run it in a tab, run it on a server, run it on hardware the original vendor never heard of. We've laid out the broader version of this shift, decompilation as a modernization strategy rather than a nostalgia project, in 5 legacy codebases AI can now modernize and let you own.

What can you legally reverse-engineer?

None of this happens in a legal vacuum, and the rules differ by jurisdiction.

• EU interoperability right. Article 5(3) of the EU Software Directive lets a lawful user observe, study, and test a program to learn its underlying ideas. Article 6 goes further, permitting decompilation without the rightsholder's authorization specifically when it's indispensable to achieve interoperability with an independently created program, under strict conditions.
• US DMCA 1201 exemptions. The US has narrower, periodically renewed exemptions, mostly aimed at preservation and research, not general-purpose decompilation.
• The 2024 setback. The Copyright Office's 2024 decision specifically blocked remote library access to preserved games, even though a comparable exemption already exists for non-game "functional" software. Preservation inside an institution's walls is fine. Sharing it over the internet, for now, is not.

The practical takeaway: interoperability and personal preservation of software you lawfully acquired sit on reasonably solid ground, especially in the EU. Redistributing someone else's reverse-engineered work, or circumventing protection on software you don't own a copy of, is where the corridor narrows fast.

Why does this matter for software ownership beyond nostalgia?

It's easy to file all this under retro-computing hobbyism. That undersells it.

Average SaaS spend per employee hit $4,830 in 2025, up from $3,960 the year before, as subscription creep keeps compounding across the average company's 275-plus SaaS tools. Every one of those subscriptions is software you're renting the right to run, not software you own. The moment a vendor sunsets a product, changes a pricing tier, or gets acquired, your access is a decision someone else made, not an asset on your balance sheet.

The emulation and reverse-engineering stack covered here is the inverse of that model, applied to a harder case: software where the vendor is already gone and there's no renewal notice coming, just a binary and whatever you can learn from it. v86 and Infinite Mac prove a sealed-off piece of history can run forever, independent of the hardware it was written for. Ruffle proves you can rebuild a discontinued runtime outright rather than merely emulate around it. AI-assisted Ghidra work proves the cost of understanding an undocumented binary has collapsed from months to days. Wasm is the delivery mechanism that makes the result portable to any browser, forever, with no vendor in the loop.

That's the actual lesson for anyone thinking about software as an asset rather than a lease: the tools to take ownership of code you only ever licensed, or that nobody licenses anymore, now exist, work, and keep getting cheaper to use.

Which tools can you use to start running legacy software in your browser today?

• v86 — x86 PC emulator that JIT-compiles guest machine code to WebAssembly; boots Windows 95/98/2000, ReactOS, and various Linux distros from a static web page.
• Infinite Mac — Streams a classic Macintosh or NeXTSTEP machine off a CDN using chunked, content-addressed disk images; boots in about three seconds and embeds in an iframe.
• Ruffle — Rust-and-WebAssembly reimplementation of Adobe Flash Player, used by the Internet Archive and Newgrounds to keep SWF content playable.
• Ghidra plus an LLM coding agent — Pairs NSA's open-source disassembler with models like Claude Opus or GPT-5-series Codex to accelerate decompilation of undocumented binaries and firmware.
• Emscripten / SDL2 toolchains — Compiles decompiled C or Rust source into a WebAssembly binary, turning a resurrected desktop program into something that runs in any browser.