Microsoft called Linux a cancer, and now it ships a real Linux kernel inside Windows

Published Jul 29, 2026, 12:30 PM EDT I’m Adam Conway, an Irish technology fanatic with a BSc in Computer Science and I'm XDA’s Lead Technical Editor. My Bachelor’s thesis was conducted on the viability of benchmarking the non-functional elements of Android apps and smartphones such as performance, and I’ve been working in the tech industry in some way or another since 2017. In my spare time, you’ll probably find me playing Counter-Strike or VALORANT, and you can reach out to me at adam@xda-developers.com, on Twitter as @AdamConwayIE, on Instagram as AdamConwayIE, or u/AdamConwayIE on Reddit. Sign in to your XDA account As someone who uses Powershell quite a bit on Windows, it's been very strange to see standard Linux commands just work, even without a Linux subsystem running underneath it. After all, it's made by the same company that once told the world that Linux was "a cancer", and here it is giving me the ability to use the tools I'd normally use on an actual Linux machine. Completely natively, no less, and as a first-party download straight from Microsoft. The likes of ls worked because they were aliases pointing at PowerShell cmdlets rather than anything Unix-derived, and Microsoft's coreutils release finally puts those actual tools on your computer. Getting PowerShell to actually hand them over is another matter, which I'll come back to. That change is honestly small in the grand scheme of things, though. Modern Windows ships a real Linux kernel, it can now run Linux containers without Docker Desktop, and Microsoft maintains its own Linux distribution that holds up part of Windows itself. Microsoft spent the better part of two decades trying to kill Linux in the press and in court, and it lost so decisively that Windows now leans on Linux to stay relevant to the people who build software on it. Your gaming PC isn't going to be secretly booting Linux under the hood any time soon, but for developers, the reason to stay on Windows is increasingly Linux itself. It's a pretty funny place for Windows to find itself in, all things considered. Microsoft treated Linux as a legal threat for most of the 2000s And profited at the same time Back in 2001, Steve Ballmer called Linux "a cancer that attaches itself in an intellectual property sense to everything it touches." His actual objection was the GPL, the copyleft licence that says anything built on covered code has to stay open too, which to a company selling proprietary software looked less like a licence and more like a trap. That kickstarted the next decade of Microsoft's seemingly unending hatred for Linux. You see, Microsoft ran a marketing push called "Get the Facts" arguing that Windows Server beat Linux on cost and reliability, targeted at the businesses eyeing Linux up for their servers. Around that time as well, Microsoft funnelled money toward SCO, the company waging a long and eventually doomed lawsuit claiming Linux was stuffed with stolen UNIX code. It was a scare-tactic that basically told IT directors that Linux may be free, but it could cost you in court. However, Microsoft upped the ante in 2007. Speaking to Fortune at the time, Microsoft's general counsel Brad Smith claimed that free software infringed 235 of the company's patents, with a breakdown that was oddly precise, 42 in the Linux kernel, 65 in its graphical interfaces, 45 in OpenOffice, and the rest scattered across other projects. Microsoft wanted royalties for all of it, and it never once said which patents it actually meant, which made the claim more or less impossible to fight and very easy to wield as a sword to scare would-be Linux users. Microsoft made use of it heavily, too. In 2009, the company sued TomTom over FAT filesystem patents, and TomTom's real crime, more or less, was shipping the Linux kernel in its satnavs, which made it the first time Microsoft started a patent dispute because of something running Linux. The case settled within a month, and TomTom agreed to license the patents rather than fight it. The bigger money came from Android, which runs the Linux kernel too, and Microsoft built a lucrative licensing operation around it. The company told manufacturers their phones infringed its patents and it started to collect a fee on each one, with HTC reportedly handing over around $5 a handset. Nomura analyst Rick Sherlund estimated the whole programme was worth roughly $2 billion a year at its peak, and some reckoned Microsoft was earning more from Android than its own Windows Phone (though that, admittedly, wouldn't be too much of a surprise). The exact terms were sealed and the figures remain estimates, but it was pretty clear what was happening: Microsoft had found a way to profit handsomely off Linux while telling everyone it was dangerous. WSL put a real Linux kernel inside Windows Most things just work Things were already changing by the time WSL showed up, though. Satya Nadella put "Microsoft loves Linux" on a slide in 2014, a sentence that would have truly blown some minds just a decade earlier. Even more surprisingly, in 2016, the company joined the Linux Foundation as a top-tier member. Ballmer, retired by then, said the Linux threat was in the rearview mirror and that he had come around on the whole thing. The most concrete peace offering came in 2018, when Microsoft joined the Open Invention Network and opened more than 60,000 of its own patents to Linux and open source, royalty-free, essentially laying down the sword the company had wielded for years. Microsoft's own announcement referenced its prickly history, coyly admitting that "it is no secret that there has been friction in the past between Microsoft and the open source community over the issue of patents." The patent threat that had hung over Linux for a decade was, more or less, called off. WSL is where all that goodwill turned into something a lot of people, myself included, use every day. The first version, announced at Build in 2016, was a translation layer that caught Linux system calls and mapped them onto the Windows kernel. It was clever but never quite complete, and you could expose that setup while running software that actually expected there to be a real kernel underneath it. WSL 2 in 2019 dropped that approach and brought an actual Linux kernel running in a lightweight virtual machine to the OS, which cleared up the compatibility problems in one go and even made systemd support possible later on, alongside the ability to run Linux GUI apps through WSLg. Microsoft was now bundling, patching, and shipping a Linux kernel as a headline feature of Windows. Taking a step back and truly taking in all of the history between Microsoft and anything Linux, it's every bit as bizarre as it sounds. There's even more to it, though; Microsoft went further at Build 2025 and open-sourced WSL outright, putting the code on GitHub after years of maintaining it behind closed doors, and only a handful of Windows kernel components were held back. The reason it gave was that WSL needed to move faster than Windows itself and lean properly on the community that had propped it up for years, which is not something the Microsoft of 2005 would have said about any Linux project, let alone its own project. For a good chunk of developers, WSL is what makes Windows usable for their work at all, letting them stay on a Windows desktop while doing everything that matters inside a Linux environment they can access with ease. Windows can now run Linux containers without Docker Desktop It's just a wslc command away Microsoft didn't stop with WSL when it came to the Linux kernel, as WSL Containers, announced at Build 2026, brings the next layer that a lot of developers care about, too. It's a built-in Windows feature, currently in preview with general availability expected in the fall, that lets you build and run Linux containers straight from Windows without Docker Desktop, Podman, or a third-party runtime involved in general. The command-line tool is called wslc, and if you're familiar with Docker, you'll be comfortable enough to get started thanks to commands like wslc run, wslc build, and wslc ps doing exactly what you'd expect. For years the standard way to run containers on Windows was Docker Desktop sitting on top of the WSL 2 backend, which is to say Docker's tooling wrapped around Microsoft's Linux kernel. WSL Containers replaces that tooling with Microsoft's own, but what it doesn't replace is the engine. Reading the source code, I found that wslc boots a dedicated VM, starts containerd, then starts dockerd against it, and it refuses commands until /var/run/docker.sock reports ready. The stack underneath is conventional enough, and wslc.exe is a reimplementation of the docker CLI calling the Docker Engine REST API across a Hyper-V socket. The layer Microsoft has absorbed is the wrapper, not the runtime. The isolation model is where things get really different: Docker Desktop runs everything in one shared VM, whereas wslc creates a session, and each session gets its own set of two vCPUs and 2 GB of RAM by default. Containers within a session still share a kernel, so this isn't per-container isolation, but a Windows application driving containers through the new container API, the one Microsoft ships as a NuGet package, gets a machine of its own rather than joining a machine-wide daemon. There's an enterprise side too, though not a whole lot is available at the time of writing. Group Policy can restrict which registries images may be pulled from, enforced at the service boundary so it restricts the CLI, SDK and plugins. Defender for Endpoint's WSL plugin now understands container events, but it requires signing up for it in private preview. Intune dashboards aren't ready either just yet. This isn't a competitor as such to the likes of Docker Desktop, Podman and Rancher, and they'll still keep working. In fact, the platform development done underneath (virtiofs, the new consomme networking mode) will benefit them too. Funnily enough, even though there's no Compose support, there's a feature request opened in the GitHub repo for WSL by the product manager of WSL requesting Compose support to be added. The most interesting part of the entire setup is the SDK and plugin API, which let a Windows application mount folders into a container, spawn processes there, and receive lifecycle events as native Windows handles. Rust-based, installable with WinGet All of this comes back around to the Linux commands that are now natively supported in Windows. Coreutils for Windows arrived at Build 2026, and it gives you a ton of the Unix command-line staples. Commands like ls, cat, cp, grep, and find now run natively, with no WSL underneath them. You install it with a single winget install Microsoft.Coreutils, and Microsoft's stated goal is to kill the friction of moving between Linux, macOS, WSL, and Windows, so the same scripts and the same habits carry across without translation. There's a catch, and it's a pretty funny one. PowerShell resolves its own aliases before it goes looking for executables on your PATH, so once you've installed the thing, typing ls still gets you Get-ChildItem. Same story for cat, sort, and echo. Microsoft's own repository tells you to sort this out yourself with Set-Alias or a function in your $PROFILE. CMD has no alias system for anything to collide with, so the tools just work there, and grep works in both shells because PowerShell never had a grep alias taking the name to begin with. Which leaves Microsoft in the position of having shipped the real Unix tools to Windows, where the main obstacle to using them is Windows' own decade of pretending it already had them. It gets messier with CMD, where some of the Unix names collide with commands DOS has had since the eighties. Microsoft bundles ports of the original DOS sort and find alongside the Unix versions so that existing scripts using /switch-style syntax keep working, and documents the clashes so you know which one you're getting. You'll really only notice when a script does something you didn't expect. Coreutils for Windows is a Microsoft-maintained fork of uutils, a Rust reimplementation of the GNU coreutils, and Ubuntu is adopting that exact same uutils project as its default starting with version 25.10. Neither side is fully finished, but it's pretty funny that both Windows and one of the biggest Linux distributions on the planet are converging on an identical set of userland tools from the same open codebase. It also gets around the very thing Ballmer was afraid of back in 2001. His fear was copyleft (the GPL specifically), but uutils is MIT-licensed and permissive, so it's exactly the kind of code you can bring into a proprietary operating system with none of the obligations that made him nervous in the first place. Look at the GPL code and how it works in the entire stack: the kernel, and the entire GNU userland inside the WSL and container VMs, all run behind a virtual machine boundary. What Microsoft ships into Windows proper is permissively licensed. Microsoft made its peace with Linux, but it did so on terms that never once threatened the way it actually makes money. Azure is where it's no longer a convenience It's an expectation Everything up to here has been the parts that developers on Windows can experience in their day-to-day life, but there's a very interesting dependency going on in Azure, too. Linux crept up on Windows there over the course of a decade, starting from about a quarter of virtual machines around 2014 to more than 40% by 2017 and past the halfway mark by 2018. Now, in the present day, Microsoft talks about the majority of its customer compute running Linux workloads. Azure is, arguably by some distance, the most important business Microsoft runs these days. And it runs on the thing the company used to sue people for using. But to make the story even more fascinating, Microsoft isn't just hosting Linux servers, it even maintains its own distribution called Azure Linux. It began life as CBL-Mariner, a lightweight in-house distro it needed to run its own infrastructure consistently, and it's now the base OS for Azure Kubernetes Service container hosts and the base container OS in Azure Local. Versions 1.0 through 3.0 were assembled package by package by Microsoft's own engineers, with spec files borrowed from Photon OS, Fedora and Linux From Scratch. Version 4.0, which hit preview at Build 2026, abandons that approach and builds the distro as a set of declarative overlays on a Fedora snapshot instead. To make it weirder still, WSLg, which allows graphical Linux applications to run on Windows, is built on Azure Linux 3.0, which is the hand-assembled one. So a Linux distribution that Microsoft builds from scratch is what makes a small piece of Windows possible. Microsoft isn't just a passive user of Linux, either, and it's been one of the larger contributors of Linux kernel code for years, going back to the roughly 20,000 lines of Hyper-V driver code it contributed under the GPL in 2009, so that Linux would run well on its own virtualization stack. The company that once treated Linux as a threat to be litigated spends real money and real effort keeping Linux healthy, because its own platform now depends on Linux running well. The reason I don't mind using Windows for development is that it now brings Linux to me. I primarily use a Mac, but if I'm ever doing something that requires my more-powerful gaming computer, WSL's real Linux kernel, native containers, and coreutils make it a decent place to do Linux work. If you took those away, then the only thing keeping me on Windows would just be the games that require an anti-cheat. I still use it anyway for that reason, but I like WSL enough that if those games weren't in the picture, I'd still probably be reasonably happy on Windows. Funnily enough, Microsoft didn't beat Linux, and in fact, it lost the argument so decisively that it had to absorb Linux to keep the developers it spent the 2000s trying to scare off. Not bad for, in Ballmer's words, a cancer.