...
| 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 a very special Linux Virtual Machine running the Microsoft version of the Linux Kernel. Unlike other VMs, the Windows system is tightly connected to this Linux VM. Windows programs can directly access the Linux files, Linux has access to the Windows disks, Linux and Windows programs can share the same network adapters, and you can combine Linux and Windows programs on the same command line.
If you want the full Linux Gnome Desktop experience, create a normal Linux VM with Hyper-V. WSL is command line only, but you can install individual Linux GUI programs into WSL and when you run them an application window pops up on the Windows desktop:
...
The Microsoft Linux Kernel runs a special non-Docker container system. You can install one or more Linux “distributions” (Ubuntu, Debian, SUSE, etc.) each into their own container under the Kernel. Unlike Docker, this special container system lets the distributions run systemd background services and shares resources like network adapters. Each distribution has its own isolated file system, processes, and librariesVM 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.
...
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.
Windows 11 Home Edition is not licensed to allow use of the full Hyper-V. There is a limited function “no configuration” version of Hyper-V that gets installed to run WSL.
If WSL is not installed, just run the Windows commandrun an elevated (Run as administrator) command prompt and enter
wsl --install
This command installs the minimal Hyper-V feature, then downloads and installs the Microsoft Linux Kernel, and then finally downloads and installs the default Ubuntu distribution. You typically then have to This requires a reboot to enable everything.
To list the other available distributions (without using Store), type the Windows command wsl --list --onlinecomplete 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.
Some WSL Implementation Internals
...
Microsoft provides the Hyper-V feature and the Linux Kernel.
Various suppliers provide WSL Distributions in the form of a tar file containing a file system. While the “wsl --install <distroname>” command will download and install a distro from the Microsoft library, you can get a tar file from some other source and create a distro from it.
The non-Docker container that runs a distro stores its files in a Hyper-V virtual disk (*.vhdx) file somewhere in the C:\windows directory. Changes made while the distro runs are written to the virtual disk and persist (whereas Docker containers do not persist changes to their file systems).
Generally, the distro named “Ubuntu” is the same version as the most recent explicit named version (“Ubuntu-24.04” as this is written). You can create two separate versions of the latest version of Ubuntu distinguished by these two names. Each will have their own distinct files on separate virtual disks. 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, you need to 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” a . You can use this tar file with a file system and then “wsl --import” the tar file you just generated, giving it a new distro nameto 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 file.
...
This is a subject that is constantly being changed by Microsoft, but there are a few basic ideas that remain constant.First, the “localhost” address of
Concept: There is one “localhost” shared by Windows and WSL
Actually, localhost (address 127.0.0.1 behaves like a network adapter but it has nothing to do with the network. In ) is a device driver in both the Windows and Linux Kernels, localhost is implemented with a dummy device and a special device driver so that a client program can talk to a server program on the same computer without data ever going to any network.There is support in both the Windows and Linux Kernel drivers for the dummy localhost devices that they Kernel. It is always a virtual network adapter with no real network and no physical device. It allows two programs on the same computer to talk to each other as if they were talking through a network.
The Localhost device drivers in Windows and Microsoft Linux have been modified to know about each other and communicate using the Hyper-V to create what amounts to a single coordinated localhost device across both systems. If two programs running in Windows and WSL both try to act as servers on port 8080, then one of them will get the port and the other will be told that the port is in use by someone else. Client programs on either Windows or WSL can then connect to localhost:8080 and talk to whichever server got the port. Data will be transferred as needed between the localhost drivers in the Windows Kernel and the Linux Kernel.
Experimentally (at the time this is being written) this behavior can also be extended to all the real network adapters in the Windows system. If network “mirroring” is enabled, the Linux Kernel creates a dummy Linux network adapter for every real Windows network adapter. It is experimental because Windows has to be in control, so Linux cannot attempt to reconfigure the network adapter to have different addressing or behavior. Client programs on either Windows or Linux can use an adapter to access servers on the real network, and server programs on Windows or Linux get a “first wins” resolution when they try to bind to an IP address and specific port number.
The default WSL network behavior is that the Linux Kernel creates one virtual network adapter that is connected to Windows, and Windows provides a NAT gateway through which client Linux programs in any Linux distribution can access the Internet. Linux server programs should bind to localhost as described abovesystem 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 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.