Well, yeah. I sympathize with @bagder here trying to be cross-platform but Windows is just Different than POSIX, and if you try to write everything for Linux then "compatibility shim" your way to Windows support, you're gonna have a Bad Time
[0]https://daniel.haxx.se/blog/wp-content/uploads/2022/11/curl-...
Edit: And there are at least 4 Windows flavours in the list!
There are probably more there. I recognize about half of those names only.
Are you really saying that it's normal to be harder to port some software into Windows than into z/OS?
No, I'm saying that from 89 OSes mentioned on that picture, a lot of them are better at being *nix because they are *nix.
But answering your question, sure! The only good thing in POSIX is that you have easy access to a lot of *nix software. Other than that, POSIX is a spectacularly bad API.
Windows doesn't really care about running *nix software natively, because most of Windows userbase just want and use different things. Therefore, why invest into a bad API? For those wanting to use *nix software on Windows, there is Cygwin or WSL anyway.
How many of them are supported in mainline Curl, aren't POSIX and aren't dead operating systems?
What is a dead operating system anyway, and how is that relevant to the point that Windows is the hardest OS to maintain support for?
* See for instance the config-*.h files in https://github.com/curl/curl/tree/1c567f797bce0befce109bceac...
No longer maintained / barely changing, like MS-DOS, Mac OS 9, Amiga OS (which does occasionally get an update but usually not much in the way of core changes)
It's relevant because Windows is a moving target and the dead operating systems aren't so there's not a lot of support work needed for them nor will there be as much of a user base.
I see Windows, Windows CE, XBox and even MS-DOS on that list.
Mac OS 9
DR DOS
OS/2
VMS
Windows CE
z/OS
MorphOS
Atari FreeMiNT
OS/400
[...]
Actually probably a fourth (EDIT: after looking more closely, make that ~half) or so of the list are not in any way UNIX.
Another comment here mentions NT being full of all sorts of quirks. Such sentiments ignore all sorts of quirks with Linux. For some reason, they're ignored or forgot about because people like digging into the internals of esoteric design choices of Unix tools and the Linux OS.
I find myself fairly OS agnostic having spent about equal times on macOS and Windows and a little less on Linux other than as a programming target. In my experience, Windows is the best these days to work on because I get both Linux and Windows on one machine and OS. macOS and Linux all by itself are too much of a compromise as a Linux and as a desktop OS, respectively, for me.
I am currently working on a cross-platform windowing tool with GLFW. Linux and macOS are by far the problem children because of strange limitations in Cocoa/macOS and because Linux has no "built-in" windowing solution.
> If it's written for linux it can be made to work well with BSD and Mac.
Maybe that's true in a theoretical sense, but it has not been my practical experience with macOS. Too many times have I found I needed a plethora of workarounds on macOS only for the same thing to work flawlessly on Ubuntu.
It doesn't matter WHY, but it is.
A lot of issues disappeared when better abstractions were found on top of POSIX.
If anything, it's even more problematic, because Windows is "wierd" and people go out of their way to create special approaches to handle it. For macOS, too many developers think it's "just posix, ya know, like Linux" and then walk into horrible compatibility edge cases.
AFAIK, only the versions of Windows that included the POSIX subsystem were certified, the last one being NT 4.0. Long time ago.
That's a weird and derogatory way to talk about people who appreciate having a standard which makes it easier to write cross-platform software.
EDIT: To expand on this comment and make it more productive. You're right. If the goal is to have first-class support for both Windows and POSIX-like platforms, the right approach is to have an understanding of what your software needs to do, what the POSIX APIs make easy, and what the Windows APIs make easy, and build abstractions which make sense based on that. But man, do I appreciate that if first-class Windows support isn't top priority, I can support essentially every other widely used platform in the world (including macOS) by just writing against the POSIX API, and I can even get okay-ish Windows support by using a POSIX compatibility layer on Windows. So my point isn't, "People who want to have first-class Windows support but do so through POSIX compatibility shims are doing it right".
It was first known as DEC OSF/1, then Digital UNIX, then Tru64.
Previous to OSF/1, DEC had sold Ultrix, first on VAX, then on MIPS.
https://en.wikipedia.org/wiki/Tru64_UNIX
The wiki says that OSF/1 was first released for MIPS, but that was before my time, and it wasn't supported for long.
I did use Ultrix on MIPS DECStations in college.
When I say "POSIX fanbois" I mean "fanboys" (people that are unreasonably attached to this standard and try to use it everywhere without being level-headed about its usefulness). That probably doesn't include the people who actually wrote the standard, which are all (in my experience) pretty reasonable and realistic about the limitations of things they've created.
This is certainly a better way to put it!
But it's possible that they indeed mostly had the POSIX standard in mind when trying to create their software, possibly because that's what they were developing on (e.g. one of the *nix distros or something compatible) and that's what was available easily.
Support for Windows might have been a bit of an afterthought, or something that was added later. It's still better than nothing, even if not always viable.