Is this person a wizard?
To me, this seems an impossible feat.
But I wonder how it seems to people who understand how it works?
I'm reminded of this joke:
Two mathematicians are talking. One says a theorem is trivial. After two hours of explanation, the other agrees that it is indeed trivial.
> But I wonder how it seems to people who understand how it works?
As someone who mostly understands what's going on - It does not seem like wizardry to me, but I am very impressed that the author figured out the long list of arcane details needed to make it work.
> this seems an impossible feat
What makes you think so?
Never heard of this joke, very funny !
AAA+ joke
With AI everybody can be a wizard ;)
The README states:
> Proudly written without AI.
As the repo says
> Proudly written without AI.
Stuff like this is far above the capabilities of today’s top AIs.
It’ll produce something, sure, but it won’t actually work, and making it work takes as much effort as building it from scratch.
Before WSL, the best ways to run unmodified Linux binaries inside Windows were CoLinux and flinux.
https://github.com/wishstudio/flinux
flinux essentially had the architecture of WSL1, while CoLinux was more like WSL2 with a Linux kernel side-loaded.
Cygwin was technically the correct approach: native POSIX binaries on Windows rather than hacking in some foreign Linux plumbing. Since it was merely a lightweight DLL to link to (or a bunch of them), it also kept the cruft low without messing with ring 0.
However, it lacked the convenience of a CLI package manager back then, and I remember being hooked on CoLinux when I had to work on Windows.
Cygwin is way older than CoLinux. CoLinux is from 2004. Cygwin was first released in 1995.
The problem with Cygwin as I remember it was DLL hell. You'd have applications (such as a OpenSSH port for Windows) which would include their own cygwin1.dll and then you'd have issues with different versions of said DLL.
Cygwin had less overhead which mattered in a world of limited RAM and heavy, limited swapping (x86-32, limited I/O, PATA, ...).
Those constraints also meant native applications instead of Web 2.0 NodeJS and what not. Java specifically had a bad name, and back then not even a coherent UI toolkit.
As always: two steps forward, one step back.
Just use ssh from Cygwin. DLL hell was rarely a problem, just always install everything via setup.exe.
The single biggest problem it has is slow forking. I learned to write my scripts in pure bash as much as possible, or as a composition of streaming executables, and avoid executing an executable per line of input or similar.
Try using the Windows busybox port of "Bash":
https://frippery.org/busybox/index.html
It has a subset of bash implemented on Ash/Dash. Arrays are not supported, but it is quite fast.
The forking problem is still present, though.
Cygwin bash isn't slow either. The problem is a typical bash script isn't a series of bash operations, it's a series of command line program executions.
For example, someone might do something like this (completely ignoring the need to quote in the interests of illustrating the actual issue, forking):
for x in *; do
new_name=$(echo $x | sed 's/old/new/')
mv $x $new_name
done
Instead of something like this: for x in *; do
echo $x
done | sed -r 's|(.*)old(.*)|mv \1old\2 \1new\2|' | grep '^mv ' | bash
This avoids a sed invocation per loop and eliminates self-renames, but it's harder to work with.Of course the code as written is completely unusuable in the presence of spaces or other weird characters in filenames, do not use this.
Slow forking is only the second biggest problem IMO. The biggest is the lack of proper signals. There's a bunch of software out there that just isn't architected to work well without non-cooperative preemption.
Huh? Signals have worked fine for a long time under Cygwin.
> Cygwin had less overhead which mattered in a world of limited RAM and heavy, limited swapping (x86-32, limited I/O, PATA, ...).
Maybe so, but my memory of Cygwin was waiting multiple seconds just for the Cygwin CLI prompt to load. It was very slow on my machines.
> Java specifically had a bad name, and back then not even a coherent UI toolkit.
Java was ahead of its time, now nothing has a coherent UI toolkit.
Meanwhile those that complained about Java, now ship a whole browser with their "native" application, and then complain about Google taking over the Web.
I think those are two solidly different camps of people
Technically correct by some estimation, perhaps, but Cygwin is a crazy approach, was slow (contrary to the implication of the "low cruft" claim), was not as compatible as these other approaches, required recompilation, and was widely disliked at most points in its life. There's a lot of crazy voodoo stuff happening in cygwin1.dll to make this work; it totally qualifies as "hacking in some foreign Linux plumbing", it's just happening inside your process. Just picture how fork() is implemented inside cygwin1.dll without any system support.
Cygwin doesn't work at all in Windows AppContainer package isolation; too many voodoo hacks. MSYS2 uses it to this day, and as a result you can't run any MSYS2 binaries in an AppContainer. Had to take a completely different route for Claude Code sandboxing because of this: Claude Code wants Git for Windows, and Git for Windows distributes MSYS2-built binaries of bash.exe and friends. Truly native Windows builds don't do all the unusual compatibility hacks that cygwin1.dll requires; I found non-MSYS2-built binaries of the same programs all ran fine in AppContainer.
Nowadays MSYS2, which does depend on cygwin under the hood, offers such a package manager (pacman of Arch Linux) and it is quite a user friendly to run native POSIX binaries on Windows without a linux VM.
In my personal experience, Msys 2 would work great until it didn't. Unless this has changed, from what I remember, Msys2 compiled everything without PIC/PIE, and Windows does allow you to configure, system-wide, whether ASLR is used, and whether it's used "if supported" or always. If that setting is set to anything but off, Msys2 binaries will randomly crash with heap allocation errors, or they do on my system. It happened so much to me when I had actual coreutils installed that I switched to uutils-coreutils even though I knew that uutils-coreutils has some discrepancies/issues. Idk if they've fixed that bug or not; I did ask them once why they didn't just allow full ASLR and get on with things and they claimed that they needed to do non-ASLR compilations for docker.
MSYS2 is my favorite in this area. Super lightweight and easy to use, highly recommend.
w64devkit it's fine too; with just a few PATH settings and SDL2 libraries I could even compile UXN and some small SDl2 bound emulators.
I remember when I first put cygwin in my path on Windows and it felt like magic. I can just ssh and git now? No need for putty or WinGit????
Developing on cygwin, however, was a right pain. If a C library you wanted to use didn't have a pre-built cygwin version (understandable!) then you end up doing 'configure, make' on everything in the dependency tree, and from memory about two thirds of the time you had to edit something because it's not quite POSIX enough sometimes.
Ha ha doing Unix like it was 1989. At the time I thought configure was the greatest of human achievements since I was distributing software amongst Sun machines of varying vintage and a Pyramid. I want to say good times but I prefer now ha ha
autotools felt old even in 90's
Cygwin implements a POSIX API on Win32 with a smattering of Nt* calls to improve compatibility but there's a lot of hoop jumping and hackery to get the right semantics. Fork isn't copy on write, for one thing.
I was a Cygwin user from about 1999 to 2022 or so, spent a little time on wsl2 (and it's what I still use on my laptop) but I'm fully Linux on the desktop since last year.
Nope, the best way was VMWare Workstation, followed by Virtual Box.
And before those Virtual PC by Connectix. Which Microsoft bought and dumped.
I thought WSL2 is functionally a virtual machine with deep host integration. That’s why you need HyperV.
Sort of. Technically speaking, just enabling hyper-v turns your base windows install into a VM. Wsl2 then just runs along side
I've been running colinux for years until early 2009 when I reinstalled my laptop with Ubuntu 8.04 and Windows XP in a VM. So much faster.
On Windows NT building software from source under Interix[0] (nee OpenNT, later "Subsystem for Unix Applications") was pretty nice.
Interix was implemented as proper NT kernel "subsystem". It was just another build target for GNU automake, for example.
(Being that Interix was a real kernel subsystem I have this fever dream idea of a text-mode "distribution" of NT running w/o any Win32 subsystem.)
>Cygwin was technically the correct approach
Requiring every single Linux app developer to recompile their app using Cygwin and account for quirks that it may have is not the correct approach. Having Microsoft handle all of the compatibility concerns scales much better.
The NT kernel (used in NT 3.1 through 2000, XP, and eventually backported to Windows 10/11's WSL) was designed from scratch in 1993 with a POSIX subsystem from day one. The whole design philosophy was "multiple personalities" - handle syscalls from different environments by translating them to native NT kernel calls. WSL1 in 2016 essentially reimplemented that same trick for Linux.
Windows 9x, by contrast, was DOS-derived. Running Linux inside it would require fundamentally different (and messier) hacks - which is probably why nobody did it at the time. The very fact that this works at all is a testament to how ahead-of-its-time NT's architecture was.
For a practical answer: you'd need something like this for legacy locked-in situations. Old medical or industrial software that only runs on Windows 98, or specialized hardware without modern drivers. That said, if you have a 486 handy in 2026, running Linux natively is almost certainly more useful than running it inside a 30-year-old DOS derivative.
All of this is true, but this is not unprecedented: after all Windows 9x was able to run DOS, and that took no shortage of wizardry
Some interesting reading:
1. What was the role of MS-DOS in Windows 95? (https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24...)
2. Why doesn’t Windows 95 format floppy disks smoothly? (https://devblogs.microsoft.com/oldnewthing/20090102-00/?p=19...)
3. Running MS-DOS programs in a window alongside other Windows programs (https://devblogs.microsoft.com/oldnewthing/20231127-00/?p=10...)
So, is it like colinux[0], but for pre-NT windows? Neat!
Back when I was still using windows (probably XP era), I used to run colinux, it was kind of amazing, setting up something like LAMP stack on the linux side was a lot easier and then using windows editors for editing made for quite nice local dev env, I think! Could even try some of the X11 servers on windows and use a linux desktop on top of windows.
When I noticed I kept inching towards more and more unixy enviornment on the windows, I eventually switched to macOS.
Apart from the obvious hack-value, I can't quite imagine even pretend use-case, with some 486 era machine, you would be limited by memory quite quickly!
Colinux was a tech feat, just not that many people noticed.
> Proudly written with zero AI.
Unfortunately this is ambiguous, as there's an AI product called Zero AI.
> Proudly written without AI.
Looks like it's been updated now to be more clear. Amazing though.
Looks like opportunity for new AI product called "without AI".
By microsoft's naming scheme this should be Linux Subsystem for Windows
No? WSL is Linux on Windows — so W9xSL is Linux on Windows 9x. I think… :)
WSL is "Windows Subsystem for Linux", so this should be "Linux Subsystem for Windows 9x"
By Microsoft’s convention, that would be a way to run Windows 9x on Linux. It’s a bit confusing. Another example is “Windows Subsystem for Android”, which is what they use for running Android apps on Windows. I think the idea is that it’s not a “Windows Subsystem” for X, but rather a Windows “Subsystem for X”.
(Edited: mixed it up on the last sentence.)
> that would be a way to run Windows 9x on Linux
Which is exactly what the post says this is. It's running Windows 9x on Linux kernel. It's strangely worded, but from the follow up comment, and the readme in the repo it seems clear that it's running on the Linux kernel.
> WSL9x runs a modern Linux kernel (6.19 at time of writing) cooperatively inside the Windows 9x kernel
Pretty sure it's the other way around. But I haven't had my coffee yet ;)
Microsoft's naming scheme confuses me every single time though: "Windows Subsystem for Linux" actually runs Linux on Windows...
You're correct: "WSL9x runs a modern Linux kernel (6.19 at time of writing) cooperatively inside the Windows 9x kernel"
I missed the part that it runs on the bloody Windows 9x kernel, I was to busy thinking about modern Windows.
Yeah it makes more sense if you consider the word Windows' to be in possessive form.
Yeah this has never made sense...
Especially since the other subsystems were referred to as the OS/2 subsystem, Posix subsystem, Win32 subsystem, Security subsystem, etc
It makes tons of sense if you understand marketing and that the brand "Windows" must always come first.
Does that explain Word for Windows?
Windows Subsystem for Word
Windows Program for Word
I guess easier than https://github.com/haileys/doslinux
Well it did take me 6 years to follow that up!
Can we get an official statement on which OS your project runs inside which OS? It's left slightly unclear, for the uninitiated!
doslinux is some tricky sleight of hand where it looks like Linux is running inside DOS, but it's actually the other way around (even though DOS boots first).
WSL9x takes quite a different approach. Windows boots first, but once Linux starts both kernels are running side-by-side in ring 0 with full privileges. They are supposed to cooperate, but if either crashes then both go down.
Modern linux kernel running cooperatively inside the Windows 9x kernel, sick!
I want a Linux Subsystem for Windows 9x or MS-DOS :P
> "no hardware virtualisation"
> looks inside
> virtual 8086 mode
that’s virtualization, not virtualisation
Little late but would this have actually allowed running early Linux under Windows when Windows 95 came out in the 90s? I remember only dual booting being available at that time.
I thought this was about running windows 9x within linux. Is there such thing without virtualisation?
You can setup handlers to automatically launch windows executables using wine/proton .
This trickery is called binfmt_misc , which is a linux kernel system to associate random binary files with custom userspace 'interpreters'
I have had it working in the past. And while it is kinda neat I prefer manually running 'wine program.exe' to have a bit more control.
I have seen reports that a binfmt_misc setup + wine is good enough to get infected by certain windows viruses ;-P
Is wine compatible enough with Iloveyou.vbs?
If I can get this to work (haven't tried yet) it directly solves a problem I have right now this week right here in 2026, 30 years after Windows 95 was even a thing.
Yes, I have weird problems. I get to look after some very weird shit.
Old still running 24/7 industrial processing circuit with oddball bespoke addons based on DOS / early windows ??
Still got those in this part of the world sharing space with state of the art autonomous 100+ tonne robo trucks.
If you're dealing with weird legacy 9x systems in 2026, another headache you've probably run into is getting them to talk to the modern web (since modern TLS and JS completely break old browsers).
I actually built a win9x compatibility mode into BrowserBox specifically for this kind of weirdness. You run the server on a modern system and launch it with bbx win9x-run, and it proxies the modern web to legacy clients. It works surprisingly well with IE5, IE6, and old Netscape on Windows 95/98/NT. Might be a fun addition to your retro utility belt!
When backward compatibility used to mean something man!
Tell us more!
Probably works for a bank.
And likely in ATM servicing.
Just few months ago seen windows 95 error message on HSBC ATM.
Hmm I wonder how stable it is.. It cannot render correctly Window control buttons (Minimize, Maximize, Close). If it fails on such basic task, I wonder where it crashes...
That's a graphics driver problem. Fairly common to see when running Windows 9x/Me under QEMU.
Everytime I see something like this, I'm like, how in the hell did they learn and then figure this out? Congrats on this!!!! I will definitely have to play with this for some of that sweet nostalga.
I am going to run this in Windows 95 on a Sun PC card under Solaris 7.
from the same commenter who effused jesus fucking christ this is an abomination of epic proportions that has no right to exist in a just universe and I love it so muchHumans are weird and can loath and desire a thing at the same time; the success of Brutalism for example.
/off to fire up Windows95 on the Octane2 and get me some hot Linux action ..
Wait until you find IE was released for Unix, using some Win32 shims. And... die hard Unix sysadmin ran it under FVWM and compared to Netscape wasn't half bad. Both propietary, but sadly NScape didn't open Mozilla yet, and the rest of the alternatives such as Arena/Amaya coudn't compete with 'modern' CSS features and the like.
Speaking of vintage IE and Netscape on old Win, it's actually still possible to use them to browse the modern web if you proxy it.
I built a Win9x compatibility mode for BrowserBox that does exactly this (https://github.com/BrowserBox/BrowserBox/blob/main/readme-fi...). Ur modern server does all the rendering, and it outputs a client link specifically designed for legacy browsers like IE5, IE6, and Netscape running on Windows 95/98/NT, streaming them the pixels. It's definitely an abomination, but there's something magical and retro that I like about viewing the 2026 internet through an IE6 window ;) ;p xx
There are better ways:
- Retrozilla with some about:config flags disabling old SSL cyphers and new keys to enable newer ones
- Iron TCL maybe with KernelEx and BFGXP from https://luxferre.top reading gopher and gemini sites such as gemini://gemi.dev proxying all the web bloat and slimming it down like crazy
- Same Gemini URL, but thru http://portal.mozz.us/gemini . Double proxy in the end, but it will be readable.
Is this Win4Lin resurrected?
This. The post immediately reminded me of Win4Lin 9x (the version before it became just another boring VM) and SCO Merge. It was insanely fast, even on the hardware of the day.
The Wikipedia page is not verify informative and presents it as a regular VM (possibly mixing up 9x and later versions that run the NT line of kernels). The manual is a bit more informative about the tech:
ilab.usc.edu/packages/special/Win4Lin-3.0.1-manual.pdf
I’m a bit surprised it hasn’t been mentioned a lot in the comments. Maybe it’s a bit too old for most people here (Linux in the late 90ies/early 00s was a much smaller community)?
Can someone explain me the so what? Like it is impressive, but why do we need it?
Sometimes people do cool things for fun, without the express intent of maximizing their BALANCE integer in their bank's SQL table.
Not everything needs to be "needed".
Incredible that current Linux kernels still have 486 support!
Which is really weird because I thought it didn't, per https://www.theregister.com/2025/05/07/linux_kernel_drops_48...
Maybe there's some detail I don't quite follow, like is has support for 486, but only those with a built in FPU?
pretty sure 486 support only _just_ got disabled, and will be gone with 7.1: https://www.phoronix.com/news/Linux-7.1-Phasing-Out-i486
Not for long anymore, apparently.
Does this mean it runs on Linux or runs on Windows. I can never tell with this MS "subsystem" naming.
WSL was a subsystem to run Linux under Windows 10 without an explicit VM host. It was an Ubuntu Linux version. Later MS released WSL2, complete redesign, still for Windows 10. With Windows 11 the WSL2 also supported GUI programs.
I think the answer is "yes"
This could prompt me to finally assemble the Pentium desktop I have in storage in parts.
lol, if you do assemble that Pentium desktop, one of the first things you'll notice is that the modern web is completely unusable on it natively.
To get around that, I recently added a legacy compatibility mode to BrowserBox (bbx win9x-run). It basically lets you run the server on your modern daily driver, and access it via IE 5, IE 6, or Netscape on the Pentium box. It strips away the modern TLS/JS rendering issues and lets you actually browse the modern web from Windows 9x. Highly recommend giving it a spin if you get that machine built!
Oddly enough, I could kind of use this right now. I have some software which used SCSI (Adaptec WNASPI32.dll) calls to administer a device over the SCSI bus .. would this Subsystem be usable for that, or does it still require I build a WNASP32.dll shim to do translation?
So, you have Windows software. This "Windows 9x Subsystem for Linux" just boots Windows 95. I don't know what you would use the Linux part for. Care to explain more what you want to do?
If you want to run your windows software in Linux, you could try Wine. Wine seems to have support for WNASPI so it's possible your software would just work. (You might have to run Wine as root I guess, to get access to the SCSI devices.)
If Wine doesn't work, Windows in QEMU with PCI passthrough to the SCSI controller might have better chances to work.
I need raw SCSI I/O to be virtualizable in the linux context, so I could run a Windows app (yes it already works in Wine), and have it 'see' a SCSI device as if it were real hardware.
Wines WNASPI32.dll is really just a facade - it doesn't provide actual SCSI services, its just there for SCSI-using apps to think they have ASPI onboard - so for my case I would need to write a shim to pass through SCSI IO requests to a Linux service - or loopback file? - to actually process the requests. I've been meaning to do this for a long time, but if there is some way I can set up a loopback file under Linux to 'pretend' to be a SCSI block device for a Windows app, I'd sure like to know if its possible ..
Okay what is it with WSL naming, this always confuses me. Shouldn't it be Linux subsystem for Windows?
If you google there are many reasonable reasons for it. But the most straight forward is:
> Because we cannot name something leading with a trademark owned by someone else.
https://xcancel.com/richturn_ms/status/1245481405947076610?s...
> Because we cannot name something leading with a trademark owned by someone else.
And this WSL project is going to run into the same problem.
Should have called it LINE.
also trademarked
The core of the software is a subsystem, specifically a Windows subsystem; you're not running this subsystem on macOS or FreeBSD.
The "for Linux" is added because it's a subsystem for Linux applications (originally not leveraging a VM).
Microsoft also had the "Microsoft POSIX subsystem" (1993) and "Windows Services for UNIX" (1999) which were built on the "Subsystem for Unix-based Applications" (rather than "Unix-based Application Subsystem"). That chain of subsystems died at the end of Windows 8, though.
There are many reasons not to put "Linux" in front, but the naming is consistent with Microsoft's naming inconsistencies. It's not the first time they used "subsystem for" and it's not the first time they used "Windows x for y" either.
The naming is ambiguous, you could interpret the Windows subsystem for Linux as a subsystem of Linux (if it had such a thing) that runs Windows, or as a Windows subsystem for use with Linux. Swapping the order doesn't change that.
In other languages, the difference would be clearer.
To me, it sounds like a subsystem that provides Windows Compability for the Linux host.
I do agree it's an issue of English being an imprecise language.
Still a better language than other myriad of languages with uselessly complicated grammars and rules. And I'm not a native English speaker.
And this is a poor example, because Microsoft wants to be Microsoft.
No natural language is inherently imprecise. Every language has its own system to resolve vagueness or ambiguity and elaborate on the supposedly "missing" features of the language. This issue is relatively settled in linguistics.
My personal experience with our legal department on naming is that if your product name includes someone else's trademark, you have to say "Our Thing for Their Thing", exactly like that. I was involved in a product that did this, and we came up with some better names, but legal said no, it must be named with "for Their Thing" at the end. Those were the magic words so we don't get sued, and indeed, we weren't sued. Our legal was non-technical and never heard of WSL; they came to this conclusion independently.
The name we shipped was even worse than Windows Subsystem for Linux, honestly. At least Microsoft spent some time on it.
"Windows subsystem" was an existing term of art on the NT architecture.
It’s a sub-system of Windows that is used for Linux.
It can work either way though.
I always have the same problem myself. Same as I had with version naming of old programs like "Microsoft Word for Windows 2.0" instead of the easier "Microsoft Word 2.0 for Windows".
The problem is Word 2.0 for Dos was released in 1985, and Word for Windows 2.0 was released in 1991. Calling it Word 2.0 for Windows wouldn't make sense, because it wasn't the 1985 release with a new coat of paint, Word for Windows was its own thing, and this was the second version. Word for Mac was also separate, but eventually Word 6 was a common code base and it made sense to have Word 6.0 for [whatever]
Other people already answered but windows was just another personality on the original idea that cutler had for WNT. It just took a while for it to get implemented as a linux
The Showstoppers book by G. Pascal Zachary is an entertaining account of NT uprising.
To reciprocate the naming of Wine, maybe it could have been named Line. Also, both have this positive clang, being associated with "having a good time".
Windows' subsystem for Linux
(Windows 9x) (Subsystem for Linux)
It's a dominance thing. Classic abuser behaviour.
Yeah, you'd think from this that it is running Linux on Windows 9x.
Microsoft names of products turn around likes, e.g.
OpenOffice XML [1] -> Office Open XML [2]
That's cool
I mean it's like trying to balance a cybetruck into 4 skateboards and flunging it over a hill cool