X on Bash on Ubuntu on Windows

Running Linux desktop apps on the Windows Subsystem for Linux

“[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 with access to the whole Ubuntu package repository. Getting 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 them you can even get running on top of WSL.

On Linux, graphical programs are historically drawn by talking to a display and windowing server simply called X. Windows itself has its own window server and doesn’t understand the X communication protocol, nor does the WSL include one. 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 very unique nature of this set up.

There are two kinds of problems that will keep Linux desktop apps from running on Windows:

  1. Problems with Windows Subsystem for Linux not being a completely faithful recreation of a running Linux kernel and the Ubuntu system.
  2. 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 controling 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 is no dbus. Considering that Bash on Ubuntu on Windows is a terminal emulator, this isn’t really 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=:0

This is actually 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

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 is no dbus, 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 filesystem.

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 actually of a Windows 10 desktop being virtualized inside GNOME Boxes running on 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 top of WSL?

19 thoughts on “Running Linux desktop apps on the Windows Subsystem for Linux”

  1. I installed Xming and was able to get Firefox to run and even load a web page before it crashed. To make it even more strange, I’m running Windows 10 under VirtualBox on Linux. As my coworker said when I described what I was doing, “Meta much?”

  2. This is great. Hopefully we will soon be able to wrap up any Linux software in a Windows installer, running an automatic shell script and installing all dependencies. That way, Linux ELF executables will become cross-platform (already supported in BSD).

    Speaking of which, now that we have X based apps running on Windows natively, it’s crazy that no one has still released a fully functional way of running them alongside Android natively in the Linux kernel’s framebuffer..

    Regarding unholiness, is it possible to get WINE installed – or perhaps it has too many unsupported dependencies?

    1. WSL was described by Windows as a “reverse WiNE”. Why would you want to install WINE to run Windows programs on top of a reverse WINE to run Linux programs on Windows? My head hurts now.

      1. Ironically enough, WINE has support for some old Windows programs (some Win32 programs from the 95/98 era and Win 3.1 16 bit programs) that are no longer supported in Windows.

  3. Looks fun but pointless too. People who are after free software shouldn’t use Windows anyway.

    1. I see it as a way to expose users who are already comfortable with Windows to Linux and free software. Whether they “should” use it or not, they’re using Windows, and the only way to tempt them over to Linux is to show them what it can do for them. Freedom come secondary to useful.

      1. I don’t think it works like that, if they have no incentive to switch to free software, they’ll stick with their narrow comfort zone, and it will only slow down GNU/Linux adoption. But whatever, it’s your project and you’re perfectly free to make anything you want. 🙂

        1. I think it does work like that. Mostly because I’m one of the people Daniel is talking about. Tons of people already use a mix of free and non-free software. WSL just makes it much more convenient to use Linux applications without using a dual boot/virtual machine set up.

  4. If you set LIBGL_ALWAYS_INDIRECT=1, you’ll also be able to run some OpenGL applications, like glxgears.

    Try it with:

    sudo apt-get install mesa-utils

    If you’re running an X Server with OpenGL extensions like XMing, you should get 3D gears rendered locally on your desktop.

  5. Hello,

    I spent some time fighting this yesterday/today. Eventually I figured out that I had to run Cygwin XServer (XWin.exe) with “-listen tcp” for this to work on the same machine.

    (I had to add a firewall rule to allow connections on TCP 6000 to allow connections from outside)

    Since that wasn’t mentioned above I figured I add this – just in case somebody is in the same bind as me.

  6. I cannot test because I do not use Windows, but you can try forcing D-Bus to use TCP instead of Unix sockets. You will want to change the listen directive in /etc/dbus-1/session.conf or session-local.conf, and you may (or may not) also have to manually set DBUS_SESSION_BUS_ADDRESS.

  7. To try and make your final sentence a little more understandable, you’re running X apps on Bash on Ubuntu on Windows in GNOME Boxes on Fedora. That’s awesome! xD

    To extend this further, I think we need to have a virtual machine program (built for Windows) running on Linux via Wine or we need a virtual machine program (built for Linux) running on Windows via WSL. But this is ridiculous enough for now!

  8. Anyone have an strace of the application they are attempting to execute? I’m working on a list of ways to manipulate applications using hooking, etc to get them executing properly without awaiting Microsoft’s closed source system for updating & extending their system call replacements.

  9. I just can’t understand why you would use Linux bash on windows. I really really can’t.

    Need good SSH support, get Unix, need good server and database os,get Unix, want a good node.js environment ? Get Unix. Want productivity suite and video game latest graphical card support? Get windows. Want to do graphical dev?go osx . Just use to the tool you need for your job. Why would you go trough the hassle to get Ubuntu bash ( and only that ) accessible to windows when you can’t even get a full native kernel emulation? It’s like… Well, I’m going to build a car from scratch, and ending up with just two weels and one seat. Microsoft classic marketing strategy,disilusuonal at best.

  10. How about Samba! (yes, really)

    Garming Sam, my colleague at Catalyst and fellow member of the Samba Team, wrote this article on how to run Samba under bash on Windows.

    The fact that Microsoft is implementing the POSIX API, and even more, the Linux ABI, seriously is really cool, and shows that something seems to have changed in Redmond. I could never have imagined this when I started in Samba 15 years ago!

Leave a Reply

Your email address will not be published. Be courteous and on-topic. Comments are moderated prior to publication.