3 ms·

To be fair it's quite impressive WSL1 got this far, but ultimately it was doomed from the start if one targets perfect compatibility. Given there's no "Linux s

by lloeki 3y ago

To be fair it's quite impressive WSL1 got this far, but ultimately it was doomed from the start if one targets perfect compatibility. Given there's no "Linux specification" the spec is the actual code, nooks and crannies and all, down to nitty gritty details and implicit behaviours that end up indirectly getting relied upon. The only solution is to basically implement these in excruciating details, which may or may not possible depending on the Windows things being wrapped. Then the question of intellectual property, copyright, and licensing come in, as MS would have to ensure that it's a clean room implementation or be subject to GPL terms (cue the Oracle Java vs Android shenanigans). So at some point it makes sense to just throw a VM at the job, cleanly separating realms, sidestepping any legal landmines, and ensuring perfect compatibility, especially as the whole HyperV infrastructure is quite solid and used throughout the MS ecosystem as a general strategy, e.g the Xbox uses HyperV to isolate games and apps. Tangent: I wish (the VM part of) WSL2 would be available on Xbox, allowing one to run Linux while keeping the whole regular OS and features!

supriyo-biswas 3y ago
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.
- CJefferson 3y ago
  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.
  - supriyo-biswas 3y ago
    My point still stands — Linux syscalls are documented, the Win32 APIs and syscalls aren’t.
    - lloeki 3y ago
      > 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.
LoganDark 3y ago
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)
ori_prior 3y ago
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.
- pjc50 3y ago
  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.
- deleted 3y ago
  [deleted]
- monocasa 3y ago
  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.

by lloeki 3y ago

supriyo-biswas 3y ago

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.

CJefferson 3y ago
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.
- supriyo-biswas 3y ago
  My point still stands — Linux syscalls are documented, the Win32 APIs and syscalls aren’t.
  - lloeki 3y ago
    > 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.

LoganDark 3y ago

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)

ori_prior 3y ago

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.

pjc50 3y ago
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.
deleted 3y ago
[deleted]
monocasa 3y ago
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.