I don't really think so. They're OSs that, when they added support for x86-64 CPUs, all opted to use the externally-defined ELF executable file format with the x86-64-sysv ABI. Note also that the architecture/ABI already includes a dedicated `syscall` assembly instruction.

On top of that, 3 of the OSs (FreeBSD, NetBSD, OpenBSD) share a common source code ancestry, meaning that the oldest and most fundamental Unix system calls (like `write(2)`) had an excellent chance of remaining compatible.

Yes, calling write(2) on Linux is different, but only in the syscall number. That's also not a coincidence, as the behaviour of write() is highly constrained by POSIX which Linux and the BSDs both adhere to, and the way to pass parameters to the call is specified by the `syscall` instruction.

That there are enough differences in the environment to be able to figure out which of Linux or *BSD the program is running on is a bit of luck, but probably not that much.

Clever and carefully researched, yes, but by coincidence, no.

Pure coincidence, perhaps not (see the other comments on this thread), but this did come across a few times as being a hack.

For instance, on the OS ABI field in ELF headers:

> Fortunately we can get around this by just setting it to the FreeBSD ABI. This is because FreeBSD is the only UNIX operating system that checks this field.

Or on loading a zero-byte segment into memory:

> However if the size in memory is zero too, then OpenBSD will refuse to run the progarm, whereas the other kernels just don't care.

I think you could indeed call it a coincidence because it's exploiting behaviors that are not really a proper ABI, just emergent behavior based on implementation details.

Someone working on the various operating systems could change those behaviors without knowing that they're breaking this thing. And they wouldn't necessarily be in the wrong to do so. Because it's not really an ABI.

There is always a certain amount of luck in successful runtime feature/platform detection when the system doesn’t provide an explicit mechanism for it. I would not call it a coincidence though. It would be rare for the systems to be different enough to require customization but also impossible to differentiate between at runtime.

I may be totally wrong here but perhaps this looks like it might be coincidental if one doesn't know many truly different OSes.

The modern OS space is dominated by 3 big OSes, and a bunch of smaller relatives, that are basically siblings. They share a huge amount of ancestry.

Whereas there are many, many others that are vastly unlike them in almost every way.

What you see as coincidence reflects the fact that these OSes are closely related.

The 3 big OSes now are Windows NT, macOS and Linux. The close relatives I mentioned are the BSDs, and then relative to them very slightly further away, Minix 3, QNX, and then things like GNU HURD, (Open)Solaris, other Unixes, etc.

All implemented mainly in C, all descendants of or inspired by one of just 2 OSes for just 2 DEC minicomputers.

Unix and all Unixes from a DEC PDP-7 OS, that became a lot more like modern Unix when ported to the PDP-11.

All Windows this century is Windows NT. The other forms (Win9x, WinCE etc.) are dead.

All NT is related to VMS, a DEC VAX OS, where the VAX is a 32-bit PDP-11.

They are all siblings.

Some OSes with the same conceptual model (disks, partitions, files, binaries, users, etc.) that are totally different:

* RISC OS.

* Classic MacOS

* AmigaOS (and MorphOS, AROS etc.)

None of these have replaceable "shells". None use file extensions. None have any trace of 8.3 filenames.

Others, like the large family that sprung from CP/M, including Concurrent CP/M, Atari TOS/GEM, etc. are broadly similar because they also came from DEC PDP OSes, but different ones, and were not originally implemented in C or anything because their shared rootstock is contemporaneous with the invention of C.

There are many many OSes that are almost nothing like even this basic model of "disks" with "filesystems" and "source code" that is compiled to "binaries" that are CPU-native and governed by "configuration files" that are probably "plain text".

Symbolics Genera and OpenGenera. IBM OS/400, now called IBM i. Taos and its successors Intent and Elate. Novell Netware, in some ways. Arguably, Inferno, the last of the Unix line.

You're looking at a cluster of closely-related OSes for a single CPU platform and saying hey, one binary can work on all of them, what a coincidence.

In fact, this very clever and ingenious hack is _because they are close relatives_.

You are pointing at a dog, a cat, a lizard, a cow, and a frog and saying "hey, look, what a coincidence: they all have 4 legs and 2 eyes and 1 mouth!"

No, it's because they are all relatives. They're all tetrapods.

But there are also insects and spiders and crustaceans and worms and comb jellies and starfish. All basically unrelated except they're all animals.

(I was going to include jellyfish, but looked at this way, jellyfish and corals and sea anemones are all related: they're all coelenterates.)

I mean, it's OK if the only animals you're familiar with are 4-legged vertebrates, but you should at least be aware that there is, literally and exactly, more to life. I mean, you've seen flies and cockroaches and things, haven't you?