WSL1 was a dead end, not because of compatibility but because of performance, especially when it comes to file system access and process operations. Windows is supremely complex in both, with things like filesystem filters, fused fork+exec+setuid+setcap+doWindowsStuffThatDoesntHaveUnixEquivalents syscalls, all of which you cannot avoid. If you layer a Linux syscall personality on top of that, things will get molasses-slow quickly.

Correct - the semantics are simply too different to directly emulate. The simple fact that starting processes takes much longer in Windows cripples naive implementations, for example.

"fused fork+exec" otherwise known as "process creation" (that is one thing i'll give windows credit for)

To be fair, at least on the syscall side, WSL1 was built in kernel space on Pico Processes, not regular NT processes. They very much were able to avoid the windows cruft. It really seemed to be the long tail on compat and the impedance mismatch on the vfs layer that killed it.

Wine does all of that though for Windows, even when the syscall structure and caveats or compatibility fixes for the Win32 APIs are unknown.

With Linux, all the syscalls and their bugs are documented, at least in the commit history, if not the man pages.

Wine is an amazing piece of software,but it’s still easy to find issues in many apps. Microsoft wanted something it could sell as a general Linux replacement, so it needed close to 100% compatibility.

My point still stands — Linux syscalls are documented, the Win32 APIs and syscalls aren’t.

> Linux syscalls are documented

It doesn't mean they are implementable atop NT/Windows kernel facilities, semantics, and behaviours, in which case it's an alternative implementation to maintain that foregoes integration.

While Wine's effort and compatibility levels achieved are impressive, they actually prove my point: compatibility is a constant fight, there are a ton of tunables (some automated), and it's still not perfect (which is what a VM gives you for essentially free).

There's more than "basic" syscall interface to it though, there's the whole implementation of features (that are GPLv2 licensed) e.g btrfs? iptables? ebpf? ptrace? hold my beer; run kernel-backed wireguard in WSL2? no problem; alsa? you betcha; real time facilities? sure! custom kernel with a missing feature like usb passthrough? be my guest; contribute to the linux kernel code? entirely possible. It's all there, today, and not at the mercy of MS's will or ability to implement this or that.

yeah, windows already ran in hyper-v anyway for protection of high-level processes at the hypervisor level, so it probably wasn't even that much of a leap to introduce other VMs alongside windows (aka WSL2)