Microsoft has recently announced the intention to integrate Linux Bash with Windows 10, making it possible to run native Linux ELF64 binaries on their operating system. To avoid incorrect speculation on how this is possible, Deepu Thomas, the Leader of the Windows Subsystem for Linux team, has provided details on how Linux runs on Windows.
To explain how Linux can run on Windows, a number of notions and features need to be introduced first:
Windows User Mode. A CPU mode used by regular applications for isolation and protection. Each application started in this mode has its own virtual address space which cannot be modified by another application. Also, if the application crashes other applications are not taken down with it.
Windows Kernel Mode. A CPU mode used by core components of the operating system such as (kernel-mode) drivers. All interactions with the computer’s hardware are handled in this mode. The components running in this mode and provided by Windows are tested extensively to avoid crashes as much as possible because crashes at this level can take down the entire system. This MSDN article explains in more detail the difference between the two Windows modes.
Windows NT Subsystems. Windows NT introduced from the beginning a separation between the APIs an application was supposed to call and the kernel layer. This enabled Windows NT to support multiple subsystems, such as POSIX, OS/2 and Win32. These subsystems were meant to facilitate porting of UNIX and OS/2 applications to Windows. The POSIX and OS/2 subsystems were discarded later but the architecture remained.
Pico Process & Driver. Project DrawBridge introduced the Pico Process with its drivers which provides a process-based container. It is a lightweight solution, lacking OS services and system calls are handled by a pair of pico drivers.
User-Mode Linux. This is a way of running Linux as an application on top of another Linux host. Instead of accessing the hardware directly, the guest Linux kernel forwards the system calls to the host Linux which does the job for it.
To run Linux, Microsoft has created Windows Subsystem for Linux (WSL) whose overall architecture is depicted in the following chart:
When the user launches bash.exe in user mode, an associated service is started, the LX Session Manager. This service is the intermediary between bash commands entered by the user at the command prompt and the corresponding native ELF64 binaries that are to be executed. The Linux binaries are part of a User-Mode Ubuntu 14.04 provided by Canonical and are launched as pico processes in user mode. Two drivers emulating the Linux kernel -lxss.sys and lxcore.sys- intercept their system calls. In most cases, the respective drivers map the Linux kernel calls into similar Windows kernel calls, but there are some cases when there is no correspondence. An example is fork(), Thomas explaining how it works:
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.
WSL offers two file systems accessible from Linux: VolFs and DriveFs. The former is in every way like a regular Linux file system including support for permission, symbolic links, case sensitivity and even characters that are forbidden in a Windows file system. The later provides interoperability with Windows, enabling the user to see all Windows volumes in Linux.
There is no virtualization involved and the Linux binaries are not ported or recompiled to make them work on WSL. Linux commands started this way access the local host like Windows applications do, not a virtualized network.
Some of the benchmarks run on WSL generated results close to those running Linux directly on the same hardware, showing that WSL does well in terms of performance, according to Thomas.
The Microsoft team has run Python and Ruby on WSL, and compiled programs with gcc as one would do on Linux, so generally it mostly works, but there are still some issues: sudo is not fully working, there is some tuning to be done for the file system, some issues running MySQL, and others. Some users have mentioned not being able to run Java, semaphores or shared memory. The first three most requested features on the UserVoice WSL channel currently are: using slash in both environments, launching Windows processes from Bash and open sourcing WSL.
Microsoft is providing this ability to run Linux on Windows to enable operation teams, especially those working on cloud instances, to be able to administer their systems from a single Windows/Linux machine without having to resort to another computer or a virtualized solution. Many systems running in the cloud are Linux machines, so it makes sense to make ops life easier.
For more details we recommend MSDN WSL Overview and the Channel 9 video WSL: Architectural Overview.
