The History of WSL: From a Cancelled Android Project to a Real Linux Kernel
Before WSL let Windows run real Linux binaries, Microsoft tried and abandoned a different compatibility project entirely. Here's the actual path from that cancellation to today's tightly-integrated WSL2.
The Windows Subsystem for Linux exists today as a genuinely well-integrated way to run real Linux tooling on Windows — but the path there wasn’t a straight line, and it started with a different, ultimately abandoned project entirely.
The abandoned precursor: Project Astoria
Before WSL, Microsoft was pursuing Project Astoria, a “Windows Bridge for Android” that would let Android applications run on Windows 10 Mobile with minimal changes — announced at Build 2015, but officially cancelled in February 2016 in favor of consolidating around a separate iOS-compatibility bridge project instead. Astoria’s cancellation cleared organizational and technical space for what came next.
WSL1: syscall translation, announced in 2016
Windows Subsystem for Linux was first revealed via a Windows 10 Insider Preview build in April 2016, shipping broadly with that year’s Anniversary Update. This original architecture — now called WSL1 — worked by translating Linux system calls into equivalent Windows NT kernel operations, without running any actual Linux kernel.
WSL1 reaches full support
By the Fall Creators Update in October 2017, WSL had exited beta status entirely, gaining support for installing multiple distros via the Microsoft Store and becoming a fully Microsoft-supported OS feature rather than an experimental preview capability.
The architectural leap: WSL2
At Build 2019, Microsoft announced WSL2 — a fundamentally different architecture running an actual, Microsoft-maintained Linux kernel inside a lightweight, purpose-built virtual machine, rather than translating syscalls. This traded WSL1’s occasionally imperfect compatibility (anything the translation layer didn’t implement simply didn’t work) for full Linux kernel compatibility, at the cost of introducing genuine virtualization concerns — memory management, networking modes, and disk virtualization — that WSL1 never had to deal with.
Extending WSL2 beyond just a terminal
Once the real-kernel foundation existed, Microsoft built substantially on top of it: GPU compute support arrived in 2020, WSLg brought Linux GUI applications to the Windows desktop starting in 2021, and systemd support, added in September 2022, closed a long-standing compatibility gap for software expecting a standard Linux init system.
Becoming a standalone, independently-updated platform
In November 2022, WSL reached version 1.0 as a standalone Microsoft Store application, decoupling its update cycle from Windows’s own release schedule entirely — meaning WSL improvements could ship on their own pace going forward, rather than waiting for the next major Windows feature update.
Why this history matters for understanding WSL today
Each major WSL capability covered elsewhere on this blog — the dedicated kernel Microsoft maintains, GPU compute, GUI app support, systemd — was added incrementally onto the WSL2 architectural foundation established in 2019, itself only possible because of the deliberate move away from WSL1’s syscall-translation design. Understanding this sequence explains why certain capabilities (real kernel modules, full networking, GPU access) simply didn’t exist under WSL1 at all, regardless of how mature that earlier architecture eventually became.