Microsoft reveals all about Windows 10's Linux subsystem

The arrival of Bash in Windows 10 took many people by surprise, but it opens up a number of opportunities including the ability to run GUI Linux apps. But it's about much more than just that. Microsoft wants people who are confused about the arrival of (deep breath...) Bash on Ubuntu on Windows to know of the potential, and has produced an explainer about the Windows Subsystem for Linux.

Microsoft's Deepu Thomas says that the subsystem was created by the Microsoft Windows Kernel team, and goes on to explain that this is much more than an interpretation layer or virtual machine. In fact, the Windows Subsystem for Linux was born from work carried out years ago for the NT kernel that was meant to bring POSIX and OS/2 support.

Thomas says that 'the magic happens' in the space between the user mode Linux binaries and the Windows kernel components. Microsoft made it possible for Linux system calls to be directed to the Windows kernel by putting unmodified Linux binaries in Pico processes. He explains a little about the makeup of the Windows Subsystem for Linux.

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:

• User mode session manager service that handles the Linux instance life cycle
• Pico provider drivers (lxss.sys, lxcore.sys) that emulate a Linux kernel by translating Linux syscalls
• Pico processes that host the unmodified user mode Linux (e.g. /bin/bash)

Of course, bringing the subsystem to Windows was far from a simple process. Getting the two to work together involves some jiggery pokery that Thomas explains:

WSL executes unmodified Linux ELF64 binaries by virtualizing a Linux kernel interface on top of the Windows NT kernel.  One of the kernel interfaces that it exposes are system calls (syscalls). A syscall is a service provided by the kernel that can be called from user mode.  Both the Linux kernel and Windows NT kernel expose several hundred syscalls to user mode, but they have different semantics and are generally not directly compatible. For example, the Linux kernel includes things like fork, open, and kill while the Windows NT kernel has the comparable NtCreateProcess, NtOpenFile, and NtTerminateProcess.

The Windows Subsystem for Linux includes kernel mode drivers (lxss.sys and lxcore.sys) that are responsible for handling Linux system call requests in coordination with the Windows NT kernel. The drivers do not contain code from the Linux kernel but are instead a clean room implementation of Linux-compatible kernel interfaces. On native Linux, when a syscall is made from a user mode executable it is handled by the Linux kernel. On WSL, when a syscall is made from the same executable the Windows NT kernel forwards the request to lxcore.sys.  Where possible, lxcore.sys translates the Linux syscall to the equivalent Windows NT call which in turn does the heavy lifting.  Where there is no reasonable mapping the Windows kernel mode driver must service the request directly.

Thomas' article is just the first of a series, so you can expect to learn much more about how Microsoft brought Linux to Windows and how it works in the coming weeks.

Photo credit: charnsitr / Shutterstock