Since the Windows 10 Fall Creators Update from 2017, the Windows Subsystem for Linux (WSL) is a fully supported Windows feature. In case you don’t already know about that feature: WSL is a compatibility layer which allows running 64 bit Linux binary executables (in ELF format) natively on Windows 10 and Windows Server 2019 in a console window. It uses much fewer resources than a fully virtualized machine. Since all Windows drives are, by default, mounted with their drive letters under
/mnt/
it also allows users to use Windows apps and Linux tools on the same set of files. By pressing Shift while right-clicking on a directory in the explorer, you will even see a new context menu entry named “Open Linux shell here“.
To enable WSL you need to enable the corresponding Windows Feature: press
WIN+R
, enter “optionalfeatures“, press
Enter
, enable the “Windows Subsystem for Linux” in the dialog and reboot the machine. After that, you can choose from and install one of the Linux distributions available in the Microsoft Store: Ubuntu, Ubuntu 18.04 LTS, Debian, SUSE Linux Enterprise Server 12, openSUSE Leap 42, Kali Linux, or just search for “Linux” on the Microsoft Store. At first start, you have to choose a username and a password and you are good to go. You can read more about the installation process in this Microsoft Guide.
Going beyond
Microsoft sees the Windows Subsystem for Linux primarily as a tool for developers, especially web developers. For example, the
gcc
compiler and the
build-essential
package is installed by default. Let’s see, if we can go beyond that stated purpose and run Linux GUI applications on Windows without the overhead of a virtual machine. And indeed that’s possible.
The first step is to install an X Server. There are already a lot of X Server apps for windows you can choose from. Maybe the most popular and up-to-date software is the VcXsrv Windows X Server. Unfortunately, that didn’t work. Next, I tried the Xming X Server for Windows, and even though the free version of this software hasn’t been updated for almost three years, it worked perfectly.
After installation of an X Server, we have to tell the Linux apps where to send the video data. To make that information persistent, you can create or edit the file
.bash_profile
in your home directory
sudo nano ~/.bash_profile
and add the line
export DISPLAY=:0
Next, we can install Firefox the usual way. For this test, I have installed Debian 9.7 as the WSL distribution, so the standard packages provide Firefox ESR:
sudo apt update
sudo apt install firefox-esr
firefox
If all worked well and the X Server is running, the Firefox app window should now open on your Windows desktop.
There is one caveat: there is no graphics acceleration available, so the video output might be a bit slow sometimes.
Small excursion: Securing the environment
After the installation of Firefox, one might have the idea to use the Windows Subsystem for Linux as a secure browsing environment to guard Windows against the diverse dangers of the web. But as mentioned above, all local drives are mounted by default in the system and every Linux process can, by default, read from and write to that drives. To change that, the Windows Subsystem for Linux introduces the configuration file
/etc/wsl.conf
. The content of this file is formatted according to any Windows ini file: a text file with section names in square brackets, followed by key-value-pairs. This is an example configuration file with, at the time of the writing of this post, all possible keys set to their default value:
[automount]
enabled = true
root = "/mnt/"
options = ""
mountFsTab = true
[network]
generateHosts = true
generateResolvConf = true
[interop]
enabled = true
appendWindowsPath = true
The most radical way to secure the environment would be to set the key
enabled
to
false
in section
automount
. No drives are mounted any more and no malware can change data outside of the virtual file system. But that also means that you cannot access any data on your windows drives to, for example, upload files.
To allow at least read access to the drives, you can set the
options
key in section
automount
to the value
metadata,umask=222,fmask=222
.
Another attack vector from inside the WSL would be to start a windows program to change data, as any windows process can access the Windows drives and also runs with the access rights of the user starting the WSL command shell. To change this, just set the key
enabled
to
false
in section
interop
. This way, no Windows program can be started from a Linux process.
So a minimal example of the
/etc/wsl.conf
file to prohibit malware access to any Windows drive would be
[automount]
enabled = true
options = "metadata,umask=222,fmask=222"
[interop]
enabled = false
In most cases, though, people installing the Windows Subsystem for Linux may want to use the advantages of using Linux tools also with their Windows files.
If you want to know more about the possibilities of configuring the file
/etc/wsl.conf
you can read all about that in Automatically Configuring WSL.
Installing a graphical editor
As a software developer, I first need an editor to create and edit the source code. So let’s try to install the more and more popular Visual Studio Code.
# install certificates so wget doesn't complain
sudo apt install ca-certificates
# get the latest VS Code installer package
wget -O code.deb https://go.microsoft.com/fwlink/?LinkID=760868
# install VS Code
sudo apt install ./code.deb
# install additional packages
sudo apt install libgconf-2-4 gconf2-common gconf-service libxss1 libdbus-glib-1-2 libasound2
At this point, we have a problem. Visual Studio Code is based on Electron, an open-source framework allowing for the platform-independent development of desktop GUI applications. Unfortunately, Electron does not run in a graphical environment without graphics acceleration. This is not a problem inherent to WSL, but to every remote graphics terminal, especially XRDP. To make it run, one can patch the library file
/usr/lib/x86_64-linux-gnu/libxcb.so.1
, but that may break other applications relying on that library. The best solution seems to be to create a local patched copy of the library and use it just for VS Code:
# make a copy of the library in the home directory
mkdir ~/lib
cp /usr/lib/x86_64-linux-gnu/libxcb.so.1 ~/lib
# modify the local copy
sed -i 's/BIG-REQUESTS/_IG-REQUESTS/' ~/lib/libxcb.so.1
To finally start Visual Studio Code, we can now use the following command line, setting the dynamic loader path so Visual Studio Code uses the modified library:
LD_LIBRARY_PATH=$HOME/lib code
And again, if all is set up correctly and the X Server is running, the Visual Studio Code window opens on the Windows desktop.
Do you prefer Atom? No problem:
# just in case you didn't do this before
sudo apt install ca-certificates
# get the latest Atom installer package
wget -O atom.deb https://atom.io/download/deb
# install Atom
sudo apt install ./atom.deb
Since Atom is also based on Electron, we just use the same local patched library version to run the application without graphics acceleration. If you didn’t install Visual Studio Code before, you first have to create the patched local library as described above.
LD_LIBRARY_PATH=$HOME/lib atom
The installation of Sublime Text is just as easy:
# just in case you didn't do this before
sudo apt install ca-certificates
# install the GPG key
wget -qO - https://download.sublimetext.com/sublimehq-pub.gpg | sudo apt-key add -
# ensure apt is set up to work with https sources
sudo apt-get install apt-transport-https
# select the stable channel so we can install it as a trial
echo "deb https://download.sublimetext.com/ apt/stable/" | sudo tee /etc/apt/sources.list.d/sublime-text.list
# install sublime-text
sudo apt update
sudo apt install sublime-text
# start sublime-text
subl
And if you are still not convinced that the Windows Subsystem for Linux might be a viable alternative for developing Linux software you can just install Eclipse:
Installing a graphical file manager
To round it up, I tried to install some graphical file manager. GTK based graphical applications normally need the
dbus-x11
package, so it’s best to install that first:
Desktop independent file manager like gentoo, Xfe, ROX-Filer, SpaceFM, and PCManFM in most cases install and run without problems, whereas Thunar is missing icons.
GNOME/GTK based file manager like Nautilus and Gnome Commander seem to mostly work. As there is no real desktop installation, Nautilus complains about the trash not being existent and just plain stops when clicking on the Desktop icon, unless a folder named “Desktop” is present in the home directory. Gnome Commander only complains about missing icons. Nemo, a Nautilus fork for the Cinnamon desktop environment, seems to work, but strangely brings its own desktop window.
With KDE based file manager your mileage may vary: Dolphin installs and runs in principle, but generates a lot of warnings in the terminal and the visual representation is broken. Konqueror installs and, despite some warning messages in the terminal, seems to run without problems. The graphically simple file manager Krusader installs and seems to work.
Where to go from here
There is already a lot of documentation about the Windows Subsystem for Linux available on the web. Below I have collected some links containing a lot of advanced information which go well beyond the scope of this post. And of course, it will be very interesting which developments in interoperability we will see in the future: a Windows Subsystem for Mac OS, maybe?
Michael Treat’s WSL setup guide on GitHub