89c0a8575d
* Rewrite update-v86.js for the current build pipeline Both v86 fixes we've been carrying are now real branches on the fork (PR #1540 electron-renderer-fs-loader, PR #1541 ide-shared-registers) combined as felixrieseberg/v86:windows95-base. update-v86.js no longer needs to patch sources at build time — it just builds whatever's checked out and copies the result. Gone: the fallback-to-copy.sh path, the skew-day check, the structural regex patches for load_file/exportSymbol/fetch-bind, the phantom-slave guard (both are in the branch), the --js-only flag. If you don't have cargo/clang/java/closure, the script fails loudly — no silent fallbacks. Added: sanity checks against the installed libv86.js for the invariants our SMB integration and parcel-build shim depend on, so if upstream changes something load-bearing we see it as a WARN at update time instead of a runtime failure. Tested end-to-end: 5/5 sanity checks, fresh boot SUCCESS in 32s. * docs and skills: capture SMB/v86/testing knowledge from the session - docs/smb-share.md: user-facing SMB integration overview (how to mount in Win95, what's implemented, what's not). Points at the protocol-level README inside src/renderer/smb/ for wire-level gotchas. - .claude/skills/probe-win95: how to boot and test the VM without a human. Env vars, file locations, failure modes, the XT scancode keyboard trick, bisect rules of thumb. - .claude/skills/update-v86: how to pull upstream v86 changes, what the five sanity-check WARNs mean, how to retire the fork branches when the PRs merge upstream. .gitignore narrowed to exclude only the runtime dirs (scheduled_tasks.lock, worktrees) instead of the whole .claude/ tree, so skills can be committed.
windows95
This is Windows 95, running in an Electron app. Yes, it's the full thing. I'm sorry.
Downloads
 Windows |
32-bit
💿 Installer
|
📦 Standalone Zip
64-bit 💿 Installer | 📦 Standalone Zip ARM64 💿 Installer | 📦 Standalone Zip ❓ Don't know what kind of chip you have? It's probably `x64`. To confirm, on your computer, hit Start, enter "processor" for info. |
 macOS |
Apple Silicon Processor
📦 Standalone Zip
Intel Processor 📦 Standalone Zip ❓ Don't know what kind of chip you have? If you bought your computer after 2020, select "Apple Silicon". Learn more at apple.com. |
 Linux |
64-bit
💿 rpm
|
💿 deb
|
|
|
|
Does it work?
Yes! Quite well, actually - on macOS, Windows, and Linux. Bear in mind that this is written entirely in JavaScript, so please adjust your expectations.
Should this have been a native app?
Absolutely.
Does it run Doom (or my other favorite game)?
You'll likely be better off with an actual virtualization app, but the short answer is yes. In fact, a few games are already preinstalled - and more can be found on the Internet, for instance at archive.org. Thanks to @DisplacedGamers I can recommend that you switch to a resolution of 640x480 @ 256 colors before starting DOS games - just like in the good ol' days.
Credits
99% of the work was done over at v86 by Copy aka Fabian Hemmer and his contributors.
Contributing
Before you can run this from source, you'll need the disk image. It's not part of the
repository, but you can grab it using the Show Disk Image button from the packaged
release, which does include the disk image. You can find that button in the
Modify C: Drive section.
Unpack the images folder into the src folder, creating this layout:
- /images/windows95.img
- /images/default-state.bin
- /assets/...
- /bios/...
- /docs/...
Once you've done so, run npm install and npm start to run your local build.
If you want to tinker with the image or make a new one, check out the QEMU docs.
Other Questions
- MS-DOS seems to brick the screen
- Windows 95 is stuck in a bad state
- I want to install additional apps or games
- Running in Docker
- Running in an online VM with Kubernetes and Gitpod
License
This project is provided for educational purposes only. It is not affiliated with and has not been approved by Microsoft.