WSL2 GUI application support related RDP protocol extensions preview specifications

Question

WSL2 GUI application support related RDP protocol extensions preview specifications

Marc-André Moreau 86

The WSL2 GUI application initial preview release is finally out, with source code implementing two new RDP virtual channel extensions in FreeRDP. While the source code can be used as reference for the RDP protocol changes, it would be a whole lot better to take a look at the corresponding preview specifications. Would it be possible to publish them in the Preview Documents section?

There is a new "gfxredir" virtual channel extension with dynamic virtual channel name "Microsoft::Windows::RDS::RemoteAppGraphicsRedirection" that is an improved version of RemoteApp using shared memory, and adapted to remoting Wayland applications.

There is a new "rdpapplist" virtual channel extension with dynamic virtual channel name "Microsoft::Windows::RDS::RemoteApplicationList" that is used to facilitate listing and launching applications available in WSL2 from the Windows host.

I haven't checked what kind of modifications have been done to the existing specifications aside from these two new virtual channel extensions, but I wouldn't be surprised if the older RAIL extension has been updated.

Steve Pronovost 1 Reputation point

2021-04-22T17:08:38.057+00:00

Hey Marc-Andre,

For the GrfxRedir protocol, we are still working on the documentation. I had hope to have it ready and release ahead of WSLg going public, but unfortunately we've been running a bit behind on this. Also, we haven't decided exactly where we will publish this one. It's kind of a special one because it doesn't apply for standard RDP over a network connection and our "protocol documentation" really target communication between a server and a client system, this one is very specific to RDP being used over a VM boundaries. We thought publishing this to the normal RDP specs location could cause some confusion and have been thinking of posting this document to the WSLg project (http://github.com/microsoft/wslg) instead once ready (by early June hopefully).

[1000 char limit]
Steve Pronovost 1 Reputation point

2021-04-22T17:08:58.717+00:00

The rdpapplist isn't an "RDP protocol" per say. RDP allows an RDP client and server to define private communication over a virtual channel. This VC is really specific to WSLg and use in the start menu integration. The server side is implemented between Weston/FreeRDP and the client side is implemented in an mstsc plugin. The source code of this plugin is available as part of the WSLg project here (https://github.com/microsoft/wslg/tree/main/WSLDVCPlugin). We weren't planning on formal RDP protocol documentation for this one as we really see this as WSLg specific use of private channel (and really not useful or applicable in other context).

[1000 char limit]
Steve Pronovost 1 Reputation point

2021-04-22T17:09:04.827+00:00

This rdpapplist is something we wanted to talk with you and the FreeRDP community about. It may make sense for FreeRDP to support similar plugin model such that this code could be factor as a server side and client side plug-in on both end as opposed to be part of the core FreeRDP as it is very specific purpose. So for example we could have a FreeRDP plugin for this similar to the mstsc plugin. Thoughts?
Marc-André Moreau 86 Reputation points

2021-04-22T17:13:28.36+00:00

You are reading my mind: take the current WSL2 GUI application support, replace Hyper-V and the VMBus by QEMU and some other type of transport, use a Linux host, implement the new virtual channel extensions in the FreeRDP client, and you end up with Linux-to-Linux GUI application virtualization. It may even be doable inside a Linux container instead of a lightweight VM. There's a use case for the Windows FreeRDP client as well, it's more flexible than mstsc because it's open source and therefore you make it do whatever you like.
Marc-André Moreau 86 Reputation points

2021-04-22T17:20:30.513+00:00

RDP goes beyond just the "network" extensions, there are a few undocumented RDP extensions that only work locally because they make use of shared memory, but I never bothered to either reverse them or ask that they be documented like the rest (I refer to the framebuffer redirection extension used in vmconnect, where it exposes a shared-memory HBITMAP handle with the VM guest framebuffer).

Treating local RDP extensions separately just because they are not usable over a network, or because they cover only special use cases, is not really helpful, it just makes adoption of such extensions harder in the end because of the lack of proper documentation. The ideal would be specifications in the same format as the other RDP protocol extensions. Don't forget you even have a whole specification dedicated to ridiculously minor features like drive letter assignment consistency across connections :)
Steve Pronovost 1 Reputation point

2021-04-22T17:20:49.567+00:00

btw, would be great if we could move the discussion to http://github.com/microsoft/wslg instead... much nicer and no 1000 char limit :-). If you could open an issue there that would be great.

1 answer

Your answer

Steve Pronovost 1 Reputation point

2021-04-22T17:08:38.057+00:00

Hey Marc-Andre,

For the GrfxRedir protocol, we are still working on the documentation. I had hope to have it ready and release ahead of WSLg going public, but unfortunately we've been running a bit behind on this. Also, we haven't decided exactly where we will publish this one. It's kind of a special one because it doesn't apply for standard RDP over a network connection and our "protocol documentation" really target communication between a server and a client system, this one is very specific to RDP being used over a VM boundaries. We thought publishing this to the normal RDP specs location could cause some confusion and have been thinking of posting this document to the WSLg project (http://github.com/microsoft/wslg) instead once ready (by early June hopefully).

[1000 char limit]
Steve Pronovost 1 Reputation point

2021-04-22T17:08:58.717+00:00

The rdpapplist isn't an "RDP protocol" per say. RDP allows an RDP client and server to define private communication over a virtual channel. This VC is really specific to WSLg and use in the start menu integration. The server side is implemented between Weston/FreeRDP and the client side is implemented in an mstsc plugin. The source code of this plugin is available as part of the WSLg project here (https://github.com/microsoft/wslg/tree/main/WSLDVCPlugin). We weren't planning on formal RDP protocol documentation for this one as we really see this as WSLg specific use of private channel (and really not useful or applicable in other context).

[1000 char limit]
Steve Pronovost 1 Reputation point

2021-04-22T17:09:04.827+00:00

This rdpapplist is something we wanted to talk with you and the FreeRDP community about. It may make sense for FreeRDP to support similar plugin model such that this code could be factor as a server side and client side plug-in on both end as opposed to be part of the core FreeRDP as it is very specific purpose. So for example we could have a FreeRDP plugin for this similar to the mstsc plugin. Thoughts?
Marc-André Moreau 86 Reputation points

2021-04-22T17:13:28.36+00:00

You are reading my mind: take the current WSL2 GUI application support, replace Hyper-V and the VMBus by QEMU and some other type of transport, use a Linux host, implement the new virtual channel extensions in the FreeRDP client, and you end up with Linux-to-Linux GUI application virtualization. It may even be doable inside a Linux container instead of a lightweight VM. There's a use case for the Windows FreeRDP client as well, it's more flexible than mstsc because it's open source and therefore you make it do whatever you like.
Marc-André Moreau 86 Reputation points

2021-04-22T17:20:30.513+00:00

RDP goes beyond just the "network" extensions, there are a few undocumented RDP extensions that only work locally because they make use of shared memory, but I never bothered to either reverse them or ask that they be documented like the rest (I refer to the framebuffer redirection extension used in vmconnect, where it exposes a shared-memory HBITMAP handle with the VM guest framebuffer).

Treating local RDP extensions separately just because they are not usable over a network, or because they cover only special use cases, is not really helpful, it just makes adoption of such extensions harder in the end because of the lack of proper documentation. The ideal would be specifications in the same format as the other RDP protocol extensions. Don't forget you even have a whole specification dedicated to ridiculously minor features like drive letter assignment consistency across connections :)
Steve Pronovost 1 Reputation point

2021-04-22T17:20:49.567+00:00

btw, would be great if we could move the discussion to http://github.com/microsoft/wslg instead... much nicer and no 1000 char limit :-). If you could open an issue there that would be great.

Answer 1

Anonymous

Hi,

The scope of Windows-remote-desktop-service includes the installation, configuration and use of RDS service.
According to my understanding, the user's question is beyond the scope of our support.

Best Regards

Share via

WSL2 GUI application support related RDP protocol extensions preview specifications

1 answer

Your answer