In a discussion on backwards-compatibility in Linux kernel and GUI ABIs, Alan Cox notes that "my 3.6rc kernel will still run a Rogue binary built in 1992. X is back compatible to apps far older than Linux."
So just how backwards-compatible are the Linux Application binary interfaces?
What is the oldest binary executable, actually written and compiled years ago, that will still run on a modern stock general-purpose Linux distribution?
I'm sure all those words are subject to interpretation. My main notion is that it is not fair to run it via an emulator or specialized virtual machine or binary translator, but some such things are probably built into some modern distros, and learning about that is part of the fun here.
Variations by hardware architecture, executable file format, language, and major library dynamic loading dependencies are also of interest.
Note, when the rules are relaxed, here's one example of going further back. The 2002 web page Running a.out executables on modern Red Hat Linux talks about using really old Linux pre-ELF a.out-format executables after doing
modprobe binfmt_aout and obtaining
libc.so.4 Again that's of peripheral interest for this question, but illustrates the sorts of things that can be involved when digging further back.
Update for you BSD fans, it's great to see that iBCS2 was supporting old Xenix apps (like zork/dungeon-2.5.6 from 1990) and SCO OpenServer 5.0.x apps as recently as NetBSD 4.0.1 (from 2008): iBCS2 & NetBSD | Fun with virtualization. But the same thing seems broken in NetBSD 5.0.x.
Update 2: One year later, after even getting an "Announcer" badge for this question, I'm still looking for an answer. And to clarify, since this is about APIs, it should be a "real" binary (non-zero length), that still at least mostly works in the original way.