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

Microsoft Announces WSL2, Replacing Syscall Translation With a Real Kernel

At Build 2019, Microsoft revealed WSL2 — not an incremental update, but an entirely different architecture running a genuine Linux kernel inside a purpose-built lightweight virtual machine.

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.

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.

Sources: