introduction

Windows has had a native Linux capability for the last few years which has proven to be stable and quite capable.

“Windows Services for Linux” (WSL) can run Linux most distributions without problems in most of the ways we might want to use it as Linux users and provides a useful adjunct to those saddled with needing to use a Windows laptop for whatever reason.

why?

There are a number of reasons, but many of these simply come down to convenience.

For most uses it can’t replace a full Linux desktop but for cases where you just want to use a Unix-based workflow for certain things such as text processing as this comes more naturally, then being able to work on the same files from within Windows and Linux without having to transfer them back and forth can be quite appealing.

It is also very useful as a development environment for devops work as it’s local and can be created and destroyed relatively easily, mostly without need for Windows Administrator privileges after the initial setup and required Windows features are enabled.

version differences

WSL version 1 is more like a “reverse Wine” in the sense that it’s an environment that provides a system call ABI interface to a Linux binary and translates these to the equivalent calls on Windows to provide similar functionality, but this approach tends to only be able to extend so far.

WSL version 2 is a para-virtualisation environment that operates at the kernel level to provide low-level functionality into the Windows environment and is apparently based on Microsoft’s work with Xen in their Azure cloud infrastructure. This allows WSL2 VMs to host X11 clients and present these on the Windows desktop alongside other native applications. WSL2 is reported to support being able to read and write native Linux filesystems directly on devices (although I’ve not tried this)

installing WSL

Microsoft do have a number of web pages on WSL and the install process however this page assumes some settings about your desired installation which may not be wanted

I’ll be going through a manual process and describing things as we go, mostly following the manual install process

installing WSL manually

enable virtual machine features

open powershell as Administrator:

enable virtual machine features and reboot the host

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
wsl.exe --install --inbox --no-distribution
shutdown /r /t 10

for example:
your Windows host will perform a reconfigure reboot

configure WSL

start Powershell as Administrator
set default version of WSL, update it and then exit the PowerShell session
```
wsl.exe --set-default-version 2
wsl.exe --update
exit
```

install image

start Powershell as a non-privileged user

list the OS images available online, install Ubuntu, then exit the PowerShell session

wsl.exe --list --online
wsl.exe --install --no-launch --distribution ubuntu-22.04
exit

for example:

image configuration

from the main menu, locate the new Ubuntu “app” (taskbar pinning is a convenience)
start the app, which will then do the initial OS build:
- use a proper non-privileged username (don’t use root)
- use a unique password
for example:

do the usual maintenance:

sudo -i
apt-get update && apt-get upgrade -y

for example:

X11 support

install the x11-apps package and dependencies
```
sudo -i
apt-get install x11-apps
```
for example:
confirm that xclock is functional
xeyes sort of works also
xdaliclock also sort of works also

caveats

There is no apparent support for some things

root window, so no changing background parameters
limited shape support, xdaliclock does work, but I’d not rely on it
transparency support seems to be non-existent
client snooping the mouse pointer outside of their own window (as per xeyes)

interoperability

Windows file system is available from within WSL as /mnt/c
WSL file system is available via a network share \\wsl.localhost\<image-name> as follows:

filesharing caveats

Modern Windows command-line tools output text as UTF-16 (for example, netstat -r) while Linux text tools tend to use UTF-8 - so you will need to use iconv on files generated under Windows or Linux tools such as grep will be unable to work with them:

$ iconv -f UTF-16le -t UTF-8

network

In the default configuration it seems that the WSL guest uses NAT to talk to the outside world as below:

access from Windows

Oddly, WSL2 guest bindings to 127.0.0.1 seem to be honoured with routing to take precedence over those of the local Windows machine, because you can (for example) totally use PuTTY to talk to your Ubuntu guest directly:

external access

In the default configuration, getting at your guest from outside the Windows host can be a tad tricky due to the NAT, however this is doable when you install the Windows openssh server feature. This binds to 0.0.0.0:22 as below (this required admin privileges)

Once configured, you can get to your Ubuntu guest with the following

$ ssh -J <windows-user>@<windows-external-ip> <ubuntu-user>@<ubuntu-internal-ip>

For example, this is from my laptop:

networking caveats

You will probably want to secure an OpenSSH daemon running on windows as this demo assumes that we’re fine with allowing password-based logins which might not be to your taste

You might not even need to do this if the Ubuntu guest can be given an actual NIC, or at least a bridged virtual NIC, but I haven’t explored that.

live demo

bwahahahah

Using Linux under Windows