Skip to content
daniel@cosenza:~/blog
WSLNews August 9, 2026 2 min read

WSLg Ships, Letting Linux GUI Apps Run Directly on the Windows Desktop

Announced at Build 2020 and released to Windows Insiders the following spring, WSLg let a Linux graphical application's window appear on the Windows desktop like any native app — no separate remote desktop session required.

Announced at Build 2020 alongside WSL2’s new GPU compute capabilities, WSLg (Windows Subsystem for Linux GUI) reached Windows Insiders as its first public preview via Windows 10 Insider Preview Build 21364, released April 21, 2021, and was more broadly showcased at Microsoft’s Build 2021 conference.

What WSLg actually let people do

Before WSLg, running a Linux GUI application inside WSL required a separately configured X server on the Windows side and manual environment configuration — an extra setup step most casual users never bothered with. WSLg removed that barrier entirely: a Linux GUI application, once launched from a WSL terminal, simply appeared as its own window on the Windows desktop.

What was actually running to make this possible

WSLg bundled a complete Wayland compositor, an X server for compatibility with non-Wayland-native applications, and a PulseAudio server, all running inside the Linux environment and tunneling rendered output to Windows over an RDP-based transport — substantial infrastructure made to feel invisible to the end user.

Why this was more than a convenience feature

Prior to WSLg, developers wanting to use Linux-native GUI development tools, or run Linux graphical applications for testing, generally needed a separate virtual machine or dual-boot setup entirely. WSLg meaningfully expanded what “just use WSL” could cover, beyond command-line and server-style workloads into full graphical application use.

How this built directly on WSL2’s architecture

WSLg’s compositor and audio server run as genuine processes inside the WSL2 Linux kernel environment — another capability, like GPU compute, that depended entirely on WSL2’s real-kernel architecture rather than being something WSL1’s syscall translation layer could have supported.

Sources: