skip to content

WSL1 and WSL2 are both called "Windows Subsystem for Linux", but they are architecturally different. Explain how each one actually runs Linux code on Windows, and what that difference changes in practice.

level: middleimportance: must knowfreq 80%

answer

  1. one name, two mechanisms
  2. translation layer versus real kernel
  3. pico processes, no Linux kernel
  4. VM boundary shows up in the filesystem
  5. file speed flips direction between them

basics

~20 s

WSL1 has no Linux kernel: an NT kernel driver translates Linux system calls, and Linux binaries run as pico processes. WSL2 boots a real Microsoft-built Linux kernel in a lightweight Hyper-V virtual machine, giving full syscall fidelity.

solid answer

~50 s

They share a name and a command line and almost nothing else. WSL1 contains no Linux kernel at all: an NT kernel driver implements Linux system calls, and each Linux binary runs as a *pico process* whose syscalls are routed into that driver. WSL2 instead boots a genuine Microsoft-built Linux kernel inside a lightweight Hyper-V utility VM, so syscalls are serviced by real kernel code. That buys full compatibility — FUSE, loadable kernel modules, the Docker daemon, working `iptables`/`nftables`, a complete `/proc` — which is why WSL2 is the default. The costs are VM-shaped: a boot, a memory footprint, NAT'd networking instead of sharing the host's stack, and slow access to Windows files, because `/mnt/c` now crosses the VM boundary over a 9P file-server protocol instead of touching NTFS directly. I pick WSL2 for nearly everything and keep WSL1 only where the workload is dominated by Windows-drive file access.

code

powershell · 3 lines
powershell
wsl --list --verbose
wsl --set-version Ubuntu 2
wsl --set-default-version 2

go deeper

for a junior

Know that WSL lets you run a Linux distribution on Windows, that version 2 is the default, and that version 2 uses a real Linux kernel while version 1 did not. Be able to say which version a distribution is on.

for a middle

Be ready to explain the two mechanisms: syscall translation with pico processes versus a real kernel in a Hyper-V utility VM, and to name capabilities that only the real kernel provides, such as kernel modules, FUSE and container engines.

for a senior

Show that you know the trade-off is not one-directional: WSL2 wins on Linux-native I/O and compatibility, WSL1 can win on Windows-drive file access, and WSL2 brings a VM's memory, boot and NAT networking costs. Recommend per-workload.

for a principal

Own the fleet decision: whether developer machines standardize on WSL2, a full Linux VM, or remote Linux hosts, given virtualization policy, disk growth of VHDX images, memory pressure on laptops, and how closely the dev environment must match production.

## Two implementations behind one name Windows Subsystem for Linux shipped twice. The name, the `wsl.exe` command line and the distribution packages stayed the same, but the mechanism underneath was replaced wholesale. Each installed distribution independently runs as version 1 or version 2, and you can convert it either way with `wsl --set-version <distro> 1|2`; `wsl --list --verbose` prints which version each one is on. ## WSL1: system-call translation inside the NT kernel WSL1 runs Linux ELF binaries with no Linux kernel anywhere in the picture. Windows loads kernel-mode drivers (`lxss.sys` / `lxcore.sys`) that implement the Linux system-call interface on top of NT executive services. A Linux program is launched as a **pico process** — a minimal process with an empty user-mode address space and no NT libraries mapped into it, whose system calls and exceptions are routed to a registered *pico provider* rather than to `ntdll.dll` and the Win32 subsystem. The provider is the WSL driver, so `open`, `fork`, `mmap` and friends are re-expressed as NT I/O manager and memory manager operations. The consequence is fidelity limited by translation. Anything that has not been implemented, or cannot be expressed on NT semantics, simply is not there: you cannot load a Linux kernel module, FUSE filesystems are unavailable, and the parts of `/proc` and `/sys` that exist are synthesized. Historically that is why the Docker daemon could not run under WSL1 — it needs real cgroups, namespaces and netfilter. On the filesystem side, WSL1's Linux root lives as ordinary files inside a Windows package directory, with Linux metadata emulated on top of NTFS, while `/mnt/c` is a direct in-process view of NTFS through the same driver. ## WSL2: a real kernel in a utility VM WSL2 starts a lightweight Hyper-V *utility VM* and boots a Microsoft-built Linux kernel inside it. The kernel is a normal open-source Linux kernel with a Microsoft configuration, delivered and updated through Windows rather than through the distribution. Because it is real kernel code, syscall coverage is whatever upstream Linux supports — no translation layer to fall behind. The distribution's root filesystem is a real **ext4 filesystem inside a VHDX virtual disk**, attached to the VM as a block device. Windows drives are no longer local: `/mnt/c` is served by a Plan 9 (9P) file server running on the Windows side and mounted by a 9P client in the VM, with the traffic crossing the VM boundary. In the other direction, Windows reaches Linux files through `\\wsl$\<distro>` (spelled `\\wsl.localhost\<distro>` on current versions), which is the same 9P server viewed from Explorer. The VM is managed for you: it starts on first use, shuts down when idle, and shares one kernel across all WSL2 distributions. `.wslconfig` in your Windows user profile tunes it — `memory=`, `processors=`, `swap=`, `networkingMode=`. ```ini [wsl2] memory=8GB processors=4 ``` ## What the swap actually changed **Gains:** full kernel compatibility (modules, FUSE, cgroups, netfilter, a genuine `/proc`), much faster Linux-native filesystem I/O on ext4, and the ability to run container engines natively. **Costs:** a virtual machine's boot time and memory footprint; a hardware-virtualization requirement (which some nested-virtualization or locked-down corporate environments do not grant); NAT'd networking with its own IP instead of sharing the Windows network stack; and slow access to Windows files, because every metadata operation under `/mnt/c` becomes a round trip across the VM boundary. That last point is the practical inversion candidates miss: **WSL1 is often faster than WSL2 at reading and writing Windows-drive files**, because it touches NTFS in-process, while WSL2 is dramatically faster inside its own ext4 root. ## Choosing between them WSL2 is the default and the right default. Choose WSL1 deliberately, per distribution, when the workload lives on the Windows drive and is metadata-heavy, or when virtualization is unavailable to you. If you go WSL2, the corresponding discipline is to keep the working files on the Linux side of the boundary. ## What the interviewer is checking That you can say "translation layer" versus "real kernel in a VM" without hand-waving, that you can name at least one capability that only exists because a real kernel is there, and that you understand the filesystem-performance trade-off runs in *opposite directions* for the two versions rather than WSL2 simply being faster.

  • Give a concrete capability that works under WSL2 but cannot work under WSL1, and say why.
    Running the Docker daemon inside the distribution. It needs real cgroups, namespaces and netfilter, plus loadable kernel modules — all of which exist only because WSL2 boots an actual Linux kernel. WSL1's translation layer synthesizes parts of `/proc` and `/sys` but cannot provide kernel subsystems it does not implement, and it cannot load modules at all.
  • If WSL2 is strictly newer, why would anyone deliberately keep a distribution on WSL1?
    Two reasons. First, workloads dominated by Windows-drive file access: WSL1 touches NTFS in-process, while WSL2 crosses the VM boundary over 9P for every operation. Second, environments where hardware virtualization is unavailable or blocked, since WSL2 requires the Hyper-V platform. Otherwise WSL2 is the better default.
  • Where does a WSL2 distribution's root filesystem physically live, and what does that imply operationally?
    In an ext4 filesystem inside a VHDX virtual disk on the Windows drive. Operationally it means the disk file grows dynamically as you write and does not shrink on its own when you delete files, so a distribution can occupy far more space than `df` reports inside Linux until the virtual disk is compacted or the distribution is exported and reimported.

WSL1 is an interpreter standing next to a Windows official, rephrasing every Linux request into Windows terms; WSL2 flies in an actual Linux official and puts them in a small office down the hall — perfect answers, but now everything has to go through the corridor.

saying these in an interview costs you the question

  • Calling WSL1 a virtual machine or an emulator
  • Believing WSL2 is faster than WSL1 at everything
  • Thinking WSL2 uses the same network stack as Windows
  • Saying WSL runs an emulated x86 CPU
  • Assuming both versions can load Linux kernel modules

context

resolving links…