VirtualXP: a Windows XP machine that boots inside a browser tab

A whole desktop where a tab used to be

VirtualXP boots an operating system inside a web page. The repository description is one line, a virtual machine running in a web browser, and the screenshot linked from the README shows a familiar Windows XP desktop rather than a terminal emulator or a window manager app. That distinction matters for what kind of use you get. This is not a web terminal with a shell prompt, and it is not a DOS box. You get a full Windows XP image, rendered by the browser, with a filesystem, a registry and a RAM disk, running without an emulator binary that you had to install and trust on your own machine.

The audience is narrow by nature. Researchers who want to inspect a Windows XP environment without a hypervisor, teachers who want a disposable machine for a demonstration, and hobbyists who want to see how far a browser-based virtual machine can be pushed all fall into that group. The README states plainly that the minified Windows XP image is provided for educational purposes only, and that the demo is not affiliated with or endorsed by the respective copyright holders. That disclaimer is doing real work in the legal sense of expectations, so treat the image as a teaching artifact rather than a redistribution channel.

Halfix underneath, with a small set of changed files

The README states that VirtualXP is a modified version of Halfix, linking the upstream project at github.com/nepx/halfix. So the architecture is not invented here. Halfix is the browser virtual machine layer, and VirtualXP takes that base and swaps in its own disk, its own boot blobs and its own configuration.

The top-level repository listing shows how thin that modification layer is. Alongside the README and a screenshot sit VirtualXP.htm, the page that hosts the machine, VirtualXP.js, VirtualXPLoader.js, worker.js, VirtualXP.json, a VirtualXP.wasm binary, VirtualXPBIOS.bin, VirtualXPVGA.bin, an icon set in three PNG sizes, a share image, and the payload itself, VirtualXP.iso. The presence of VirtualXPBIOS.bin and VirtualXPVGA.bin next to the image says that the BIOS and the VGA BIOS are carried as separate blobs rather than folded into the disk image, which is the shape a virtual machine expects when it starts a guest from a compact ROM image.

The README does not document the internal format of VirtualXP.json, and it does not explain what worker.js does. Those files are there to be read, and the project invites exactly that: the point of a browser-based machine is that the whole thing can be inspected in a text editor.

Loading the machine from the published page

There is no install step, no package manager and no build script. The project is delivered as a hosted page, and the README points at it directly:

https://lrusso.github.io/VirtualXP/VirtualXP.htm

Opening that URL in a browser is the whole install procedure. Everything the machine needs travels with the page, which is why the repository also carries a VirtualXP.iso file rather than a download link to some external image host. A reader who wants to run it offline can serve the repository directory from any static file server and open VirtualXP.htm from there instead.

The first real use is not a command. You wait for the guest to boot, then work inside the Windows XP desktop the browser is rendering. The interesting configuration step, the one that separates VirtualXP from simply opening the hosted page, is editing the machine's registry while it is switched off, which is covered next. What you should see on a successful load is a Windows XP desktop rendered in the page with a working pointer, because the project ships both the BIOS and the VGA blob needed to draw that screen.

Mounting the offline registry hives with reg load

The registry inside the image is a set of ordinary Windows registry hive files, and the README explains exactly which ones. Inside VirtualXP.iso the System Registry lives in two files, and the mapping is given as a table: HKEY_CURRENT_USER corresponds to the path \I386\SYSTEM32\CONFIG\DEFAULT, and HKEY_LOCAL_MACHINE corresponds to \I386\SYSTEM32\CONFIG\SOFTWARE. To edit them you copy those two files out of the image onto a hard drive that has a standard Windows installation, then mount each hive under an offline key:

reg load HKCU\OFFLINE C:\DEFAULT
reg load HKLM\OFFLINE C:\SOFTWARE

After that the hives are visible in Registry Editor under HKEY_CURRENT_USER\OFFLINE and HKEY_LOCAL_MACHINE\OFFLINE, and the settings the virtual machine reads can be changed there. When the edits are done the hives are unmounted, which both removes the mounted keys and writes the changes back into the files:

reg unload HKCU\OFFLINE
reg unload HKLM\OFFLINE

Finally the modified DEFAULT and SOFTWARE files are copied back into the VirtualXP.iso image. Two constraints follow from the workflow itself. The hive paths end in a DEFAULT and a SOFTWARE file, so the copy step has to preserve those exact names, and the unload step is what commits the edits, so skipping it silently discards the work.

Rebuilding the RAM disk with a 7-Zip self-extractor

The second editable artifact is a self-extracting executable stored inside the image as \MODELRAM.EXE. The README explains that it was created with the 7-Zip command line and that it automatically extracts a Documents and Settings folder into the RAM disk when VirtualXP boots. In other words, the image ships a prebuilt archive whose job is to populate the RAM disk at boot, and the way to change what lands in that RAM disk is to rebuild the archive.

The command is given in full:

7z a MODELRAM.EXE -mx9 -sfx "Documents and Settings"

The pieces are worth reading rather than copying blindly. The a flag adds files to the archive, -mx9 selects maximum compression, -sfx makes the output a self-extracting executable, and the quoted Documents and Settings argument is the directory whose contents get packed. The output is the MODELRAM.EXE file that goes back into the image in place of the previous one, and the README notes that Magic ISO Maker and WinImage were the tools used to change the ISO content in the first place. So the maintenance loop for VirtualXP is a hand-built toolchain rather than a script: an ISO editor, 7-Zip for the RAM disk payload, and a Windows machine with reg.exe for the hives.

Where this approach stops working

Several limits are visible in the repository itself, and none of them are hidden by the documentation. The first is licensing. The repository's licence is not stated, and the top-level file listing contains no licence file next to the README, the page and the image. For a project that ships a Microsoft operating system image, that is a genuine constraint on any plan to redistribute or build on it.

The second is the release process. There are no GitHub releases, and the last push was on 2026-05-24. Nothing in the repository provides a changelog, a versioned artifact or a build script that regenerates VirtualXP.iso, so a visitor has to trust the checked-in image as-is. That image is described as minified, which is the right call for a payload that has to travel over a web connection, but it also means the contents are not in an editable form.

The third limit is the operating system itself. Windows XP is a two-decade-old platform with a browser-based machine of this kind inheriting every limitation that implies, from the ancient networking stack to the graphics drivers the VGA blob emulates. The README does not document how to add a network adapter, how to share files with the host, or how to get an image other than the bundled one into the machine. If your task needs any of those, this is the wrong tool.

A browser guest against a hosted desktop and a local hypervisor

The realistic alternatives sit at two ends of the range. At one end is a hosted remote desktop or a managed virtual machine you rent, where someone else owns the kernel, the updates and the uptime. At the other is a local hypervisor, where the guest is a process on your own machine with its own disk image and your own snapshot tooling.

VirtualXP sits between them and the difference is specific rather than promotional. A hosted desktop gives you a persistent, patched machine with network access and a support path, and it asks nothing of your browser beyond a login. A local hypervisor gives you snapshots, shared folders and full control of the image, and it asks for a real hypervisor install and a Windows licence to run the guest legally. VirtualXP asks for a browser and a JavaScript engine, and it gives you a guest that disappears when the tab closes, with no persistence beyond the ISO file in the repository and no obvious path to a snapshot.

That profile is a good fit for a self-contained research box and a poor fit for anything long-lived. The launch path is also the shortest of the three by a wide margin, since a page URL is all you need.

An open payload with an open build process

The appeal of the project is that the whole machine is inspectable. The ISO, the BIOS blob, the VGA blob, the page, the loader and the worker script all sit in the repository, and the two editable subsystems, the registry hives and the RAM disk archive, come with the exact commands needed to change them. For a machine that runs an entire operating system inside a browser tab, that transparency is the main thing on offer, and it is genuine rather than claimed, since the file listing matches the story in the README.

What it does not offer is a reproducible build. Regenerating VirtualXP.iso from scratch needs Magic ISO Maker, WinImage, 7z and a Windows host with the registry hives copied out by hand, and none of that is scripted. Combined with the unstated licence and the absence of releases, the practical conclusion is that VirtualXP is best treated as a legible, modifiable artifact you can read end to end and adjust for a specific experiment, rather than as a maintained product with a support channel. The last commit on 2026-05-24 is a useful marker for anyone who returns to it and finds the browser behaviour has drifted.

Editorial conclusion

Adopt VirtualXP if you need a throwaway Windows XP environment for research, malware triage in a lab you control or plain curiosity, and you are comfortable editing raw registry hives and rebuilding an ISO by hand. Do not adopt it as a production desktop, a shared remote session or a base for anything you intend to ship, because the licence is unstated, the image is minified and the last push was on 2026-05-24 with no tagged releases. Before trusting it with anything real, open VirtualXP.htm from the published site, confirm the machine boots in your browser, and diff the checked-in VirtualXP.iso against the one your build would produce before you change a single registry key.

Frequently asked questions

Official sources

1. Issues
2. lrusso/VirtualXP on GitHub
3. README