Put Windows and Ubuntu desktops side by side

[alexanderwhatley]

Seeing now that the Ubuntu desktop from WSL itself can be run using dbus, does the WSL team have plans to eventually integrate the Ubuntu desktop into Windows itself, so we can have multiple Windows and Ubuntu desktops side by side?

[iamaaron]

I believe that defeats what they are going for here. They are trying to bring the Bash to Windows, not necessarily the GUI. They are trying to give developers tools that they would use in accordance to the Bash, not a GUI.

[alexanderwhatley]

Sure, but a GUI would be really helpful too, as plenty of GUI tools that would be very helpful with development, such as IPython notebook, Spyder IDE, RStudio, MATLAB IDE, etc. run very poorly or not at all on Xming or dbus, and would be impossible to use productively unless some kind of Ubuntu UI was provided.

[Manouchehri]

Try VcXsrv, it handles multiple windows fine.

[aseering]

iPython Notebook works great; I use it a lot. Though you need the fix described here. Just open a browser (either Linux or Windows) and point it at the notebook's URL.

I haven't tried the other programs that you listed; it's a fair general point, though I would personally prefer to have Windows and Linux windows alongside each other rather than being on separate desktops, which I also think is closer to being a reality today.

[fpqc]

Yes, Manouchehri is right, you can run VcXsrv in multi-window mode, which displays X applications side-by-side with Windows GDI? applications (GDI iirc being the Windows equivalent of X).

VcXsrv running in this mode has a few quirks (clicking a native Windows window does not inform the X application that it has lost focus, which matters for things like Tilda, there is no direct way to register Windows global hotkeys from VcXsrv, VcXsrv does not yet provide full support for HW acceleration, leading to slower performance of X applications, etc), but by in large, it works very very well (and if WSL catches on like I expect, there might be a lot of work done to improve VcXsrv, maybe MS might even fork it and maintain a sort-of-chromium-like repo for it, in order to improve functionality with the whole OS and without having to rewrite it (no fear of lost sales by MS, since improvements to VcXsrv would only be relevant for Windows users, and Microsoft has much better internal documentation on some of the low-level stuff that is used to implement GDI and that could be extended to X)).

I don't know if anyone has made a directsound implementation of something like Pulse or Alsamixer, but the main thing remaning for side-by-side functionality is audio.

[aseering]

Pulse, like X, can work as a client/server model over TCP, and there's a Pulse server for Windows. But the last time I checked, it didn't work yet -- see #486 .

[fpqc]

Another thing other than weechat that uses sockets in datagram mode.

But wait, aseering, does that not mean that pulse needs to be configured in UDP mode instead of TCP mode?

[aseering]

@fpqc -- I've updated #486 ; it seems that pulse is internally using a socketpair() internally for interprocess (inter-thread?) communication, and that's what's failing. So it's not the TCP socket that's causing the issue.

[fpqc]

@aseering Exactly like weechat then, which uses it for FIFO and some other stuff.

@russalex @benhillis See, according to @aseering, this gives you guys all the more reason to support Unix sockets in datagram mode (I read the manpage, and I am guessing that AF_LOCAL, PF_LOCAL, AF_UNIX, PF_UNIX sockets are all the same thing, called generically a unix socket) it will allow you to support audio probably without any other modifications!

Because so much of the Linux UI stack can be connected through IP ports, and their final outputs are available as direct ports on Windows (VcXsrv, Pulseaudio), it seems like WSL could allow people to use Linux software with full Windows driver support, which would be really exciting.

[benhillis]

@fpqc You are correct, why have one name for something when you can have four? :)

Unix datagram sockets are very high on our list of features to implement because they will unblock a lot of things.

[fpqc]

@aseering So I was looking at this documentation on using Pulse remotely (effectively our use case) https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network/

and I read a bit about how it works.

I think what is failing is that Pulse is trying to set up a Datagram-mode unix socket, seeing that it fails, then quitting. This dgram socket is a socket that listens for audio for at least one of the many (maybe legacy) Linux audio frameworks. There may be an option (like the dbus fix) that tells pulse to set up listening on a different protocol, or disable listening on a legacy system like maybe OSS.

This will basically work with WSL by trunking the audio streams to the "remote" Windows pulse port.

However, according to that documentation, there is a way to set the env variables up so that like "DISPLAY=:0" for X, you can just directly forward the audio applications to the "remote" pulse server, completely bypassing the "local" linux-side one.

I would be testing this right now, but I had a power supply failure at home last night, and my replacement is only coming Tuesday, so it's phone-only for this weekend for me. Maybe you can figure it out?

[therealkenc]

Note that Pulse is opening up a local unix socket by default because it assumes (correctly in most use cases) that there's a local Pulse server that can talk to an audio device. Implementing more of AF_UNIX does not help Pulse or X because Win32 doesn't speak AF_UNIX, and conversely, WSL has no video or audio devices. It is awesome to see AF_UNIX improving though.

It might be that WSL inspires people to work on the Windows ports of X.org or Pulse. I hope it does. But remember there have been DOS/Windows X11 server ports since Quarterdeck released Desqview/X circa 1992. WSL does not change the utility proposition much. If people wanted to improve the quality of X.org Windows ports, they've had 20+ years to do so. The Android port of X lives in a somewhat similar state as XvSrv. XQuartz is a little better.

[fpqc]

@therealkenc Since /proc and /dev are implemented by lxcore and lxss, rather than Ubuntu userland, isn't there lots of potential for MS to keep track of and expose unix sockets on the Windows and Linux sides to allow for better inter-op (i.e. direct communication rather than going the long way around through TCP)? Also, if Pulse supports unix sockets fully, it should be easy to put the Pulse daemon in TCP mode, where the Windows copy can connect? There are a few ways that pulse can work, and unlike an X server, it doesn't need to attach to hardware (because of how its sinks work, this mode allows non-tcp-enabled audio applications to stream over a network through a pulse daemon. It also supports broadcasting over UDP in RTP mode).

Also, I hope some far-sighted people at MS might look into official MS-endorsed contribution, financial or programming, to a project like vcXsrv or an officially-endorsed fork, if devs aren't looking to improve X11 support on Windows. It would make sense financially for MS, because it improves their own product.

[therealkenc]

Unix sockets operate on filesystem inodes, such as /tmp/.X11-unix/X0:. Yes, Microsoft could add Win32 APIs to interact with C:\tmp\.X11-unix\X0:, and the VcXsrv people could use that API. A hint of why Win32 doesn't have a AF_UNIX API is in the name. Windows apps would run better on Ubuntu too if Linus started accepting Win32 API patches. [Granted, it is an unusual turn of events that Ubuntu, Android, OS X, and ChromeOS all have a broadly-speaking POSIX API under the hood, and Win32 ended up the odd man out. Who saw that coming 20 years ago.]

In any rate, Unix sockets are a bit of a historic artifact. Back in the day it performed better than ipv4 over localhost. Modern OSs support zero copy tcp, so it's kind of academic. Also there has been around eight Moore's Law doublings since it mattered.

A PA server without audio hardware is quite possible, just like a headless X server. They are hard to listen to, though.

[fpqc]

I think that PA might be easier to configure with the Linux-side server creating a single pipe over TCP to the Windows-side server (and it seems like this is an ordinary and supported configuration in X-less cases), at least from my small amount of reading the PA documentation while I am computerless.

Also, the Win32 API wouldn't need to expose Unix sockets as actual files in the Windows filesystem but as virtual communications ports in the Win32 style. It's not because TCP is better or worse but rather because it might make it easier to write programs on the Windows side that are aware of Linux-side daemons without having to reconfigure all of the Linux-side stuff to use remote communications.

[therealkenc]

Picking up this old thread on a quiet Friday. No, it wouldn't make configuration easier to create a single pipe for PA over TCP. But that said, doing AF_UNIX on Windows isn't as entirely silly as I thought. As it turns out your "virtual communication ports" are already a thing: abstract namespace Unix sockets. If WSL is to have real interop with Windows, it is going to need a DBUS<->COM bridge for cut&past / drag&drop. For example, cutting a mime image/png out of Edge and pasting into MS Office Online in Firefox on WSL, or dragging a file out of Windows Explorer and dropping into Nautilus. And visa-versa. [Which no doubt someone will post a bug that this doesn't work some day.]

All of this is doable (and should be done) in user-space for what it is worth, so there isn't any need for NT kernel changes. You can write a service on each side to marshal AF_UNIX in both directions over /dev/lxss, if there were someone actually motivated to do so. I am thinking mostly this motivation does not exist, because again the utility proposition remains a problem. You could have done the same thing over AF_INET for many years. It does look like someone was crazy enough to consider the idea but I have no idea where that project ended up.

[therealkenc]

Amusingly, AF_UNIX was announced in the 17063 Insider Blog, and alluded to (bizarrely) here. Kind of a hell thaws moment (next, native ptys on Windows). Not that I can try it out because Windows Update has been completely borked since FCU. But it would be fun to hack up VcXsrv and the PulseAudio Windows server to use the transport. Blog post here.

[therealkenc]

Ran course. AF_UNIX is now available in Windows. Baby steps to Windows/Unix unity and world peace.