vmsocket with mintty

[therealkenc]

Saw your post. First off, very nice work on getting AF_VSOCK working.

That being said, I am pretty sure mintty isn't going to be the killer-app for this. Thing is, we already have a channel. You've probably already also noticed that old /dev/tty1 in WSL1 is now the (infinitely more sensible) new /dev/pts/0 in WSL2.

Which is to say: there isn't actually a point to using another channel (be it AF_INET on localhost like wsltty, or AF_VSOCK in a hypothetical wsltty2). But not to discourage you or anyone from doing it for the time-sink value. It just doesn't make much sense when /dev/pts/0 is right there.

The fix is going to be along the lines of WSL#3279.

But regarding the mail you cited... If you do take a run at a wsltty2, you want MSYS2 via vcpkg, not Cygwin. MSYS2 apps are otherwise native Windows apps. In particular, they don't pretend to support </sys/socket.h> (see this thread). You'd just use <winsock2.h>. All of which to be clear has nothing to do with mintty, which doesn't care whether the bytes are going over a AF_VSOCK or a 300 baud modem. And after you've gone and marshaled the bytes over AF_VSOCK, on the WSL2 side you are going to have to create a (wait for it) /dev/pts/N just like sshd or telnetd (in your case let's call it wslvsockttyd). [The pretty screencap with all the sixels is by the way just Git Bash (note the icon) aka mintty with Windows OpenSSH and sshd doing the pty heavy lifting.]

As an aside since I'm here, I also have in my head (but not on paper) an api for marshaling data in and out of WSL2 which is not susceptible to the flawed "sorry the api is in flux" line of reasoning that we've been faced with since 2016. I'm sure you've noticed by now the disappearance of /dev/lxss in WSL2. In a more perfect world, that implementation detail wouldn't have changed anything. Think URIs to describe the channel and closed-but-extensible backends to implement the channel. One such backend could be based on vmsocket.

[Biswa96]

new /dev/pts/0 in WSL2

My grey matter is perforated in that area 😁 So, I'm reading some books.

the disappearance of /dev/lxss in WSL2

"I'm sure you've noticed by now" that the PPL restriction is somehow lighter now (except the conversion). So, anyone can make their own init, LxssManager, except need administrator privilege.

[therealkenc]

So, anyone can make their own init, LxssManager, except need administrator privilege.

Yeah did notice that 😉

Actually in a more perfect world, there is no need for elevated privilege at all, notwithstanding the unrelated and arguably superfluous step of enabling Hyper-V in the first place.

(except the conversion)

And there is the rub. Since WSL1 isn't going anywhere (this is a good thing), there is going to remain some unavoidable complexity in the model so everything looks seamless the end users.

[mintty]

Is this leading to a solution to build a wslbridge alternative for WSL2?
Anyone working on that?

[Biswa96]

Anyone working on that?

Answer: This repository 😄

I found some defects:

1. The addr.VmId is not exported with any documented method. So I may have to use raw COM methods.
2. According to this, vmsocket does not support getsockname. So I may have to use constant port numbers.

But these two points may not affect user experience. Any suggestions are welcome 🤗

[mintty]

Confused. If it's something similar to wslbridge-frontend and wslbridge-backend, the client would be a cygwin program and not #include <linux/vm_sockets.h>?

[Biswa96]

Ohh.. my mistake, I've not add any readme. Now, the code is just a demo to connect WSL2 and Windows.

[therealkenc]

The addr.VmId is not exported with any documented method. So I may have to use raw COM methods.

That's WSL#4131

[therealkenc]

new /dev/pts/0 in WSL2

My grey matter is perforated in that area 😁 So, I'm reading some books.

Probably counts off topic to wslbridge2 (in this one topic repo) but I spent the weekend doing a mintty fork based on ConPTY. There is no Hyper-V IPv4 address to divine, and no addr.VmId to divine either, because there is no bridge. Plays well with both WSL1 and WSL2. The relevant code is here. The code is still wet, and I wouldn't exactly call it production ready (it might never be). There are some rough edges. But, to a first order it works.

[mintty]

"vmsocket with mintty"

Can you describe a reproducible usage scenario?

[mintty]

Which of the 4 programs in hvsocket is the a.out in your screenshot?

[Biswa96]

I have added the code for "vmsocket with mintty". Compile the hvpty both in cygwin and WSL side with make. Run Windows side first then WSL side. Only the code need some sauce to be production ready. Technically, this issue is now solved. cc. @therealkenc @mintty

[mintty]

Running the client:

> LC_ALL=C ./hvpty
assertion "ret == 0" failed: file "hvpty_win.cpp", line 40, function: SOCKET Initialize()
Aborted (Speicherabzug geschrieben)

(Note the German error description despite LC_ALL=C which indicates the message is from Windows, not cygwin)

Running the server:

$ ./hvpty-backend
hvpty-backend: hvpty_wsl.c:32: Initialize: Assertion `cSock > 0' failed.
Aborted (core dumped)

If both errors would not happen, how would the backend be started? Can this be automated for a replacement of wslbridge?

[Biswa96]

hvpty is for WSL2. This whole discussion is about WSL2.