# felixrieseberg/windows95: Windows 95 in an Electron App, Reviewed

> An Electron shell around the v86 x86 emulator that boots a real Windows 95 disk image on macOS, Linux and Windows. It is a curiosity and a teaching artifact, not a virtualization tool.

**felixrieseberg/windows95** — Windows 95 in an app. Runs on macOS, Linux, and Windows.

- Repository: https://github.com/felixrieseberg/windows95
- Stars: 24,242 · Forks: 1,348
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/felixrieseberg-windows95

## What felixrieseberg/windows95 actually is, and who it is for

The README opens with a flat statement: "This is Windows 95, running in an Electron app. Yes, it's the full thing. I'm sorry." That sentence sets the tone for the whole project. It is not a reimplementation, a skin, or a web mock-up of the 1995 desktop. A real x86 machine is emulated inside a desktop application, and a Windows 95 disk image boots inside it.

The audience is narrow and specific. It suits people who want a Windows 95 machine they can launch like any other app, without configuring QEMU, VMware or 86Box first. It suits developers curious about how a TypeScript and React front end drives an emulator core. It does not suit anyone who needs a reliable retro-computing workstation, because the README is candid about the trade-off: "Bear in mind that this is written entirely in JavaScript, so please adjust your expectations." The same section answers a rhetorical question about whether it should have been a native app with one word: "Absolutely."

## The v86 core, the Electron shell and the disk image

The credits are unambiguous: "99% of the work was done over at v86 by Copy aka Fabian Hemmer and his contributors." v86 is an x86 virtualization layer written in JavaScript. This repository is the packaging around it.

The application is an Electron app. package.json names electron 42.3.3, react 19.2.6 and react-dom 19.2.6 as dependencies, with Electron Forge 7.11.2 and Vite 8.0.13 in devDependencies. The entry point is ./dist/src/main/main.js, so the main process is compiled TypeScript rather than shipped source. The UI layer is React, which is what draws the window chrome, menus and the disk-image controls around the emulated screen.

The machine state is not generated at runtime. It comes from a prebuilt Windows 95 image plus a saved snapshot. The contributing section describes the required layout as /images/windows95.img, /images/default-state.bin, /assets/..., /bios/... and /docs/... inside the src folder. The image and the state file are the two files that matter: one is the hard disk, the other is the boot state the app restores. Neither is committed to the repository.

There is also a native QEMU path for people who want to work on the image itself. The qemu script in package.json launches qemu-system-i386 with 128 MB of memory, the raw image, a Sound Blaster 16 device, a Pentium CPU and an NE2000 ISA network card on user-mode networking. It is a maintenance tool for the image, not the way the app runs.

## Installing it: prebuilt packages versus building from source

The README's Downloads section is the intended path. It lists a 32-bit and 64-bit Windows installer and standalone zip, a macOS zip for Apple Silicon and one for Intel, and rpm and deb packages for Linux on 64-bit, ARM64 and ARM. All of them point at the v5.0.1 release assets. The README adds a note for people unsure of their hardware: on Windows, the chip is probably x64, and on macOS, if the computer was bought after 2020, choose Apple Silicon.

On Debian or Ubuntu, the amd64 package is installed against the downloaded file with dpkg, and on Fedora or another rpm-based distribution the equivalent is rpm -i against the downloaded rpm. After either command the application should appear in your desktop menu, and launching it boots straight into the emulated machine. There is no first-run setup wizard, because the disk image is already prepared.

Building from source is a different job, and the README is explicit that the disk image is not part of the repository. You obtain it from a packaged release using the Show Disk Image button, which the README places in the Modify C: Drive section. Once the images folder has been unpacked into src, the README gives the build as two commands:

```bash
npm install
npm start
```

npm install also runs patch-package through the postinstall script, so any patches under the patches directory are applied automatically. If the images folder is missing or misplaced, the app has nothing to boot; the README's layout is the thing to check first. The repository also exposes npm run qemu and npm run qemu:cdrom for working on the image outside the app.

## Running it in Docker, and why the Dockerfile is a historical artifact

The repository ships a Dockerfile contributed by Paul DeCarlo, and the README links separate Docker and Kubernetes/Gitpod instructions under docs. The header comment gives the intended invocation, which mounts the X11 socket, passes the display, and attaches the sound device:

```bash
docker run -it \
 -v /tmp/.X11-unix:/tmp/.X11-unix \
 -e DISPLAY=unix$DISPLAY \
 --device /dev/snd \
 --name windows95 \
 toolboc/windows95
```

The same comment block documents the failure you are most likely to hit: if you see Gtk-WARNING **: cannot open display: unix:0, run xhost +.

Read the base image line before you rely on this. It is FROM node:10.9-stretch, and the entrypoint is npm start, which runs the Electron app. Node 10 and Debian Stretch are both long past their support windows, and the container still needs a working X server on the host. This is a route for someone who wants to see the thing run on a Linux box without installing a package, not a deployment pattern. The Kubernetes and Gitpod document exists for the same reason: it is about getting a display to the app, not about running Windows 95 as a service.

## Where it falls short: games, state and the wrong expectations

The README pre-empts the most common question. Asked whether it runs Doom, it answers: "You'll likely be better off with an actual virtualization app, but the short answer is yes." Some games are preinstalled, and more can be found elsewhere, with archive.org named as an example. The README also relays a recommendation from @DisplacedGamers to switch to 640x480 at 256 colors before starting DOS games.

That concession is the honest boundary of the project. A JavaScript x86 emulator inside an Electron renderer is slower than a native hypervisor, and the README's own framing of expectations points at performance rather than compatibility. If your goal is to run period software at speed, or to attach real hardware, this is the wrong tool.

State handling is the second limitation. The app restores a saved default state, and the repository's own help file lists entries for MS-DOS appearing to brick the screen and for Windows 95 getting stuck in a bad state. Those entries exist because the emulated machine can end up somewhere the app cannot recover from on its own. There is no documented rollback mechanism in the README beyond the shipped default state, so recovery means resetting to that state rather than undoing a specific change. The README does not document snapshot management beyond the default-state file.

## Compared with 86Box, VMware and DOSBox-X

The alternative depends on what you want. For faithful period hardware, 86Box emulates specific motherboards, chipsets and expansion cards, which is why people reach for it when a game or driver needs an exact Sound Blaster or video card. This project emulates one fixed machine configuration through v86, described in the qemu script as a Pentium-class CPU with a Sound Blaster 16 and an NE2000 card. You get that machine, not a configurable one.

VMware and VirtualBox take the opposite approach: they run the guest with hardware acceleration on the host CPU, so Windows 95 is fast, but you supply the installer media, partition the virtual disk and install the operating system yourself. That is the route the search results about installing Windows 95 on VMware describe. Here, the installation is already done and shipped as an image.

DOSBox-X targets DOS and Windows 9x compatibility with a focus on period-accurate timing for games. It gives you far more control over the emulated environment. This project gives you less control and a much shorter path from download to a running desktop. The trade is deliberate, and the README does not pretend otherwise.

## Licence, maintenance and the cost of upgrading

package.json declares "license": "MIT", and the repository contains a LICENSE.md. The README's License section adds a scope statement that matters more than the identifier: "This project is provided for educational purposes only. It is not affiliated with and has not been approved by Microsoft." The MIT grant covers the code in this repository. It does not cover Windows 95 itself, which is Microsoft's, and it does not cover the v86 core, which is a separate project with its own terms. Anyone redistributing a build that bundles the disk image is making a judgement the README does not make for them. This is not legal advice; read LICENSE.md and the upstream licences.

The repository is not archived, and the last push was on 2026-09-11, which is recent. Releases are less frequent: v5.0.0 and v5.0.1 both landed on 2026-04-13, and v4.0.0 on 2025-02-21. Note that package.json carries version 6.0.0 while the newest published release is v5.0.1, so the source tree is ahead of the release artifacts. If you install a package, you are installing the v5.0.1 build, not the current source.

Upgrade cost is low for packaged installs, since the app updates itself through update-electron-app. It is higher for source builds, because the toolchain moves: Electron 42, TypeScript 6 and Vite 8 are all current-generation dependencies, and patch-package reapplies patches on every install. A patch that no longer applies after a dependency bump will fail the install rather than the build, which is the failure to watch for.

## Conclusion

Adopt it if you want a self-contained Windows 95 machine for demos, nostalgia or teaching how an emulator is wired into an Electron shell, and you accept that the README itself says you are better off with a real virtualization app for games. Skip it if you need USB passthrough, arbitrary drive images, or a headless server VM. Before anything else, confirm which artifact matches your machine: the README notes that if you bought your computer after 2020 you likely want the Apple Silicon zip, and that on Windows the chip is probably x64. Source builders should verify that images/windows95.img and images/default-state.bin are in place, because the disk image is not in the repository.

## FAQ

### How do I install felixrieseberg/windows95 on Linux?

Download the package matching your architecture from the v5.0.1 release and install it with dpkg or rpm. The README lists deb and rpm builds for 64-bit, ARM64 and ARM.

### Can I run felixrieseberg/windows95 without installing anything on my machine?

The repository includes a Dockerfile that runs the app in a container, with the run command documented in the file header. It still needs an X11 display on the host, and the base image is node:10.9-stretch.

### Does felixrieseberg/windows95 run games?

The README says you will likely be better off with an actual virtualization app, but confirms that games run and that some are preinstalled. It recommends switching to 640x480 at 256 colors before starting DOS games.

### Why does npm start fail after cloning felixrieseberg/windows95?

The disk image is not in the repository. You need to get it from a packaged release using the Show Disk Image button and unpack the images folder into src so that images/windows95.img and images/default-state.bin exist.

### Is felixrieseberg/windows95 the same as v86?

No. The README credits v86 with 99% of the work. This project packages that emulator core inside an Electron app with a React interface and a prepared Windows 95 disk image.

## Sources

- [felixrieseberg/windows95 on GitHub](https://github.com/felixrieseberg/windows95)
- [Issues](https://github.com/felixrieseberg/windows95/issues)
- [README](https://github.com/felixrieseberg/windows95/blob/main/README.md)
- [Releases](https://github.com/felixrieseberg/windows95/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/felixrieseberg-windows95