I think from what I've read that this is the case, but I've read some other info that's made it less clear to me.
On the second part of the question regarding container engines, I'm pretty sure that may also be correct, and it kinda makes me wonder a little about risks of engine lock-in, but that may be a little out of scope.
In my experience docker will run Linux images everywhere. I believe it uses WSL on windows and a VM on macs.
So it entirely depends on what your engine supports.
I believe there are open standards for the binary format of images so switching engines may be possible. But again depends how the containers are built.
Containers are practically a linux thing. The specs to run containers are open (Open Container Initiative). That's why if you aren't on linux, the most common solution is to virtualise linux or add a layer that translates linux syscalls to those on the host OS (e.g windows subsystem for linux). Once the linux environment exists you have multiple orchestrators (docker, podman, kubernetes, etc.). They all either have their own runtime or use an existing one (runc, crun, youki, ...).
I haven't read the OCI specs, but IINM containers are built upon linux primitives (namespaces, cgroups, and I forget the rest).
TIP: programs that run inside docker containers should be compatible with the host system's kernel.
If you want to run a container targeted for a linux distro on windows, you need some intermediate that will translate Linux sys calls to windows ones. I don't have experience with this but I believe that's what WSL accomplishes? Among other things.
Regarding your question about lock-in, if I understand it correctly, you are targeting the kernel really, thats the "engine". So "lock-in" is about the same as you choosing which OS to target.
Regarding your question about lock-in, if I understand it correctly, you are targeting the kernel really, thats the “engine”. So “lock-in” is about the same as you choosing which OS to target.
I may have been using the wrong terminology. Going off another reply here what I was referring to may also be called an orchestrator? So by this I was referring to software like Docker and possibly getting tied up in it.
I see. That's a good question because I'm not even aware of other "orchestrators" outside of kubernetes 😅
A Linux container can only run on a Linux kernel (and likewise for Windows and Mac). But there are plenty of tools to more-or-less transparently solve that particular problem by e.g. running a virtual machine in the background to host a shared Linux installation that hosts the containers (and then mapping ports and stuff for you).