[antics]

SUA was not half-baked, this is a very, very hard problem. There is a very serious difference in the way POSIX and Windows model a lot of really important OS primitives, from asynchronicity model in signals, to the semantics of syscalls like `fork`. Every process using these primitives on POSIX has specific behavior defined under those primitives, and if you don't choose _exactly_ the right behavior on the POSIX subsystem in Windows you will definitely break programs.

So, no. You can't "just" implement a POSIX subsystem correctly. These systems are just not compatible. It will always be half broken.

[lelandbatey]

Indeed. The Cygwin project has done an amazing job working to act as a compatibility layer between Windows and POSIX, but even Cygwin, with all the time and energy that's gone into it, still has some rough edges. Not to say that using it isn't awesome, but it's not perfect.

[teacup50]

Microsoft does control the kernel, and given that, none of this stuff is particularly complicated.

As for choosing "_exactly_ the right behavior" ... the whole point of POSIX is to clearly define the exact right behavior!

[dragonwriter]

Sure, its "easy" if Microsoft wants to redefine Windows in POSIX terms; iits not easy to keep Windows functioning as Windows and provide a POSIX compatibility layer, since Windows isn't designed around POSIX expectations.

[teacup50]

Do you actually have specifics, here? I'm happy to discuss things like how to model fork() in-kernel.

[pjmlp]

Which for everyone that has written code across UNIX systems knows it has quite some issues across systems that are supposed to share some kind of common architecture.

Even worse when the architecture is completely different.