Microsoft Releases Ubuntu on Windows Preview

Microsoft announced the Windows Subsystem for Linux (WSL) at BUILD 2016 in San Francisco on March 30, 2016, and released the first public preview on April 6, 2016 as part of Windows 10 Insider Build 14316. The feature was developed in partnership with Canonical — Ubuntu’s creator — and debuted as “Bash on Ubuntu on Windows,” reflecting that the initial user-space environment was Ubuntu 14.04 LTS. The announcement was notable in context: Microsoft had declared “Linux is a cancer” through then-CEO Steve Ballmer in 2001, and the company’s relationship with open-source software had been defined by opposition and IP disputes through much of the 2000s. Under CEO Satya Nadella (appointed February 2014) and developer tools head Scott Guthrie, Microsoft’s position had reversed: the company had acquired developer tooling companies, open-sourced .NET Core, published Visual Studio Code, and introduced extensive Azure Linux support. WSL was the direct expression of that shift for developer tooling on the desktop. The architecture of WSL 1 was engineered by a small team within Microsoft’s kernel group: it used “pico processes” — a lightweight process model introduced in Windows 10 — combined with an NT kernel driver (lxss.sys and lxcore.sys) that intercepted Linux system calls (syscalls) made by Linux ELF binaries and translated them into equivalent NT kernel operations. This allowed unmodified Linux binaries compiled for x86-64 Ubuntu to execute within Windows without a virtual machine or kernel swap: bash, ssh, python, gcc, apt-get, grep, awk, sed, and most standard Unix command-line tools ran as native processes in the Windows process model.

WSL 1 shipped to general availability in the Windows 10 Anniversary Update (version 1607) on August 2, 2016. The syscall translation approach had inherent compatibility limits: Linux programs that used kernel features with no NT equivalent (certain ioctl codes, some /proc filesystem entries, Linux-specific socket options) either returned errors or behaved differently than on a real Linux kernel. Performance for Linux filesystem operations was impaired because the translation layer had to work through the Windows NT filesystem (NTFS), and conversely, Windows filesystem operations on Linux files went through a different path than native Windows file access. These limitations were acceptable for command-line development tools but prevented containers (which required Linux-specific kernel namespaces and cgroups) from running under WSL 1. The WSL team announced WSL 2 at Microsoft Build in May 2019: instead of syscall translation, WSL 2 ran a real Linux kernel (initially Linux 4.19, later 5.4 and subsequent versions) inside a lightweight Hyper-V virtual machine optimized for low memory overhead and fast startup. WSL 2 reached Windows Insider preview in June 2019 and general availability in Windows 10 version 2004 (May 2020).

WSL 2’s architectural change resolved the fundamental compatibility issues: full syscall compatibility meant containers, systemd (added in WSL 2 in September 2022), and complex Linux software ran without modification. Docker Desktop for Windows adopted WSL 2 as its backend, replacing the previous Hyper-V VM backend and delivering significantly better integration between Windows and Linux containers. GPU compute support arrived in WSL 2 in June 2021, enabling CUDA workloads (NVIDIA GPU compute), DirectX 12 compute (for Intel and AMD GPUs), and OpenCL execution on WSL 2 — making WSL 2 suitable for machine learning development without a dual-boot Linux installation. Windows Terminal (released May 2019, GA April 2020) provided a modern multi-tab terminal emulator with built-in WSL 2 integration alongside PowerShell and cmd.exe. By 2022, WSL 2 had become the standard Linux development environment for Windows-based developers who needed Linux tooling: the combination of VS Code’s Remote - WSL extension (connecting VS Code to a WSL 2 filesystem and process environment), WSL 2’s full kernel compatibility, and Windows Terminal’s interface made the experience nearly equivalent to native Linux development for most development workflows, while retaining access to Windows-native applications, Microsoft Office, and Windows device drivers in the same machine.