There’s always been a weird double standard in open source software where it has been seen as ‘reasonable’ to expect the same code to compile and work on everything from an Arduino to an IBM mainframe, PDP11 to a RISC-V.
..But getting it to work on Windows? What? Do you expect the developers to fork out for Windows licenses? Don’t be ridiculous. Heck, some software is still downright snooty about the absurd idea that it should run cleanly on a Mac.
What's always seemed weird about that, to me, is that I've never been surprised when some lone hacker — who is not the developer of the tool in question — volunteers to use the PA-RISC machine they have access to make something work in that environment. Contrast that with the Windows world, where maybe two thirds of all developers that exist on the planet use Windows, somehow they still can't find one bloke who'll do the same work there. How can the Windows world be so rich with talented professionals but still never seem to find one who'll contribute a patch.
“Why will nobody from the Windows community contribute to our software? Is it because I said that my baseline assumption is that they’re all incompetent?”
I know plenty of extremely competent software developers that are Windows users but, it seems, they use different software. The intersection I found was people inclined to help who are forced by corporate powers to use Windows on environments where WSL doesn’t work well (I’m one of those).
If the software is written in ways that deeply embed assumptions of POSIX-derived concepts then it’s not just popping in a few extra #ifdef WINDOWS blocks.
Most software shouldn’t be looking to the OS that closely anyway and anything that has to interact closely with the platform in non-portable ways should be, in an ideal world, separated into its own library so it never needs to be ported to anything other than the platform it calls home.
Playing devil's advocate: since the operating system mostly abstracts the underlying hardware, when programming with a high-level language, an IBM mainframe running Linux and a MIPS router running Linux are both closer to an AMD64 desktop running Linux than the same AMD64 desktop running Windows. And Windows is a particularly annoying case, since its native API is so different from the Linux native API (and details leak even when using API wrappers, for instance removing a recently-created file can fail on Windows because some other process like an antivirus grabbed a handle to it).
But yes, I agree that a nontrivial fraction of the objections to making software run on Windows (or Mac) is for ideological reasons.
Everyone is welcome to report issues in my projects. I'm allowed to pick which ones I work on. I use Linux, so issues reproducible on Linux have priority. RISC-V sounds fun, I'd probably took a look if I could reproduce the issue with qemu. I don't find Windows fun, and I doubt I would fix any Windows-speficic issue myself (unless it's something trivial, like newline handling).
Pull requests are a different beast, Windows-users are always welcome to fix the issues they face and submit their improvements back.
Obviously I get that something that is written in ‘portable C’ for Linux-flavored POSIX plus GNU tools is going to be harder to get working on Windows than on m68k Linux. That’s not in dispute.
It’s more the way that people act like targeting Linux-flavored POSIX with ‘portable C’ both A) is the be-all and end-all of portability and B) entitles people who have got Linux-flavored POSIX environments and C tool chains up and running in arbitrarily weird contexts to full support.
There are other environments. Some of them are very widely used. Acting bemused by the idea someone would want to run your software in somewhere other than a Linux context, while being unsurprised that people want to take that Linux context and run it in arbitrarily weird ways is the double standard I am confused by.
Obviously it’s not universal - there are plenty of open source projects that take different paths and philosophies towards portability - think of Python, say, or Firefox.
But there is a persistent attitude that because Linux can run ‘anywhere’, supporting Linux is portability.
To be fair, software written against Unix-flavored POSIX runs on almost every commercially supported operating system out there, from Linux and QNX, macOS and all the way to z/OS, which is a certified UNIX operating system (incredibly).
The only significantly used OS that’s not there is Windows. Also, IBMi, Unisys’s MCP and Atos’s GCOS and GECOS (surprisingly still supported). And OpenVMS too.
“Why are you complaining that you can’t use this software on Windows? It’s portable - You can run it on a zMachine! Heck, it even runs on BSDs”
Windows is not some obscure platform nobody uses. Wanting to run software on it is reasonable.
And I feel I should point out I am saying this as a lifelong Mac user, not a Microsoft shill. Parts of the Linux-centric community’s blind obstinate insistence that Windows just isn’t relevant because it’s non-POSIX just looks petulant.
> Windows is not some obscure platform nobody uses. Wanting to run software on it is reasonable.
If the maintainers don’t use Windows, it’s kind of not really their problem. If the user wants to use Windows and wants the software to run on Windows (and not under WSL), then they can fix it. Patches are usually welcome.
On the Mac side, it’s kind of in a sweet spot: the GUI is good, lots of excellent software for it, AND it’s a good Unix. When working on a Mac, I very rarely need to resort to a virtual Linux environment the way I do on Windows.
Microsoft has too many billions of dollars to count. Maybe they should be the ones to be held accountable for upholding community standards, not the free volunteers.
..But getting it to work on Windows? What? Do you expect the developers to fork out for Windows licenses? Don’t be ridiculous. Heck, some software is still downright snooty about the absurd idea that it should run cleanly on a Mac.