Hacker News Reader

Comment by kbolino | Hacker News Reader

The bigger problem was how fast Linux evolves. Windows kernel development is glacial by comparison. Keeping up with every new thing in Linux was tantamount to maintaining a second operating system.

View on HN

IIRC, there was an article, whose author said that improving NT kernel without blessing from higher ups is even frowned upon.

So making a better WSL on syscall layer, which NT kernel is designed for, is not only behind a technical effort wall, but also behind a big red tape.

That's a good thing. The kernel is supposed to be the most stable thing.

I'd argue that the breaking point was Docker. Running typical Linux userland applications was doable - and they did it - but making Docker work would have been effectively impossible, as it depends on a ton of highly Linux-specific systems (namespaces, cgroups, bind mounts, etc) with no direct Windows equivalents.

Windows has native support for containers.

Windows containers are interesting. Windows--like most other operating systems--mediates interaction between applications and the operating system though libraries (specifically, user32.dll and kernel32.dll). Whereas, Linux provides a stable syscall ABI that applications can directly interact with. This makes Linux containers fairly insensitive to host kernel version, as long as they don't use experimental features and the host kernel isn't older than the stable features needed by the container processes.

I would have expected Microsoft to address this issue in Windows containers by supplying the correct version of the system DLLs at runtime. However, it seems that they decided to bake them in at build time instead. This makes Windows containers similar to Linux containers but it could have made them quite kernel-version-sensitive. According to MSDN, newer kernels are able to run older images, implying to me that they've begun to stabilize the kernel interface, potentially enough to enable proper static binaries. See https://learn.microsoft.com/en-us/virtualization/windowscont...

For the topic at hand, though, Windows containers run Windows software, and a lot of software that gets containerized never runs on Windows normally and so can't easily be containerized for that platform. Even when the language and libraries are cross-platform, the build process often isn't.

Windows containers have two execution models.

In one, each container gets its own kernel copy, while the other one works like Linux containers, and indeed you need a recent version, as there were some issues doing that on older versions, which is yet another reason to be running Windows 11.

Note that having kernel copy to go along the containers is also existing on Linux world, this is what advanced security models like Kata containers.

There is plenty of Windows software on big corporations that will never be ported to Linux, and that is the golden use case for at least put them into containers.

One such example are all the .NET Framework applications that will never be rewritten into modern .NET, or Windows Services (aka UNIX daemons).

Sure - and I assume that's how Docker for Windows works. But that's a long way from getting Docker for Linux to run on WSL1 - for that to work, WSL1 would need to implement details of the Docker implementation like overlay mounts (to pick an example at random). That suddenly starts looking a lot less like a compatibility layer and more like a reimplementation of parts of Linux.

Reply on news.ycombinator.com