| 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).
(from: https://github.com/xilun/cbwin/ )
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.