...
| Code Block |
|---|
C:\Users\gilbert>winget list|wsl grep Git Git Git.Git 2.48.1 winget GitHub Desktop GitHub.GitHubDesktop 3.4.17 winget |
WSL creates is a VM running the Microsoft Linux Kernel. That VM launches a special Container runtime. There are Windows commands to create a Container image based on a snapshot of a current Linux distribution such as Ubuntu 24.04 or Oracle Linux 9.1. By choosing the distribution, the user also chooses a set of pre-installed programs and libraries and a package manager that can download additional components. The container is owned exclusively by the Windows user who creates it. It cannot be shared with anyone else. During setup the Windows user selects a default administrative userid and password, which then becomes the default Linux userid under which the Linux programs run.
This solves the otherwise impossible problem of reconciling the entirely different security systems of Windows and Linux. Linux programs run in a container created by a Windows user who has full control and global permission over everything in the container he created. Nothing runs in the container except programs started by the owning user. The container cannot be shared, so no other Windows user has access to anything in it. They can build their own containers over which they will have their own exclusive control. Linux programs access Windows file as the Windows user that created the container in which they are running and that called them and therefore started them running.
WSL creates a tightly coupled communication pipe between the Windows login session and each WSL Container owned by the logged in Windows user. At each end of the pipe is a private network file server and a private sort of ssh command server. These servers are transparently integrated into the Windows 11 tools (like File Explorer) and the Microsoft Linux Kernel so that Windows sees the Linux file system as mounted Windows files, and Linux sees the Windows disk letters as mounted Linux files.
A particularly slick trick is the ability for the execution of a command to slide back and forth between the two systems whenever a Windows exec and a Linux program appear on each side of “|” (a pipe). The Windows and Linux command line execution allow the standard output of a Windows program to be piped to a WSL interface which transmits the byte streams to Linux where a new bash process is created, an environment is set up, and a program is run so that its standard input is the stream of Windows bytes adjusted for the difference in the way Windows and Linux handle line end characters.
A Linux program can pipe its standard output to a Windows program by WSL interface that does the same thing in the opposite direction.
It is a whole lot more complicated to explain how you can type a Windows command to run a Linux Gnome program and have the Linux user window pop up as a GUI application on the Windows desktop. Windows has a Wayland compositor so it can usually translate Linux application calls into a usable Windows app.
...
WSL tries to hide the fact that it runs Linux programs in a Container. Each Container is called a “distro”, short for “distribution”. On the one hand, a “distribution” can refer to a tar file of the file system of any of the common available Linux distribution (Ubuntu, Debian, Kali, etc.). In Container language, this would be called an Image. However, WSL also talks about starting up a distro and running a program in it. This corresponds to a “container”. WSL gets away with the ambiguity because in the very limited command set that the wsl.exe program provides, if you do a
wsl --install Ubuntu-24.04
This is both a command to download the Ubuntu-24.04 tar file Image from a Microsoft library source (dare we call it “WslHub”?) and also to start running it in a Container called Ubuntu-24.04. Unlike Docker or other container systems, WSL only allows you to create one container from any one named image. There is a way to get around this restriction, but Microsoft doesn’t make it easy and doesn’t tell ordinary end users how to do it.
When you use the distro name in the --install, you are talking about the Image. After that, references to the same distro name are about the Container built from the Image during the install.
Not a Docker Container
Docker is a specific system for building a specific type of container used to run applications. Each Docker container is running just one program. If you need more than one program, you group containers together and connect them with a virtual network. If you make any changes to a file in the container, the change is lost when the container stops running.
While WSL containers are also built from an image file, the image is typically one of an entire normal Linux operating system, except for the Kernel. Unlike Docker, it can have background services managed by “systemd”. You can install any Linux package. You can install snaps. You can even install the docker.io package and have a full Docker Engine running inside a WSL distro.
The default and probably best adapted distribution is Ubuntu (24.04 LTS). Ubuntu has supported WSL since the earliest version, installs with systemd and snap enabled, and provides the widest library of programs that you can install and run using the apt package manager.
If you are going to run a sequence of Linux commands, then typing the command “wsl” with no arguments converts the Windows command line into a Linux bash session (like running ssh to a Linux machine on the network). Microsoft also provides a bash.exe command that does the same thing.
There is no way to translate Windows file access control to Linux file permissions. The WSL environment is, therefore, private to each Windows user. If two users are logged into the same Windows machine, each has their own personal copy of WSL Ubuntu. The user has implicit full (root) control over his own WSL system and files. Anything in WSL cannot be directly shared with another user. However, if a WSL service connects to the network as port 8080, then other users on the same machine can connect to localhost:8080 and access the service over what appears to be “the network”.
On Windows, the Linux file system in your Ubuntu distribution is referenced by the Windows UNC name of \\wsl$\ubuntu.
...
Microsoft product. It adds limited individual Linux program execution to a Windows operating system, but Windows remains completely in charge and the user mostly runs Windows applications from the Windows desktop. If you want to add a full Linux operating system to your Windows laptop, then use Hyper-V to create a virtual machine. Then you have the full experience of installing, configuring, and administering Linux and you get the user interface of a full Linux desktop like Gnome.
The first version, called WSL 1, emulated the Linux application program services on a pure Windows system. That provided poor performance and there were some Linux features that could not be emulated. The current version, called WSL 2, runs a Microsoft version of the Linux kernel in a virtual machine, then installs various “distributions” of Linux (Ubuntu, Debian, Kali, Fedora, RHEL) on top of that Kernel. The trick is that Microsoft has added logic to both the Windows Kernel and the Linux Kernel so that they communicate to each other to create a seamless user experience.
You can simply install WSL on your Windows system and use it casually. There is other documentation for an end user. The purpose of this paper is to describe how WSL works so that a slightly more advanced user, like a developer, can understand how to make more advanced use of the service.
Therefore, we will start with a high-level overview of how WSL works as a whole, then drill down into individual components to understand what will work, what won’t work, and how to get it to do what you want.
A Short History
The first version of Windows NT 3.1 somewhere around 1993 had a Posix Subsystem that provided a stipped down Unix compatible application programming interface. Over time, that was expanded to a Unix Subsystem with a more complete API, and that was expanded to WSL 1. For any of these to work at all, the Windows Kernel and File System has always had support for Unix behavior as well as Windows behavior. For example, the Windows file system has always been able to create two different files in the same directory whose names differ only by case, but case-insensitive Windows did not create or support such files.
Ultimately Microsoft had to admit that emulation didn’t work. To get real Linux compatibility, you needed the real Linux Kernel, and to maintain sanity you needed separate file systems, one pure Windows and one pure Linux, but then connect them to each other as if there was a network file share between the two.
When and How do you Switch?
If you have a Linux system on your network, whether it runs on a real computer or a VM, you can connect to it and run commands with ssh and share files over the network. In both cases, however, you need an account on both systems and must authenticate to the Linux account when you connect.
WSL is designed to be a single system. You login to Windows once and that is the only authentication you need. Linux requires you to create a user name with a user id number, but once that is created the behavior is a single identity that extends across systems.
If you are running Windows Command Line (cmd.exe) you can type “ssh” to start Bash on a remote Linux system. Until you type “exit”, the commands you enter into your Windows cmd.exe window are sent to Linux and execute remotely. By typing the ssh command in Bash you can open a session to Windows and the commands you enter into your Linx “term” window will run remotely on Windows.
In WSL, you can switch between Windows and Linux based on the type of program that the system is going to run next. This is literally true in the Microsoft Linux Kernel, which has been modified so that when Linux is about to run a program from its disk, and the program has an extension of *.exe and is a Windows executable, then the Linux Kernel realizes that the program has to run in Windows and automatically begins the process of communicating with the Windows Kernel to switch the context back to Windows execution. For this to work, the Linux current directory has to be preserved and become the Windows current directory. Microsoft also converts the Linux Environment variables to Windows.
Linux programs do not have a special extension. We could imagine a future version of Windows where the Kernel is capable of identifying a file as a Linux executable, but for now you must explicitly add “wsl” (wsl.exe) in front of any Linux command that you want to run from the Windows environment. That program switches the execution environment from Windows to Linux while again preserving the current directory and mapping the environment variables.
A command line entered in either environment can have a string of mixed Windows and Linux commands separated by the pipe “|” operation. When this happens, WSL in either environment arranges for the standard output of the program running on the left side of “|” to be shipped through the WSL connection between the two environments and then fed as standard input to the program on the right side of “|”.
Authentication, Security, Access
There is no reasonable way to design a mapping between the complex Windows file permissions system and the Linux owner/group/everyone permissions model. As explained above, the WSL security model is that you logged into Windows with your Windows Userid and that must become your only security context and decide your access to everything.
To accomplish this, the Linux “system” created by Windows is an internal component private to your Windows login. Each Windows user gets a personal copy of Linux programs and files. You cannot share it with someone else, and no other user can connect to it with SSH. You can run a Web application in WSL that provides a service on a port, and another user can run a client program that connects to it, but that is the only type of cross user interaction permitted.
The Windows user is effectively the administrator of his own Linux instance, with “root” access to its file system. The WSL Linux system as a whole accesses Windows files as the currently logged in Windows user that owns it.
The WSL Linux Kernel is a Windows Component
Microsoft distributes and maintains the WSL Linux Kernel. They can replace it on Patch Tuesday as part of monthly maintenance. They can upgrade it with new releases. This does not affect your WSL instance. All your programs and packages continue to run as before.
You get to choose one or more Linux “distributions” to use when creating a WSL instance. If you choose to install Ubuntu 24.04 on a physical computer or VM, you download an ISO file or USB drive image that you boot to run the installer, and it contains a Linux Kernel that it installs on the destination machine. A WSL Linux “distribution” contains all the same files, programs, and libraries, but it does not have its own Kernel. Also, a WSL Linux “distribution” is a tar file backup of the file system that is restored by Windows to a virtual hard disk VHDX file rather than a bootable DVD or USB image.
It is a Container, but not the type you are used to
Unix has always had the concept of generic “containers”. When any Unix program creates a child process, it can restrict the environment of the child so that it cannot see certain directories and devices, or where the parent program substitutes alternatives for standard well known system devices.
Docker turned this feature into a very powerful system for running applications, but the Docker container is a specific use of the general idea which Docker optimized to run a single application in the smallest, most efficient, and easiest to maintain non-interactive background service. While building, testing, and debugging an application for Docker, a developer could run a container in interactive mode with the equivalent of ssh to bash.
In the early days of WSL 1 and the original WSL 2, a WSL Linux distribution was limited to “single user mode” without background services, which is essentially the same behavior as a Docker container. However, WSL is inherently interactive, and over time the WSL Linux distributions have become versions of the full operating system with background services (running under “systemd”) and pretty much everything in the “server” distributions of Linux (everything but a desktop like Gnome).
You can do all that in a container, it is just not a Docker container anymore. Running a WSL distribution in a specialized container management system solves two problems:
Container images always contained a copy of all the Linux system programs, files, libraries, packages, and configuration distributed as tar files without a copy of the Kernel. That approach was exactly what WSL needs.
The tight coupling between the WSL Microsoft Linux Kernel and the Windows Kernel could be most easily implemented if there was only one WSL Linux VM with one Kernel. If that one Kernel then created a container system and ran Linux distribution images in isolated containers, it could create the required separation between different distributions run by different Windows users while maintaining the simplicity of a single VM.
What about Linux GUI apps?
Unix originally ran on large computers. Users sat at desktop terminals and connected to the Unix machine over phone lines. A terminal provided a screen and keyboard and just enough electronics to send keystrokes over the phone to the computer and send characters back from the computer and write them to the screen.
When people wanted graphical applications, a more powerful terminal was created and a communications protocol was developed named “X”.
The PC was created, and over time it replaced the X terminal, but there were lots of programs written to what was then the X11 API. As Unix migrated to the PC, the simplest solution was to preserve the X11 interface and add to Linux separate logic to manage the screen, keyboard, and mouse with code that emulated an X11 terminal, get rid of the phone line or network, and internally connect the emulated terminal to the existing applications. This persisted for a surprisingly long time in an era where Windows was running DirectX12 and video cards had a GPU, gigabytes of RAM, and various computer APIs.
There were lots of programs that ran on Windows and emulated an X11 terminal.
Slowly Linux has developed an alternative to X11 named Wayland, which makes more sense when the keyboard, mouse, and display adapter are directly connected to the computer on which Linux is running. WSL added a version of the Wayland Compositor component running in Windows while the rest of Wayland continues to run in the Linux Kernel. This allows applications running in WSL Linux to “open a window on the screen” and have that window open on the Windows desktop.
Integrated File Systems
Linux has always been able to share and use shared files with Windows over the network (Samba, CIFS). However, directories have to be explicitly shared, and the client has to provide credentials. Security is a constant issue.
In WSL there is only one user. The programs you run in Windows or Linux are your programs, and you have every right to access your files in either the Windows or Linux file systems. Therefore, WSL exposes all your Linux files to your user session on Windows. Linux gains access to Windows files though your Windows login and inherits your permission to the subset of Windows files you can access.
The Windows File Manager has a “Linux” section that displays your WSL Linux instances
...
And if you select one you see all the Linux directories:
...
But if you want to access them through a path expression, there is a UNC name of the form \\wsl$\ubuntu.
| Code Block |
|---|
C:\Users\gilbert>dir \\wsl$\Ubuntu\
Directory of \\wsl$\Ubuntu
03/31/2024 04:00 AM <DIR> sbin.usr-is-merged
02/11/2025 07:59 PM 2,424,984 init
09/27/2024 03:13 PM <DIR> srv
11/23/2024 08:12 PM <DIR> mnt
03/07/2025 11:42 AM <DIR> proc
03/07/2025 11:42 AM <DIR> dev |
...
| Code Block |
|---|
ls -ltr /mnt total 0 drwxrwxrwx 1 gilbert gilbert 4096 Mar 7 11:16 d drwxrwxrwx 1 gilbert gilbert 4096 Mar 7 11:16 c drwxrwxrwx 1 gilbert gilbert 4096 Mar 7 11:16 e drwxrwxrwt 2 root root 60 c drwxrwxrwx 1 gilbert gilbert 4096 Mar 7 11:4816 wsle drwxrwxrwt 72 root root 30060 Mar 7 11:48 wslg |
While /home/username is your Linux home directory, when you run a Linux program from Windows then the program starts in the same current directory that Windows had, expressed through the mapping:
| Code Block |
|---|
C:\Users\gilbert>wsl
gilbert@MWPFxxxxx:/mnt/c/Users/gilbert$ |
When you go from Windows to Linux, your Windows Environment variables are merged with Linux environment variables.
In Linux, if you type a command that turns out to be a *.exe program, the Microsoft Linux Kernel handles the transition from Linux back to Windows. At this time there is no way for Windows to automatically recognize a Linux program, so you have to run “wsl <programname>”. However, you can create a programname.bat file somewhere in your Windows path. For example, grep.bat could contain:
wsl grep %*
...
:48 wsl
drwxrwxrwt 7 root root 300 Mar 7 11:48 wslg |
Here you can see the C, D, and E disk letters. Based on the rule that when you switch between systems, you get the same current directory after the switch, while Linux gives you the usual $HOME of /home/userid, if you enter Linux by tying the wsl.exe or bash.exe command, you end up with the previous Windows current directory expressed in its WSL path form:
| Code Block |
|---|
C:\Users\gilbert>wsl
gilbert@MWPFxxxxx:/mnt/c/Users/gilbert$ |
Here the command prompt shows that the current directory was C:\Users\gilbert, and when you get to bash in Linux you are in the same directory, but the path is now expressed as starting in /mnt.
Installation
You can install WSL and the distribution from the Windows Store in Windows 11. However, there is no Store in Windows Server 2025, so you might as well get used to the command line.
...
This installs the minimal Hyper-V feature, then downloads and installs the Microsoft Linux Kernel, and finally downloads and installs the default Ubuntu distribution. This requires a reboot to complete the installation. When you run wsl for the first time, the Ubuntu system will go through a first time initialization asking you to enter the userid and password that will administer the system.
...
WSL Implementation
...
Network Protocol
Bell Labs created Unix when computers were big expensive machines shared by users. One people switched to using networks of smaller computers, they started work on a successor to Unix with a codname of “Plan 9”. The idea was to make a network of PCs look like a single system with a lot of users. Files on different computers would appear to be one big file system, and programs and servers running on different machines would look like they were all running in one operating system. To make this work, they developed a very powerful network-based disk sharing and program to program communication protocol named “9P”.
Microsoft adopted 9P as a way to combine the Windows OS (disks, files, programs) with a Linux OS so that the combination of two systems looked to the user like a single tightly integrated system. However, the Microsoft adaptation of 9P runs between a logged in Windows user and the WSL Linux VM started by that logged in user.
While Windows and Linux assume that everything is private by default and a user has to explicitly share disks or directories with the network, the 9P model is that everything is shared by default and something is private by setting permissions. This aligns with the view that while you are logged into Windows and running WSL, your Windows programs have full access to everything on your personal copy of a WSL distribution, and WSL programs you run have access to anything on Windows that you (the currently logged in user under which WSL is running) have access to.
WSL originally ran in single user mode (like a Docker container). Then Microsoft added support for systemd by adding an option in the /etc/wsl.conf file in the WSL distribution file system. Ubuntu defaulted to enabling systemd after 23.10.
WSL has some complicated rules for networking that require their own section.
The Distros
Microsoft provides the Hyper-V feature and the Linux Kernel.
Some of the groups and companies that create real Linux distributions also configure and package the tar files that contain a configuration of their system suitable for use in WSL. There are also GitHub communities that build tar files you can download and import yourself.
wsl --install --online
This command will list the names of WSL Distributions that have been contributed and accepted into a Microsoft library. Any of them will be downloaded and installed with the command
wsl --install <distroname>
You can have more than one distribution installed on your system. Each distribution runs under the Microsoft Linux Kernel in one of the special non-Docker containers. The container separates the file system and memory of each running distro, but they share a single kernel and see side effects of the activities of programs in other containers. In particular, after any program in any container binds to a port number on any network adapter, programs in other distro containers attempting to bind to the same port number will get the error return that the port is already in use by another program.
The default distribution is “Ubuntu” which at the time of writing is version 24.04. Canonical has been the most enthusiastic supporter of WSL and tends to be the first to support new features added by Microsoft. In particular, Canonical maintains libraries of installable programs that reflect WSL improvements such as support for graphic applications and the availability of systemd.
The “wsl --install <distroname>” only works with distronames supplied by Microsoft, and you can only have one installed configuration for each name. Canonical provides two names for what turns out to be identical distributions: “Ubuntu” and “Ubuntu-24.04” install two separate copies of the same system. Once installed, the running distros have separate file systems and therefore separate programs and libraries.
If you need a third instance of Ubuntu, or a second instance of one of the other available distros, or you want to backup a distribution after you have carefully configured one and installed just the right packages, or you want to copy this carefully crafted distribution to another computer, then you can generate your own tar file of the distribution with the “wsl --export”. You can use this tar file to create a second copy of the distribution with a different name on the same computer, or you can copy it to another computer and use it to create a copy of the same distribution+configuration+packages+program using the “wsl --import” command.
If you are inclined to create a distro from a Beta version of Ubuntu, they keep compressed tar files in a public Web site called https://cloud-images.ubuntu.com/releases/. Remember to unzip the file because “wsl --import” takes a tar and not a tar.gz filethe smallest computer was still expensive and shared by multiple users.
As smaller, less expensive machines became common and were connected to each other over high speed networks, the people who developed Unix started work on a project to create a new OS specifically designed for that type of hardware. They named the project after what is widely regarded as the Worst, Cheesiest Movie Ever Made, a film titled “Plan 9 From Outer Space”. The project never completed, and the system was never released.
However, their first problem was to imagine a set of services and a network protocol that would more closely couple small computers to each other so they would appear to be one big system so each computer would lose its individual identity and just become part of overall “hive mind”. The protocol was called 9P. When Microsoft was looking for a way to tie the Windows logged on use to a WSL Linux container as if it were a single integrated system, they decided that 9P was a good starting point. It went far beyond shared files and solved the problem of triggering remote execution, propagating environment variables to another system, and piping the output of one program to the standard input of another program running on another machine.
Windows Home Edition
Windows Home Edition is not licensed to run Hyper-V, but it does support WSL. When Microsoft decided to move from WSL 1 (Emulation) to WSL 2 (Linux Kernel VM), they created a version of Hyper-V that had no user interface, no configuration options, and could create only specific virtual machines defined by Microsoft.
When you enable WSL, if you do not already have Hyper-V enabled on your computer then Windows will install this limited use version of it automatically. No matter which version of Hyper-V you get, you have to reboot to complete the installation.
The Distros
WSL 1 had already defined the format of a tar backup of a Linux file system that could be restored to create a WSL “distro”. However, in WSL 1 this tar file was restored to a hidden subdirectory of one of the Windows system directories on your NTFS C:\ drive. This hidden directory was flagged to use the Unix-compatible option that was part of the original NTFS design but was almost never used, where file names were case sensitive and text files had Unix line end characters.
WSL 2 supported the exact same distro tar file, but restored it to a VHDX virtual disk file that could be formatted with a real Linux file system.
Microsoft provides a library of WSL distros supplied by partners. Ubuntu (currently 24.04) is the default and will be installed when you enable WSL unless you actively prevent it with the --no-distribution option. You can list other options with the command:
wsl --install --online
You can choose a distribution to install with
wsl --install <distroname>
WSL distributions can also be installed with Windows Store, but the command line installation works on Windows Server, where Store is not available.
This easy command interface allows you to create one WSL distro container instance of any named distribution. To create a second instance of the same distribution (with different files and a selection of different packages), you have to start with a first installed distro, then run the command
wsl --export <distro> <tar-file-pathname>
to create a tar file backup of the distro. Then you can clone it to a second named WSL container with the command
wsl --import <newdistroname> <location> <tar-file-pathname>
where <location> is the Windows disk file directory under which a new directory is created with the newdistroname under which all the new distro files are stored.
One distro is designated the Default. It is the distro you run when you type the “wsl” command without a distro name.
...
The Localhost device drivers in Windows and Microsoft Linux have been modified to know about each other and the Hyper-V system that connects them. They coordinate their actions to behave as if they were a single entity. When programs bind to port numbers, the two drivers synchronize this operation so that only one program on either system owns the port. When data is transferred between clients and servers, Hyper-V is called to move the data when one program is on Windows and the other is in WSL.
It was previously noted that multiple distributions running in containers on the WSL Kernel share the Linux localhost device. As a result, localhost can be used to communicate between two programs whether they are running in the same system, one is in Windows and one is in a WSL distro, or each is in a different Linux distro.
At the time this is being written, there is experimental support to extend the behavior of Localhost to all the other real network adapters. This is called “mirrored” networking. When enabled, the Linux Kernel gets a virtual network adapter for every physical network adapter on the Windows host and the other is in WSL.
It was previously noted that multiple distributions running in containers on the WSL Kernel share the Linux localhost device. As a result, localhost can be used to communicate between two programs whether they are running in the same system, one is in Windows and one is in a WSL distro, or each is in a different Linux distro.
Fact: Distro Containers see WSL VM Virtual Network Adapters
There is limited Microsoft documentation.
Docker hides all real devices from its containers, but the WSL container system exposes not just Localhost, but all the virtual network adapters attached to the WSL Linux VM.
However, you cannot control the creation of the WSL Linux VM, nor can you see it in Hyper-V Manager, nor can you change it. The standard behavior is that WSL creates one virtual network adapter (eth0) connected to a virtual network adapter on the host Windows system called “vEthernet (WSL (Hyper-V firewall))” which provides a gateway function with NAT (network address translation) and DNS. Using this each WSL distro gets access to the Internet though the same path as applications running on the host.
Alternately, you can enable networkingMode=mirrored. This is not well explained by Microsoft, but it appears to be an approach that extends the behavior of the Localhost virtual device to all of the real network adapters on the Windows system. The device drivers in Windows and Linux synchronize port assignment, and Hyper-V moves data between the Linux virtual device and the Windows physical device as needed. Again, the distro containers share the same Linux device in the kernel.
There may be some rough edges trying to make this work, which is why the support is still labelled experimental.
Without network mirroring, WSL creates a shared Localhost device, and then one virtual network adapter in the Linux Kernel that is connected to a gateway service in the Windows host. This is separate from the Hyper-V Default network because it is not connected to Hyper-V VMs, but it provides essentially the same general Internet access service.
Because distro containers share virtual network adapters on the WSL Linux Kernel, they share access to the real host network adapters as well.