Today was the day during which I was going to get going with ghdl.
Or so I thought.
Initially I was reading up on the updates, and was going to start by running a simple example in their docker.
I haven't dealt much with docker so far; I know the concept(s) and that has been enough.
So I thought I'd read up a little on what the normal workflows are, etc. But I got sidetracked by vaugely worded comments on the docker page about the difference between Linux and Windows docker images.
I've heard a lot of people say that Windows-based docker-images is impossible! but what do I find, it's been supported for 4 years already.
Linux images can be hosted with process-isolation in a Linux-VM, or be hosted more separated where each image gets its own small VM.
But what about windows images?
Apparently they are built on top of Microsoft-provided base-images which contain container-adapted DLLs(?). By default images built on those just soft-link to the base image, but this can be overridden as mentioned in the Windows Container FAQ on MSDN.
After an hour of fruitless digging on Docker and various Microsoft-sites I found this reverse-engineering post site where some bloke summarized that virtualization works with Jobs and Silos. A Job loosely corresponds to the Linux mechanism control group (cgroup). The namespacing mechanism in Linux is loosely the same as a silo which can change the root namespace object in windows, through which filesystem, registry, and other things is accessed.
With these new search terms in hand I found book about Windows Internals with details about how to create and operate jobs and silos.
It is likely that MSIX (which I stumbled over when looking for container APIs) uses these mechanisms to achieve their containerized structure. MSIX replaces the old AppV which did virtualization by filter drivers and similar redirection.
Chronological (or something ¯\_(ツ)_/¯ ) Category: blog