Comment by skissane

If Microsoft wanted to invest more in Windows, I think the most useful thing would be to add more POSIX/Linux APIs and semantics to the Win32 API, to make it easier to port Linux software to being native Win32 apps… look at what Cygwin does, and identify the pain points (e.g. fork, exec without changing PID), and implement them in Win32 so Cygwin can be a thinner layer.. e.g. the NT kernel itself actually does have the moral equivalent of fork(), but Cygwin can’t use it because the Win32 subsystem (CSRSS.EXE) isn’t fork-aware, so instead Cygwin has to resort to highly complex and slow hacks instead… well, why not just make Win32 fork-safe? Of course, probably making every DLL and COM object fork-safe is way too much work (even on Linux, not all shared libraries are), but they could expose a way to “taint” a process as unforkable if any of those components get activated in it… maybe they could make Cygwin such a thin layer it becomes unnecessary, what if UCRT gave you equivalent functionality and all you had to do was ‘#define POSIX’?

I think that would be far more useful in practice than trying to close the gap between WSL1 and WSL2, which is what I’d interpret your “implement Linux” proposal as meaning

As far as trying to emulate Darwin goes, I think relatively few would be interested in running macOS apps on Windows, and I wonder whether there is a risk Apple might sue

I wonder if AI coding agents are going to improve to the point that they might radically change the incentives here - if adding new features becomes a lot cheaper, maybe the cost-benefit analysis will shift towards implementing more of this stuff