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.
Meanwhile those that complained about Java, now ship a whole browser with their "native" application, and then complain about Google taking over the Web.
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.
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.
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.
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!
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.
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?
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 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".
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.
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.
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.
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.
https://github.com/skeeto/w64devkit
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/
Yes, I have weird problems. I get to look after some very weird shit.
Still got those in this part of the world sharing space with state of the art autonomous 100+ tonne robo trucks.
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.
https://en.wikipedia.org/wiki/Windows_NT_3.1#Architecture
> Because we cannot name something leading with a trademark owned by someone else.
https://xcancel.com/richturn_ms/status/1245481405947076610?s...
It can work either way though.
OpenOffice XML [1] -> Office Open XML [2]
[1] https://www.openoffice.org/xml/general.html
[2] https://en.wikipedia.org/wiki/Office_Open_XML
I mean it's like trying to balance a cybetruck into 4 skateboards and flunging it over a hill cool