One Windows command installs WSL, while source work needs Visual Studio 2022
For a user, the entry point is unusually small: run wsl --install in a Windows command line. WSL then provides Linux command-line tools, utilities, and applications alongside Windows programs without a dual boot. The value is the boundary crossing. A developer can keep Windows editors and desktop software while using a Linux shell, package manager, compiler, or local service on the same machine.
Building the repository is a different product experience. Microsoft's developer guide requires CMake 3.25 or newer, Visual Studio 2022 with the repository's selected workloads, and Developer Mode or administrator privileges for symbolic links. A PowerShell setup script uses WinGet Configuration to install prerequisites. CMake generates wsl.sln, and the output becomes an MSI or is deployed through another PowerShell script.
WSL integrates Linux with Windows instead of creating a neutral VM workflow
WSL is designed for a Windows host. Its convenience comes from sharing the daily machine, Windows filesystem access, command interoperability, networking behavior, and Microsoft-managed updates. Developers who want a disposable machine with an explicit hardware boundary may prefer Multipass or Vagrant. Teams standardizing one environment definition across Windows, macOS, and Linux also need another layer, because WSL itself is not available on the other 2 host families.
The repository covers both WSL 1 and WSL 2 development paths, and its test runner accepts a version switch. The surrounding system is split by responsibility: the WSL2 Linux kernel is in microsoft/WSL2-Linux-Kernel, Linux GUI support is in microsoft/wslg, and user-facing documentation is in microsoftdocs/wsl. That division is reasonable at Microsoft scale, but one checkout does not contain every component that affects a user's result.
What happened when we ran it
Our fresh Debian container cloned commit 4bfbaca and selected the Python project under ./distributions/. Installation succeeded in 49 seconds, adding 50 packages and using 62 MB. Its build check passed in 6 seconds. The whole checkout contained 1,466 files, about 323,982 source lines, and 35.1 MB, with 7 CI workflow files, no Dockerfile, and a tests directory.
The test step failed with exit code 5 after 11 seconds because pytest found no tests in that selected subproject. The complete log tail was no tests ran in 0.00s; it reported 0 passed and 0 failed out of 0. Pip-audit found 1 known vulnerability in the installed Python environment. This is a failed harness step and a coverage gap, not evidence that a WSL runtime test failed.
Microsoft's actual WSL test route is Windows-specific. After a Windows build, developers run bin\<platform>\<target>\test.bat, optionally select WSL 1, or filter to unit tests and individual cases. Our Linux sandbox did not generate the Visual Studio solution, build the WSL binaries, install an MSI, create a test distribution, or execute that batch runner. Any review that turned 0 collected Python tests into a judgment on the full runtime would be misleading.
The distributions folder validates images rather than the WSL runtime
The measured Python subproject is still real work. Its scripts validate distribution manifests and downloaded .wsl images, check SHA-256 values and archive formats, inspect ELF architecture, examine configuration keys, verify file ownership and permissions, and warn about systemd units discouraged under WSL. The requirements file pins 5 direct Python packages, while our resolved environment contained 50 packages.
Those checks explain why the generic harness selected the folder, but they also explain the empty pytest result. The directory contains validator scripts and DistributionInfo.json, not a Python test suite. A better cross-platform check for this repository would invoke the validator with a real manifest or archive. A full product check still requires Windows because WSL's C++, packaging, host services, and integration tests depend on that platform.
Windows diagnostics control WSL telemetry
The privacy document says WSL collects usage, stability, and performance diagnostics through Windows telemetry. Users can disable diagnostic data in Windows Settings under Privacy and Security, and the same page offers a way to view submitted diagnostic data. The source identifies telemetry calls through WSL_LOG_TELEMETRY. This is more specific than a vague privacy promise, though the practical control remains a Windows policy rather than a WSL-only switch.
Contributors also need to handle logs carefully. The guide routes security issues and blue-screen crashes to the Microsoft Researcher Portal instead of public GitHub issues. Networking reports may include packet captures, WSLg data, or crash dumps produced by the diagnostic script. That is appropriate for debugging a host integration layer, but organizations should review captured material before attaching it to a public issue or sending it outside the company.
Version 2.7.12 is stable while 2.9.9 remains a preview
GitHub showed 33,581 stars, 1,810 forks, and 989 combined issues and pull requests. The code was pushed on August 31, 2026. The latest stable release was 2.7.12 from August 18, while 2.9.9 was published as a prerelease on August 25. Current issue activity covers filesystems, networking, GPU behavior, sleep and resume, and new command work, which fits the breadth of a Windows and Linux boundary layer.
Issue 8696, opened in 2022 and updated on August 31, had 519 comments about WSL becoming unresponsive after hibernation. One crowded issue does not describe every laptop, and the combined 989 count includes pull requests. It does show why a mature, heavily used system still needs workload-specific testing. WSL is the practical default for Linux development on Windows, but stable release status cannot guarantee every Windows build, driver, network mode, filesystem path, and sleep cycle.