For anyone curious (as I was) the basic difference is that WSL1 implemented the Linux syscall table directly whereas WSL2 actually runs Linux on top of some virtual drivers (hypervisor).

WSL 2 runs a full Linux kernel under Hyper-V. There are some out-of-tree or staging drivers included in Microsoft's Linux kernel derivative and they publish their kernel sources at https://github.com/microsoft/WSL2-Linux-Kernel.

i routinely upgrade my WSL2 kernel. Now on 6.6.87.1. Personally, I love WSL2.

Note that in recent versions of Windows, typically the bulk of Windows now runs under a hypervisor (i.e., "in a VM") as well: https://learn.microsoft.com/en-us/windows-hardware/design/de...

If the WSL 1 ended up working, it would have been one of the best historical coincidences in MS's history. A long forgotten feature in the NT kernel, unique to pretty much any other OS out there, used to push it's dominance in the 90's, is revived almost 30 years later, to fight for relevance with Unix based OS, once again. To quote Gorge Lucas, It's like poetry, it rhymes.

I can tell that if POSIX subsystem in Windows NT was actually a good enough UNIX experience, I would never bothered with those Slackware 2.0 install disks.

And the subsystems concept was quite common in micro-computers and mainframes space, Microsoft did not come up with the idea for Windows.

The original POSIX subsystem was just there so MS could say that it exists (and pass DoD requirements).

It got actually somewhat usable with the 2k/XP version, slightly better in Vista (notably: the utilities installer had option to use bash a default shell) and IIRC with 7 MS even again mentioned existence of the thing in marketing (with some cool new name for the thing).

Indeed, and that is why if I wanted to do university work at home instead of fighting for a place at one DG/UX terminal at the campus, I had to find something else.

I am aware it got much better later on, but given the way it was introduced, the mess with third party integrations, as Microsoft always outsourced the development effort (MKS, Interix,..), it never got people to care about afterwards.

First impressions matter most.

Realistically anyone who cared would be using something like Cygwin (and the original UNIX server market segment evaporated due to Linux and had zero interest in migrating to NT in that form--some did migrate due to application layer benefits like .NET but not for the same workloads.)

There is an alternative universe where Windows NT POSIX is really as it should have been in first place, and Linux never takes off as there is no need for it.

As there is another alternative one where Microsoft doesn't sell Xenix and keeps pushing for it, as Bill Gates was actually a big fan of.

Obviously we'll never know, but I seriously doubt that parallel universe would've had a chance to materialize. Not the least due to "free as in beer" aspect of Linux whilst web/Apache was growing at the pace it did. All proprietary unices are basically dead. Sun was likely the sole company that had the best attitude to live alongside open source, but they also proved it wasn't a good enough business post bubble burst. NT and Darwin remain alive due to their desktop use, not server.

NT underlies the majority of M365 and many of the major Azure services. Most F500s in the US will have at the very least an Active Directory deployment, if not other ancillary services.

IIS and SQL Server (Win) boxes are fairly typical, still.

I am not suggesting NT is dead on servers at all. I am positing it would be dead had it not been for owning the majority of desktops. Those use cases are primarily driven as an ancillary service to Windows desktop[1], and where they have wider applicability, like .NET and SQL Server, have been progressively unleashed from Windows. The realm of standalone server products were bulldozed by Linux; NT wouldn't have stood a chance either.

[1]: In fact, Active Directory was specifically targeted by EU antitrust lawsuit against Microsoft.

For all large corps, users sit at 1990s-style desktop computers that run Win10/11 and use Microsoft Office, including Outlook that connects to an Exchange server running on Windows Server. I'm not here to defend Microsoft operating systems (I much prefer Linux), but they are so deeply embedded. It might be decades before that changes at large corps.

That was true once, but not true now. On-prem Exchange is rapidly being squashed by Microsoft in favor of 365. The direction of travel for the Outlook client is clearly towards web (I note anecdotally that the Mac client, always a poor relation to Windows, is so laughably clunky that the Mac users I know forgo it in favor of the web client.) If the service is in the 365 cloud and the client is a web browser, who needs Windows for this discussion? We might end up in a future of terminals again for the worker bees and 'real' computers only for the people who need Excel and Word and for whom the web versions dont cut it

IBM z/OS is officially a Unix-a very weird Unix which uses EBCDIC-but it passed the test suite (an old but still valid version, which makes it somewhat outdated) and IBM paid the fee to The Open Group, so officially it is a Unix. (Although somewhat outdated, they recently added a partial emulation of the Linux namespace syscalls-clone/unshare/etc-in order to port K8S to z/OS; but that’s not part of the Unix standard.)

If Microsoft had wanted, Windows could have officially been Unix too-they could have licensed the test suite, run it under their POSIX/SFU/SUA subsystem, fixed the failures, paid the fee-and then Windows would be a Unix. They never did-not (as far as I’m aware) for any technical reason, simply because as a matter of business strategy, they decided not to invest in this.

With Microsoft having either Windows NT with proper UNIX support, or real UNIX with Xenix, there would be no need for Linux, regardless of it being free beer.

Whatever computer people would be getting at the local shopping mall computer store already had UNIX support.

Lets also not forget that UNIX and C won over the competing on timesharing OSes, exactly because AT&T wasn't allowed to sell it in first place, there was no Linux on those days, and had AT&T not sued BSD, hardly anyone would have paid attention to Linux, yet another what-if.

WSL 1 works fine. I much prefer it over 2 because I only run windows in a VM and nested virtualization support isn't all there.

Also feels a lot less intrusive for light terminal work.

That would not be unique, as is what BSD has done for Linux compatibility basically forever.

BSD and Linux are in the same bucket, so that doesn't count, not any more than MacOS compatibility with Linux. Windows is the odd one out.

I don't think it is fair to brush it off under "same bucket; doesn't count." The syscalls are still different and there's quite a bit of nuance. I mean the lines you're drawing are out of superficial convenience and quite arbitrary. In fact, I'd argue macOS/Darwin/XNU are really Mach at their core (virtual memory subsystem, process management and IPC) and BSD syscalls are simply an emulated service on Mach, which is quite different from traditional UNIX. The fact that as a user you think of macOS much more similar to Linux is not really reflective of what happens under the hood. Likewise NT has very little to do with Win32 API in its fundamentals but Win2k feels the same to the user as WinME, but under your framing, you'd same-bucket those.

> Likewise NT has very little to do with Win32 API in its fundamentals but Win2k feels the same to the user as WinME, but under your framing, you'd same-bucket those.

I probably would, in this context. Well, maybe not WinME, because that was a dumpster fire. But any Windows coming down from NT line, which is what's relevant in the past 20 years, sure. Same bucket.

Solaris did as well.

I know -- I was super excited to see WSL1 and wished it worked. NT when started was the OS/2 personality and back at that time was excited to see NT as the OS to end all OSes (by running them all as a personality).

But WSL2 is freaking incredible, I'm super excited to see this and just wish the rest of windows would move to a Linux kernel and support bash natively everywhere. I was never a fan of powershell, sh/dash/ash/bash seem fine

Why not just use Linux then?

The whole point of Windows right now is having a kernel that a) does not shove GPL down the device manufacturer's throat and b) care about driver API stability so that drivers actually work without manufacturer or maintaner intervention every kernel upgrade.

People like to talk like GPL is evil, but it's underpinning more of the world than many people see.

And thanks to no ABI/API stability guarantees, Linux can innovate and doesn't care about what others might say. Considering Linux is developed mostly by companies today, the standard upkeep of a driver is not a burden unless you want to shove planned obsolescence down the throats of the consumers (cough Win11 TPM requirements cough).

I wouldn’t call the GPL “evil”, but I do think it’s more unrealistic given current western economics and mooching practices. Some copyright here and there does help keep food and water on the table.

Nothing prevents one from selling GPL'd software. https://www.gnu.org/philosophy/selling.en.html

Despite the FSF's word games with "copyleft", the GNU GPL, Creative Commons, and F/OSS licenses rely on legal copyright protections in order to work. It's the copyright holder who reserves the right to license the software by those terms.

https://www.gnu.org/philosophy/free-sw.html

https://creativecommons.org/faq/#is-creative-commons-against...

Closed source is protected in other ways besides copyright. Trade secrets, confidentiality, NDA, proprietary ownership, obfuscation, and in the case of hardware, big globs of epoxy and other countermeasures to ensure nobody can get in and reverse-engineer it.

> Some copyright here and there does help keep food and water on the table.

While I'm a strong Free Software proponent, I'm not a zealot and insist on a black or white approach.

Yes, some software can be closed source, I agree, but it shouldn't be the bedrock software, i.e. anything required to enable hardware (firmware, OS, and preferably the utilities).

For the record, I'm paying for a couple closed source software packages on Linux which provide very unique feature s. These are inSync and Pagico.

On top of that, you can always sell GPL software (remember, you shall ship the source with the product. opening it it to everyone is not a requirement). On top of it, you can sell support or special versions. curl has a special version for paying customers, and ccid driver developers sell ccid compliance testing.

So, there are always alternatives, and the reality has more shades of gray than two distinct colors.

Sure, but consider that some people might not be able to just make that choice in any given context.

I was working as a freelancer wher a lot of my job meant interfacing with files other people made in Software that only runs reliably on Windows or Mac (and I tried regularly).

So WSL provided me with a way to run Linux stuff without having to run a fat VM or dual boot. In fact my experience with WSL is probably why I run Linux as my daily driver OS in academia now, since here the context differs and a switch to Linux was possible.

Whether a thing is useful is always dependent on the person and the context. WSL can absolutely be a gateway drug to Linux for those who haven't managed to get their feet wet just yet.

I completely agree with you. WSL2 can be useful for many scenarios at its current form.

We tend to forget that "Horses for Courses" and "Your Mileage May Vary" applies way broader than we think.

The obvious answer: you can't. I work in constrained environment with an IT department that provides the hardware and (most of) the software I develop on. I agree with all the WSL cheering here, it integrates almost seamlessly.

But you're asking the wrong question. It should be "why not use MacOS?" if you need a stable UI with UNIX underneath :).

That's another sound option, but as a person who doesn't like Homebrew and stuffing /usr/local with tons of things, a lightweight Linux VM becomes mandatory after some point on macOS, too.

Other than that, macOS plus some tools (Fileduck, Forklift, Tower, Kaleidoscope to name a few), you can be 99% there.

Homebrew on arm64 installs to /opt/homebrew.

Oh. They changed it at last? This is good news. Thanks for letting me know.

Yup absolutely.

I use macos as my daily driver, but any real work on it happens on a linux container or VM. Using one of {cursor, vscode, windsurf} with a devcontainer is a much better approach for me.

Current macos is going the windows direction with some architecture choice (default uninstallable software, settings panel mess, meaningless updates,…)

>Why not just use Linux then?

Why not both? Like me?

I sometimes say, tongue in cheek slightly, that the best Linux desktop is Windows.

> I was never a fan of powershell, sh/dash/ash/bash seem fine

It depends on what you're doing. PowerShell is incredible for Windows sysadmin, and the way it pipes objects between commands rather than text makes it really easy to compose pretty advanced operations.

However, if I'm doing text manipulation, wrangling logs, etc, then yes, absolutely I'm going to use a *nix scripting language.

>But WSL2 is freaking incredible

It's good. But if/when you start using it as your main work platform nagging issues start cropping up. The native linux filesystem inside it cannot actually reclaim space. This isn't very noticeable if you aren't doing intensive things in it, or if you are using it as a throwaway test bed. But if you are really using it, you have to do things like zero out a bunch of space on the WSL disk and then compact it from outside in the Windows OS. Using space from your NTFS partition / drive isn't very usable, the performance is horrible and you can't do things like put your docker graph root in there as it is incompatible. It also doesn't respect capitalization or permissions and I've had to troubleshoot very subtle bugs because of that. Another issue is raw network and device access, it basically isn't possible. Some of these things are likely beyond the intended use of WSL2, in its defense. Just be aware before you start heavily investing your workflow in it. For these use cases a traditional dual boot will work far better and save you much frustration.

Or just go straight to Hyper-V, without all the WSL stuff.

Hyper-V for a cheap solution.

But VMware still excels at running desktop Linux on Windows. Especially for distros that use 3D accelerated desktops (aka literally anything that uses a recent GNOME or KDE release).

One thing that I notice nobody mention about VMWare on Windows is what about the issues with "Virtualization Based Security"? If you have this enabled VMWare uses "Windows Hypervisor Platform" which I think is also tied in with Hyper-V for running VMs through VMware making them noticeably worse and more unstable especially when dealing with USB devices. During the installer, you'll be warned of this too if memory serves correct. Cons are you cannot use WSL2 and reduced security. How much in reality does it reduce security I'm not exactly sure but I wish it wasn't like this or there was a better workaround for VMware on Windows. VBS feature is enabled by default on all Windows 11 and I think most later releases of Windows 10.

The Windows Hypervisor does suck in terms of an actual virtualization features, but it does reduce security significantly by disabling it. It’s a big front line defense against memory attacks.

The essential problem was that critical Windows APIs like CreateProcess and the NTFS file system were far too slow to be used in UNIX-like ways. If you tried to run git or build things in WSL1 - a key use case - it was way slower than doing so on native or VM Linux.

Performance was one problem, but imho the biggest was that MMAP semantics were inherited from the NT side and made a lot of applications crash (mmap's created could only be as large as the file's current size as in Windows, while Linux/BSD semantics allows for a mmap larger than the file that's usable without constant remapping as the file grows).

They didn't prioritize it until fixing at a late stage, barely before WSL 2 came out. Sometimes i do wonder if they made a premature decision to move to WSL2 since there was quite a lot of basic applications/runtimes that were crashing due to this fix lacking (Naturally a lot of other new Linux API's like io_uring probably would have made it an api chasing treadmill that they just wanted to circumvent).

> (mmap's created could only be as large as the file's current size as in Windows, while Linux/BSD semantics allows for a mmap larger than the file that's usable without constant remapping as the file grows).

I thought you could do it using ntdll functions, no?

https://www.jeremyong.com/winapi/io/2024/11/03/windows-memor...

Good to know, still the obscureness of this function or semantics led WSL1 to be incompatible for a long time (Also skimming this article touches upon some 0-sized mappings being an issue?).

Regardless this led WSL1 to have fatal incompatibilities for a long time, iirc basic stuff like the rpm system or something similarly fundamental for some distros/languages relied on it. And once WSL2 existed people just seems to have gone over.

Hm. I used Git on WSL1 for many years, with medium sized repos hosted on a Windows drive, and it worked great. When I moved to WSL2 Git became a whole lot slower - it now takes about 5-8 secs to execute 'git status' where before it was instant.

Are your git repos in ntfs? WSL1 Linux drives are slow and in WSL2 Ntfs.

Yes, exactly, this is well known. So the parent post seems incorrect.

Win32 APIs like CreateProcess suck because they have to spend so much time setting up the stuff that allows Win32's application model to mimic that of 16-bit Windows, which was coopreratively multitasked. The NT kernel is much faster at creating processes when it doesn't need to worry about that stuff.

As for NTFS: it's not NTFS specifically, it's the way the I/O system is designed in the NT kernel. Imagine any call from outside that layer transitioning through a stack of filter drivers before actually reaching the implementation. Very powerful stuff, but also very bad for performance.

> Imagine any call from outside that layer transitioning through a stack of filter drivers before actually reaching the implementation.

Linux BPF programmers say, "hold my beer, watch this!"

They can code 12 BPF filters for the price of 3 Windows filters.

Windows actually created a new process type for this: Pico processes[1]. This allows WSL1 to perform quite a bit better than Cygwin on something like Windows XP.

1. https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-pro...