As for fork: believe me, I'd be happy if, as as side effect of this work, more applications used posix_spawn. But Cygwin can also support an efficient posix_spawn implementation: https://github.com/dcolascione/cygspawn
A lot of the complexity actually comes from mapping POSIX filesystem semantics to Unix ones. stat(2) in Cygwin is ungodly expensive for this reason. Your layer won't be able to avoid this work without providing fewer features.
https://twitter.com/RichFelker/status/602313644026761216
There are still plenty of applications that use fork semantically, to keep the same process image in the child, which benefit somewhat from a fast fork. But most places where fork affects performance now are things that are already pessimized by using fork+exec instead of posix_spawn: the shell, make, cgi, etc. (GCC still uses vfork, but GNU make recently switched from vfork to fork because of vfork-related bugs.) Regardless of how fast or slow fork is on midipix (but I expect it to be fairly fast, much faster than cygwin), they would benefit a lot more from just switching to using posix_spawn.
how about this one?
fopen + mmap + unlink
Afaik windows APIs forbid deleting mmaped files.
open rw, set length, mmap from two 2 processes to have shared memory, unlink & close.
expected behavior is to have a chunk of shared memory without the tempfile in the directory tree
For one or the other reason, fork() has become in many discussion of posix on windows something of a fetish. The interface surely has its place, and figuring out how to efficiently implement it took a huge amount of effort, yet the vast majority of applications do not truly need it. Matter of the fact is that even on linux, where fork(2) is natively supported, the sequence fork+execve is more costly than clone+execve (where clone's flags are CLONE_VM && !CLONE_THREAD). For additional reference, see for instance the implementation of posix_spawn in musl libc (http://git.musl-libc.org/cgit/musl/tree/src/process/posix_sp...).
If high performance of the posix layer were not possible the project would have not existed. Among the factors that make high performance possible are 1) direct use of kernel interfaces (aka the Native API, where most of the runtime layer is written as a user-space driver), 2) utf-8 as the primary supported multibyte encoding as a foundational concept rather than an afterthought, and 3) tls implementation that matches in speed the native tls facility.