I realize not everyone will care about this, but I find the naming for these WSL-like subsystems is confusingly backwards. i.e. It should have been Linux Subsystem for Windows, or Window's Subsystem for [Linux | FreeBSD | etc].
I still think they could fulfill that requirement and call it the "Windows Linux subsystem" or something, but what do I know?
Unrelated, but I think the WSL2 design is kind of stupid. It's just a VM. I think the WSL1 design, where it was a syscall layer, is a better call. But that was slower, IIRC chiefly because the NT filesystem syscalls are slower than Linux's VFS. Rather than improve that problem, they side-step it by running Linux in a VM.
But once you give up the specialization for Android and want WSL to be a "real Linux" (i.e. behave like a specific Ubuntu/Fedora/etc distribution) now you no longer can get away with being Linux-like, you have to be Linux (i.e. you need the syscall layer to directly mirror all kernel development and features). It's actually fairly impressive how much worked with WSL(1) given how different the internals were, but you didn't have to go that far to find tools/services/etc that just wouldn't work.
Instead, once you consider how long MS had been working on Hyper-V, and how interested they are in using it to apply additional security boundaries/isolation (e.g. VBS) within what outwardly appears to be a single Windows OS instance to the user, it makes a lot of sense to leverage that same approach to just run a real Linux kernel atop Hyper-V. In that world, you no longer have to match Linux kernel development, you just need to develop/maintain the kernel drivers used to interact with Hyper-V - and MS already had a lot of experience and need to do that given how much of Azure is running Linux VMs.
In my original comment I said that the difference is the Linux VFS for a reason. The slow part in NT is when you go from a filename to a handle. Doing things like caching lookups by name is, IIRC, the responsibility of the individual drivers. Linux does better at this by having a heavily optimized layer sitting between the filesystem driver and the caller. Doing tons of open(2)s is faster on Linux because of the overall kernel design.
The syscall way is just a form of emulation that you have to contain and it becomes a pain to keep up to date. VMs will use more ressource but at least they are disposable and only require a good virtualization layer on the host.
Funnily enough, with time, Microsoft might be able to run all the OSs inside their own OS. Of course, that won't happen for something like macOS but that would be hilarious.
So making a better WSL on syscall layer, which NT kernel is designed for, is not only behind a technical effort wall, but also behind a big red tape.
I would have expected Microsoft to address this issue in Windows containers by supplying the correct version of the system DLLs at runtime. However, it seems that they decided to bake them in at build time instead. This makes Windows containers similar to Linux containers but it could have made them quite kernel-version-sensitive. According to MSDN, newer kernels are able to run older images, implying to me that they've begun to stabilize the kernel interface, potentially enough to enable proper static binaries. See https://learn.microsoft.com/en-us/virtualization/windowscont...
For the topic at hand, though, Windows containers run Windows software, and a lot of software that gets containerized never runs on Windows normally and so can't easily be containerized for that platform. Even when the language and libraries are cross-platform, the build process often isn't.
In one, each container gets its own kernel copy, while the other one works like Linux containers, and indeed you need a recent version, as there were some issues doing that on older versions, which is yet another reason to be running Windows 11.
Note that having kernel copy to go along the containers is also existing on Linux world, this is what advanced security models like Kata containers.
There is plenty of Windows software on big corporations that will never be ported to Linux, and that is the golden use case for at least put them into containers.
One such example are all the .NET Framework applications that will never be rewritten into modern .NET, or Windows Services (aka UNIX daemons).
The WSL2 design isn't stupid, it's practical. What I will give you is that it's not elegant in an "ivory tower of ideal computing" sense.
It is stupid in that it's not really any kind of subsystem, it's just a vm. VMs have their uses, but it's basically just an app.
The reason hardware such as my usb serial example (or any serial) worked on wsl1 was because it actually was a subsystem.
WSL2, on the whole, is much more compatible. If you want 100% Linux compatibility, just run Linux.
Yet in practice works very well
There's saying if something is stupid, but works, then it aint stupid
Your name is bizarrely better considering how small the difference is.
> The explanation they give is they need to put their trademark, Windows, before Linux. Sometimes they say this is advice from the legal department.
It feels like they have some strange internal naming policy. Maybe it is called the “Policy Product for Naming.”
That wasn’t the original primary reason for it… Windows NT began life as NT OS/2… at first, an evolved OS/2 API was going to be its primary API… then as Windows 3.x took off and the IBM-Microsoft relationship further soured, the OS/2 API was downgraded to a backward compatibility afterthought, and eventually (in Windows XP) dropped entirely.
And because they weren’t even sure what the primary API was going to be at first… and the whole idea of multiple OS “personalities” was all the rage - IBM’s Mach-based Workplace OS sought to unify AIX and OS/2 (and they even talked about extending that to OS/400), Taligent (IBM-Apple joint venture) had similar objectives - so it is understandable they made this API flexibility a focus of their early plans
And the guy they hired as technical lead in developing NT, Dave Cutler - had come from DEC, which had the very real problem of selling two largely incompatible operating systems (Unix and OpenVMS) - and they also sought to unify them through multiple personalities, as their next generation operating system MICA which would merge Unix and OpenVMS, which Cutler was working on, until DEC management decided to cancel the project, and Cutler went to Microsoft to do the same thing there
It IS honestly kind of cool. If Microsoft would invest into their solid OS instead of enshitifying it, they could implement Linux and Darwin on a single system. That would be quite a selling point.
I think that would be far more useful in practice than trying to close the gap between WSL1 and WSL2, which is what I’d interpret your “implement Linux” proposal as meaning
As far as trying to emulate Darwin goes, I think relatively few would be interested in running macOS apps on Windows, and I wonder whether there is a risk Apple might sue
I wonder if AI coding agents are going to improve to the point that they might radically change the incentives here - if adding new features becomes a lot cheaper, maybe the cost-benefit analysis will shift towards implementing more of this stuff
My idea was to implement a true Windows subsystem for these alongside Win32.
Okay, technically it is something new – a picoprocess provider – because classic Windows environment subsystems were too heavyweight.
Trying to use the classical environment subsystem model (which POSIX and OS/2 used) for Linux wouldn't give you any clear advantage and would come with a significant performance cost. That's the whole reason why they added picoprocess providers to NT (originally intended to support Android emulation, later retargeted to generic Linux, the result of which was WSL1)
Can you have a process both calling syscalls from the Linux Subsystem and the Win32 Subsystem? Was that possible with the old-school Subsystems?
So I guess this project should be FreeBSD's subsystem for Linux? Or should it be FreeBSD's subsystem for Windows' subsystem for Linux?
Sure, but it is a Linux system.
It's kind of like saying Edge is a "Windows subsystem for the browser".
If Microsoft is putting someone else’s trademark (in this case Linux or PostgreSQL) in its product name, their own trademark will always come first and someone else’s trademark will come last.
The same Windows services are provided to "Seamlessly integrate Microsoft Widows into your Linux environment."
WSU became WSL!
Whoever decided on the name didn't have sentence diagramming in elementary school English class.
- Power management subsystem
- Scheduling subsystem
- Sound subsystem
etc
The word before "subsystem" describes the subsystem itself, not the greater system to which it belongs.
WINE => Windows Subsystem for Linux/FreeBSD/UNIX
WSL => Linux/FreeBSD Subsystem for Windows