WSL9x: Run Linux on Windows 95/98/ME with Kernel Hackery

  • Thread Author
Windows 95 and Windows 98 have long since become punchlines in modern computing, but every so often the retro world produces something that feels less like nostalgia and more like a proof of concept for sheer engineering audacity. WSL9x is one of those projects: an experimental, GPL-3-licensed hack that aims to make Linux run inside Microsoft’s old Windows 9x family, including Windows 95, Windows 98, and Windows ME. It is not Microsoft’s Windows Subsystem for Linux, and it is not a practical alternative for daily computing; it is a technical dare, and a fascinating one at that. The project’s own framing makes clear that this is about retrocomputing, kernel plumbing, and curiosity-driven systems work rather than mainstream utility.

Retro Windows 95 computer with a screen showing Linux-on-Windows UML architecture overlay.Overview​

The immediate appeal of WSL9x is obvious: it inverts the normal expectations of both Windows and Linux. Instead of running Linux on top of modern Windows, or using a VM, or booting from separate media, the project tries to make Linux coexist with a 1990s consumer operating system that predates the NT-era assumptions behind modern Microsoft virtualization. That makes it a spectacularly odd piece of software, but also an unusually instructive one. The project reportedly uses a patched Linux 6.19 kernel and glues it into the Windows 9x environment through old-school mechanisms that would have looked at home on a beige tower in 1997.
The technical novelty matters because Windows 95, 98, and ME are not NT-based systems. They are the consumer lineage that lived on a different architectural island, with different driver models, different memory assumptions, and a much thinner separation between user space and kernel-era machinery. WSL9x therefore cannot lean on the machinery that made WSL possible on modern Windows. Instead, it appears to use a patched Linux kernel based on User-Mode Linux, a VxD driver, and a small DOS-side client called wsl.com to connect the Linux side to an MS-DOS prompt window. That is not just retro style; it is the substance of the project.
There is also a cultural layer here. Retrocomputing has become a proving ground for people who enjoy reviving abandoned ecosystems, but WSL9x stands out even by those standards because it crosses a line from “can I still make this machine useful?” into “can I make a modern kernel participate in a dead platform’s boot-time logic?” That is why the project feels closer to a systems research stunt than a hobby port. The point is not convenience. The point is to demonstrate that old boundaries are sometimes more permeable than they look.
The result is not meant to be mistaken for Microsoft’s official WSL line, nor for anything that would make Windows 95 or 98 a realistic Linux host in 2026 terms. It is a living artifact of a very specific kind of engineering culture: one that values source-level experimentation, obscure compatibility layers, and the satisfaction of making two incompatible worlds shake hands for a brief moment. That makes the project less useful than it is interesting, but no less newsworthy.

Why WSL9x Matters​

The first reason WSL9x matters is that it spotlights how much of modern computing is built on assumptions that never applied to the Windows 9x era. Contemporary Linux-on-Windows stories usually rely on virtualization, container-like isolation, or NT-era integration. WSL9x sidesteps all of that and instead asks what happens if you work with the constraints of old DOS and Windows 9x tooling. That is a very different engineering posture, and it produces very different tradeoffs.
The second reason is historical. Windows 95 and Windows 98 were the consumer face of Microsoft’s desktop dominance for years, but their architecture was never designed to host a modern multi-process Linux stack. Even the project’s own description emphasizes that Windows 9x predates Microsoft’s official WSL and the modern kernel and virtualization tools that accompany it. In practical terms, that means WSL9x is showing off compatibility-layer creativity rather than inherited platform strength.

Architectural contrast​

The architecture is the whole story. On modern Windows, WSL works because Microsoft can build on the NT kernel, virtualization support, and contemporary driver paths. WSL9x has to do something else entirely, using a patched kernel and a VxD driver in a landscape where old hardware conventions still matter. That is why the project feels so improbable: it is not merely “Linux on Windows,” but “Linux through the machinery of late-1990s consumer Windows.”
A useful way to think about it is this:
  • Modern WSL is platform engineering.
  • WSL9x is compatibility archaeology.
  • Modern WSL aims for developer convenience.
  • WSL9x aims for technical proof and retro charm.
  • Modern WSL depends on contemporary OS primitives.
  • WSL9x depends on vintage hooks that most developers have never touched.
This contrast is what makes the project such a compelling headline. It is not about beating Microsoft at its own game. It is about showing that the game itself can be played on a much older board if someone is willing to redraw the rules. That is the kind of absurdity retrocomputing thrives on.

How the Project Works​

According to the project description, WSL9x has three main building blocks. First is a patched Linux kernel derived from User-Mode Linux that substitutes Windows 9x kernel APIs for the usual POSIX assumptions. Second is a VxD driver, which is the legacy virtual device driver model used by Windows 9x. Third is a DOS-side bridge utility, wsl.com, which links the Linux environment to the command prompt workflow that still makes sense on a 9x-era machine.
This three-part structure matters because it reveals the project’s philosophy. Rather than pretending Windows 95 can behave like modern Windows, the developer appears to be using the operating system’s own old extension points. In other words, WSL9x does not modernize Windows 9x; it works through Windows 9x, which is a much more difficult and much more elegant trick.

Kernel layer​

The kernel layer is the most remarkable piece. A Linux kernel in this context cannot simply assume it will find the normal system interfaces or runtime environment it expects on a modern distribution. Instead, it must be adapted to live within the very different constraints of a 9x machine. That makes the project closer to a kernel translation experiment than a conventional port. It is also why the effort is necessarily experimental rather than polished.

Driver layer​

The VxD driver is equally important because it anchors the Linux side to the Windows 9x side. VxDs are a historical artifact, and seeing them appear in a 2026 Linux interoperability project underscores just how deeply retro this work goes. The driver is not a decorative flourish; it is the bridge that lets a modern kernel interact with a platform that was never expected to host one.

DOS integration​

The wsl.com component is the final connective tissue. Its purpose is to create a simple command-line entry point from the DOS prompt, which preserves the feel of the era and gives the user a way to interact with the Linux side without a modern GUI stack. That choice fits the project’s identity: it is not trying to pretend the 1990s never happened. It is leaning into them.
The practical implications are straightforward:
  • The project is not a drop-in replacement for WSL on modern Windows.
  • It is not a virtualization product in the usual sense.
  • It is not intended for casual users.
  • It is intended for developers, retrocomputing enthusiasts, and source-build tinkerers.
That last point is vital. The project’s value lies in what it reveals about system boundaries, not in how many desktop tasks it can replace. The ambition is real, but so is the constraint.

The Retrocomputing Appeal​

Retrocomputing succeeds when it makes old machines feel newly legible, and WSL9x does exactly that. It takes an era many users remember as the beginning of mainstream home computing and pushes it into territory nobody expected. A machine that once struggled to feel stable under a heavy browser or office suite now becomes the setting for a Linux-kernel experiment. That inversion is funny, but also revealing.
There is a nostalgia factor here, of course. Windows 95 and 98 are culturally loaded products, especially for readers who came of age in the Pentium era. The article’s own framing points out that these systems ran across hardware ranging from 386DX and 486-class machines to early Pentiums, which is part of why the project feels so improbable today. A lot of readers will not have physical access to such machines, but many will have memories of them, which makes the project feel oddly personal.

Why hobby projects matter​

Hobby projects often expose assumptions that production software hides. When a developer has to make Linux cooperate with Windows 9x APIs, the result can surface lessons about abstraction, portability, and legacy interface design that no polished commercial product would ever need to confront. That is why these experiments matter even when they are not broadly useful. They are stress tests of imagination.
The broader retro scene also benefits from projects like this because they keep old platforms in active conversation. Instead of being static museum pieces, vintage operating systems become canvases for experimentation. That keeps knowledge alive, especially around features like VxDs and DOS-era integration paths that are otherwise fading from practical memory.
A few reasons the project resonates:
  • It turns an obsolete platform into a live systems lab.
  • It blends nostalgia with real kernel-level engineering.
  • It reminds readers that software history is still hackable.
  • It makes old constraints feel creatively productive rather than limiting.
  • It offers a rare chance to see Linux and Windows 9x cooperate.
That mix of absurdity and rigor is exactly why the project is newsworthy. If it were merely a toy, it would be easy to dismiss. Instead, it looks like a serious technical exercise wearing a very silly hat.

What It Is Not​

It is just as important to understand what WSL9x is not. It is not an official Microsoft technology, and it does not make Windows 95 or 98 into modern Linux hosts in any general-purpose sense. The project’s own description, echoed in the source piece, makes plain that this is an independent retrocomputing effort with no Microsoft involvement. That distinction matters because the name can easily create confusion among readers who assume the project is somehow connected to the contemporary WSL brand.
It is also not a polished compatibility layer. The source description calls out its experimental status and frames it as a tool for developers comfortable building and testing low-level software from source. That means the barrier to entry is substantial, and the expected audience is narrow. The project is more about “can this be done?” than “should everyone use this?”

Practical limits​

The limits are not an accident; they are embedded in the design. Windows 9x systems lack the modern kernel and virtualization foundation that would make Linux hosting relatively straightforward. Any project that tries to bridge that gap is going to be fragile, specialized, and dependent on deep system knowledge. That fragility is part of the charm, but it is also the reason this cannot be confused with a consumer-ready product.
It is also worth emphasizing that the project’s appeal is not performance. Running a patched Linux kernel alongside a 1990s consumer OS is inherently a niche and likely resource-constrained proposition. If the benchmark is “How does this compare with WSL2 on Windows 11?” the answer is simple: it does not. If the benchmark is “How far can systems hacking be pushed on aging software?” the answer becomes much more interesting.
Key distinctions to keep in mind:
  • Not official WSL
  • Not a mainstream emulator
  • Not a general-purpose desktop solution
  • Not a modern virtualization stack
  • Not a replacement for dual-booting on current hardware
That clarity matters because the project’s name is intentionally playful, but the underlying work is serious. Confusing the two would miss the point entirely.

What Makes the Hack Technically Interesting​

The deepest technical interest in WSL9x comes from how it reinterprets old operating system interfaces instead of discarding them. By reportedly leaning on Windows 9x kernel APIs and a VxD driver, the project exploits the extension mechanisms that made consumer Windows flexible in the first place. That is a very different mindset from trying to shoehorn Linux into a modern Windows NT abstraction.
Another reason the project stands out is its use of a patched Linux kernel in an environment where most people would assume a kernel-level experiment would be impossible or hopelessly unstable. The source material says the current setup uses a modern Linux kernel 6.19 alongside the Windows 9x kernel, which is the sort of detail that stops the whole thing from being a mere curiosity. It suggests active engineering rather than a one-off proof screenshot.

Why User-Mode Linux matters​

Using a User-Mode Linux foundation is clever because it gives the developer a known kernel experimentation model to start from. That likely reduces some of the normal friction of porting Linux into a very unusual host environment. The important bit is not that User-Mode Linux is new; it is that it gives the project a conceptual bridge between Linux internals and an externally managed host.
The Linux kernel itself is the star here, but the real achievement is orchestration. Getting a kernel to coexist with an operating system that never anticipated this kind of cooperation requires careful control over bootstrapping, driver interaction, and command-line handoff. That is why the project feels like systems theater: every layer is part of the performance.
A few technical takeaways:
  • The project is fundamentally about kernel adaptation.
  • It relies on legacy Windows extension points.
  • It uses a DOS-era command bridge as part of the workflow.
  • It demonstrates that old APIs can still be repurposed.
  • It shows how deeply compatibility engineering can be extended.
In a world where most software discussion revolves around cloud abstraction and app sandboxes, a project like this is refreshing precisely because it drops readers back into the guts of the machine. There is no marketing veneer here, just architecture, friction, and ingenuity.

Enterprise vs Consumer Perspective​

For enterprise buyers, WSL9x has almost no direct operational value, and that is fine. Enterprises care about supportability, security, maintainability, and predictable integration paths. WSL9x is a hobby project on unsupported consumer operating systems, so it sits far outside any rational desktop management strategy. What it can offer, indirectly, is a reminder of how far Windows developer tooling has come.
For consumers, the story is more emotional than practical. Many readers will simply enjoy the idea that a long-obsolete operating system can still be coerced into doing something astonishing. That is especially true for people who remember Windows 95 and 98 as the machines they learned on, broke on, and eventually outgrew. The project taps into that memory while also making it clear that modern Linux flexibility is not the first time systems engineers have tried to bridge incompatible worlds.

Different expectations, different value​

The enterprise lens asks, “What is the support model?” The consumer lens asks, “How cool is this?” WSL9x answers the second question far better than the first. That is not a flaw; it is simply the natural result of a project designed for curiosity rather than procurement.
It also highlights a broader truth about platform evolution. Modern WSL exists because Microsoft built a strong developer story on top of a mature OS architecture. WSL9x exists because retrocomputing enthusiasts keep probing what the earlier architecture can still tolerate. The gap between those two outcomes is the story of the last quarter-century of PC engineering.
A concise comparison:
  • Enterprises need support contracts.
  • Consumers want wonder and nostalgia.
  • Microsoft wants platform stickiness.
  • Retro hackers want unexpected compatibility.
  • The project satisfies the last group almost perfectly.
That makes WSL9x a niche success by design. Its audience is small, but the signal it sends is big.

Strengths and Opportunities​

WSL9x’s biggest strength is that it transforms a joke premise into a credible engineering story. The project reportedly combines a patched Linux kernel, a VxD driver, and a DOS-side command bridge in a way that actually fits the Windows 9x world, rather than fighting it. That makes it a compelling showcase for retro systems work and a valuable teaching example for how old software boundaries can be repurposed.
It also has strong educational potential. Even people who never plan to run it can learn from the design choices, especially around legacy driver models and cross-environment bootstrapping. That gives the project a life beyond the small audience that may build it themselves.
  • It demonstrates imaginative kernel engineering.
  • It preserves knowledge of Windows 9x-era mechanisms.
  • It gives retrocomputing a genuine technical milestone.
  • It may inspire other legacy-platform experiments.
  • It helps younger readers understand why old systems mattered.
  • It proves that “unsupported” does not always mean “uninventive.”
  • It creates a shareable story that broadens interest in systems programming.
There is also a reputational opportunity for the retro scene. Projects like this help keep retrocomputing from being dismissed as pure nostalgia. They show that the field still contains active technical exploration, not just emulation, preservation, or collecting. That distinction matters.

Risks and Concerns​

The biggest risk is misunderstanding. The name WSL9x can easily mislead readers into thinking it is related to Microsoft’s official WSL product line, when it is actually an independent experiment focused on Windows 95, 98, and ME. That branding ambiguity is harmless in enthusiast circles but potentially confusing for casual readers.
A second concern is fragility. Any project built on vintage OS internals, DOS-era command hooks, and patched kernel behavior is likely to be delicate, especially across different hardware configurations. The source makes clear that this is not a polished product, which is exactly the right expectation, but it also means the project may be more impressive in demos than in sustained use.

Practical and technical limitations​

There is also the obvious maintenance issue. Old systems, old driver models, and experimental kernel patches all add up to a project that will demand attention from people who already understand low-level systems development. That raises the bar for contribution and limits the pool of testers.
Another risk is over-enthusiastic comparison with modern WSL. The project is a different category entirely, and evaluating it against Windows 11-era Linux support would miss the point. It is meant to be judged as a retro systems hack, not as a product roadmap.
  • The name can create brand confusion.
  • The architecture is likely fragile on varied hardware.
  • Contribution requires specialized low-level expertise.
  • The project is not suitable for general deployment.
  • Public expectations may exceed its actual stability.
  • Long-term maintenance may depend on a tiny community.
  • Comparisons with modern WSL can distort its real purpose.
Even so, those risks are mostly the price of admission for this kind of work. If the goal were reliability, the project would be missing the entire point.

What to Watch Next​

The most important thing to watch is whether the project remains a one-off curiosity or develops into a more structured retro platform experiment. If the developer continues publishing builds, documentation, or source changes, WSL9x could become a reference point for future legacy-OS hacking. If it stalls, it may still be remembered as a clever proof-of-concept, which is not a bad outcome in retrocomputing terms.
A second thing to watch is community response. Projects like this often attract people who want to test, port, or extend them, but they can also be overwhelmed by novelty interest rather than serious contributor energy. Whether the project attracts real kernel and retro-hardware tinkering will determine how far it goes beyond the initial headline.

Signals of maturity​

The best signal would be better documentation around how the patched kernel, VxD driver, and DOS bridge fit together. Another good sign would be a clearer explanation of which 9x systems are supported and what hardware constraints exist. If the project becomes easier to understand, it becomes easier to preserve.
Watch for these developments:
  • More detailed build and boot instructions.
  • Evidence of broader Windows 9x compatibility.
  • Clarification of the kernel patching model.
  • Community forks or contributor patches.
  • Retro hardware test reports from enthusiasts.
It will also be interesting to see whether the project inspires similar work for other legacy platforms. The underlying idea—reusing old OS extension points to host unexpected workloads—could be applied in other ways, even if the exact implementation remains unique to Windows 9x.

WSL9x is not a product, and that is precisely why it is worth paying attention to. It reminds us that software history is not just a sequence of obsolete releases; it is a pile of mechanisms that can still be recombined into something surprising when enough curiosity, patience, and kernel knowledge are thrown at the problem. A modern Linux kernel inside Windows 95 is not going to change computing for the masses, but it does say something important about the people who keep finding new things to do with old machines. In an age of increasingly sealed platforms, that kind of open-ended experimentation feels almost rebellious—and that may be the most modern thing about it.

Source: Linuxiac Someone Made a Windows 95 Subsystem for Linux
 

Back
Top