WSL: a second environment subsystem
How Windows runs real Linux binaries — the modern answer to the old POSIX subsystem box in the architecture diagram.
What you should already know
This topic is marked expert. Skim these first if any of them feel unfamiliar.
Guided paths in this branch
Follow a short sequence step by step. Each path links to the first topic; use Read next on each page to continue.
Loader & runtime
PE images, DLL loading, and WOW64 on 64-bit Windows.
Why it matters
Classic Windows architecture diagrams show Win32, POSIX, and OS/2 as alternative 'environment subsystems' on top of the same Executive. POSIX and OS/2 are long gone, but WSL is a genuine, actively developed modern successor to that same idea, and it works in two very different ways depending on the version.
Mental model
WSL1 tried to be a real environment subsystem: translate Linux system calls onto NT primitives, the same spirit as the old POSIX subsystem. WSL2 gave up on translation and instead runs a real Linux kernel in a lightweight Hyper-V partition, integrated tightly enough that it barely feels like a VM.
How it works
- 1WSL1 uses 'pico processes' — lightweight NT processes with almost no Windows-specific structure attached — plus a kernel driver (lxss/lxcore) that intercepts Linux system calls and translates them onto real NT kernel operations.
- 2WSL2 instead boots a real, Microsoft-maintained Linux kernel inside a lightweight Hyper-V child partition, using the same root/child partition model and VMBus-based integration covered in the Virtualization level, with 9P and a dedicated network stack bridging the two sides.
- 3Both versions present a single, unified filesystem view and process interop (you can call a Windows .exe from a Linux shell and vice versa), which is implemented differently underneath depending on which version you're running.
Key terms
- Pico process
- A minimal NT process with almost none of the usual Windows subsystem structure, used by WSL1 to host a translated Linux process.
- lxss / lxcore
- The WSL1 kernel driver that translates Linux system calls into NT kernel operations.
- 9P
- The network file-system protocol WSL2 uses to share files between the Windows host and the Linux guest.
Why WSL1 and WSL2 behave differently under the same commands
A syscall-heavy workload (lots of small file operations) can behave very differently between WSL1 (every call translated onto NT primitives, some of which don't have a clean equivalent) and WSL2 (a real Linux kernel handling the same call natively, at the cost of crossing a VM boundary for host interop).
Common misconception
Treating 'WSL' as one thing hides a real architectural difference. WSL1 is genuinely a translation-based environment subsystem, in the same spirit as the classic POSIX subsystem; WSL2 is a virtualization story, not a translation one, and belongs as much to the Hyper-V chapter as to this one.
You should read next
Ranked from your current topic, related links, branch depth, and any active guided path.
intermediate
DLL loader, PEB, and module lists
How Windows loads shared libraries and tracks runtime module state.
Related topic
intermediate
Ntdll & the user/kernel boundary
How user-mode code reaches native system services through ntdll and syscalls.
Related topic
intermediate
Hyper-V & partitions
Root vs child partitions, vCPUs, and synthetic devices.
Related topic