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.
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.
WSL1 worked this way, but this approach has many drawbacks (e.g. FS operations are slower on Windows, which can have massive impacts on Linux application performance).
Since WSL2 they switched to a VM approach - Windows and a specialized Linux are both running under a hypervisor next to each other.
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 😅