* Ubuntu, and all children apps run under current user's credentials, but are launched under an Lxssmanager servicehost process (as opposed to explorer.exe)
* ProcMon can interact (send sigterm / etc to) unix processes; but as shown on htop, unix processes are not aware of windows ones; nor have I found any ways to send signals backwards
* API compatibility is excellent. Last 2 days, I have re-compiled a full python & elasticsearch & mysql stack into this. Overhead is significantly lower, than any of the virtualization stacks
* I don't use AV tools; however, I suspect they don't check for ELF files. Host system is mounted in /mnt/c , /mnt/d ,etc in LXSS, with current-windows-user creds
* 2-command Sandbox reset: lxrun /uninstall & lxrun /install <- will restore the linux subsystem to factory default
* LXSS root dir (/usr /var, etc) is in c:\Users\$username$\AppData\Local\lxss\rootfs\ ; home is mounted into c:\Users\$username$\AppData\Local\lxss\home\$username$\
And some caveats:
* Filewatching (specifically, inotify_add_watch ) does not (yet) work
* Manipulating files from the host occasionally makes it _disappear_ (??!) from visibility in the linux subsystem. Specifically, git pull from bash, then git update from host makes git update from bash impossible (index file open failed). Same problems with other types of host file-manipulation. This might be due to permissions, or somethings I haven't figured out yet.
And there is some strange behaviour with the keys. Actually using LXSS become far lees powerfull to the users of Conemu thanks to this. Vim and NeoVim does weird things with the arrows, on mc I can't navigate on the filesytem with the cursors, and htop does weird things.
I suspect that might be conemu, and compatibility thereof. Specifically, running the bog-standard bash prompt (with conhost.exe) makes this a no-repro; all keys / arrows works in MC & htop
Or, with current stable (160724), install "Bash on Ubuntu On Windows" (ugh), then in ConEmu, open the Tasks section in Settings and click "Add default tasks...", then Yes.
You may want to add the tilde to the path, as it seems to open to /mnt/c/Users/<username>/. Also, I think it still messes with the keys, but not always. They seem to work fine right after starting it.
| Note that outbash.exe listens on 127.0.0.1, but validates that processes that establish a connection are running as the same user as outbash.exe (this check is implemented starting with version v0.7). Therefore, it can be used on multi-user computers.
So, I suspect this uses TCP & networking to do that; which does work: you can listen to a port in LXSS, and that will be accessible via 127.0.0.1 ;and you can connect to 127.0.0.1 from LXSS, and it will be routed to eg. windows listeners . Above was specifically about process-based signals, and non-network-hacks.
I confirm it only uses TCP for all communications between Win32 and WSL; source: I wrote cbwin. For now there is no other documented API, so this is the only sane choice (actually you can also use temp files on the FS, but it would be a poor idea for several reasons)
Using TCP is actually not that much different than opening a Linux or Windows device or IPC object and using it, except that: * you must handle serialization and framing, * you typically get no security for free (I get some back with a GetExtendedTcpTable + OpenProcessToken + AccessCheck hack), * performance is not excellent, esp with the security check, however on a modern computer you can still sustain launching at a mean rate of ~40 Win32 process / sec (and peak rate of hundreds per sec), which is largely enough for any use case I expect. (Actually if you do spawn Win32 process too fast for too long, Windows tends to graphically bug even after you stop that activity. It might be because of my graphic card driver, because I did not had that issue in a VM.)
On the plus side of using TCP, I could easily test some of the WSL side code on a real Linux to track some bugs (temporarily allowing non localhost connections on my dev environment)
To be clear, cbwin is not and will never be a complete substitute to proper IPC / interactions between Win32 and WSL, but that's not too much of an issue because MS will very probably add some in a future release -- I think at least some way to launch Win32 programs from WSL, and at least working pipes between processes of both world (not 100% sure, but I would be surprised if they don't).
Short summary:
* Ubuntu, and all children apps run under current user's credentials, but are launched under an Lxssmanager servicehost process (as opposed to explorer.exe)
* ProcMon can interact (send sigterm / etc to) unix processes; but as shown on htop, unix processes are not aware of windows ones; nor have I found any ways to send signals backwards
* API compatibility is excellent. Last 2 days, I have re-compiled a full python & elasticsearch & mysql stack into this. Overhead is significantly lower, than any of the virtualization stacks
* I don't use AV tools; however, I suspect they don't check for ELF files. Host system is mounted in /mnt/c , /mnt/d ,etc in LXSS, with current-windows-user creds
* 2-command Sandbox reset: lxrun /uninstall & lxrun /install <- will restore the linux subsystem to factory default
* LXSS root dir (/usr /var, etc) is in c:\Users\$username$\AppData\Local\lxss\rootfs\ ; home is mounted into c:\Users\$username$\AppData\Local\lxss\home\$username$\
And some caveats:
* Filewatching (specifically, inotify_add_watch ) does not (yet) work
* Manipulating files from the host occasionally makes it _disappear_ (??!) from visibility in the linux subsystem. Specifically, git pull from bash, then git update from host makes git update from bash impossible (index file open failed). Same problems with other types of host file-manipulation. This might be due to permissions, or somethings I haven't figured out yet.