While WSLg works with or without virtual GPU support, if you intend to run graphics intensive applications such as Blender or Gazebo, it is best to be running on a system with a GPU and driver that can support WSL. To share memory between the Linux guest and Windows host we use virtio-fs. We decided to keep that support in as it could reuse in other interesting scenarios outside of WSLg, for example for remoting application from a Pi running Linux. While building WSLg, we first implemented RAIL while the necessary pieces enabling the switch to VAIL were being developed in parallel. We've added support for both RAIL and VAIL to the libweston RDP backend, although for WSLg only the VAIL support is effectively used. In VAIL, it is understood that the Server and Client are on the same physical system and can share memory across the Guest/Host VM boundary. In RAIL, it is assumed that the Server and Client are running on different physical systems communicating over the network and thus pixels need to be copied over the RDP transport.

The main difference between RAIL and VAIL is how pixels are transported across from the RDP server to the RDP client. The application integration is achieved through an RDP technology called RAIL (Remote Application Integrated Locally) and VAIL (Virtualized Application Integrated Locally). We've also added various functionality to it, such as support for multi-monitor, cut/paste, audio in/out, etc. For WSLg, we've extended the existing RDP backend of libweston to teach it how to remote applications rather than monitor/desktop. Weston is the Wayland project reference compositor and the heart of WSLg. Most users who just want to use GUI applications in WSL don't need to worry about those details. Although we expect very few folks to actually need or want to do that, we've shared detailed instruction on our contributing page on how to both build and deploy a private version of the system distro. We use a read-only mapping such that the user gets a well known discard behavior on any changes, every time WSL is restarted, instead of getting a surprise when WSL is serviced.Īlthough the Microsoft published WSLg system distro as read-only, we do want to encourage folks to tinker with it and experiment. The reason we do this is to enable a servicing model for the system distro where we replace the old one with the new one without having to worry about migrating any user data contained within. Any modifications, made to the in-memory instance of the system distro (such as installing new packages or creating a new file), are effectively discarded when WSL is restarted. Every instance of the system distro is loaded read-only from its backing VHD. While a user can get a terminal into the system distro, the system distro is not meant to be used directly by users. The system distro runs partially isolated from the user distro to which it is paired, in its own NS/PID/UTS namespace but shares other namespaces such as IPC, to allow for shared memory optimization across the boundary.

For details on how to build and deploy a private system distro please see our build instructions.Įvery WSL 2 user distro is paired with its own instance of the system distro. This is a minimal Linux environment, just enough to run the various pieces of WSLg. The system distro is based on the Microsoft CBL-Mariner Linux. You can also launch these from your terminal window using the commands: Once these applications are installed, you'll find them in your start menu under the distro name. Sudo curl https: // /repos /edge /pool /main /m /microsoft -edge -dev /microsoft -edge -dev_118. Sudo dpkg -i google -chrome -stable_current_b Sudo wget https: // dl. /linux /direct /google -chrome -stable_current_b From integration into the Start Menu for launch to appearing in the task bar, alt-tab experience to enabling cut/paste across Windows and Linux applications, WSLg enables a seamless desktop experience and workflow leveraging Windows and Linux applications. WSLg strives to make Linux GUI applications feel native and natural to use on Windows. While users can accomplish this today using a multiple system setup, with individual PC dedicated to Windows and Linux, virtual machine hosting either Windows or Linux, or an XServer running on Windows and projected into WSL, WSLg provides a more integrated, user friendly and productive alternative. WSLg provides an integrated experience for developers, scientists or enthusiasts that prefer or need to run Windows on their PC but also need the ability to run tools or applications which works best, or exclusively, in a Linux environment. WSLg is short for Windows Subsystem for Linux GUI and the purpose of the project is to enable support for running Linux GUI applications (X11 and Wayland) on Windows in a fully integrated desktop experience.

Witgui windows