... except that (a) WSLv2's kernel will be running in a VM, and (b) macOS's kernel is much more like Linux's -- fork/exec, networking, filesystem, memory, TTY.
I see WSLv2 as more of a concession that a *nix-style interface is what developers want, and that the NT kernel can't deliver that.
NT supports interfaces for supporting a fork model efficiently, it's just not well documented. In fact, you can write an efficient, Windows-native POSIX environment entirely from user space using existing APIs: https://midipix.org/
The only thing that NT really lacks is a Unix-style TTY subsystem. The interplay in Unix between TTYs, process control, and signals is complex and deep, and none of it lends itself toward abstractions--it's all quintessentially Unix. For almost everything else, NT provides interfaces that can be used to efficiently implement Unix semantics.
Microsoft isn't interested in supporting a modern POSIX environment natively as that would merely accelerate the migration of the software ecosystem away from Windows APIs. IMO, it's why they killed WSL1. WSL1 was de facto a modern, native Unix personality on NT. They may not have managed 100% Linux compatibility, but they could've simply relabeled it Windix or something, used a small team to round things out, and received UNIX V7 certification in a jiffy.
WSL is about managing the shift toward a Linux-based cloud world, capturing as much of that business as they can without unnecessarily risking their existing footprint. WSL2 neatly allows them to maintain Windows API lock-in while also providing substantial value for those needing to develop Linux-based software. WSL1 fell short on both accounts, though standing alone I think it was much cooler technology.
> They may not have managed 100% Linux compatibility, but they could've simply relabeled it Windix or something
My take on it was that they were never able to implement all the syscalls (WSL just couldn’t reliably run some production server software), and filesystem calls were horribly slow (try npm install on a reasonably large JS project if you have any doubt).
You may be right — but I’d still like to dream that one day Microsoft will release a true Linux (or OpenSolaris, BSD, or whatever!) OS of their own, which their Office apps will fully support. That’ll be the day I weigh another option besides macOS.
Accessing Windows' NTFS volume from WSL2 Linux is (and will always be) even slower. I have no doubt they've could've substantially improved file access, but management pulled the plug. WSL1 was basically just a proof of concept, afterall.
Also, don't forget that Windows and NTFS has never been known for performance. Expecting file access to be as fast as ext4 from a Linux kernel was just the wrong set of expectations. If you want Linux performance you need to use Linux, of course, accessing it's own block device directly; and people demanding that are going to get it with WSL2. The cost is that integration will be worse, both in terms of ease of use as well as performance. AFAIU WSL2 is using 9P now and in the future probably virtio-fs (https://virtio-fs.gitlab.io/) or something similar.
People keep saying how lightweight the WSL2 VM is. Well, that's how all modern VM architectures are now. If you launch a vanilla Linux, FreeBSD, or OpenBSD kernel inside Linux KVM, FreeBSD bhyve, or OpenBSD VMM there's very little hardware emulation, if any[1]; they all have virtio drivers for block storage, network, balloon paging (equivalent of malloc/free), serial console, etc; for both host and guest modes.
[1] I don't think OpenBSD VMM supports any hardware emulation.
> The only thing that NT really lacks is a Unix-style TTY subsystem.
The long, laborious ConHost / NT Console subsystem rewrite/refactor over the last few years has moved Windows a lot closer to the Unix PTY system for internal plumbing (while not breaking the NT Object side of things). The fancy new Microsoft Terminal in alpha testing now takes advantage of that.
> WSL1 fell short on both accounts, though standing alone I think it was much cooler technology.
I feel like this is an interesting case where version numbers hurt more than help, because it sounds like WSL1 and WSL2 rather than a pure 2 > 1 are going to be side-by-side for some time now (moving distros between WSL1 and WSL2 is supposedly a simple powershell operation and can be done in either direction) and hints from Microsoft that there may even still be additional investments in WSL1 depending on user use cases and interest.
I think it's good for the NT Kernel to maintain subsystem diversity, and so I do hope that WSL1 continues to see interesting uses, even if a lot of developers will prefer WSL2 more for day-to-day performance.
I see WSLv2 as more of a concession that a *nix-style interface is what developers want, and that the NT kernel can't deliver that.