In Spring of 2016 at Microsoft Build, Microsoft announced Bash on Ubuntu on Windows which enables native Linux binaries to run on Windows via Windows Subsystem for Linux (WSL), with WSL anyone can run Linux distros (Linux distribution) from Microsoft Store in minutes. This quickly begun to use by Millions of Windows 10 users and got improvement with every Windows Semi-Annual release.

✨ WSL

WSL 1 uses lxss.sys, lxcore.sys drivers and pico process that host unmodified user-mode Linux. These drivers translate the Linux system calls into NT APIs and emulate the Linux kernel

WSL 1 emulates Linux syscall to NT kernel which makes some calls very difficult and even nearly impossible to emulate (there are around 380 syscalls in Linux and new syscalls get added with new release) and virtual file system also introduces performance latencies and WSL community was quite actively asking to improve the performance which resulted on embedding in-house Linux kernel in Windows 10 called WSL 2 by Microsoft.

🌟 WSL 2

In Spring of this year at Microsoft Build, Microsoft again surprises Linux Developer community by announcing WSL 2 which contain Linux kernel in Windows 10 (this is not the first time Microsoft shipping Linux kernel, before they shipped a Linux kernel known as Azure Sphere). This time Windows 10 is running Linux kernel inside an optimized lightweight Hyper-V VM (different then traditional VM experience) provides improvements over WSL 1 and full system call compatibility which allow application like Docker to use built-in Linux kernel instead of creating its own VM to support Linux Containers (MobyLinux) or LCOW approach.

WSL 2 will NOT be a traditional VM experience. A traditional VM experience can be slow to boot up, is isolated, consumes lots of resources, and requires your time to manage it. - Microsoft Docs

Release of WSL 2 is not yet provided; at the time of writing Windows 10 Fast Ring 20H1 builds are including WSL 2 for insiders to test and provide early developmental feedback. The kernel embedding in WSL 2 is open source and available on GitHub.

🐳 Let’s talk Docker

Even before the release of WSL, Docker and Microsoft are collaborating to support and streamline the Docker platform on Windows for both Linux and Windows containers, as the result of collaboration containers support and tooling around Windows Development environment got much better and better with time.

Since the Architecture revamp of WSL, Docker reconsiders to try leveraging the sweetness of WSL 2 in their workflows like Docker Desktop and Kubernates (Docker Desktop includes a standalone Kubernetes server and client) on Windows 10, from the initial release of WSL, Docker, wanted to leverage WSL in their workflows but due to performance lack and emulating syscalls make it nearly impossible to go with WSL.

As WSL 2 is supported in Windows 10 Home, Docker Desktop will now run on the Home editions of Windows 10 🎉.

After Docker now discuss a little about tooling which Microsoft is providing to develop on Linux subsystem and containers using Windows and VSCode!

👩🏻‍💻 VSCode & 📡 Remote Extensions

Recently Microsoft has introduced a collection of Remote Extensions to provide developers, full-featured Linux environment on Windows Host. Extensions are currently in the preview but I’m able to get my work done without any issues.

Remote – WSL allow command and extension to run directly on a Linux distro, you can open the folder in WSL (Windows directory are also mountable e.g. /mnt/c) and start developing and debugging code inside.

Remote - Container extension lets you use a Docker container as a full-featured development environment. The extension attaches to a development container running a well-defined tool and runtime stack

🙌🏻 Final Words

As Microsoft is no more a ‘Windows only’ company and more emphasizing on developers feedback either from GitHub issues or the traditional UserVoice mechanism to enhance tooling or plan next iteration. Enhancement in tools like Docker and WSL create a Win-Win situation for Developers, allowing you to focus on WHAT part instead of HOW part of the development picture, i.e. to get started with the .NET Core application targeting Linux, I no more need to worry about setting up the VM, installing the correct tooling and runtimes to kick off development, instead I can spawn a Docker .NET Core SDK container or could use WSL, install .NET Core SDK inside WSL and connect my VSCode in both cases using Remote Extensions and target the application to Linux.