Since Satya Nadella took over the helm of Microsoft in 2014, Redmond's aversion to Linux and open source software in general has given way to a new openness. As a result, Linux virtual machines (VMs) now run without complications on the Hyper-V hypervisor and in the Azure cloud.

The Windows Subsystem for Linux (WSL) adds a new compatibility layer to Windows 10. As the name implies, WSL is not a hypervisor that runs complete Linux systems in the form of virtual machines, but an interface that directly supports the execution of Linux ELF64 binaries [1].

WSL Architecture

The subsystem introduces what are known as pico processes [2], which run in user mode, forming the shell for unmodified executable Linux applications. To do this, they forward their system calls to the pico provider drivers lxss.sys and lxcore.sys in kernel mode and translate the system calls to their Windows counterparts. In the case of Linux system calls that have no direct equivalents in the Windows kernel, the drivers emulate the Linux kernel.

The surrounding enclosure is the LXSS Manager service, which runs in user mode and becomes active as soon as a user launches a Linux distribution with WSL. The LXSS Manager then creates a Linux instance, in which it launches the init followed by the Bash shell and all other executable files as pico processes (Figure 1). In early versions of WSL, as soon as the user closed the WSL console, the LXSS Manager cleaned up the respective Linux instance, which meant it was not possible to run background processes. However, Microsoft has since added this option [3]. If processes are still active in the background, a Linux instance now lives on, even if an interactive window is no longer open for the user.

Figure 1: The WSL comprises the LXSS Manager and pico processes in user mode, as well as the pico provider drivers in kernel mode (source: [4]).

Partially Compatible Filesystems

Because the Linux instances are not complete VMs isolated from the Windows operating system, the processes can interact directly with Windows and its filesystems. However, the filesystem strategies for folder and file management and for handling permissions differ between the two worlds. WSL meets this challenge by imitating the Linux Virtual File System (VFS) and by wiring interfaces to several filesystems through VFS [5]. Thus, TmpFs maps the memory-resident temporary Linux filesystem. The Linux pseudo-filesystems also have their counterparts in WSL in the form of ProcFs and SysFs (Figure 2).

Figure 2: WSL provides interoperability between Linux and Windows filesystems through multiple interfaces (source: [5]).

The primary WSL filesystem is VolFs. It is used for the root directory of the respective Linux instance. VolFs provides full support for Linux filesystem permissions, which can be edited by commands such as chmod, and other features such as symbolic links, case-sensitive folders and files, FIFOs, and sockets. The root directory of each instance is located in the %userprofile%\AppData\Local\Packages\<Name-and-ID-of-Linux-Instance>\LocaleState\rootfs path in Windows.

The literature on WSL – and partly in Microsoft's own online documentation – still has references to the %userprofile%\AppData\Local\lxss path, which is where the root directory lived in the first implementation of WSL launched by Microsoft in 2016 in cooperation with the Linux distributor Canonical, known for its Ubuntu distribution. However, this path only has historical significance. In current Windows installations, this original variant of WSL no longer exists.

When dealing with the root directory, note that you can view the folders and files under Windows but not change them because NTFS does not support all of the Linux special features. Although NTFS can distinguish between upper- and lowercase, the permissions are not compatible, and not all characters in folder and file names that Linux supports are also allowed in Windows. VolFs takes care of these differences and stores them as metadata in the NTFS extended attributes. If you were to use Windows to add new folders and files to the root directory, these extended attributes would be missing and VolFs would be unable to use the data. Likewise, the extended attributes would be lost from existing data, which would thus become unusable for VolFs as soon as you change them under Windows. It was not until build 18342 (1903) of Windows 10 that this situation improved; Windows can now access root directories thanks to the introduction of shares in the form \\wsl$\<Name-of-Distribution>.

Exchange with DrvFs

Originally, interoperability between the worlds was only guaranteed by DriveFS, or DrvFs for short, which does not support all the functions that Linux supports. DrvFs restricts the names of folders and files to the character set that Windows uses and is compatible with Windows permissions. Data stored in DrvFs can be case sensitive, but Microsoft warns that not all Windows applications can handle this.

With regard to access privileges, you should note that WSL can map the permissions set under Windows in Linux but, of course, cannot revoke them. As the above path to the root directory shows, the Linux instances under Windows are user specific. Each Windows user receives their own Linux instance, and the data is stored in the user's personal profile. Within a Linux instance, users always have root privileges, but it does not automatically make you an admin outside of Windows. You can therefore only write from within Linux with sudo to locations that you are allowed to write to in Windows.

Under these conditions, the setup is bidirectionally compatible, and you can work with the usual Linux tools (e.g., awk and sed), as well as with Windows tools in VolFs-connected drives.