What is WSL?
At a high level, WSL provides the ability to run Linux binaries on Windows. The desire to run Linux binaries has been around for many years, at least if the existence of projects such as Cygwin (https://cygwin.com ) is anything to go by. According to its homepage, Cygwin is 'a large collection of GNU and Open Source tools which provide functionality similar to a Linux distribution on Windows'. To run Linux application on Cygwin, it needs to be rebuilt from source. WSL provides the ability to run Linux binaries on Windows without modification. This means that you can grab the latest release of your favorite application and work with it immediately.
The reasons for wanting to run Linux applications on Windows are many and varied and include the following:
- You are currently using Windows but have experience and familiarity with Linux applications and utilities.
- You are developing on Windows but targeting Linux for the deployment of your application (either directly or in containers).
- You are using developer stacks where the ecosystem has a stronger presence on Linux, for example, Python, where some libraries are specific to Linux.
Whatever your reason for wanting to run Linux applications on Windows, WSL brings you this capability and does so in a new and productive way. Whilst it has been possible to run a Linux virtual machine (VM) in Hyper-V for a long time, running a VM introduces some barriers to your workflow.
For example, starting a VM takes enough time for you to lose your flow of thought and requires a dedicated amount of memory from the host machine. Additionally, the file system in a VM is dedicated to that VM and isolated from the host. This means that accessing files between the Windows host and Linux VM requires setting up Hyper-V features for Guest Integration Services or setting up traditional network file sharing. The isolation of the VM also means that processes inside and outside the VM have no easy way to communicate with each other. Essentially, at any point in time, you are either working in the VM or outside of it.
When you first launch a terminal using WSL, you have a terminal application in Windows running a Linux shell. In contrast to the VM experience, this seemingly simple difference already integrates better into workflows as it is easier to switch between windows on the same machine than between applications on Windows and those in a VM session.
However, the work in WSL to integrate the Windows and Linux environments goes further. Whereas the file systems are isolated by design in a VM, with the WSL file system access is configured for you by default. From Windows, you can access a new \\wsl$\ networked file share that is automatically available for you when the WSL is running and provides access to your Linux file systems. From Linux, your local Windows drives are automatically mounted for you by default. For example, the Windows C: drive is mounted as /mnt/c.
Even more impressively, you can invoke processes in Linux from Windows and vice versa. As an example, as part of a Bash script in the WSL, you can invoke a Windows application and process the output from that application in Linux by piping it to another command, just as you would with a native Linux application.
This integration goes beyond what can be achieved with traditional VMs and creates some amazing opportunities for integrating the capabilities of Windows and Linux into a single, productive environment that gives you the best of both worlds!
The integration that has been achieved between the Windows host and the Linux VM environments with WSL is impressive. However, if you have used WSL 1 or are familiar with how it works, you may have read the previous paragraphs and wondered why WSL 2 moved away from the previous architecture, which didn't use a VM. In the next section, we'll take a brief look at the different architectures between WSL 1 and WSL 2 and what the use of a VM unlocks despite the extra challenges the WSL team faced to create the level of integration that we have just seen.