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.
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.
As a dependency of a shipping Windows application that needs to cleanly coexist side-by-side with existing Cygwin installations and optionally support silent install/upgrade/uninstall through mechanisms like SCCM, Intune, and Group Policy?
Not so much.
I do use the setup program to build the self-contained Cygwin root that's ultimately bundled into my program's MSI package and installed as a subdirectory of its Program Files directory, however.
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.
That's fake cooperative emulation of signals. It isn't preemptive (unless someone got a kernel driver approved while I wasn't looking?) thus many things either work poorly or not at all. Pause-the-world GC algorithms are a good example. Coroutine implementations also have to be cooperative.
If you're curious, I believe the issue was discussed at length in the Go GitHub issues years ago. Also on the mailing lists of many other languages.
I've never had a problem installing from setup, but some tools were (maybe still are, it is a long time since I've needed anything not in the main repo) ported to windows using the cygwin dlls were distributed with their own versions and could clobber the versions you have otherwise (and have their versions clobbered when you fix that).
> slow forking
There isn't much that can be done about that: starting up and tearing down a process on Windows is much more resource intensive operation than most other OSs because there is a lot going on by default that on other OSs a process ops into, only if it needs to, by interacting with GUI libraries and such. This is why threads were much more popular on Windows: while they are faster than forking on other OSs too, especially of course if data needs to be shared between the tasks because IPC is a lot more expensive than just sharing in-process memory, the difference is not as stark as seen under Windows so the potential difficulties of threaded development wasn't always worth the effort.
Cygwin can't do anything about the cost of forking processes, unfortunately.
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.
To solve the problem or because you saw "slow" and "bash" and wanted to bring up something cool but unrelated?
If I go from 10 seconds of forking and .04 seconds of shell to 10 seconds of forking and .01 seconds of shell, I don't actually care about how cool and fast the shell is. And I've never had the speed of bash itself be a problem.
I used cygwin pretty heavily in the late 90s and early 2000s. It was slow. I had scripts that took days to run dealing with some network file management. When I moved them over to linux out of frustration (I think I brought in something like a pentium 90 laptop, gateway solo I think?) they were done in tens of minutes.
I'm sure they did the best they could ... it was just really painful to use.
This matches me experience as well. Some of my earliest rsync experiences were with the Cygwin version and I can remember scratching my head and wondering why people raved about this tool that ran so slowly. Imagine my surprise when I tried it on Linux. Night and day!
You don’t get an app that looks the same across platforms. You do get apps that look like they belong on your platform, even though the code is cross-platform. It uses the native toolkit no matter where you run it across Windows, GTK, Qt, Motif, macOS/Carbon, macOS/Cocoa, and X11 with generic widgets.
Older platforms are also supported, like OS/2, Irix, and OSF/1.
It’s a C++ project, but it has bindings for most of the languages you’d use to build an application. Ada? Go? Delphi? Ruby? Python? Rust? Yes, and more.
https://wiki.wxwidgets.org/Bindings
The problem is, most of these bindings are out-of-date. Delphi from 2012, Basic from 2002, D from 2016. wxRuby is a dead link. wxAda was already dead in 2009, as the discussion I can google suggests.
So, if you use wxWidgets, you probably have to use either C++ or Python version, others are unlikely to be supported.
I have used cygwin for 30 years and never had any dll hell issues, because all the programs came from the cygwin installer. Never once needed something outside it.
It's not just DLL hell. Cygwin was also notorious for being really out of date. Security vulnerabilities and missing features were both very common at one point.
Meanwhile those that complained about Java, now ship a whole browser with their "native" application, and then complain about Google taking over the Web.
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.
A lot of this is issues Microsoft could fix if they were sufficiently motivated
e.g. Windows lacks a fork() API so cygwin has to emulate it with all these hacks
Well, technically the NT API does have the equivalent of fork, but the Win32 layer (CSRSS.EXE) gets fatally confused by it. Which again is something Microsoft could potentially fix, but I don’t believe it has ever been a priority for them
Similarly, Windows lacks exec(), as in replace the current process with new executable. Windows only supports creating a brand new process, which means a brand new PID. So Cygwin hacks it by keeping its own PID numbers; exec() changes your Windows PID but not your Cygwin PID. Again, something Microsoft arguably could fix if they were motivated
> A lot of this is issues Microsoft could fix if they were sufficiently motivated...
They did fix it, in a sense, with WSL1 picoprocesses. Faster and more compatible than Cygwin. Real fork and exec on the Windows NT kernel. Sadly, WSL2 is even faster and more compatible while being much less interesting. WSL1 was pretty neat, at least, and is still available.
In any event, this diversion doesn't change my analysis of Cygwin. Cygwin still sucks regardless of whose fault it is. I intentionally left this stuff out of my post because I thought it was obvious that Cygwin is working around Windows limitations to hack in POSIX semantics; it's the whole point of the project. None of us can change Windows or Cygwin and they're both ossified from age and lack of attention. We have to live with the options we've actually got.
If you need a Windows build of a Linux tool in 2026 and can't use WSL, try just building it natively (UCRT64, CLANG64, MSVC, your choice) without a compatibility layer. Lots of tools from the Linux ecosystem actually have Windows source compatibility today. Things were different in the 90s when Cygwin was created.
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 was designed to produce a configure script with zero dependencies other than the compiler toolchain itself. I always thought it would be a good way to bootstrap a system configuration database (like the kind X11 already had, the name I forget) but it turned out to be too convenient to just drop autotools into every project instead.
So now even today, compiling any GNU package means probing every last feature from scratch and spitting out obscenely rococo scripts and Makefiles tens of thousands of lines long. We can do better, and have, but damn are there a lot of active codebases out there that still haven't caught up.
Reminds me of a fun weekend I spent ~5 years ago building the newest version of every GNU program I could get to build on NEXTSTEP 3.3 (running on 68k NeXT hardware) without major changes.
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 very confusing. When you pick "MSYS2", you are building exclusively for the MSYS2 target environment, and might not have proper compatible windows headers. When you pick "MINGW32/64", you are instead building for the normal windows environment, and get proper windows headers. But if you didn't know that, you would end up confused about why your program is not building.
It doesn't help that the package simply named "gcc" is for the MSYS2 target.
And just to add insult to injury, you probably don't want MINGW64 either, as it relies on the ancient MSVCRT.DLL C runtime library that lacks support for "new" features like C99 compatibility and the UTF-8 locale, and that Microsoft never supported for use by third-party applications in the first place.
Instead, you either want UCRT64 or CLANG64, depending on whether you want to build with the GNU or LLVM toolchains, as it uses the newer, fully-supported Universal C Runtime instead.
> lacks support for "new" features like C99 compatibility
This made me laugh. It reminded me of course work I did in university that was clearly written many years before I took the course as it recommended we manually enable the "new" c99 standard in our compiler, which I guess survived in the documentation up through when I took the course, at which point it was still relevant since GCC was otherwise defaulting to C11 by the time I was using it.
It's still useful to use MSVCRT in certain circumstances, such as targeting the earliest 64-bit versions of Windows.
As for UTF-8 support, it's the manifest file that determines whether Windows sets the ANSI code page to UTF-8. (There's also an undocumented API function that resets the code page for GetACP and the Rtl functions that convert ANSI into Unicode. But this would run after all the other DLLs have finished loading.) Having the code page correct is enough to support Unicode filenames and Unicode text in the GUI.
It just won't provide UTF-8 locale support for the standard C library.
Sure, or older 32-bit versions of Windows for that matter, or for building software that hasn't been ported to UCRT.
I can certainly relate to this: I'm currently sitting on a request for an enhancement to a product (currently running on a 32-bit Windows 10 VM) with a build system that has never been updated to support any Microsoft platform other than MS-DOS, or toolchain newer than Microsoft C 5.1.
It's annoying to wade through six different versions of the same package for different runtimes and word sizes. Heaven forbid you accidentally install the wrong one.
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.
Ha that tracks my own usage and timeline almost precisely, although I was using cygwin and WSL2 in parallel for a while. Lot of complaints about cygwin speed here, but NTFS filesystem access is actually a lot faster on cygwin than WSL2!
It's kind of both. Hyper-V is a bare-metal (type 1) hypervisor. Windows runs virtualized, one level above it, in a privileged (host) VM, next to other (guest) VMs.
Assuming you were on NT-lineage, rebuilding for SFU (Interix) was the technically correct and nice implementation, though since a lot of Linux programs are non-portable (or have maintainers who mistakenly think they can do better than autotools) it was a pain in practice.
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.
Why not? That is just a matter of porting stuff over, like a FreeBSD ports collection, an apt repo, or a bunch of scripts for Proton/Wine such as Lutris.
Cygwin started in 1995. Microsoft wasn't cooperative with FOSS at all at that point. They were practicing EEE, and eating some expensive Unix/VMS machines with WNT.
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!
What I especially like about this Windows 9x Subsystem project, is that it proves that coLinux could have been written way earlier. Now imagine how less dual booting we would have needed in 1996 if that happened, and how it would have affected VMware which only existed since 1998.
I remember myself on my first year of CS, set theory classes, at the whiteboard, trying to make a proof, but there something I was not able to prove at all, so I said 'it's trivial' and the doctor said 'yeah, it's trivial' and we went further.
The one I've always flown with is, trivial means (1) a special case of a more general theory (2) which flattens many of the extra frills and considerations of the general theory and (3) is intuitively clear ("easy") to appreciate and compute.
From this perspective, everything is trivial from the relative perspective of a god. I know of no absolute definition of trivial.
No, this was really something trivial, in the sense that you could feel it's true. Like 2+2=4 but to prove it you need to create a set of functions, axiom and a theorem
> 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.
The primary function of modern operating systems is to allow multiple programs to run, without interfering with each other, even if they try too. This means that each program can only read its own limited amount of memory and only gets to use the processor for a limited time, before another program gets a turn. Windows did not start using those features until Windows NT, which XP is based off of. Through Windows 98, any program could do whatever it wanted, and that hardware sat idle. Windows versions up to 98 were more like a library of features that a program could use, to display a user interface and talk to hardware peripherals.
There's special hardware in a processor, for the operating system to limit each programs access to memory and processing time, which Windows 9x leaves unused. This means that the Windows 9x Subsystem for Linux can say "look at me i'm the operating system now" and take over that hardware to run a modern operating system.
Windows 3.11 was a hypervisor running virtual machines. The 16-bit Windows virtual machine (within which everything was cooperatively multitasking), the 32-bit headless VM that ran 32-bit drivers, and any number of V86 DOS virtual machines.
Win9x was similar in the sense that it had the Windows virtual machine running 32-bit and 16-bit Windows software along with V86 DOS VMs. It did some bananas things by having KERNEL, USER, and GDI "thunk" between the environments to not just let 16-bit programs run but let them continue interacting with 32-bit programs. So no, Win9x was in fact 32-bit protected mode with pre-emptive multitasking.
What Win9x prioritized was compatibility. That meant it supported old 16-bit drivers and DOS TSRs among other things. It also did not have any of the modern notions of security or protection. Any program could read any other program's memory or inject code into it. As you might expect a combination of awful DOS drivers and constant 3rd party code injection was not a recipe for stability even absent bad intentions or incompetence.
Windows 2000/XP went further and degraded the original Windows NT design by pulling stuff into kernel mode for performance. GDI and the Window Manager were all kernel mode - see the many many security vulnerabilities resulting from that.
This is correct. Win9x did have memory protection, it just made an intentional choice to set up wide open mappings for compatibility reasons.
WSL9x uses the same Win9x memory protection APIs to set up the mappings for Linux processes, and the memory protection in this context is solid. The difference is simply that there is no need to subvert it for compatibility.
That's greatly oversimplified, or less generously, just flat out wrong. Win32 programs have always had their own isolated address space. That infamous BSOD is the result of memory protection hardware catching an access to something outside of that address space. When you open a DOS box, it uses the paging and V86 hardware mechanisms to create a new virtual machine, even though it shares some memory with the instance of DOS from which Windows was booted.
What Windows 9x didn't have was security. A program could interfere with these mechanisms, but usually only if it was designed to do that, not as a result of a random bug (if the entire machine crashed, it was usually because of a buggy driver).
It's mostly explained if you go to the project page. For me, the I would say the hardest thing about something like this is gleaning the Microsoft driver APIs. In the 9x days, Microsoft documentation was not quite thorough and difficult to access. It's still not pleasant.
This is in the class of things where even if the specific text doesn't trace to a true story, it has certainly happened somewhere, many times over.
In the math space it's not even quite as silly as it sounds. Something can be both "obvious" and "true", but it can take some substantial analysis to make sure the obvious thing is true by hitting it with the corner cases and possibly exceptions. There is a long history of obvious-yet-false statements. It's also completely sensible for something to be trivially true, yet be worth some substantial analysis to be sure that it really is true, because there's also a history of trivial-yet-false statements.
I could analogize it in our space to "code so simple it is obviously bug free" [1]... even code that is so simple that it is obviously bug free could still stand to be analyzed for bugs. If it stands up to that analysis, it is still "so simple it is obviously bug free"... but that doesn't mean you couldn't spend hours carefully verifying that, especially if you were deeply dependent on it for some reason.
Heck I've got a non-trivial number of unit tests that arguably fit that classification, making sure that the code that is so simple it is bug free really is... because it's distressing how many times I've discovered I was wrong about that.
[1]: In reference to Tony Hoare's "There are two ways to write code: write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it."
I don't think you understand how jokes work. They are mostly "distortions" of real dialog or events to add incongruous or absurdist elements. Here, Hardy's not uncommon momentary doubt about whether a statement really was obvious, while faintly amusing, is made into a joke by turning the momentary doubt into a 15 minute excursion. People then riff on the joke by turning that excursion into a mathematician presenting an elaborate proof that a statement is "obvious", quite contrary to the meaning of "obvious".
What's a good resource going over the architecture of Windows 3.x and 9x? I know bits and pieces, like that it has a "VM Monitor", and there's support for this sort of thing, though the details are all over the place. Most people summarized Windows as just "running on top of DOS", which is clearly not correct. Obviously, it doesn't use "virtual machines" in exactly the modern sense of the word, but there's clearly something cool and technical going on, that most sources seem to gloss over.
Before Windows Internals book we all know (called Inside Windows NT in its first editions), there was Windows Internals and other books and articles by Matt Pietrek. It starts from disassembly of WIN.COM studying the insides of DOS to figure out under which more or less common version of MS-DOS Windows is being run.
This being on the front page the same day as "Show HN submissions tripled and now mostly have the same vibe-coded look" is nice to see. One person spends 6 years understanding Win9x internals to run a modern Linux kernel inside it. The other thread is full of apps that took 20 minutes to prompt into existence. Posts like this make me happy.
(not trying to pick a fight, but...) what difference it makes if an agent spent 100$ to understand and came to the same result, given it is those who use it that will benefit of it, and thus the craze here.
note: i'm not saying author did not improve his skills overall, but also last '6 years' perhaps also means - fair amount of digging the web with search engines, which are... like AI 0.1
The difference is that despite the fact that I will never use this, I am nonetheless here to celebrate the effort. What difference does it make if someone runs a marathon or takes an uber given they may arrive at the same location?
And likely the prompt itself was generated. Instead of "create me an owl app" write: "create me a comprehensive prompt to create an owl app". Then paste that prompt to next AI session.
I've been working on a WebExtension that calls out to zygolophodon and returns plain HTML to the browser. In the process of rebasing it over recent changes but here is the working webext-old branch:
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”.
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.
No it's the Word app which is included in your organization's Copilot 365 .NET SharePoint license assuming you know how to trigger the download. The chatbot the license is named after doesn't have a clue either so good luck.
It runs Linux with Windows underneath it, hence Windows is the subsystem being subordinate (in the most literal sense where it simply means "order" with no further implications) to Linux.
Per wongarsu's post, something like the OS/2 Subsystem is an OS/2 system with Windows beneath it, but the OS/2 Subsystem is much smaller and less consequential, thus subsidiary (in the auxiliary sense) to Windows as a whole.
Isn't marketing fun?
This is how we end up with hundreds of products that provide "solutions" to your business problems and "retain customers" and upwards of a dozen other similar phrases they all slather on their frontpages, even though one is a distributed database, one is a metrics analysis system, one handles usage-based billing, one is a consulting service, one is a hosted provider for authentication... so frustrating trying to figure out just what a product is sometimes with naming conventions that make "Windows Subsystem for Linux" look like a paragon of clarity. At least "Linux" was directly referenced and it wasn't Windows Subsystem for Alternate Binary Formats or something.
I agree. Don't have a citation now, but I remember reading that this was a copyright problem. They wanted to name it "Linux Subsystem for Windows", but apparently the Linux foundation does not allow unaffiliated projects to have a name beginning with "Linux", or something like that.
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.
I know there’s a small hobby industry of people creating Windows 9x compatibility shims for later Windows APIs… but who needs that when you can just run Linux apps?
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...
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.
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.
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!
Kernel-Ex and Basilisk and friends (Serpent browser or whatever it's called) plus some TLS stuff can browse the modern web just fine. JS, OTOH... get NoScript ASAP and block selectively.
Or better, ditch the web completely and head to Gopher/Gemini.
I agree there seem to be other options. But they all have fractal-edged interfaces to the legacy stuff, and you need to be careful about, as you said, script issues and vulns. That's the BrowserBox advantage - a fully modern, remote rendering system that can still be accessed from the legacy box, but securely. And easy setup. Admittedly, doing it the way you're doing is probably free - BrowserBox is not free - but it saves you lots of this delicate management of config, etc. Because the interface model is cleaner: just one HTTP endpoint that legacy browsers can actually access, streaming them fully modern browsing that's rendered elsewhere, securely.
I get the degradation to Gopher as a way to solve many issues, but many things just don't work there. And it may have its own vulnerabilities.
Ah! I solved that easily enough. Internet Explorer 8 works okay for the webby front ends to operate the transmitter equipment. How do you run that, in this day and age, safely?
Run it in Windows XP, in a VM.
Now here's the clever bit - qemu will allow you to expose the keyboard, mouse, and framebuffer as a VNC server. So you set up Apache Guacamole to point a VNC client at the VM, and then "normal people" can log in, operate the transmitter, and log out again.
You can do a lot of sneaky things with that, including setting up headless X, running VNC on it pointed at your qemu VM, and then streaming the headless X servers's framebuffer out with ffmpeg.
Yes sometimes work can be a bit boring with not much to do, why do you ask?
That is pretty cool, man. VM with XP in QEMU sending VNC frames to Guacamole clients on the web.
BrowserBox is basically the same pattern as this setup (streaming graphics from some browsing substrate somewhere to web clients) except architecture is different: a modern box on the same private network runs the BrowserBox server, and the win box (QEMUd or otherwise) connects to its http endpoint, using whatever browser it has (tested back to IE5 even, tho that's a way more buggy browser than IE6. IE8 should be golden). That way you get the full modern web, no compromises. But crucially the web is not actually accessing your legacy box. So, no comrp0mises, ie., no easy vulns. Especially a concern for older browsers. Plus, we've got policy controls to lock down capabilities (copy, paste, URL lists, internal IP access controls, etc).
In your case it sounds like you are running the webby servers on the XP box, too, so BrowserBox would link back into those over the same private network, render them on the modern box, send it back to the XP box, then clients can connect over the QEMU VNC bridge you already have.
Alternately you could just do away with the Win XP browsing, and have BrowserBox connect to your webby endpoints for transmitters wherever you run them, and then expose that browsing graphics stream to clients over whatever endpoint you want. Many options!
I like your ffmpeg out setup. How did that go? Share more about that? Pretty interesting, I love this old architectures, and legacy systems compatibility quests.
I should do a blog post and stick it on here, right?
> In your case it sounds like you are running the webby servers on the XP box, too,
Yeah - it's a web front end to some specialised software written on I guess Microsoft C++ (if I had time, enthusiasm, and a copy of it lying around I suppose I'd wave Ghidra at it and see what happens).
I'll look into BrowserBox, that sounds handy.
> I like your ffmpeg out setup. How did that go? Share more about that? Pretty interesting, I love this old architectures, and legacy systems compatibility quests.
Surprisingly well. I think you could probably stream it straight to Twitch or something if you wanted. Yeah, this sounds like a blog post.
There is a section of the Forties Pipeline where they have a huge amount of gas handling plant in central Scotland. Last time I was on site (admittedly 15 years ago but I don't see this changing soon) the SCADA outstations were run by absolutely minty box fresh VAXStation 3100s. Plastic not even peeled off the front panel badges fresh.
I recently saw that running on special 16 channel DAT recorders used by the 999 service, recently as in "within the past five years". I believe they've been retired but kept around in case they need to recover tapes off them.
I kept my mouth ABSOLUTELY FUCKING SHUT about knowing my way round OS/2 Warp 4.
I've completely forgotten pretty much everything about OS/2... worked support for iomega for a while covering OS/2, Jazz and 2nd level zip calls in the late 90's. I have very little desire to look back to those days.
Except it would be nice if computers were as snappy as back then... so many layers of cruft that nothing really pops. I remember I used to just disable all the NT/2K animations and it felt so nice. I built a career on web apps, but most are just really poorly written it pisses me off.
I remember running CoLinux back in my training days ~2005-2006. It seemed a bit like black magic to me at the time, but it worked quite well for my needs.
But CoLinux - IIRC - required the NT branch of Windows. I can only imagine the level of hackery it takes to make this happen on Windows 9x.
Part of me wants to weep at the sheer perversity, part of me wants to burst into manic laughter. It is indeed a world of endless wonders.
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.
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:
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)?
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 think this is in the sense of needing a modern-ish hardware with VT-x/AMD-V support (instead of the already-contemporary v8086 which is already in use by Windows at this time).
Sidebar: does anyone else find the naming of this super confusing—does this mean embedding windows in linux or linux in windows? Surely we could find a way to refer to composing operating systems that isn't inherently ambiguous. Say, "linux inside of windows" would be less ambiguous.
Edit: to the people who downvoted, I corrected my spelling mistake. I will perform due penance.
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.
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.
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
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".
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
- 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
Not sure if I’d call converting modern web to Gemini better. It’s a downgrade. If you want modern fidelity on old systems you need BrowserBox. Or i guess you could fiddle with Retrozilla flags if that works
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.
Interesting idea. Does it actually work? If so, didn't the guy kind of simplified WSL here?
I have not tested this yet, so I have no idea - but if he managed to pull this off then this may be one of the greatest achievements this year. Or perhaps there are some restrictions to it? Does compiling stuff work in it? So many questions ... who has the answers?
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 ..
Before WSL, the best ways to run unmodified Linux binaries inside Windows were CoLinux and flinux.
http://www.colinux.org/
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.
On your own system, sure.
As a dependency of a shipping Windows application that needs to cleanly coexist side-by-side with existing Cygwin installations and optionally support silent install/upgrade/uninstall through mechanisms like SCCM, Intune, and Group Policy?
Not so much.
I do use the setup program to build the self-contained Cygwin root that's ultimately bundled into my program's MSI package and installed as a subdirectory of its Program Files directory, however.
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.
That's fake cooperative emulation of signals. It isn't preemptive (unless someone got a kernel driver approved while I wasn't looking?) thus many things either work poorly or not at all. Pause-the-world GC algorithms are a good example. Coroutine implementations also have to be cooperative.
If you're curious, I believe the issue was discussed at length in the Go GitHub issues years ago. Also on the mailing lists of many other languages.
I've never had a problem installing from setup, but some tools were (maybe still are, it is a long time since I've needed anything not in the main repo) ported to windows using the cygwin dlls were distributed with their own versions and could clobber the versions you have otherwise (and have their versions clobbered when you fix that).
> slow forking
There isn't much that can be done about that: starting up and tearing down a process on Windows is much more resource intensive operation than most other OSs because there is a lot going on by default that on other OSs a process ops into, only if it needs to, by interacting with GUI libraries and such. This is why threads were much more popular on Windows: while they are faster than forking on other OSs too, especially of course if data needs to be shared between the tasks because IPC is a lot more expensive than just sharing in-process memory, the difference is not as stark as seen under Windows so the potential difficulties of threaded development wasn't always worth the effort.
Cygwin can't do anything about the cost of forking processes, unfortunately.
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):
Instead of something like this: 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.
You could also use the inbuilt substitution mechanism:
No, seriously, give an ash-derivative a try.
Dash has been benchmarked as 4x faster than bash. The bash manpage ends by stating that "bash is too big, and too slow."
> No, seriously, give an ash-derivative a try.
To solve the problem or because you saw "slow" and "bash" and wanted to bring up something cool but unrelated?
If I go from 10 seconds of forking and .04 seconds of shell to 10 seconds of forking and .01 seconds of shell, I don't actually care about how cool and fast the shell is. And I've never had the speed of bash itself be a problem.
I used cygwin pretty heavily in the late 90s and early 2000s. It was slow. I had scripts that took days to run dealing with some network file management. When I moved them over to linux out of frustration (I think I brought in something like a pentium 90 laptop, gateway solo I think?) they were done in tens of minutes.
I'm sure they did the best they could ... it was just really painful to use.
This matches me experience as well. Some of my earliest rsync experiences were with the Cygwin version and I can remember scratching my head and wondering why people raved about this tool that ran so slowly. Imagine my surprise when I tried it on Linux. Night and day!
> 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.
Qt looks nice as a user and gnome gtk isn’t too bad either
Wx isn’t bad either. https://wxwidgets.org/
You don’t get an app that looks the same across platforms. You do get apps that look like they belong on your platform, even though the code is cross-platform. It uses the native toolkit no matter where you run it across Windows, GTK, Qt, Motif, macOS/Carbon, macOS/Cocoa, and X11 with generic widgets.
Older platforms are also supported, like OS/2, Irix, and OSF/1.
https://wiki.wxwidgets.org/Supported_Platforms
It’s a C++ project, but it has bindings for most of the languages you’d use to build an application. Ada? Go? Delphi? Ruby? Python? Rust? Yes, and more. https://wiki.wxwidgets.org/Bindings
The problem is, most of these bindings are out-of-date. Delphi from 2012, Basic from 2002, D from 2016. wxRuby is a dead link. wxAda was already dead in 2009, as the discussion I can google suggests.
So, if you use wxWidgets, you probably have to use either C++ or Python version, others are unlikely to be supported.
wxRuby has been resurrected as wxRuby3, see https://mcorino.github.io/wxRuby3/
Among actively developed bindings, there is also wxRust at https://crates.io/crates/wxdragon
Cygwin works fine if I am compiling stuff locally for my own use, but that cygwin1.dll (plus any dependencies) is a problem for distribution.
What I usually do is make sure my code builds with both Cygwin and MingW, and distribute the binaries built with MingW.
> 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.
I have used cygwin for 30 years and never had any dll hell issues, because all the programs came from the cygwin installer. Never once needed something outside it.
It's not just DLL hell. Cygwin was also notorious for being really out of date. Security vulnerabilities and missing features were both very common at one point.
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.
> but Cygwin is a crazy approach, was slow
A lot of this is issues Microsoft could fix if they were sufficiently motivated
e.g. Windows lacks a fork() API so cygwin has to emulate it with all these hacks
Well, technically the NT API does have the equivalent of fork, but the Win32 layer (CSRSS.EXE) gets fatally confused by it. Which again is something Microsoft could potentially fix, but I don’t believe it has ever been a priority for them
Similarly, Windows lacks exec(), as in replace the current process with new executable. Windows only supports creating a brand new process, which means a brand new PID. So Cygwin hacks it by keeping its own PID numbers; exec() changes your Windows PID but not your Cygwin PID. Again, something Microsoft arguably could fix if they were motivated
> A lot of this is issues Microsoft could fix if they were sufficiently motivated...
They did fix it, in a sense, with WSL1 picoprocesses. Faster and more compatible than Cygwin. Real fork and exec on the Windows NT kernel. Sadly, WSL2 is even faster and more compatible while being much less interesting. WSL1 was pretty neat, at least, and is still available.
In any event, this diversion doesn't change my analysis of Cygwin. Cygwin still sucks regardless of whose fault it is. I intentionally left this stuff out of my post because I thought it was obvious that Cygwin is working around Windows limitations to hack in POSIX semantics; it's the whole point of the project. None of us can change Windows or Cygwin and they're both ossified from age and lack of attention. We have to live with the options we've actually got.
If you need a Windows build of a Linux tool in 2026 and can't use WSL, try just building it natively (UCRT64, CLANG64, MSVC, your choice) without a compatibility layer. Lots of tools from the Linux ecosystem actually have Windows source compatibility today. Things were different in the 90s when Cygwin was created.
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
Autotools was designed to produce a configure script with zero dependencies other than the compiler toolchain itself. I always thought it would be a good way to bootstrap a system configuration database (like the kind X11 already had, the name I forget) but it turned out to be too convenient to just drop autotools into every project instead.
So now even today, compiling any GNU package means probing every last feature from scratch and spitting out obscenely rococo scripts and Makefiles tens of thousands of lines long. We can do better, and have, but damn are there a lot of active codebases out there that still haven't caught up.
Reminds me of a fun weekend I spent ~5 years ago building the newest version of every GNU program I could get to build on NEXTSTEP 3.3 (running on 68k NeXT hardware) without major changes.
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 very confusing. When you pick "MSYS2", you are building exclusively for the MSYS2 target environment, and might not have proper compatible windows headers. When you pick "MINGW32/64", you are instead building for the normal windows environment, and get proper windows headers. But if you didn't know that, you would end up confused about why your program is not building.
It doesn't help that the package simply named "gcc" is for the MSYS2 target.
And just to add insult to injury, you probably don't want MINGW64 either, as it relies on the ancient MSVCRT.DLL C runtime library that lacks support for "new" features like C99 compatibility and the UTF-8 locale, and that Microsoft never supported for use by third-party applications in the first place.
Instead, you either want UCRT64 or CLANG64, depending on whether you want to build with the GNU or LLVM toolchains, as it uses the newer, fully-supported Universal C Runtime instead.
> lacks support for "new" features like C99 compatibility
This made me laugh. It reminded me of course work I did in university that was clearly written many years before I took the course as it recommended we manually enable the "new" c99 standard in our compiler, which I guess survived in the documentation up through when I took the course, at which point it was still relevant since GCC was otherwise defaulting to C11 by the time I was using it.
It's still useful to use MSVCRT in certain circumstances, such as targeting the earliest 64-bit versions of Windows.
As for UTF-8 support, it's the manifest file that determines whether Windows sets the ANSI code page to UTF-8. (There's also an undocumented API function that resets the code page for GetACP and the Rtl functions that convert ANSI into Unicode. But this would run after all the other DLLs have finished loading.) Having the code page correct is enough to support Unicode filenames and Unicode text in the GUI.
It just won't provide UTF-8 locale support for the standard C library.
Sure, or older 32-bit versions of Windows for that matter, or for building software that hasn't been ported to UCRT.
I can certainly relate to this: I'm currently sitting on a request for an enhancement to a product (currently running on a 32-bit Windows 10 VM) with a build system that has never been updated to support any Microsoft platform other than MS-DOS, or toolchain newer than Microsoft C 5.1.
MSYS2 is my favorite in this area. Super lightweight and easy to use, highly recommend.
It's annoying to wade through six different versions of the same package for different runtimes and word sizes. Heaven forbid you accidentally install the wrong one.
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.
https://github.com/skeeto/w64devkit
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.
Ha that tracks my own usage and timeline almost precisely, although I was using cygwin and WSL2 in parallel for a while. Lot of complaints about cygwin speed here, but NTFS filesystem access is actually a lot faster on cygwin than WSL2!
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
Enabling hyper-v turns your base windows install into a VM host, not a virtual machine itself.
It's kind of both. Hyper-V is a bare-metal (type 1) hypervisor. Windows runs virtualized, one level above it, in a privileged (host) VM, next to other (guest) VMs.
https://en.wikipedia.org/wiki/Hyper-V#Architecture
Huh that’s interesting I didn’t realize that
Nope, the best way was VMWare Workstation, followed by Virtual Box.
And before those Virtual PC by Connectix. Which Microsoft bought and dumped.
More like they integrated the technology they cared about into their products.
Assuming you were on NT-lineage, rebuilding for SFU (Interix) was the technically correct and nice implementation, though since a lot of Linux programs are non-portable (or have maintainers who mistakenly think they can do better than autotools) it was a pain in practice.
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????
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.)
[0] https://en.wikipedia.org/wiki/Interix
> However, it lacked the convenience of a CLI package manager back then
Cygwin still lacks that to this day, you have to fire up to GUI installer to update packages.
MSYS2 is cygwin with pacman cli.
I used to use LOADLIN.exe - worked pretty, IIRC
>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.
Why not? That is just a matter of porting stuff over, like a FreeBSD ports collection, an apt repo, or a bunch of scripts for Proton/Wine such as Lutris.
Cygwin started in 1995. Microsoft wasn't cooperative with FOSS at all at that point. They were practicing EEE, and eating some expensive Unix/VMS machines with WNT.
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!
[0] http://colinux.org/
Colinux was a tech feat, just not that many people noticed.
Yes (coLinux author).
What I especially like about this Windows 9x Subsystem project, is that it proves that coLinux could have been written way earlier. Now imagine how less dual booting we would have needed in 1996 if that happened, and how it would have affected VMware which only existed since 1998.
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.
I remember myself on my first year of CS, set theory classes, at the whiteboard, trying to make a proof, but there something I was not able to prove at all, so I said 'it's trivial' and the doctor said 'yeah, it's trivial' and we went further.
"Trivial" doesn't exclusively mean "easy", though it is often used as a euphemism like that.
In a literal sense, it very well may have been trivial, even if neither you nor the professor would have been able to easily show it.
What's your definition of trivial?
The one I've always flown with is, trivial means (1) a special case of a more general theory (2) which flattens many of the extra frills and considerations of the general theory and (3) is intuitively clear ("easy") to appreciate and compute.
From this perspective, everything is trivial from the relative perspective of a god. I know of no absolute definition of trivial.
the absolute definition of trivial is trivial to show
Maybe it wasn't trivial at all for both of you ...
No, this was really something trivial, in the sense that you could feel it's true. Like 2+2=4 but to prove it you need to create a set of functions, axiom and a theorem
> 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.
Now I know two mathematician jokes. The other one is "A mathematician is a device for converting coffee into theorems."
The primary function of modern operating systems is to allow multiple programs to run, without interfering with each other, even if they try too. This means that each program can only read its own limited amount of memory and only gets to use the processor for a limited time, before another program gets a turn. Windows did not start using those features until Windows NT, which XP is based off of. Through Windows 98, any program could do whatever it wanted, and that hardware sat idle. Windows versions up to 98 were more like a library of features that a program could use, to display a user interface and talk to hardware peripherals.
There's special hardware in a processor, for the operating system to limit each programs access to memory and processing time, which Windows 9x leaves unused. This means that the Windows 9x Subsystem for Linux can say "look at me i'm the operating system now" and take over that hardware to run a modern operating system.
This is wildly inaccurate.
Windows 3.11 was a hypervisor running virtual machines. The 16-bit Windows virtual machine (within which everything was cooperatively multitasking), the 32-bit headless VM that ran 32-bit drivers, and any number of V86 DOS virtual machines.
Win9x was similar in the sense that it had the Windows virtual machine running 32-bit and 16-bit Windows software along with V86 DOS VMs. It did some bananas things by having KERNEL, USER, and GDI "thunk" between the environments to not just let 16-bit programs run but let them continue interacting with 32-bit programs. So no, Win9x was in fact 32-bit protected mode with pre-emptive multitasking.
What Win9x prioritized was compatibility. That meant it supported old 16-bit drivers and DOS TSRs among other things. It also did not have any of the modern notions of security or protection. Any program could read any other program's memory or inject code into it. As you might expect a combination of awful DOS drivers and constant 3rd party code injection was not a recipe for stability even absent bad intentions or incompetence.
Windows 2000/XP went further and degraded the original Windows NT design by pulling stuff into kernel mode for performance. GDI and the Window Manager were all kernel mode - see the many many security vulnerabilities resulting from that.
This is correct. Win9x did have memory protection, it just made an intentional choice to set up wide open mappings for compatibility reasons.
WSL9x uses the same Win9x memory protection APIs to set up the mappings for Linux processes, and the memory protection in this context is solid. The difference is simply that there is no need to subvert it for compatibility.
That's greatly oversimplified, or less generously, just flat out wrong. Win32 programs have always had their own isolated address space. That infamous BSOD is the result of memory protection hardware catching an access to something outside of that address space. When you open a DOS box, it uses the paging and V86 hardware mechanisms to create a new virtual machine, even though it shares some memory with the instance of DOS from which Windows was booted.
What Windows 9x didn't have was security. A program could interfere with these mechanisms, but usually only if it was designed to do that, not as a result of a random bug (if the entire machine crashed, it was usually because of a buggy driver).
Thank you, that's a great explanation.
It's mostly explained if you go to the project page. For me, the I would say the hardest thing about something like this is gleaning the Microsoft driver APIs. In the 9x days, Microsoft documentation was not quite thorough and difficult to access. It's still not pleasant.
It’s good use for AI
Have the model spit out example programs to study the API
Never heard of this joke, very funny !
The win9x kernel famously doesn't do very much, which seems like it can give you ample room to port some of Linux's low level functionality to it.
She is indeed some sort of wizard
> this seems an impossible feat
What makes you think so?
AAA+ joke
I believe this wasn't really even a joke, but a real story that got distorted as joke: https://hsm.stackexchange.com/a/8054
This is in the class of things where even if the specific text doesn't trace to a true story, it has certainly happened somewhere, many times over.
In the math space it's not even quite as silly as it sounds. Something can be both "obvious" and "true", but it can take some substantial analysis to make sure the obvious thing is true by hitting it with the corner cases and possibly exceptions. There is a long history of obvious-yet-false statements. It's also completely sensible for something to be trivially true, yet be worth some substantial analysis to be sure that it really is true, because there's also a history of trivial-yet-false statements.
I could analogize it in our space to "code so simple it is obviously bug free" [1]... even code that is so simple that it is obviously bug free could still stand to be analyzed for bugs. If it stands up to that analysis, it is still "so simple it is obviously bug free"... but that doesn't mean you couldn't spend hours carefully verifying that, especially if you were deeply dependent on it for some reason.
Heck I've got a non-trivial number of unit tests that arguably fit that classification, making sure that the code that is so simple it is bug free really is... because it's distressing how many times I've discovered I was wrong about that.
[1]: In reference to Tony Hoare's "There are two ways to write code: write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it."
I don't think you understand how jokes work. They are mostly "distortions" of real dialog or events to add incongruous or absurdist elements. Here, Hardy's not uncommon momentary doubt about whether a statement really was obvious, while faintly amusing, is made into a joke by turning the momentary doubt into a 15 minute excursion. People then riff on the joke by turning that excursion into a mathematician presenting an elaborate proof that a statement is "obvious", quite contrary to the meaning of "obvious".
> I don't think you understand how jokes work.
That makes sense, I was just born yesterday.
> 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".
Should be called "out AI" then
Tomorrow's "Show HN".
Letter case matters.
not in windows
What's a good resource going over the architecture of Windows 3.x and 9x? I know bits and pieces, like that it has a "VM Monitor", and there's support for this sort of thing, though the details are all over the place. Most people summarized Windows as just "running on top of DOS", which is clearly not correct. Obviously, it doesn't use "virtual machines" in exactly the modern sense of the word, but there's clearly something cool and technical going on, that most sources seem to gloss over.
I wonder how similar this project is to "BSD on Windows": https://archive.org/details/bsd-on-windows
Also, I know about https://en.wikipedia.org/wiki/Architecture_of_Windows_9x, but it's not really meaty enough for my taste. :)
Before Windows Internals book we all know (called Inside Windows NT in its first editions), there was Windows Internals and other books and articles by Matt Pietrek. It starts from disassembly of WIN.COM studying the insides of DOS to figure out under which more or less common version of MS-DOS Windows is being run.
Other well known anecdotes and pieces:
https://jacobfilipp.com/msj-index/
https://web.archive.org/web/20240318233231/https://bytepoint...
I obtained the DDK from WinWorld: https://winworldpc.com/product/windows-sdk-ddk/windows-95-dd...
It's got lots of very thorough documentation and sample code to dig through
This being on the front page the same day as "Show HN submissions tripled and now mostly have the same vibe-coded look" is nice to see. One person spends 6 years understanding Win9x internals to run a modern Linux kernel inside it. The other thread is full of apps that took 20 minutes to prompt into existence. Posts like this make me happy.
The project's readme states "Proudly written without AI." Love seeing this.
(not trying to pick a fight, but...) what difference it makes if an agent spent 100$ to understand and came to the same result, given it is those who use it that will benefit of it, and thus the craze here.
note: i'm not saying author did not improve his skills overall, but also last '6 years' perhaps also means - fair amount of digging the web with search engines, which are... like AI 0.1
The difference is that despite the fact that I will never use this, I am nonetheless here to celebrate the effort. What difference does it make if someone runs a marathon or takes an uber given they may arrive at the same location?
And likely the prompt itself was generated. Instead of "create me an owl app" write: "create me a comprehensive prompt to create an owl app". Then paste that prompt to next AI session.
Direct link without the social hop-through: https://codeberg.org/hails/wsl9x
Thanks. Mastodon still requires executing javascript just to read a post, so I usually ignore it.
https://github.com/mastodon/mastodon/issues/23153
https://github.com/mastodon/mastodon/issues/19953
Here is a CLI for reading Mastodon instances, no account required.
https://github.com/jwilk/zygolophodon
I've been working on a WebExtension that calls out to zygolophodon and returns plain HTML to the browser. In the process of rebasing it over recent changes but here is the working webext-old branch:
https://github.com/jwilk/zygolophodon/compare/master...pabs3...
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?
Don't you mean Copilot 365 .NET SharePoint Document Platform for Windows?
No it's the Word app which is included in your organization's Copilot 365 .NET SharePoint license assuming you know how to trigger the download. The chatbot the license is named after doesn't have a clue either so good luck.
Windows Subsystem for Word
Windows Program for Word
It runs Linux with Windows underneath it, hence Windows is the subsystem being subordinate (in the most literal sense where it simply means "order" with no further implications) to Linux.
Per wongarsu's post, something like the OS/2 Subsystem is an OS/2 system with Windows beneath it, but the OS/2 Subsystem is much smaller and less consequential, thus subsidiary (in the auxiliary sense) to Windows as a whole.
Isn't marketing fun?
This is how we end up with hundreds of products that provide "solutions" to your business problems and "retain customers" and upwards of a dozen other similar phrases they all slather on their frontpages, even though one is a distributed database, one is a metrics analysis system, one handles usage-based billing, one is a consulting service, one is a hosted provider for authentication... so frustrating trying to figure out just what a product is sometimes with naming conventions that make "Windows Subsystem for Linux" look like a paragon of clarity. At least "Linux" was directly referenced and it wasn't Windows Subsystem for Alternate Binary Formats or something.
I agree. Don't have a citation now, but I remember reading that this was a copyright problem. They wanted to name it "Linux Subsystem for Windows", but apparently the Linux foundation does not allow unaffiliated projects to have a name beginning with "Linux", or something like that.
You can parse it as "Windows (Subsystem for [running] Linux)"
also bad for your product name to start with a competitors brand
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 know there’s a small hobby industry of people creating Windows 9x compatibility shims for later Windows APIs… but who needs that when you can just run Linux apps?
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.
Hah, amazing.. And unresolved for all those years?
There's not a whole lot of interest in making Windows 9x run well on QEMU.
These days especially, it's better to just use 86Box for those operating systems.
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.
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!
Kernel-Ex and Basilisk and friends (Serpent browser or whatever it's called) plus some TLS stuff can browse the modern web just fine. JS, OTOH... get NoScript ASAP and block selectively.
Or better, ditch the web completely and head to Gopher/Gemini.
I agree there seem to be other options. But they all have fractal-edged interfaces to the legacy stuff, and you need to be careful about, as you said, script issues and vulns. That's the BrowserBox advantage - a fully modern, remote rendering system that can still be accessed from the legacy box, but securely. And easy setup. Admittedly, doing it the way you're doing is probably free - BrowserBox is not free - but it saves you lots of this delicate management of config, etc. Because the interface model is cleaner: just one HTTP endpoint that legacy browsers can actually access, streaming them fully modern browsing that's rendered elsewhere, securely.
I get the degradation to Gopher as a way to solve many issues, but many things just don't work there. And it may have its own vulnerabilities.
Ah! I solved that easily enough. Internet Explorer 8 works okay for the webby front ends to operate the transmitter equipment. How do you run that, in this day and age, safely?
Run it in Windows XP, in a VM.
Now here's the clever bit - qemu will allow you to expose the keyboard, mouse, and framebuffer as a VNC server. So you set up Apache Guacamole to point a VNC client at the VM, and then "normal people" can log in, operate the transmitter, and log out again.
You can do a lot of sneaky things with that, including setting up headless X, running VNC on it pointed at your qemu VM, and then streaming the headless X servers's framebuffer out with ffmpeg.
Yes sometimes work can be a bit boring with not much to do, why do you ask?
That is pretty cool, man. VM with XP in QEMU sending VNC frames to Guacamole clients on the web.
BrowserBox is basically the same pattern as this setup (streaming graphics from some browsing substrate somewhere to web clients) except architecture is different: a modern box on the same private network runs the BrowserBox server, and the win box (QEMUd or otherwise) connects to its http endpoint, using whatever browser it has (tested back to IE5 even, tho that's a way more buggy browser than IE6. IE8 should be golden). That way you get the full modern web, no compromises. But crucially the web is not actually accessing your legacy box. So, no comrp0mises, ie., no easy vulns. Especially a concern for older browsers. Plus, we've got policy controls to lock down capabilities (copy, paste, URL lists, internal IP access controls, etc).
In your case it sounds like you are running the webby servers on the XP box, too, so BrowserBox would link back into those over the same private network, render them on the modern box, send it back to the XP box, then clients can connect over the QEMU VNC bridge you already have.
Alternately you could just do away with the Win XP browsing, and have BrowserBox connect to your webby endpoints for transmitters wherever you run them, and then expose that browsing graphics stream to clients over whatever endpoint you want. Many options!
I like your ffmpeg out setup. How did that go? Share more about that? Pretty interesting, I love this old architectures, and legacy systems compatibility quests.
I should do a blog post and stick it on here, right?
> In your case it sounds like you are running the webby servers on the XP box, too,
Yeah - it's a web front end to some specialised software written on I guess Microsoft C++ (if I had time, enthusiasm, and a copy of it lying around I suppose I'd wave Ghidra at it and see what happens).
I'll look into BrowserBox, that sounds handy.
> I like your ffmpeg out setup. How did that go? Share more about that? Pretty interesting, I love this old architectures, and legacy systems compatibility quests.
Surprisingly well. I think you could probably stream it straight to Twitch or something if you wanted. Yeah, this sounds like a blog post.
You should! It would be a good read. And likely help others. Please send me an email when you get to it: cris@dosaygo.com
I will, won't be until maybe after the weekend though.
When backward compatibility used to mean something man!
Similar, radio transmitter stuff.
There is a section of the Forties Pipeline where they have a huge amount of gas handling plant in central Scotland. Last time I was on site (admittedly 15 years ago but I don't see this changing soon) the SCADA outstations were run by absolutely minty box fresh VAXStation 3100s. Plastic not even peeled off the front panel badges fresh.
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.
For a long time all the IBM ATMs ran OS/2 Warp 4.
I recently saw that running on special 16 channel DAT recorders used by the 999 service, recently as in "within the past five years". I believe they've been retired but kept around in case they need to recover tapes off them.
I kept my mouth ABSOLUTELY FUCKING SHUT about knowing my way round OS/2 Warp 4.
I've completely forgotten pretty much everything about OS/2... worked support for iomega for a while covering OS/2, Jazz and 2nd level zip calls in the late 90's. I have very little desire to look back to those days.
Except it would be nice if computers were as snappy as back then... so many layers of cruft that nothing really pops. I remember I used to just disable all the NT/2K animations and it felt so nice. I built a career on web apps, but most are just really poorly written it pisses me off.
> Except it would be nice if computers were as snappy as back then... so many layers of cruft that nothing really pops.
You should try Haiku: https://www.haiku-os.org/
It's actually pretty usable these days, at least on Thinkpads and other "generic Intel chipset" machines.
Specialised radio transmitter stuff, involving paging. One manufacturer, still producing turnkey systems that run on Windows 95.
VxDs and Watcom C... now those are names I haven't heard in a long time.
Do any screen editors work in the command prompt windows? Try with "export TERM=ansi".
You'll also need to load the ANSI tsr iirc.
I remember running CoLinux back in my training days ~2005-2006. It seemed a bit like black magic to me at the time, but it worked quite well for my needs.
But CoLinux - IIRC - required the NT branch of Windows. I can only imagine the level of hackery it takes to make this happen on Windows 9x.
Part of me wants to weep at the sheer perversity, part of me wants to burst into manic laughter. It is indeed a world of endless wonders.
Huh - I didn’t know Linux had a usermode $ARCH! Or maybe it’s an earlier fork? The kernel version looks to be 6.9.
(To clarify: while the kernel is actually running at ring 0, to act as a driver it seems to use the usermode profile.)
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...)
Is this Win4Lin resurrected?
No, this runs Linux within Windows, so rather a “Lin4Win”.
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)?
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 want a Linux Subsystem for Windows 9x or MS-DOS :P
Wouldn't that be WINE?
Isn't this exactly that but just named incorrectly?
That's called wine and dosbox.
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.
> "no hardware virtualisation"
> looks inside
> virtual 8086 mode
I think this is in the sense of needing a modern-ish hardware with VT-x/AMD-V support (instead of the already-contemporary v8086 which is already in use by Windows at this time).
that’s virtualization, not virtualisation
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?
This is genius! Now I hope to run all my childhood games on a modern Ubuntu.
@haileys I would love to see that on ArcaOS! I bet it can't be done.
Sidebar: does anyone else find the naming of this super confusing—does this mean embedding windows in linux or linux in windows? Surely we could find a way to refer to composing operating systems that isn't inherently ambiguous. Say, "linux inside of windows" would be less ambiguous.
Edit: to the people who downvoted, I corrected my spelling mistake. I will perform due penance.
Shouldn’t it be called Linux Subsystem for Windows 9x - LSW9x?
If you run it in qemu, all good.
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.
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.
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.
"Windows subsystem" was an existing term of art on the NT architecture.
https://en.wikipedia.org/wiki/Windows_NT_3.1#Architecture
It’s a sub-system of Windows that is used for Linux.
It can work either way though.
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.
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]
[1] https://www.openoffice.org/xml/general.html
[2] https://en.wikipedia.org/wiki/Office_Open_XML
we did it fellas -- linux on the desktop
Humans 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.
Not sure if I’d call converting modern web to Gemini better. It’s a downgrade. If you want modern fidelity on old systems you need BrowserBox. Or i guess you could fiddle with Retrozilla flags if that works
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"
Brilliant! Bye bye M$
can i use this as Window manager for linux?
no because it's linux running in windows not the other way around.
> "Much of the actual Win9x kernel integration including context switching lives in the Linux kernel."
Does it live there irrespective of this project? Or is that part of the patching?
Interesting idea. Does it actually work? If so, didn't the guy kind of simplified WSL here?
I have not tested this yet, so I have no idea - but if he managed to pull this off then this may be one of the greatest achievements this year. Or perhaps there are some restrictions to it? Does compiling stuff work in it? So many questions ... who has the answers?
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 ..
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.
integer? what is this, the IRS?
Not everything needs to be "needed".
That's cool
I mean it's like trying to balance a cybetruck into 4 skateboards and flunging it over a hill cool