Now that we've had a chance to come to terms with the whole Bash on Windows thing, it's time Microsoft delivered a deeper look at how the integration works. For the curious, that explainer -- the first of a series -- is finally here.
To begin with, if you're wondering what the official name for the project is, it's the Windows Subsystem for Linux (WSL). As Microsoft's Deepu Thomas explains over on MSDN, it's not your normal virtual machine or interpretation layer -- it's a lot more sophisticated than that:
WSL is a collection of components that enables native Linux ELF64 binaries to run on Windows. It contains both user mode and kernel mode components. It is primarily comprised of:
1. User mode session manager service that handles the Linux instance life cycle 2. Pico provider drivers (lxss.sys, lxcore.sys) that emulate a Linux kernel by translating Linux syscalls 3. Pico processes that host the unmodified user mode Linux (e.g. /bin/bash)
It is the space between the user mode Linux binaries and the Windows kernel components where the magic happens. By placing unmodified Linux binaries in Pico processes we enable Linux system calls to be directed into the Windows kernel. The lxss.sys and lxcore.sys drivers translate the Linux system calls into NT APIs and emulate the Linux kernel.
The system builds off of very early work Microsoft did on the Windows NT kernel that allowed support for POSIX and OS/2. This support was eventually "retired", but the fact that it happened made WSL much easier to implement.
Of course, it's not 100 per cent native. While the lxcore driver will do its best to translate Linux calls to Windows ones, it features some "I'll do must best" handling too:
As an example, the Linux fork() syscall has no direct equivalent call documented for Windows. When a fork system call is made to the Windows Subsystem for Linux, lxcore.sys does some of the initial work to prepare for copying the process. It then calls internal Windows NT kernel APIs to create the process with the correct semantics, and completes copying additional data for the new process.
Apparently the next post on WSL will cover how Pico processes work, so be sure to check that out when it goes up.