This is only tangentially related, but libuv and mio's Windows implementations use the undocumented AFD readiness-based poll interface [1], since there isn't a documented readiness-based interface on Windows. The undocumented interface is now effectively stable since, among other reasons, Microsoft uses Tokio in some of its products.
libuv does all sorts of shenanigans, like using the undocumented fields in STARTUPINFOW the CRT uses to pass file descriptors to processes inheriting handles so that you can open whatever file descriptor you need in your children processes like in POSIX
But Microsoft kind of expects this crap and will support it until the end of time; Apple can't give a crap until and will readily break programs even when they use legal APIs
> Decoupling the User/Kernel boundary in Windows is a monumental task and highly non-trivial, however, we have been working hard to stabilize this boundary across all of Windows to provide our customers the flexibility to run down-level containers. Starting with Windows 11 and Windows Server 2022 we are enabling the ability to run process-isolated WS2022 containers on Windows 11 hosts.
[1] https://github.com/tokio-rs/mio/blob/master/src/sys/windows/...