What is WSL?

What is WSL?

WSL stands for Windows Subsystem for Linux. It is a feature built into Windows 10 and Windows 11 that lets you run a complete Linux environment - the shell, the package manager, the file system, command-line tools - right alongside your normal Windows desktop. You do not reboot into it and you do not set up a separate machine. You open a terminal, and you are in Linux.

For a developer, that means the GNU/Linux tools most servers actually run - bash, apt, grep, ssh, git, Python, Node.js, Docker - behave exactly the way they do in production, on a laptop that is otherwise running Windows. It is Microsoft's answer to a question developers asked for years: can I have Linux without leaving Windows?

A genuine Linux kernel, running on Windows, a terminal command away.- the short version

The problem it solves

Most of the world's servers run Linux. The tooling, the shell scripts, the deployment guides, the open-source ecosystem - all of it assumes a Linux environment. But a large share of developers work on Windows machines. That mismatch used to leave you with three awkward options.

• Dual boot. Install Linux beside Windows and restart your computer to switch. Powerful, but you cannot use Windows and Linux at the same time, and rebooting to check one command is painful.
• A full virtual machine. Run Linux inside software like VirtualBox or VMware. It works, but it is heavy - you allocate fixed memory and disk up front, boot a whole second operating system, and pay a real performance tax.
• Approximate it. Use Git Bash, Cygwin, or similar tools that emulate Linux commands. Fine for basics, but it is not real Linux, and things break in subtle ways the moment you stray from the common path.

WSL removes the trade-off. You get an actual Linux environment that starts in a second, shares your machine's resources dynamically, and sits right next to your Windows files and apps. No reboot, no pre-allocated VM to babysit.

WSL 1 and WSL 2

There are two generations of WSL, and the difference matters because they work in fundamentally different ways.

WSL 1 was a translation layer. It took the system calls that Linux programs make and translated them, on the fly, into the equivalent Windows system calls. There was no Linux kernel involved at all - Windows pretended to be Linux. This was clever and made Windows file access fast, but the imitation was never perfect, and software that needed real Linux kernel features simply did not run.

WSL 2 took a different path: it ships a real, complete Linux kernel running inside a lightweight virtual machine. Because it is genuine Linux underneath, compatibility is essentially complete - if it runs on Linux, it runs here. WSL 2 is the default today and the right choice for almost everyone. The main reason anyone still reaches for WSL 1 is a narrow one: working with files that live on the Windows side, where WSL 1's direct access can be faster.

How WSL 2 works

The phrase "lightweight virtual machine" is doing a lot of work, so it is worth unpacking. A traditional VM is something you feel: you assign it 8 GB of memory and 60 GB of disk in advance, you boot it, and it runs as a visibly separate computer. WSL 2 hides almost all of that.

Under the hood, Windows runs the Linux kernel inside a stripped-down, highly optimized VM built on the same virtualization technology (Hyper-V) that powers Windows' own features. But the experience is designed to feel native:

• It starts instantly. The Linux environment boots in a second or two the first time you open a terminal, then stays warm.
• Memory is shared, not reserved. WSL 2 grows and shrinks its memory use as your Linux programs need it, instead of locking a fixed amount away from Windows.
• The kernel is maintained by Microsoft. It is a real Linux kernel, shipped and updated through Windows Update, so you are not compiling or patching it yourself.

The result is a VM you almost never think about. It feels less like running a second computer and more like Linux is just one of the things your terminal can be.

Getting started

On a current version of Windows, installing WSL is a single command. Open PowerShell or the Command Prompt as Administrator and run:

That one command turns on the required Windows features, downloads a Linux kernel, and installs Ubuntu as the default distribution. After a reboot, Ubuntu asks you to pick a username and password the first time it launches - this is your Linux account, separate from your Windows login - and you land at a normal bash prompt.

You are not limited to Ubuntu. WSL supports many distributions - Debian, Fedora, openSUSE, Kali, and others - and you can install several side by side, each fully isolated. To enter one later, just run wsl for your default, or wsl -d Debian to choose a specific one.

Living in two file systems

The thing that confuses most newcomers is that you now have two file systems, and where your files live affects how fast everything runs.

Your Linux distribution has its own file system, with the familiar /home/you layout. From inside Linux you can also reach your Windows drives - they are mounted under /mnt, so your Windows C: drive appears at /mnt/c. Going the other way, your Linux files are reachable from Windows through a special network path that File Explorer understands: \\wsl$\Ubuntu (newer builds use \\wsl.localhost\Ubuntu).

One rule saves a lot of grief: keep your project files on the Linux side (under ~), not on the Windows side (under /mnt/c). Crossing between the two file systems is slow, and tools that touch thousands of files - npm install, git status on a big repo - can crawl if the code lives on /mnt/c. Put the project in your Linux home and the same commands fly.

Windows and Linux interop

WSL is not a sealed box - the two worlds are wired together on purpose. You can call Windows programs from the Linux shell, and Linux programs from Windows, and pipe data between them.

• Run Windows apps from Linux. Append .exe and a Windows program launches: notepad.exe notes.txt opens Notepad, code . opens the current folder in Windows VS Code, explorer.exe . opens File Explorer.
• Pipe across the boundary. Output from a Linux command can flow straight into a Windows one: cat log.txt | clip.exe copies a Linux file's contents onto the Windows clipboard.
• Editors connect in. Tools like Visual Studio Code have a WSL mode: the editor runs as a normal Windows app while the code, terminal, and extensions all run inside Linux. You edit in a familiar window, but everything executes in the Linux environment.

This interop is the quiet reason WSL feels so comfortable. You are not choosing Windows or Linux for a given task - you reach for whichever one is better and let them hand work back and forth.

Where WSL fits and where it doesn't

WSL is the right tool for a wide range of everyday development, but it is not a universal answer. Knowing the edges keeps you from fighting it.

Reach for WSL when you are doing command-line development, building or testing software that will ship to a Linux server, running Linux-first tooling, or following a tutorial written for Linux or macOS. For web back-ends, scripting, containers, and most server-side work, it is excellent - and pairing it with Docker Desktop gives you native-speed Linux containers without a separate VM.

Look elsewhere when you need full graphical Linux desktop environments (WSL can run Linux GUI apps, but it is not built to be your daily desktop), when you need hardware-level access or specialized device drivers, or when a workload demands the absolute last few percent of performance that only bare-metal Linux or a tuned full VM delivers. Those are real cases - they are just not the common ones.

Why developers use it

The appeal is that WSL ends a compromise developers lived with for a long time. You keep Windows for the things Windows is good at - the desktop apps, the hardware support, the corporate environment your laptop already lives in - and you get a real Linux environment for the things Linux is good at, without switching machines or rebooting.

It has also reshaped what a Windows dev setup looks like. A modern workflow is often Windows on the outside, an editor like VS Code in Windows talking to a project that lives in Linux, a Linux shell for every command, and Linux containers running through WSL underneath. The boundary between the two operating systems fades into the background, which is exactly the point.

If you work on Windows and have ever felt the friction of tooling that quietly assumed Linux, WSL is the thing that makes the friction disappear. It is built in, it installs in one command, and once it is there you mostly stop thinking about it - which is the highest compliment you can pay a piece of infrastructure.