How-To
Running Graphical Programs on Windows Subsystem on Linux
Pushing the boundaries of what WSL can do.
This is the third article in a series on using Microsoft Windows Subsystem on Linux (WSL). The first article discussed how to enable Linux on Windows and install it on an ESXi server. The second article covered some of the things you can do with WSL after it's been installed. This final chapter will cover using graphical programs on it.
Running OpenSSH Server
WSL comes with the OpenSSH package, but because it's only a minimal package, it will need to be uninstalled, and the full OpenSSH server installed and configured
(Figure 1). Fortunately, WSL comes with apt-get, making it a trivial process to install the full version:
#sudo apt-get remove openssh-server
#sudo apt-get install openssh-server
[Click on image for larger view.]
Figure 1. Installing OpenSSH Server.
Windows 10 comes with an SSH server, and it will either need to be disabled or the port that will be used for SSH on WSL will need to be changed. I chose to do the latter and use port 2200 for WSL SSH.
A few other parameters will also need to be changed in the OpenSSH configuration file. The file -- /etc/ssh/sshd_config -- will need to be edited to add/change the following:
Change - PermitRootLogin no
Add - AllowUsers yourusername
Change - PasswordAuthentication yes
Add - UsePrivilegeSeparation no
Change - ListenAddress 0.0.0.0
Change - Port 2200
After these changes have been made, the SSH service will need to be restarted:
# sudo service ssh --full-restart
Any firewalls running on the Windows side will need to be disabled or have a port opened up.
Figure 2 is a screenshot of connecting to the WSL SSH server directly from WSL from the Windows 10 desktop using PuTTY, and my desktop using PuTTY.
[Click on image for larger view.]
Figure 2. Connecting to WSL SSH server.
Note: If you're having difficulty getting OpenSSH Server running, you can always try another SSH server such as Dropbear. To install and use dropbear do the following:
#sudo apt-get install dropbear
#sudo dropbear
Run Graphical Programs
Microsoft doesn't support graphical programs on WSL. Bash on WSL is intended for running command-line programs that developers might need, but it's possible to run graphical Linux desktop programs on Windows using the Bash shell. To be more precise, you'll be able to display graphical programs running in WSL on a Windows 10 desktop by using an X server which runs on Windows 10.Â
To use WSL with graphical programs, an X server will need to be installed on the Windows 10 system and the DISPLAY variable will need to be set in Bash. Fortunately, there are many X servers that run on Windows; some of the more popular free ones are Xming, Cygwin X, and vcXsrv.
I've used Xming and have had good luck with it in the past. It comes with a setup wizard, and I installed it on my Windows 10 system without any difficulty (Figure 3).
[Click on image for larger view.]
Figure 3. Installing Xming.
I used the default settings; after launching it, Xming appeared in my system tray, running in the background and waiting for a graphical WSL program (Figure 4).
[Click on image for larger view.]
Figure 4. Xming in the system tray.
Trying Out Graphics Applications
Once you have an X server installed and running, you'll need to install graphics applications. A good starting point would be the x11-apps package, which has about two dozen X applications, including xclock, xcalc, and xeyes. To download and install it run the following:
# sudo apt-get install x11-apps
Once the applications have been installed, you can start them by setting your display and executing the application on the Bash shell. Figure 5 shows xeyes running (a program with "eyes" that follow a moving cursor).
# export DISPLAY=:0
# xeyes
[Click on image for larger view.]
Figure 5. Running an X application.
Three other applications that I worked with were Blockout (a 3-D Tetris-like game), VLC (a video player), and the Firefox Web browser. All of them were installed using apt-get:
# sudo apt-get install blockout2
# sudo apt-get install vlc
# sudo apt-get install firefox
Firefox (Figure 6) worked even though I received some error messages on the command line when I first started it. Blockout (Figure 7) worked flawlessly, which surprised me as it is an extremely graphics-intensive application.
[Click on image for larger view.]
Figure 6. Running Firefox.
[Click on image for larger view.]
Figure 7. Running Blockout2.
When I tried to run VLC, many error messages were generated when I tried to load an MP4 file. The VCL interface and error messages are shown in
Figure 8.
Microsoft has a very good Web server and doesn't recommend running one on WSL, but I was able to install, configure, and run the Apache2 server, albeit with some warning on startup, and while it was running.
# sudo apt-get install apache2
# sudo /etc/init.d/apache2 start
I did try other graphic applications such as twm, xterm, tightvncserver and xman, and they worked fine, while other applications such as xprop, xmag, xload and xconsole didn't.
[Click on image for larger view.]
Figure 8. Trying (unsuccessfully) to run VLC.
Add WSL to Your Toolbox
I honestly didn't expect the X graphics system to work on WSL, and although it's far from being ready for production, I was able to run some fairly sophisticated and powerful programs using it.
In this three-part series I first walked you through downloading and installing Windows 10 on vSphere. I then showed you how to use it for what it was designed for, and finally I pushed its limits to do things it was expressly designed not to do. This demonstrates that WSL is a valuable tool that you may want to install and become familiar with. Although the graphics programs are inconsistent, the rich set of text line tools make it a valuable tool for developers and casual users alike.
About the Author
Tom Fenton has a wealth of hands-on IT experience gained over the past 30 years in a variety of technologies, with the past 20 years focusing on virtualization and storage. He previously worked as a Technical Marketing Manager for ControlUp. He also previously worked at VMware in Staff and Senior level positions. He has also worked as a Senior Validation Engineer with The Taneja Group, where he headed the Validation Service Lab and was instrumental in starting up its vSphere Virtual Volumes practice. He's on X @vDoppler.