> For the complete documentation index, see [llms.txt](https://kmanu225.gitbook.io/cs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kmanu225.gitbook.io/cs/software-engineering/unix-linux-on-windows-choosing-the-right-environment/wsl-a-real-linux-environment-inside-windows.md).

# WSL: A Real Linux Environment Inside Windows

With [Cygwin](/cs/software-engineering/unix-linux-on-windows-choosing-the-right-environment/cygwin-posix-compatibility-on-windows.md), you rebuild POSIX software so it can run on Windows. **WSL (Windows Subsystem for Linux) takes a different approach: it runs a real Linux environment alongside Windows.** WSL uses a real Linux kernel inside a lightweight, managed virtual machine, while keeping tight integration with Windows.

### When should you use WSL?

WSL is a strong choice when:

> You develop on Windows, but your application or toolchain is really meant for Linux.

Typical examples include:

* building software that will run on Linux servers;
* using `apt`, GCC, Bash, Python, Node.js, or other Linux tools;
* running Linux build scripts unchanged;
* testing software in Ubuntu or another Linux distribution;
* working with Linux containers;
* using Linux-specific libraries or system calls.

For example:

```bash
sudo apt install build-essential cmake
git clone https://example.com/project.git
cd project
cmake -S . -B build
cmake --build build
```

These commands run inside Linux, not through a POSIX compatibility layer.

### What makes WSL different?

The important distinction is:

```
Cygwin
    -> Windows kernel
    -> POSIX compatibility layer
    -> rebuild application for Cygwin

WSL
    -> real Linux kernel
    -> Linux userspace
    -> run normal Linux applications
```

With WSL, you can use a normal Linux distribution, package manager, libraries, and development tools.

At the same time, Windows and Linux remain closely integrated: Windows files are accessible from Linux, and Windows applications can be launched from a WSL shell.

### Keep Linux projects in Linux

If Linux tools are doing most of the work, keep the project inside the Linux filesystem:

```
~/projects/myapp
```

rather than:

```
/mnt/c/projects/myapp
```

This avoids unnecessary filesystem overhead between Windows and Linux.

### WSL is not a traditional VM

WSL does use virtualization, but the VM is managed automatically.

You normally do not need to configure virtual disks, network adapters, installation media, or a separate Linux desktop.

That makes WSL much more integrated than a traditional virtual machine while still providing a real Linux environment.

### Should you use WSL?

Use WSL when your requirement is:

> **"My workstation is Windows, but my software and development environment are Linux."**

It is usually the most natural solution for Linux application development on a modern Windows machine.

If the main goal is instead to package an application with its dependencies into a reproducible environment, containers may be a better fit.