Launch GUI Application in WSL without XServer

[macxfadz]

I have installed windows 10 (b.1703) creators update recently and I am using ubuntu subsystem(WSL).There I have installed Visual Studio Code successfully.Problem is that any GUI elements required by application can not be launched(no GUI will be elements displayed reason may be WSL has no direct Graphic driver support).

I wanted to know How to provide graphic driver support to WSL in order to facilitate GUI applications? without installing 3rd party software such as XMing-Xserver,putty etc.

Else do we have any other mechanism to achieve it ? only modifying Ubuntu(Linux subsystem) side? other than switching to Windows 10 Insider preview builds?

I addressed this issue in superuser forum too.Please be kind enough to refer it too - Superuser link

[fpqc]

Not right now. After I pressed Ben Hillis about it, he said maybe in the future they might implement some kind of (usermode) graphics driver as well as some kind of kernel-mode interface in the far distant future that would pipe EGL/OpenGL through Windows Presentation Foundation with a separate rendering and display application on the windows side, but it's not at all a priority now. You would still run X or Wayland, but within the environment in that case.

I don't remember the specifics but you should be able to find it if you search the issues board.

[onomatopellan]

"With LoWe it's possible to run X programs without employing any third-party X servers."
https://github.com/kpocza/LoWe

I didn't try it yet though.

[fpqc]

@onomatopellan It is very slow because it relies on saving files to disk. It literally outputs the framebuffer to disk, then reads it back through wpf, because there is no DMA through a graphics driver.

Edit: Also, it won't be hardware accelerated, so it's rendering is as slow as X over TCP, but together with the framebuffer streaming method, it's likely several orders of magnitude slower..

[markeissler]

@macxfadz I think this is just way beyond at least the current scope for WSL. Similar requests are being made by other users and it would seem to me that there's confusion over what WSL is trying to provide vs what some users think it should provide.

From what I understand, at the moment WSL is trying to support text-based apps along with an ability for both Linux and Windows to access each others' file space. This is a huge win for developers specifically those who have been working on either OSX/macOS or Linux because of the native support for a *nix shell among other things. On both systems users have had the ability to launch GUI apps directly from the command line because the command line (shell) is an integrated part of the underlying OS. That's not the case in Windows 10.

In Windows 10 the approach is to use Windows native apps when a GUI is required, and then those apps would be able to access the WSL file system as needed.

However, there are still problems with this approach. I can think of, for instance, trying to run VSCode in Windows where you also need to access the WSL file system. Some examples are developing for Ruby, Go, Node: where VSCode itself needs access to related libraries just to handle Intellisense and other necessary features. The solution so far is to install all of the dependencies in both places (Windows and in WSL) but that's just not ideal, it's certainly not convenient where on Linux and OSX/macOS all of this just works.

Some users are suggesting that the way to fix this is to launch a Linux native VSCode (or whatever) from WSL and to do that you'd need to start an Xserver. But this is kinda silly in that it's not an elegant solution at all. If you really want to do that, then just run a VM.

I think a far better way to solve the problem would be establishing some sort of context that a Windows app can leverage to know that all of its own dependencies are in Windows and all of the project's dependencies are in WSL. With that second context in place, an app like VSCode would only resolve its very own dependencies in Windows and look elsewhere (i.e. within WSL) to resolve any other dependencies.

But who knows. Perhaps the WSL team already has something planned around fixing this. In the meantime, I continue to use macOS.

[sunilmut]

@macxfadz - Thanks for you suggestion. As others have also noted, the current focus is on command line. But, WSL does not do anything to block GUI through Xserver. So, feel free to play around.

[ghost]

Some users are suggesting that the way to fix this is to launch a Linux native VSCode
(or whatever) from WSL and to do that you'd need to start an Xserver. But this is
kinda silly in that it's not an elegant solution at all. If you really want to do that, then
just run a VM.

Well, things may not be "elegant" ... but it is the *nix family, ubuntu/debian - linux.

Things should be practical prior to elegant. :)

There is elegance in the *nix world though. The NixOS has a very sophisticated
approach to a filesystem. GoboLinux has the prettiest file layout IMO.

I am with all those who want to have xorg-apps work one way or the other and
many already work as-is via various ways, e. g. I can use mate-terminal just
fine if I start xming (mingw ... whatever the name was... Xming X server)

These discussions are still useful. For example, I did not hear about LoWe
before.

The problem with your comment about running a VM is that some users, for
various reasons, can not or do not want to use a VM. I for example always
felt that a VM is a lot of extra work for little gain. Dual booting is an option
but with the "Windows Subsystem" I can actually avoid all of that. I think
that that approach is better than both dual booting and VM actually.

All my ruby code works just fine, ironically even better than the rubyinstaller
ruby.exe, so I do all my work on windows in a terminal (like mate-terminal),
on a win10 laptop, and it works. There are a few minor glitches ... sometimes
it seems as if the input just "hangs" until I press enter (weird ...), and there
is a slight speed penalty from what I have noticed. But aside from these
small issues, I compiled most of gnome so far and am working on kde
eventually, all on this subsystem/simulation thingy, and it works really very
well.

But having said that, I also agree - I guess the more important focus is
to iron out the non-GUI things first. I am sure the next release build will
have lots of improvements already, and some minor ones hopefully
that can be looked into too, like why lspci is not working correctly so (not
a huge issue but it would be nice if it would work, but I digress - it is
for another issue request).

[sunilmut]

@shevegen - good comments and useful insights. Please do not let the "closed" tag stop anyone from chiming in. It's only for us to track issues. Discuss away!

[markeissler]

@shevegen

The problem with your comment about running a VM is that some users, for
various reasons, can not or do not want to use a VM. I for example always
felt that a VM is a lot of extra work for little gain. Dual booting is an option
but with the "Windows Subsystem" I can actually avoid all of that. I think
that that approach is better than both dual booting and VM actually.

I don't understand. VMs are pretty lightweight these days thanks to processing power, large amounts of memory and disk, etc., that are available to us. On the macOS side I run VMware all day in conjunction with Docker but if I really wanted to go lightweight I could just fire up hyperkit or xhyve which are native hypervisors similar, I think, to hyper-v; granted, neither hyperkit or xhyve support a GUI, still booting up a linux environment in them is super fast.

While I think it's great that a Windows-based X-server can solve parts of this problem, somewhat, it's still not the ideal way to go about this: it's a technology originally developed for connecting local terminals to remote applications. There needs to be a way more efficient (and performant) means of connecting a GUI to an app running in WSL and with all of the work that's been done so far just to marshall linux kernel calls to/from the Windows NT kernel I would think that there might be something on the roadmap to make this new functionality of Windows 10 more, errr, macOS-like.

[macxfadz]

@ALL
I post this issue because of this,I am a C/C++ developer,currently I am using Visual Studio for my day today developments.Think we have GUI application or 3D-Game (based on Vulkan api)to build,currently there is a nice feature i,e, through ssh we can debug our program run on WSL with Visual studio ,a great feature isn't it? but when it comes to mashup with Computer Graphics phenomena,if WSL can communicate with Graphics Driver installed on windows ? things get better right?
Linux and Windows two different architectures we know,but WSL actually runs on windows platform,Microsoft developers may able to build an adapter or intermediate graphic api calling mechanism between WSL and Graphic Card.
Think someone can make argument like this ,

what if we installed vendor provided graphic driver (Linux version) on WSL ,will it work?

Theoretically No,My opinion ,why? because still WSL is a "Program" run on Windows platform,if you need graphic call you have drive it though windows graphics driver ? am I incorrect?
Therefore the solution can be bring out by our O/S vendor - Microsoft Devs,only they can build intermediate/direct Graphic API call layer between WSL and VGA/GPU hardware with aid of Hardware vendor.

Since I am not a Computer Science guy feel free to correct me If my opinion is bad or incorrect.I am Mathematics Student who has passion about GPGPU programming.Therefore I really like to work between Windows and Linux Platforms. I really appreciate and love this VS -WSL debug concept,it's really helpful.What we want is little support to bring it from CLI to run at least simple GUI app.
Thank you.

[fpqc]

@macxfadz it's one of the higher-ranked uservoice requests. It's also not happening yet. They have other things that are a higher priority.

[macxfadz]

@fpqc Can we expect a solution for this matter on next Windows 10 release on coming September?

[fpqc]

@macxfadz specifically they have ruled it out in the next release. Not sure what will be the status in the likely 1806 release (going by the usual release schedule). Keep your eye on the release notes and blog.

The only thing we do know is that MS did implement something similar in the ADSS precursor to WSL (android emulation layer for windows mobile that was discontinued, though the majority of its codebase was moved over to WSL).

[Ciantic]

I find this interesting, it could allow to develop e.g. with Haskell or OCaml by running the VSCode from inside WSL.

Haskell for instance is next to impossible to get working with all the tools in Windows, and many tutorials point out that don't do it, since you waste just your time. I have tried, on and off again, and indeed, I just waste time.

[dresswithpockets]

@Ciantic you can use VS Code in windows and compile in WSL. You can also run language servers in WSL and have them still operable over localhost, if you want to use some LS features in VS Code. So, at the very least, you can do that and it will be roughly the same in terms of functionality as running VS Code in linux.