How to run old Windows software without a virtual machine
By Andrew Nakas · Published June 9, 2026 · Updated July 1, 2026 · ~7 minute read
The reflex, when you need to run an old Windows program on a non-Windows machine, is to spin up a virtual machine: install VirtualBox, find a Windows ISO, sit through setup, and finally run your one little EXE inside it. That works — but for a lot of cases it's wildly more effort than the task deserves. Here's how to tell when you can skip the VM entirely, what the lighter path actually looks like step by step, and — honestly — when the VM is still the right tool.
What a VM costs you
A full virtual machine gives you a complete, isolated Windows. The price: several gigabytes of disk, a Windows license, a chunk of RAM dedicated while it runs, and a real time investment to set up and maintain. If your goal is "run this 1999 utility once to recover a file," you've built an entire operating system to do it. That's the mismatch worth noticing.
It's worth itemizing that price, because each line hides its own friction:
- The license problem. Old software often behaves best on an old Windows — 98, 2000, XP — and Microsoft stopped selling those years ago. A legitimate install means digging out a retail key you still own; in practice, plenty of people end up hunting ISOs and keys of murky provenance instead. Go the other way, with a modern Windows 10/11 guest, and you're paying for a license just to run one free 4 MB utility from 2001.
- The disk image. A Windows guest wants tens of gigabytes of disk before you've installed anything of your own. That image then lives on your drive permanently — and needs backing up, if you'd mind losing it.
- RAM while it runs. A comfortable guest takes a couple of gigabytes away from your host machine the entire time it's open, which you will feel on an 8 GB laptop.
- Maintenance. Hypervisor updates, guest additions that break after a host OS upgrade, snapshots to manage, and an old, unpatched guest you now have to think twice about connecting to a network. A VM is a pet: it needs feeding.
None of that is wasted if you use the VM constantly. Nearly all of it is wasted if the VM exists to run one small program, occasionally.
The lighter option: a browser tab
For classic 32-bit Windows software — roughly the 1995–2008 era — you often don't need Windows at all. A WebAssembly build of Wine can run the EXE directly in a browser. ExeBrowser is exactly this: open a page, boot Wine, drop the EXE, and it runs locally in the tab with nothing installed and nothing uploaded. No ISO, no license, no setup. For an old game, a small utility, or pulling data out of a legacy program, it's minutes instead of an afternoon.
It works because Wine re-implements the Windows API rather than booting Windows, and a bundled x86 emulator supplies the CPU the browser doesn't have. (We unpack that in Wine vs. an emulator.)
Two limits to be upfront about. Speed: the CPU-emulation layer lands you at roughly 10–40% of native speed — invisible in a menu-driven utility, very visible in anything CPU-hungry. Persistence: the virtual C:\ drive lives in memory and is wiped when the tab reloads, so anything the program writes has to be downloaded before you close it. Both come up in the walkthrough below.
What this looks like in practice
Here's the whole workflow for a typical old program, end to end:
- Boot Wine. Open ExeBrowser and click Boot Wine. The runtime's filesystem is fetched on demand, so the first boot only pulls what the session actually needs rather than a full disk image.
- Load the whole folder (or a zip of it), not just the EXE. Old programs rarely travel alone — they expect DLLs, data files, and configuration sitting next to them in their install directory. Uploading the folder brings all of that along, and everything is copied into Wine's virtual
C:\drive before launch so relative paths still resolve. Dropping the lone EXE is the single most common cause of "it just won't start." - Pick the entry EXE. If the bundle contains more than one executable —
setup.exe, the app itself, an uninstaller — a picker asks which one to launch. Choose the program, or the installer if it needs installing first. - Use it. Click the canvas to capture your keyboard and mouse; press Esc to release them. The program is running locally in the tab — nothing was uploaded anywhere.
- Download your output. Before you close or reload the tab, use "Download files written by this app." It packages everything the program wrote — converted files, documents, game saves — into a zip. This step isn't optional if you care about the output: the in-memory drive is wiped on reload. On your next visit, re-upload that zip to pick up where you left off.
That's the entire lifecycle. No ISO, no snapshots, no guest additions — and also no persistence you didn't explicitly ask for, which is a feature or a limitation depending on the task.
When the browser route is the right call
- One-off tasks. Open a file, run an installer, extract something, then you're done.
- Locked-down machines. School or work devices where you can't install a VM but a browser is available.
- Classic 32-bit apps and 2D games. The engine's sweet spot — see the app guides.
- Software preservation and demos. Showing someone an old program without shipping a VM image.
- Privacy-sensitive files. The file never leaves your device; it's read locally into an in-memory drive.
When you still want a VM
- Modern 64-bit applications. The browser engine is 32-bit only.
- 3D games needing DirectX 9+ or recent GPUs. Browser-based 3D is limited.
- Software with DRM, online activation, or anti-cheat. These probe the system in ways a lightweight layer can't satisfy.
- Anything you'll use heavily, all day. Native speed and full compatibility win when it's your daily driver.
- Apps needing a real, persistent Windows environment — drivers, services, deep system integration.
A quick decision rule
Ask two questions. Is the app a classic 32-bit program (pre-2008-ish)? And is this a one-off or occasional task rather than your everyday tool? Two yeses mean a browser tab will very likely do the job, and you can save the VM for the cases that truly need it. Try the light path first — it costs nothing and takes a minute. If it doesn't run, you've lost almost no time before reaching for the heavier tool.