“[WSL] doesn’t include X Windows or any other graphical subsystem.” Oh, why did Microsoft have to go and make that a challenge?
The less-than-a-day-old Windows Subsystem for Linux (WSL) lets you run you the bash command prompt on Windows 10. It’s a mostly-complete Linux environment with access to the whole Ubuntu package repository.
Update (): You’ll want to read my newer article on WSLg for the current state of Linux desktop apps on Windows 10.
Installing new software onto WSL is faster and easier than using the Windows Store! (No account, login, license server negotiation, nor payment required.) The Ubuntu repository doesn’t just contain server-grade software, but also a full suite of desktop applications. Some of these you can even get running on top of WSL.
On Linux, graphical user interface (GUI) programs are drawn by talking to a display and windowing server simply called X or X11. Windows itself has its own window server and doesn’t understand the X communication protocol, nor does WSL include an X/X11 Server.
However, third-party open-source developers are awesome and have had working X servers running on top of Windows for years! Historically, you’d connect your X on Windows server to another Linux computer and run the programs over the network. Because X can do that.
Making graphical programs run on X for Windows through the new Windows Subsystem for Linux requires some configuration — and don’t expect too many programs to work just yet. No one has had time to iron out the bugs caused by the unique nature of this setup.
There are two kinds of problems that will keep Linux desktop apps from running on Windows:
- Problems with Windows Subsystem for Linux not being a completely faithful recreation of a running Linux kernel and the Ubuntu system.
- Problems with the X for Windows server not implementing everything that modern Linux programs expect.
There are some obvious issues of the former type: As of now, WSL doesn’t have a working pty/tty system used to interact with the controlling terminal, and it doesn’t appear to completely support Unix file sockets used by services and programs to talk to each other.
This all means I haven’t been able to find even a basic Linux terminal emulator that will run, and that most desktop programs fail since there’s no dbus. Considering that Bash on Ubuntu on Windows is a terminal emulator, this isn’t that much of a loss.
On the X server-side, I ended up using Cygwin X, but you should have similar luck with the much simpler vcXsrv. Download and install the window server like any other Windows program, then find and start vcXsrv from the Start menu. Then jump over to Bash and let it know about the new X server by running the command:
export DISPLAY=:0This is enough to run some of the simpler programs: Classic toys like xclock, xcalc, and xeyes work fine. Even some modern and classic GNOME programs will run mostly fine if you attempt to start them two–three times. Including, most surprisingly, the gnome-control-center!
X on Bash on Ubuntu on Windows – unimaginable just two weeks ago!
The venerable xeditor and SciTE text editors also run fine. They can read and save files from the Windows drive by looking in /mnt/c/.
Things start to fall apart if you try to get more ambitious, though. I could start GEdit – the GNOME text editor, but it crashes if you try to open a file or type (ibus?) Most other programs fail to start for various reasons: xterm and rxvt fail to get a pty, gnome-session fails because there’s no dbus session running, and Firefox starts but crashes after a few seconds.
Chromium crashes while trying to set up its sandboxing, after complaining about things in /dev and /proc. R works until you try to plot anything, then crashes. Xemacs21 pops up a window for a fraction of a second, then crashes.
The Liferea RSS reader manages to fetch feeds, but crashes when you try to look at one. No KDE programs work – they are all completely dependent on dbus. I couldn’t manage to install OpenJDK to try running a java program; one of the dependencies wasn’t happy with the emulated /proc file system.
I should mention that several of the aforementioned crashes were generic Linux segfaults and the like. I tried to look into those with gdb (the GNU debugger), but it was unable to properly start the process to be debugged – I suspect it would work on single-threaded programs, but anything graphical is likely to be multithreaded.
In summary, a large swathe of programs currently fail for technical reasons that might well be fixed; another large group fail for mysterious reasons that might or might not get better and simple standalone programs, especially very old ones, mostly work.
The screenshot in this article is of a virtualized Windows 10 desktop running inside GNOME Boxes on top of Fedora Linux while it’s running some various X and GTK+ desktop programs from Windows Subsystem for Linux! Why, you may ask? Because I could.
What unholy contraption can you get running on WSL?