Sounds promising. But I'd like to see Docker work with Microsoft to produce something even better for Windows, using the new Windows Subsystem for Linux (WSL). With WSL, Docker and Microsoft should be able to bring Linux-based Docker containers to Windows, without the performance hit and resource fragmentation that inevitably come with virtualization. True, WSL doesn't support namespaces and cgroups, but IIUC, Windows itself has equivalent features. So the Docker daemon would run under Windows, and would use a native Windows API to create containers, each of which would use a separate WSL environment to run Linux binaries. I don't know how layered images would be supported; Microsoft might have to implement a union filesystem.
Native Docker support in Windows will be available in the next Windows server release, and is already available in the Windows technical preview bits (since TP4).
To be clear, Windows containers allow you to run containers that contain Windows executables under Windows. mwcampbell is talking about running containers that contain Linux executables on Windows.
I guess the only thing that would prevent this from working is having the linux subsystem available on the host (and of course support for all the syscalls being made).
What is the use case though? What would be even better is if MS created a "windows container" that could run under Linux, then you could just ditch windows all together.
I don't see big companies using something this hackish for containers that are running on servers anyway. For working on the desktop this might come in handy for devs, but honestly I think MS should focus their energy on something else.
Keep in mind, Linux containers work since there's only one Linux kernel, and the rest of the OS is just files that can be stuck into the container. Anything that can pretend to be the Linux kernel (like a Solaris "branded zone") can run a Linux container.
But you'd actually need many different kinds of "Windows container", since Windows actually has an abundance of kernel-exposed runtimes: the DOS VMM, Win16 with cooperative threading, Win32 with COM, WinNT, WinRT, the POSIX subsystem...
You could certainly write a particular container runtime to allow a specific type of app (e.g. WinRT apps) to run, and that might be enough to enable developers going forward to target both Windows and Linux hosts for their Windows apps. But that would hardly be Windows, in the sense of being able to have your app launch arbitrary other "Windows" processes in the same container the way that Docker apps do with arbitrary Linux processes.
Having all the machinery to simulate all the vagueries that have changed in the Windows OS core over time, such that one container could contain any and all Windows processes running together, would be a much harder challenge. I don't know what the combined surface area of all the runtimes the Windows kernel exposes looks like, but I can't imagine it'd be something even MS could re-implement as a Linux-kernel translation layer easily (especially considering all the compatibility shims each layer provides to make specific apps work, that would have to be carried forward into the translation layer.)
The same use cases as Linux. Being able to isolate applications, being able to allocate resources more fluidly, being able to centralize management all the better. Windows has actually gained some real nice virtualization management over the past few versions, and this would fit right in with them.
