Kamp: A Generation Lost in the Bazaar

Windows' POSIX support is circa 1988. What I mean, for example, is that Windows API designs tend to leverage threads and callbacks, while Unix uses readiness notification through file descriptors. There are big differences between those two paradigms, and bridging them requires a lot of bug prone boilerplate code.

That's just one example. I18N and L10N is another. The list goes on-and-on.

The best way for an application to simultaneously support Unix and Windows is to not support it for those components which heavily rely on system-specific features. That particularly applies to GUI software.

The problem is that people try to design highly detailed, portable interfaces, when instead of thinking about small details they should think big. That is, break out huge chunks of the application and develop them in parallel, but separately. Trying to write them "portably" as one cohesive whole is foolhardy.

Same logic applies to the build environment. Trying to write or find the "one build system to rule them all" is a fool's errand. You can do better than autotools or CMake by simply not trying to accomplish what those two tools ultimately fail to do. Not developing the Windows portion of a GUI application completely in Visual Studio is just asking for endless and unnecessary headaches.

Point being, if you don't mix portable and non-portable code, you don't really need a complex, "portable" build solution.

People don't use WIndows SUA because it's not installed by default. The purpose of writing Windows software is, presumably, so other Windows users can run it, not only so other people with SUA can run it.

Windows is presumably dropping their ancient POSIX support for the same reason they've never supported newer C versions and perhaps for the same reason their commitment to C# was so short lived--because their management team doesn't really care about anything other than the old Win32 API which keeps vendors locked in to the platform.

Supporting POSIX or C isn't going to draw people to the platform, it'll just make everybody else's life easier. Attempt to support newer C++ features is what will help draw and keep developers, as will their typical overhyped promises about an SDK/API revolution in the next Windows product.

You seem to have only the vaguest idea what was going on with NT and personalities, so I guess it might help to fix some of that before we get to the "Why" part

- There is no real "NT userland". The NT-specific stuff all lives below the personalities, and is thus accessible from all of them. Unlike a Unix Microsoft does not officially document and support the system call interface to their kernel.
- Win32 originates in Windows NT (although obviously the design owes plenty to Win16) and was present as a personality essentially from the platform début. This is the "native" personality of NT operating systems, and the one with access to all the nice toys invented in the last 25 years.
- The original POSIX and OS/2 subsystems date to the early 1990s too.

You're correct that POSIX is present because it was felt to be advantageous in contract negotiations. You would be wrong if you imagined that Microsoft intended /anyone/ to use this interface. It's drastically hobbled, implementing only a bare minimum of POSIX features and serving to demonstrate (as someone has commented above) that POSIX is "useless" because it doesn't specify enough to build much real software. BSD sockets, for example, are not a mandatory POSIX feature, and thus Microsoft omits them. Likewise X is not present, nor is any alternative Unix-like windowing system.

The OS/2 personality is there for the same reason. It's a checkbox item. Can this all-singing all-dancing NT run our old OS/2 software? Yes says the salesman. Then the NT stuff is installed, the OS/2 app doesn't work, and Microsoft explains that oops, that's using an unsupported API but hey, one of the many Windows ISVs will be happy to offer you an alternative that does run on NT.

Services For Unix isn't an evolution of the POSIX personality. It's Microsoft reluctantly accepting the reality that people wanted to actually _run_ Linux software (hence all the GNU utilities) on their expensive NT systems and that all too often now the IT management is present when the salesman makes his pitch and will laugh uncontrollably if the POSIX personality is mentioned. They needed a new pig, as my old CEO would say. So they bought Interix (which is what customers who desperately needed this stuff to actually work had been using instead of the POSIX personality) and renamed it SFU (I'm surprised they couldn't find an excuse to insert a 'T' in that abbreviation) but of course they've essentially allowed it to stagnate so that it's becoming irrelevant again.

It's a mistake to imagine that NT's innards resemble those of a Unix at all. It's similarly _capable_ but that's all. Roughly everything you can do on Linux from a certain era you can also do on NT from that era. But the /way/ you do them is very different. There is a different philosophy at work in the Microsoft kernel team than in Linus' project.

Today the Microsoft salesman will deflect questions about cross platform compatibility by suggesting that you can run all your "legacy" (ie non-Microsoft) software in a virtual machine. If you're dumb enough to fall for that, you deserve everything you will get.