The History of WSL: From a Cancelled Android Project to a Real Linux Kernel

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” announced alongside a separate iOS-compatibility bridge (“Project Islandwood”) at Build 2015, intended to let Android applications run on Windows 10 Mobile with minimal changes. Microsoft officially cancelled Astoria on February 25, 2016, stating directly that maintaining two separate mobile-compatibility bridge technologies was unnecessary and confusing for developers, and that it would focus exclusively on the iOS bridge going forward — pointing affected developers toward that bridge and toward Xamarin (a cross-platform tooling company Microsoft had announced plans to acquire that same week) as alternatives. 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 Windows 10 Insider Preview Build 14316, released in April 2016 — the build that first let Windows users run a genuine Ubuntu userspace, including tools like ssh, apt, python, and vim, directly from a native Bash shell. Enabling it originally required turning on Developer Mode and separately enabling the “Windows Subsystem for Linux (Beta)” optional feature, reflecting its very early, experimental status at the time. This original architecture — now retroactively called WSL1 — worked by translating Linux system calls into equivalent Windows NT kernel operations, without running any actual Linux kernel at all. It shipped broadly, out of beta, with that year’s Anniversary Update.

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.

Why WSL1 hit a real, structural ceiling

WSL1’s syscall-translation approach was a genuinely clever piece of engineering for its time, but it had a fundamental limitation baked into its design: any Linux system call, kernel module, or /proc//sys behavior the translation layer hadn’t specifically implemented simply didn’t work, full stop. This wasn’t a matter of gradually filling in missing pieces over time — some categories of software (anything depending on genuine kernel-level behavior the translation layer couldn’t feasibly emulate) were architecturally out of reach for WSL1 regardless of how much additional translation coverage Microsoft added. This ceiling is the direct, specific reason Microsoft undertook the more radical WSL2 rewrite rather than continuing to incrementally improve WSL1’s translation coverage.

Why the timing of each addition tells its own story

The gap between WSL2’s 2019 architectural announcement and features like GPU compute (2020) and WSLg (2021) reflects the reality that a genuine Linux kernel running in a lightweight VM was a necessary foundation those later features depended on, not something that could have been retrofitted onto WSL1’s syscall-translation model at all. GPU-PV’s kernel-level device proxying and WSLg’s Wayland compositor both assume the presence of an actual Linux kernel capable of loading the appropriate drivers and running genuine kernel-space code — capabilities WSL1 never had and couldn’t have gained without becoming, in effect, WSL2.

The pace of change since 1.0

Reaching version 1.0 as a standalone Store application in November 2022 didn’t mark the end of WSL’s active development — mirrored networking, DNS tunneling, Dev Drive integration, and continued kernel updates all followed afterward, delivered through the same decoupled Store update mechanism that made this faster cadence possible in the first place. The 1.0 milestone is better understood as WSL’s graduation to an independently-versioned platform than as a finish line, consistent with how quickly its feature set has continued to expand in the years since.

Related:

Sources: