Last week, Microsoft and Canonical (the company behind the Ubuntu Linux distribution) were scheduled to host a developer conference focused on the Windows Subsystem for Linux (WSL) at Microsoft’s Redmond campus. Ars was invited, and I had plane tickets in hand—but the physical conference was canceled at the last minute due to the coronavirus.
Note that I did say the physical conference was canceled—WSLconf itself went on, with 22 speakers and 21 talks given. Virtual attendees were reportedly more than double the (sold out) physical attendee registration and included developers from all around the world. Presentations were given over the Bluejeans videoconferencing platform, and Canonical’s Developer Advocate Hayden Barnes says that the recorded sessions will be made generally available soon.
What’s a WSL? And how do I install it?
Most Ars readers will already know that there’s a Windows Subsystem for Linux available and that it does… Linux stuff. But what’s less clear is how to actually install it or why you’d want to.
The installation part is simple and free, though it requires two separate steps. First, you need to install WSL as a Windows feature, using the Features applet, which can be accessed directly from the Start menu. This involves a relatively quick download, followed by an immediate reboot.
Once the WSL feature is installed, the next step is installing an actual Linux distribution underneath it. There are many choices available—including Kali, Debian, OpenSUSE, Alpine, and two Long Term Support (LTS) versions of Ubuntu. We chose the newest Ubuntu LTS; searching the Store for Ubuntu brings it right up, and one click (followed by a several-hundred-megabyte download) installs it.
Once the download and installation for Ubuntu 18.04 finishes, Ubuntu 18.04 LTS shows up as an app in the Start menu. Clicking it brings up a console window that should be immediately familiar to any Linux user—it’s a bash prompt, inside what looks an awful lot like any other Ubuntu installation. And it should—under the hood, what you’re looking at is a full Ubuntu virtual machine, running under Hyper-V.
The major differences between WSL and a standard Hyper-V VM revolve around integration. There are no guest drivers to install, and the C: drive is already mounted read-write for you, under /mnt/c. You can easily and seamlessly read and write files across operating system barriers, without needing to think too much about it.
Now that I know what WSL is, why do I want it?
Let’s be honest, here—if you’re not a developer, a Linux user, or someone who’s already curious about Linux… you probably don’t. If you’re a Linux user—or Linux-curious—WSL is a great way to get your feet wet and experiment freely without needing to dual-boot. This largely replaces older workarounds like the venerable Cygwin, which provided a partial Linux-like userland environment that still runs beneath Windows itself.
While it’s possible to run some GUI (Graphical User Interface) apps under WSL with the use of an additional X server like MobaXTerm, that’s really not WSL’s current focus—at least, it’s not what the folks both presenting and attending at WSLconf are most interested in. What most developers are getting excited about is the ease of cross-platform development under WSL.
To demonstrate, we built a simple Hello World-style program using Nim. Nim is a higher-level language that offers easy compilation into standard C code; the C code is then run through the GCC compiler to produce an executable binary.
We do want to be clear that Nim is by no means the only way to build cross-platform code under WSL. We just used it here as a clean, quick, simple way to make a Hello World-style app without a lot of cruft to get in the way of seeing what’s going on.
import os echo "Hello, " , paramStr(1) , "!"
Compiling this Nim code produces an executable that takes the first argument given to it and uses it to greet the user:
[email protected]:~$ nim compile ./hello.nim [debug stuff elided] [email protected]:~$ ./hello you Hello, you! [email protected]:~$
nim compile a couple of extra arguments, you can—while still within the Linux environment—instead build a Windows executable, copy the resulting
hello.exe out to your C: drive, and then run it from within Windows itself.
C:Usersunprivileged> hello.exe you Hello, you! C:Usersunprivileged>
This is, clearly, a very trivial example—but it’s not hard to find much more extensive and powerful examples of the same basic technology being used in much larger environments.
Case study: EA’s Frostbite Engine
Using WSL and Visual Studio allows companies to rapidly onboard Windows-native devs to Linux build environments and greatly simplify their toolchains. EA’s use of Visual Studio and WSL to build and debug its Frostbite Engine is a great example:
At EA our Frostbite Engine has a Linux component used for our dedicated servers that service many of our most popular games. When we saw that Microsoft was adding support for Linux in a workload in Visual Studio, this caught my interest!
At EA our game developers are used to a Windows environment for development so we thought that forcing them to develop in a Linux environment directly would be a difficult ask […] After the release of the Visual Studio Linux Workload, we found that Microsoft had basically wrapped up all of the tools/processes up nicely into a Visual Studio Workload we could ask our Developers to install and be able to debug directly in Visual Studio!
So far the integration with WSL and remote debugging the workload provides has been a success and has drastically cleaned up our tools/processes surrounding Linux debugging/development. Our developers have been really happy with the improved experience.
EA and Frostbite are far from the only example of large projects benefiting from Microsoft’s relatively recent—but clearly serious—commitment to deep Linux integration and support. Much of the last few years’ renaissance in Linux gaming has been due to the Unity engine’s support for Linux—but what many people may not realize is that the engine’s Linux support comes from being built on .NET, which is itself a fully cross-platform development environment.
The actual talks given at WSL included topics focused on infosec, Devops automation, Kubernetes, and more. We look forward to them becoming generally available and will update here with links once they do.