Mintty: Does mintty 3.0.5 detect wslbridge version per distro?

[BrianInglis]

mintty 3.0.5 release notes say only:
"WSL integration
. Switched to wslbridge2 gateway.
. Fixed handling of --WSL default distribution."
Does this mean mintty detects the WSL version per Windows release and distro and the available wslbridge/2 version(s) and invokes the appropriate wslbridge/2 version?
Should we provide our own wrapper to do so?

[Biswa96]

No not at all. The WSL version detection should be done in wslbridge and I'm planning to do so. But there comes two issues in my repo. First I have to solve them... 😭

[mintty]

Biswa's response is the future plan. The current release detects WSL modes "V1" vs "V2" and invokes the proper gateway, either wslbridge2 or hvpty, respectively. The former wslbridge is not used anymore.

I'm not sure what wrapper you have in mind, but it would be a good idea to package wslbridge2 for cygwin, so explicit invocation of mintty --WSL from cygwin would work without manual installation.

[Biswa96]

Here is my thoughts https://github.com/Biswa96/wslbridge2/issues/11.

[BrianInglis]

The current release detects WSL modes "_V1_" vs "_V2_" and invokes the proper gateway, either wslbridge2 or hvpty, respectively. The former wslbridge is not used anymore.

Compatibility with the existing interface wslbridge(1) in name at least should be maintained in mintty. Fixes that break backward compatibility should be avoided if at all possible, or have the need for breaking compatibility, and the migration requirements and workarounds explained. Many Cygwin and mintty users are non-developers who may have uses for WSLtty but need some hand holding even when changes are automated. They blame themselves or their system for doing something wrong when it breaks, and the cause and recovery are mysterious to them.

Is mintty wslbridge2 handling compatible with wslbridge(1)? So can I just copy wslbridge to wslbridge2 and use with _V1_ non-VMs as before? Or do I need to keep mintty 3.0.2 around for that?

It would be helpful if there was some more documentation in mintty about WSL, bridge operation, front ends, back ends, interfaces, etc.

I have run wslbridge (rebuilt to always use current Cygwin in the front end for flexibility and totally static back end for portability and stability across the latest distros for Debian, Fedora, SuSE, Ubuntu), with Cygwin mintty since --WSL appeared, with cross file system links for interoperability and ease of testing package builds and scripts across all environments.

I am holding off upgrading Windows, Cygwin, mintty, wslbridge*, until I can understand what are all the alternatives and the best approaches, given that some of the distros are not from the MS store, it is not yet clear to me: what might happen if any attempt was made to upgrade those to containers, and how to maintain interoperability with the internal file systems.

I'm not sure what wrapper you have in mind, but it would be a good idea to package wslbridge2 for cygwin.

Would have been a wrapper to select wslbridge(1)/2 but you select wslbridge2/hvpty.

Are there options to configure WSL _V1_ gateway and WSL _V2_ gateway protocols, front end and back end names and/or paths?

I had thought that wslbridge2 provided what is apparently done by hvpty, so what does wslbridge2 do that wslbridge(1) did not, and what does hvpty do instead, more than a netcat/socat session, more than an ssh session?

Is AF_HYPERV different from AF_VSOCK, which is the supported Linux VM protocol family, and is there any support for either in Cygwin?
Are all the putty network hooks long gone from mintty, so it could not be retargeted directly to AF_INET/AF_VSOCK/AF_HYPERV?
Would it be better to develop the current interface(s), with standard documentation, possibly more intuitive names, and package them?

[Biswa96]

Too many questions to answer. I will try to answer all of them, if anyone is missed let me know. Here it goes 💨

Is mintty wslbridge2 handling compatible with wslbridge(1)?

• The only difference users see only the --distribution option in wslbridge2. Old wslbridge2 uses the undocumented GUID from registry in -distro-guid option.

do I need to keep mintty 3.0.2 around for that?

• Yes you need to update mintty also because older mintty used --distro-guid option.

Are there options to configure WSL V1 gateway and WSL V2 gateway protocols, front end and back end names and/or paths?

• There are --wsldir and --windir options to change working directory. You can get all the options details using classical --help option.

so what does wslbridge2 do that wslbridge(1) did not

• In short, wslbridge2 replaces bash.exe with wsl.exe.

what does hvpty do instead

• hvpty replaces the AF_INET socket with AF_HYPERV socket. Hence the synchronization method is little different.

Is AF_HYPERV different from AF_VSOCK

• Different name is different realm. AF_HYPERV <--> Hyper-V <--> WSL2/Linux <--> AF_VSOCK

is there any support for either in Cygwin?

• One has write it from scratch. Here https://cygwin.com/ml/cygwin/2019-07/msg00023.html

[mintty]

To pick out the most essentials of your questions:

Is mintty wslbridge2 handling compatible with wslbridge(1)? So can I just copy wslbridge to wslbridge2 and use with V1 non-VMs as before? Or do I need to keep mintty 3.0.2 around for that?

The answer is 3 times no. As Biswa responded already, the interface is different, so wslbridge2 is not a drop-in replacement. However, the interface is handled transparently, under the hood of the --WSL option if you use this comfortable way of invocation.
Keeping wslbridge (1) for WSL V1 was not an option, since with recent WSL updates, an increasing number of problems was exhibited, and for me wslbridge would even not work at all anymore.
However, if it still works for you and you'd prefer it for some reaons, you can still use 3.0.5 with an explicit invocation of wslbridge, without the --WSL option in that case.

[Biswa96]

From @BrianInglis questions,

is there any support for either in Cygwin?

It is possible to map sockaddr_vm (Linux) to SOCKADDR_HV (Windows). The only thing that I do not know how to map is GUID VmId in SOCKADDR_HV structure. That GUID is specific to a VM session and only valid for current session. If VM is shutdown it will be changed next time. There is a workaround for that but cygwin has to create its own registry with admin privileges.

so what does wslbridge2 do that wslbridge(1) did not, and what does hvpty do instead, more than a netcat/socat session, more than an ssh session?

Since the inception of wslbridge, it only takes bits & bytes from WSL side and throws them to Windows side and vice-versa. wslbridge2 and hvpty does that same thing. The only difference is working procedure. Read the very first line of wslbridge README file.

[BrianInglis]

Thanks I found what I wanted answered further down.
So it looks like the bridges provide either pty like or pipe like stdio streams, over an RPC session using local AF_UNIX, AF_INET, or AF_HYPERV transports.
I take it the newer bridges drop AF_UNIX and pipe like stdio streams?

[Biswa96]

@BrianInglis Now wslbridge2 detects WSL version internally by-default. There is also a --wslver option to set WSL version explicitly. Also I am planning to make a FAQ with your questions.

[Biswa96]

Are there options to configure WSL V1 gateway and WSL V2 gateway protocols, front end and back end names and/or paths?
Would it be better to develop the current interface(s), with standard documentation, possibly more intuitive names, and package them?

@BrianInglis May you explain these two questions? These may help to develop wslbridge2 project.

[BrianInglis]

Suggest mintty options like the following, with what I believe are the undocumented, implied defaults shown e.g.:

# WSL v1 bridge front end wrapper - run from Cygwin by mintty
WSLv1fe=wslbridge2 
# WSL v1 bridge back end wrapper - run from Linux (statically built for Linux) by mintty
WSLv1be=wslbridge2-backend 
# WSL v2 HyperV VM bridge front end wrapper - run from Cygwin by mintty 
WSLv2hvvmfe=hvpty 
# WSL v2 HyperV VM bridge back end wrapper - run from Linux (statically built for Linux) by mintty
WSLv2hvvmbe=hvpty-backend

More intuitive names may be derived by writing out the program title (like above or under NAME on man page), then abbreviating those to get names like e.g. wslv1bridgefe... and wslv2hvvmbridgefe... .

Standard documentation includes at least man pages (possibly also HTML and/or GNU info pages), and internal --help, including the options, default bridge interface program names, and functional and operational documentation in mintty as well as "wsltty", wslbridge2, hvpty, and their back ends: documenting when, where, and how each of the bridge interfaces are selected and executed.

These bridge interface programs should all be specifiable and driven from mintty, providing only transparent communications channels as much as possible, from invocation until termination of the back end "shell" or other process invoked, in the traditions of rlogin and ssh.
It might be advisable to allow sessions to be established remotely, from workstations to WSL and/or HyperV servers, and ssh tunnelled thru the bridge interfaces for high security development environments (finance, intelligence, military, security).

[Biswa96]

There is no "hvpty" now in wslbridge2 repository, see v0.5 release. There is an option -V (or --wslver) to explicitly set WSL distribution version. If user do not provide that option wslbridge2 automatically detects it with WslGetDistributionConfiguration function.

I have not thought about the man page and the usages other than WSL. But I will try.

[Biswa96]

From the above @BrianInglis's questions:

is there any support for either in Cygwin?

Is there any way to place the Windows socket into cygwin world? For example, create a socket with ws2_32.dll socket() function and take that SOCKET value into cygwin so that other read/write, poll, select, close operations can be performed.

[BrianInglis]

*TL;DR: _Cygwin_ supports an extensive Unix socket API, enough to port most network apps, which are not heavily dependent on either _BSD_ or _Linux_ low level system facilities e.g. there is no _Cygwin_ ifconfig.

Typically some mix of _Fedora Linux_ and/or _BSD_ flavour API is supported, to be somewhat compatible with RH(/IBM), and be _BSD_ licensed, for use by RH(/IBM) and others in commercial apps or systems, as is the newlib _libc_ on which _Cygwin_ is based.

The newlib _libc_ supports POSIX functions for _eCos_ and _RTEMS_ RTOSes, each of which have been used in satellites, on a number of boards and chips, as well as standalone bare board/chip apps and systems, including a lot of support from and by ARM and others for their systems and chips.

_Cygwin_ is effectively the equivalent of a hosted fork of a newlib BSP (Board Support Package) supporting Windows PCs, but layered over newlib to emulate POSIX functions, by replacing and implementing functions using Windows APIs.
Because of the mismatch between Unix and Windows approaches, rather than being able to use Windows APIs generally as direct replacements for Unix syscalls, _Cygwin_ often requires a multi-layered approach to provide a faithful emulation of POSIX semantics.

Some _Cygwin_ volunteer contributors may also be RH(/IBM) employees, and/or paid and/or volunteer contributors to GCC, GDB, GLIBC, and/or newlib projects, and/or participants on standards committees, and/or have long histories in Unix and PC platform development.