Microsoft has long intended to make Windows the place for developers. Its intention is shown in both software and hardware as the company aims to deliver tools that make it possible to build code wherever and for whatever.
One recent example: the specifications of the second version of its flagship Surface Laptop Studio. Not only does this latest version include an Intel NPU for AI development, it also doubles the system memory from 32GB to 64GB for the top-end version of the laptop. That gives you plenty of resources for building end-to-end applications that cross from cloud to mobile and beyond.
Having a lot of memory simplifies running multiple operating systems at the same time, allowing you to build cross-platform development toolchains that don’t leave your PC and take advantage of both the Windows Subsystem for Linux and the Windows Subsystem for Android. Running on top of Windows’ Krypton hypervisor, both subsystems offer a way to build and test code wherever you’re working without having to spin up additional resources or plug in extra hardware. They’re also both under continuous development, regularly adding new features and tools.
WSL is now ready for prime time
The original vision of a Linux-compatible set of APIs on top of Windows proved complex to maintain and would always lag the fast-moving Linux kernel. As a result, it was deprecated in favor of a Linux virtual machine running on a Windows host, with a shared file system to simplify cross-platform working. Updates added a way to run X11 and Wayland graphical UIs alongside Windows applications, using a version of Windows’ own remote desktop tool.
The resulting hybrid works well, using Windows Terminal as a command line for your choice of Linux and installing Linux distributions directly from the Windows Store. There are still some holes, especially where applications need to autostart back-end processes or work with technologies like systemd. You’re also limited to a fixed virtual disk and a static memory allocation, forcing WSL to run inside strict resource limits, unable to scale up or down with demand. Other problems come with networking, where you’re working with multiple IP addresses rather than treating the two environments as a whole.
Despite these issues, WSL has proven popular. It’s easy to use and offers a way to build cloud-native applications inside a Windows development environment. Tools like Visual Studio Code can work with the Linux guest, using Windows to host its UI while working directly in the Linux file system (and with GitHub) to use its debugging tools with Kubernetes and Linux-based web servers.
Microsoft has continued to update the WSL host tool, updating it roughly monthly through the Windows Store. Linux environments are updated using their own native tools, so if you’re using Ubuntu you’ll continue to use apt like any other Debian-based system, adding repositories as necessary to support tools like Microsoft Edge.
The latest release of WSL 2 adds a selection of features that help maintain a development environment, ensuring optimum use of both memory and disk, as well as adding new networking features that simplify configuration and integration with the host OS. Although they’re currently only accessible under an experimental flag in WSL’s configuration file, they’re important enough to use in your development environment.
New WSL resource management features
Automatic memory reclaim checks to see if WSL is idle and if it is, reduces the amount of memory used by its virtual machine. You have two options: gradual, for a slow release, and dropcache to release the memory used for caches instantly. The slow option takes 30 minutes to go to zero, allowing your WSL install to reclaim memory as it stops idling. This approach allows memory-intensive Windows operations such as compilation to get the most from your PC without shutting down your WSL VM.
Similarly, there’s now a way to shrink WSL virtual hard disks, using Hyper-V’s sparse disk option. For now, it’s only for new disks, though you can also use the WSL command line to set existing distro disks to sparse mode. This should help reduce the size of virtual disks while still letting them grow to support new applications or for page files.
Merging Windows and Linux networking
It’s important to understand that although it runs in Windows, WSL is a separate environment that uses Linux tools. You may have to duplicate efforts, for example managing security and firewalls separately. The new WSL tools bridge this gap, providing ways to let WSL consume existing Windows settings so you don’t have to use Linux tools.
The new mirrored networking mode replaces the exiting NAT tunnel with a direct connection to your LAN. This has been needed for some time and finally does away with needing to connect to the Linux VM on a separate IP address. Now if you’re running development servers under WSL, you’ll be able to connect using the familiar loopback address, 127.0.0.1. It also finally enables IPv6 access to and from your WSL VM, allowing you to simulate running in a cloud provider such as Azure.
Other new networking features include DNS tunneling, which allows the WSL VM to work directly with the Windows DNS server to manage address resolution without sending any packets from WSL to resolvers. This should reduce the risk of networking problems, especially when you’re working behind a firewall that filters packets from unknown IP addresses.
Finally, you can now use Windows firewall rules in the Hyper-V networking stack, allowing WSL to inherit network security settings directly from Windows. There’s also the option to add WSL-specific firewall rules to Hyper-V via PowerShell.
Resource management and networking have been perennial problems for WSL since launch, and this update seems to address most of the common concerns. It’ll be interesting to see how the new features work in practice, and if Microsoft will provide any management tools for WSL’s configuration files. It certainly has provided tools for Windows Terminal’s configuration, and that might be a good place to manage WSL too.
Build and test Android in Windows
Much like WSL, the Windows Subsystem for Android runs an Android virtual machine in Windows, using Intel’s Arm to x86 tool. Microsoft has been adding additional features: support for Windows graphic drivers, including Direct 3D 12 support for the Vulkan API. Other features share Windows folders directly and use local network connections. These updates make it easier to use it as a target for Android application development, using Android tools to side-load your code into the virtual Android environment.
The result is a single development platform that lets you use Windows development environments and tools, building servers on Linux, web, and desktop clients on Windows and working with tools like Flutter to deliver Android apps, all without leaving your laptop. Plus you can run them all inside your firewall or even without an internet connection, avoiding the pitfalls of cloud-hosted development environments. It all comes together to show that we’re finally getting close to Microsoft’s dream of making Windows the one-stop developer OS.
Next read this:
