It's not truly contained, though. There is no security boundary between the host and the guest there - WSL can access your entire filesystem, for example (subject to usual ACL checks, of course).

The reverse is also true, by the way - WSL portion of filesystem can be observed directly from Win32 (cd %USERPROFILE%\AppData\Local\lxss and look around, but don't touch - there's some magical pixie dust there that's easy to disturb and break things from the Linux side of things).

Can't you make whole drives available to a true VM in the same way?

You can, but in a VM, you still have two different and separate filesystems, and then some mechanism to provide a window into one from another (custom FS driver mounted in a directory, SMB share etc). In WSL, there is only one filesystem.

And it's not just filesystems. We're also talking about potentially shared file descriptors/handles (where appropriate), access to processes in both directions etc.

So from user's perspective, I would argue that it's actually more similar to Wine. Even if the implementation is more low-level (syscall emulation vs userspace API emulation).

> Wine runs on the host OS, WSL runs apps from linux image. This image is self contained, just like a VM.

Actually (it's been a long time since I last used Wine though, so I might remember incorrectly), Wine is "self contained" as well and there's a "C: drive" directory structure with notepad.exe etc. too, just like the WSL system.

That's a very narrow definition of self-contained though. Wine does not implement its own filesystem operations, it uses the host's filesystem api to access host-native files. It doesn't even emulate a jail/chroot, because the host's / filesystem is by default accessible through Z:\

I think your right, now that you've jogged my memory.