A closer look at WSL 1

Microsoft promotes WSL 2 as the preferred way of running software for Linux on Windows. But for those running Windows in a virtual machine that does not support nested virtualization, WSL 2 is a non-starter. It is unfortunate then that WSL 1 has some severe limitations. But for what it's worth, WSL 1 is by far the most technically interesting system of the two.

WSL 1: a real Windows subsystem?

While WSL 1 does build on the affordances provided by the Windows kernel and Windows executable loader, which were designed to run executables with different 'personalities' side-by-side, it is a different kind of subsystem than the other subsystems for 3 reasons:

1. WSL 1 does not require applications to target it explicitly through the use of a PE header. A PE header is part of a portable executable, but WSL 1 actually runs ELF executables, and there is no need for developers to build special executables for WSL 1.

1. WSL 1 is started using the LXSS Manager service, which keeps track of all Linux processes (including daemons), threads, and their runtime state. bash.exe (a Windows executable) is actually a client for the LXSS Manager service, and asks it to start bash (a Linux executable).
2. WSL 1 exposes Windows drives to Linux processes (e.g. C: mounted at /mnt/c) using the Drive FS file system, which imposes limitations to ensure the integrity of the underlying NTFS file system. The files of a Linux distribution running in WSL 1 (e.g. /bin, /etc, /home, etc.) are stored on a Volume FS file system, which fully supports Linux file system semantics. (Windows processes should not attempt to access these files.)

So there are enough differences to say that WSL 1 is (was?) more like the 'next generation' of Windows subsystems.

WSL 1: not a virtual machine

Whereas WSL 1 could be considered the next generation of Windows subsystems, WSL 2 is 'just' a Hyper-V virtual machine running an enlightened Linux kernel. Enlightenment allows the Linux kernel to perform hyper calls, function calls to the Hyper-V hypervisor. The Linux kernel created by Microsoft uses this to achieve the tight integration that WSL 2 requires. But running Linux software on Linux in a virtual machine on Windows seems less technically interesting compared to running Linux software directly on Windows.

The WSL 1 pico provider resembles the concept of a unikernel, where part of an operating system kernel runs alongside the application in the same address space. This requires a much smaller host kernel to run in kernel space. A smaller kernel is easier to reason about and secure.

In 2011 Microsoft published a whitepaper called Rethinking the Library OS from the Top Down (PDF), demonstrating Drawbridge, a refactoring of Windows 7 to a library OS that was able to run unmodified applications such as Excel, Internet Explorer, and IIS, using a kernel that is 1/50^th the size of the Windows 7 kernel, offering some significant security advantages. And while the startup time and memory use of these applications was not as good as running them on Windows 7, it was much better compared to running them under Hyper-V.

Summary

WSL 1 seems to represent the logical conclusion of Microsoft's research into the library OS. For the optimist, the remaining kernel compatibility issues could be fixed in WSL 1.1, and further improvements to the Windows kernel could bring more and different library operating systems. Alas, Microsoft decided to abandon this approach, and at most we'll get better integration of enlightened Hyper-V guests.