When Windows Versions?

[SPIRY-RO]

When Windows version?

So far I saw it seems lighting is very Unix dependable. Which seems like an extreme flaw. Now with this update I hoped that this issue would have been taken with great attention in order to real increase the adoption of Lighting.

https://upload.wikimedia.org/wikipedia/commons/4/41/StatCounter-os_combined-ww-monthly-201704-201704-map.png

This statistic should been taken in consideration when developing any software for mass usage specially for financial markets.

https://en.wikipedia.org/wiki/Usage_share_of_operating_systems

So again. Please Windows support?

[ZmnSCPxj]

Relevant: https://lackingrhoticity.blogspot.com/2015/05/passing-fds-handles-between-processes.html

C-lightning passes file descriptors around like candy using Unix-domain sockets to transport them, we need to generalize this to Windows (which requires a separate call in the sender to map it on the recipient handle table before sending, whereas Unix does the remapping automatically).

C-lightning uses sockets to communicate between processes, we need to either switch to internal Windows message passing or use AF_INET loopback with some shared secrets to emulate transport (i.e. the Cygwin technique, which is less efficient than Windows message passing).

Edit: also relevant: https://docs.microsoft.com/en-us/windows/desktop/api/winsock2/nf-winsock2-wsaduplicatesocketa

[NicolasDorier]

Never tested it, but windows might have implemented linux socket https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/

[ZmnSCPxj]

@NicolasDorier From your linked article:

Ancillary data: Linux‘s unix socket implementation supports passing ancillary data such as passing file descriptors (SCM_RIGHTS) or credentials (SCM_CREDENTIALS) over the socket. There is no support for ancillary data in the Windows unix socket implementation.

Typically we pass around socket file descriptors from the connectd to the lightningd and then to the "real" channel-level daemon openingd channeld closingd. The linked article seems to show we still cannot do this "seamlessly" even with the new AF_UNIX on Windows.

It looks like we need to write our own wrapper around sockets and processes (i.e. even pipecmd has to be rewritten!) in order to get running on Windows.

Or alternately, wait for Windows to port themselves to a *nix derivative....

[ZmnSCPxj]

Relevant as well: https://stackoverflow.com/questions/4778043/winsock-not-supporting-read-write

Like all sensible Unix daemons we use read / write on sockets, because you only really need send/recv if you are doing magic things like sending OOB data or overoptimizing your stream connection by hacking the underlying packet layer, and because "everything is a file descriptor". But on Windows you need send/recv, because it is not a *nix derivative like all sensible operating systems are. Cygwin use helps wrap this a little though.