Primarily the Windows Subsystem for Linux was released for developers used to deploying things on Linux servers, but after a week using it, I have to say it's proven a stable and capable substitute for what I was using on my previous laptop. The application for launching the command line is known as 'Bash on Ubuntu on Windows'. As we'll see, this is no mere command line emulator, although it's the inverse of
WINE in a very approximate sense. From the users' point of view it appears to function just like a virtual machine.
Finding Your Way Around the Command Line
The first thing I wanted to do was learn something about the Linux subsystem's environment, and running '
ls -l' in the root directory, I could see there was a full Linux/UNIX filesystem present.
And this is isolated from the host machine's actual filesystem, which is mounted as an external volume at
/mnt/C/. If I wanted to use the nano editor to modify a text file in MyDocuments on the C: drive, I'd therefore need a command like:
$nano /mnt/c/Users/User/MyDocuments/[filename]
If the '
top' command (or '
ps' or '
pstree') is used immediately after starting the application, and before switching to the root account, you'd see only two processes listed:
init and
bash, because we aren't working with a full operating system. That's also why there aren't any kernel modules loaded either.
For the command line to be of any real use, we'll need to install other programs for browsing the Internet, reading emails, modifying configuration files, developing and compiling code, etc. Here WSL provides us with dpkg and apt, which we can use to query the repositories and install whatever programs we need from them. Programs I typically use include:
- alpine: Email client
- apt: My package manager of choice
- binutils: For various analysis and reverse-engineering
- gcc: Just in case things need compililng
- hexcurse: Hex viewer and editor
- HT(E): Disassembler and hex viewer
- lynx: A decent command line Web browser
- Midnight Commander (mc): Semi-graphical file manager interface
- nano: Perhaps the most accessible command line text editor
- pal: Calendar application
- poppler-utils: Contains the utilities required to read the text contents of a PDF in the command line
- sc: Spreadsheet application
- vim: My fallback text editor, if nano isn't present on a remote server
There's
a post elsewhere on this blog on how to perform various installation and upgrade operations using the apt package manager. To install, upgrade and remove programs, you must switch to the root account using the following command and providing the setup password:
$sudo su
To avoid the same broken package header problems I sometimes encountered before, I run '
apt-get update' prior to installing/upgrading anything.
The Subsystem Internals
What is the Windows Subsystem for Linux (WSL)? Is it an interpreter? Is it a virtual machine? Or is it an emulator? WSL is, roughly speaking,
an interpreter for ELF64 executables, and I've mentioned it as a sort of reverse-WINE. It has three general components: 1) A session manager running in user mode to handle the Linux instance, 2) The LXSS Manager Service and LXCore components that emulate a Linux kernel system call interface within the Windows kernel space, and 3) A Pico process for the Bash command line itself.
The LXCore translates the UNIX system calls to NT API calls, thus enabling Linux executables to run on the Windows system and use the host system resources. In order to simulate a Linux environment, the LXSS Manager needs to maintain an instance of the Linux system to manage the processes and threads associated with the system calls.
Lxcore.sys contains a system call layer, a Virtual Filesystem layer, and the several filesystems that comprise the directory structure you see when running '
$cd / ls'. VolFs and DrvFs might send system calls to the actual Windows NT kernel.
The best abstraction of the WSL concept I've seen is posted on the WSL development team's blog, where a comparison is made between the '
ls' command and its Windows Command Prompt counterpart, '
dir'. Both appear to do the same thing for the user, and both are user-space processes sending their system calls to kernel space. The difference is '
dir' sends its calls directly through the Windows NT API to the kernel, whereas '
ls' must communicate through the WSL core (Lxss.sys). You'll find LXSS as a DLL in
C:\Windows\System32\lxss\LxssManager.dll.
Another difference is '
ls' launches a 'Pico process' to achieve this, which differs from a conventional Windows process in that some of the regions, including the Process Environment Block and Thread Environment Block, are absent from its virtual address space. Basically a Pico process is a stripped-down process that requires a driver (such as WSL) to execute.
Therefore, the appearance of working within a Linux VM is illusory: bash.exe actually initiates another executable on behalf of the user, and WSL translates the system calls of both into NT API calls.
A consequence of this is that Linux shell executables can be run through Bash.exe in the Windows Command Prompt, using the following:
bash.exe -c "[command]"
Here I've run the '
top' command this way:
Well, that's the Windows Subsystem for Linux. Here are a few of the development team's blog posts if you want to learn more about it: