> ## Content Index > Fetch the complete content index at: https://www.ctrl.blog/llms.txt > Use this file to discover other available public pages before exploring further. # Run Linux desktop apps on the Windows Subsystem for Linux - URL: https://www.ctrl.blog/entry/how-to-x-on-wsl/ - Published: 2016-04-07T03:24:00.000Z - Updated: 2026-08-23T22:11:24.000Z - Description: First look at running X11 graphical Linux applications under an X Server (like xming) on Windows 10 using the Windows Subsystem for Linux (WSL)! - Author: Daniel Aleksandersen - Tags: Linux, Microsoft Windows *“\[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** (2021-04-23): You’ll want to read my [newer article on WSLg](https://www.ctrl.blog/entry/wslg-desktop-apps/) 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: 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 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](https://x.cygwin.com/?ref=ctrl.blog), but you should have similar luck with the much simpler [vcXsrv](https://sourceforge.net/projects/vcxsrv/?ref=ctrl.blog). 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: ```shell export DISPLAY=:0 ``` This 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](https://cdn.synaps.media/control/content/images/2026/08/bash-on-windows-x.png)](https://cdn.synaps.media/control/content/images/2026/08/bash-on-windows-x.png?ref=ctrl.blog) *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](https://apps.gnome.org/app/org.gnome.Boxes/?ref=ctrl.blog) 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?