Recently I have watched with awe a couple of presentations on Docker on Windows. Wow… proper containers on the Windows kernel, I haven’t seen it coming! I thought that “porting” cgroups and namespaces from Linux was something hard to accomplish. Surely, all the bits where already almost there: Windows has had something similar to cgroups for resource control (Jobs, sets of processes which can enforce limits such as working set size, process priority, and end-of-job time limit on each process that is associated with the job) since NT 5.1 (XP/Windows Server 2003), and NT has had kernel namespaces since its beginning (NT 3.1). For details I recommend reading this excellent article: Inside NT Object Manager.

However, seeing this bits put together and exposed to the userland with a nice API, and Docker ported (not forked!) to use it, is something else.

Of course, I was instantly curious. How did they do that? The Windows Containers Documentation contains no clue: all you can find is a quick start.

There a couple of videos on presentations done at DockerCon EU 2015 and DockerCon 2016, but documentation is really scarce. Non-existent.

From the videos you understand that, as usual, Windows does not expose in an official way (at least, for now) the primitives needed to create the virtual environment for creating a container, but rather exposes a user-mode DLL with a simplified (and, hopefully, stable) API to create “Compute Systems”. One of the exposed functions is, for example, HcsCreateComputeSystem.

A search in MSDN for vmcompute.dll or, for example, HcsCreateComputeSystem, does reveal nothing… the only documentation is found in a couple of GitHub projects from Microsoft: hcsshim, a shim used by Docker to support Windows Containers by calling into the vmcompute.dll API, and dotnet-computevirtualization, a .NET assembly to access the vmcoumpute.dll API from managed languages.

Once it is documented, this “Compute Systems” API is surely something I want to try out for Pumpkin.

Meanwhile… there is a passage in the presentations and in the official Introducing Docker for Windows Server 2016 that left me with mixed feelings. You cannot use “FROM scratch”  to build your own image; you have to start with a “minimal” windows image.

Currently, Microsoft provides microsoft/windowsservercore or microsoft/nanoserver.

The Windows Server Core image comes with a mostly complete userland with the processes and DLLs found on a standard Windows Server Core install.  This image is very convenient: any Windows server software will run on it without modification, but it takes 10GB of disk space! The other base layer option is Nano Server, a new and very minimal Windows version with a pared-down Windows API. The API is not complete, but porting should be easy and it is less than 300MB.

But why do I need at least a 300MB image? The point of containers is to share the kernel of the host, isn’t it?

The explanation is buried in one of the DockerCon presentations, and it makes a lot of sense: the Win32 API is exposed to Windows programs through DLLs, not directly as syscalls.

(Note: I will call it the “Win32 API” even on x64, because there really isn’t any “Win64” API: it is the same! Just look at the names of the libraries: kernel32, gdi32, user32, …)

Of course, internally those DLLs will make syscalls to transition to kernel mode (sort of, more on this later), but the surface you program against in Windows is through user mode DLLs.

What really hit me is the sheer number of “basic” components required by Windows nowadays. I started to program using the Win32 API when there were only 3 of these DLLs. OK, 4 if you count advapi32.dll.

Sure, then there was ole32, if you wanted to use OLE, and comctr32, if you wanted “fancy” user controls, and Ws2_32 if you wanted sockets… But they were “optional”, while now without  crss.exe, lsass.exe, smss.exe, svchost, wininit, etc. you cannot even run a “no-op” executable.

Or can you?

I will take an extremely simple application, which “touches” (creates) a very specific file (no user input, to make things easier), and try to remove dependencies and see how far you can get (Spoiler alert: you can!)

I will divide my findings in three blog posts, one for each “step” I went through, and update this post with links every time I post a new one.

• Step 1: no C runtime
• Step 2: no Win32 API
• Step 3: no Native API (no ntdll.dll)