3 ms·

> a full Linux install in a VM Really? I always thought the subsystem worked translating OS calls back and forth without virtualizing an entire machine. It su

> a full Linux install in a VM Really? I always thought the subsystem worked translating OS calls back and forth without virtualizing an entire machine. It sure has an entire OS, kernel and all, but not a virtualization layer. Maybe that was the case for WSL but not WSL2?

akdev1l 2y ago
That was WSL1 and as a result had a bunch of unimplemented syscalls. Microsoft realized trying to keep up with the ever-growing list of syscalls on Linux is actually not practical hence they opted for the virtualized approach with an actual Linux kernel to achieve 1:1 syscall compatibility. They released that as WSL2. Technically the name is not accurate anymore as there aren’t any “subsystems” at work anymore.
deleted 2y ago
[deleted]
jborean93 2y ago
WSL1 used a concept called a pico process [1] and the pico driver that is associated with the process is forwarded the syscalls to translate to the required NT APIs. WSL2 is a VM running through Hyper-V but integrated in a way that mostly looks like a normal process. It was introduced to improve filesystem performance (on the Linux mounts) and avoid having to translate and maintain the syscalls required by Linux [2]. The tech behind WSL1 is quite fun but WSL2 certainly has better compatibility and aside from FS performance between Linux and Windows is mostly a positive. [1] https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-process-overview https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-pro... [2] https://devblogs.microsoft.com/commandline/announcing-wsl-2/ https://devblogs.microsoft.com/commandline/announcing-wsl-2/
dgunay 2y ago
WSL 1 worked that way. WSL2 is a full Linux vm.
mschuster91 2y ago
Yep, WSL1 was a translation layer. Extremely awesome but unfortunately dog slow for anything involving npm packages or large(r) PHP environments as all file accesses would go through the translation layer, the Windows filter chain (aka virus scanners) and then finally NTFS. WSL2 in contrast is a VM, which avoids all the slow paths in file accesses - all that Windows sees is a bunch of bulk block I/O to the backing file of the VM disk.
- rcarmo 2y ago
  On the other hand, running Python, Go and .NET on it was a dream. Awesome development environment, and much more battery friendly, to the point where I still use it.
JonathonW 2y ago
WSL2 is "just" Linux running in a Hyper-V VM (with some special sauce on top of it to handle things like interacting with the filesystem or doing Wayland and X11 graphics, plus containerization stuff to allow multiple distributions to be installed and run under one VM and one kernel). WSL1 was a completely different approach, adding a Linux compatibility layer to Windows itself. There, you never had a Linux kernel running at all-- Linux syscalls would call into WSL, which would talk directly to the NT kernel to do whatever that syscall needed to do. WSL1 didn't last very long (still present, but not actively being developed)-- turns out that reimplementing one operating system on top of another is a Hard Problem (see also: Wine). WSL2 avoids this entirely, and also avoids most of the impedance mismatches that you get when trying to reimplement POSIX on top of NT. WSL2 solved a whole bunch of compatibility problems essentially overnight that WSL1 never even got around to.

akdev1l 2y ago

That was WSL1 and as a result had a bunch of unimplemented syscalls. Microsoft realized trying to keep up with the ever-growing list of syscalls on Linux is actually not practical hence they opted for the virtualized approach with an actual Linux kernel to achieve 1:1 syscall compatibility. They released that as WSL2. Technically the name is not accurate anymore as there aren’t any “subsystems” at work anymore.

deleted 2y ago

[deleted]

jborean93 2y ago

WSL1 used a concept called a pico process [1] and the pico driver that is associated with the process is forwarded the syscalls to translate to the required NT APIs. WSL2 is a VM running through Hyper-V but integrated in a way that mostly looks like a normal process. It was introduced to improve filesystem performance (on the Linux mounts) and avoid having to translate and maintain the syscalls required by Linux [2]. The tech behind WSL1 is quite fun but WSL2 certainly has better compatibility and aside from FS performance between Linux and Windows is mostly a positive. [1] https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-process-overview https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-pro... [2] https://devblogs.microsoft.com/commandline/announcing-wsl-2/ https://devblogs.microsoft.com/commandline/announcing-wsl-2/

dgunay 2y ago

WSL 1 worked that way. WSL2 is a full Linux vm.

mschuster91 2y ago

Yep, WSL1 was a translation layer. Extremely awesome but unfortunately dog slow for anything involving npm packages or large(r) PHP environments as all file accesses would go through the translation layer, the Windows filter chain (aka virus scanners) and then finally NTFS. WSL2 in contrast is a VM, which avoids all the slow paths in file accesses - all that Windows sees is a bunch of bulk block I/O to the backing file of the VM disk.

rcarmo 2y ago
On the other hand, running Python, Go and .NET on it was a dream. Awesome development environment, and much more battery friendly, to the point where I still use it.

JonathonW 2y ago

WSL2 is "just" Linux running in a Hyper-V VM (with some special sauce on top of it to handle things like interacting with the filesystem or doing Wayland and X11 graphics, plus containerization stuff to allow multiple distributions to be installed and run under one VM and one kernel). WSL1 was a completely different approach, adding a Linux compatibility layer to Windows itself. There, you never had a Linux kernel running at all-- Linux syscalls would call into WSL, which would talk directly to the NT kernel to do whatever that syscall needed to do. WSL1 didn't last very long (still present, but not actively being developed)-- turns out that reimplementing one operating system on top of another is a Hard Problem (see also: Wine). WSL2 avoids this entirely, and also avoids most of the impedance mismatches that you get when trying to reimplement POSIX on top of NT. WSL2 solved a whole bunch of compatibility problems essentially overnight that WSL1 never even got around to.