Microsoft Announces WSL2, Replacing Syscall Translation With a Real Kernel

At Microsoft’s Build developer conference on May 6, 2019, Microsoft announced WSL2 — not an incremental improvement to the existing Windows Subsystem for Linux, but a fundamentally different underlying architecture.

What actually changed architecturally

Where the original WSL (retroactively named WSL1) worked by translating Linux system calls into equivalent Windows kernel operations, WSL2 instead runs an actual, Microsoft-maintained Linux kernel inside a lightweight, purpose-built virtual machine — a genuine architecture change, not a performance tuning update to the existing approach.

Why Microsoft made this specific tradeoff

WSL1’s translation-layer approach meant anything relying on Linux kernel features the translation didn’t implement — certain filesystem behaviors, networking primitives, actual kernel modules — simply didn’t work. Running a real kernel under WSL2 closed this compatibility gap essentially completely, at the cost of introducing genuine VM-level concerns (memory allocation, virtualized networking, disk virtualization) that WSL1 never needed to address.

The rollout timeline from announcement to general availability

Following the May 2019 Build announcement, WSL2 first reached users through the Windows Insider program before becoming broadly available with a subsequent Windows 10 feature update — a staged rollout consistent with how Microsoft handled other significant WSL capability additions in the years afterward, giving time for the new virtualization-based architecture to be tested against a wide range of real-world hardware and software configurations before reaching the full Windows user base.

What users actually had to do about it

WSL2 launched as an option alongside WSL1 rather than an automatic, forced replacement — existing WSL1 distros could be explicitly converted to WSL2, or new distros installed directly as WSL2, giving users control over the migration rather than an unannounced architecture change under existing setups.

The broader significance of this announcement

This single architectural decision is what later made GPU compute support, WSLg’s GUI application support, and systemd support possible — none of which could have been built on top of WSL1’s syscall-translation model, since they all depend on kernel-level capabilities only a real Linux kernel provides.

The specific kernel version and the performance case Microsoft made

The initial WSL2 builds shipped Linux kernel version 4.19, built and maintained in-house by Microsoft specifically tuned for size and performance within the WSL2 environment, rather than an unmodified upstream kernel build. Alongside the architectural announcement, Microsoft’s own devblogs post cited concrete performance figures making the practical case for the change: unpacking a zipped tarball ran up to roughly 20 times faster under WSL2 than WSL1, while common development operations like git clone, npm install, and cmake ran roughly 2 to 5 times faster — figures aimed specifically at developers who might otherwise have viewed the migration as purely an internal architecture change with no visible day-to-day benefit.

Why the “first Linux kernel shipped with Windows” framing mattered

Beyond the specific technical architecture, commentators at the time repeatedly emphasized a symbolically significant detail: this marked the first time an actual Linux kernel would ship as part of Windows itself, serviced through Windows’s own update mechanism, rather than being installed separately by the user from an external source. Coming from a company whose historical relationship with Linux and open source had been considerably more adversarial in earlier decades, this framing carried real weight in how the announcement was received across the developer and open-source community, beyond its purely technical merits.

Related:

Sources: