[TUHS] Is there a good, even definitive, list of reimplementations of the Unix kernel? What would good cut-off criteria be?

Paul Winalski via TUHS tuhs at tuhs.org
Mon Apr 20 02:08:17 AEST 2026


On Sun, Apr 19, 2026 at 11:47 AM John Cowan <cowan at ccil.org> wrote:

> On Sun, Apr 19, 2026 at 11:25 AM Paul Winalski <paul.winalski at gmail.com>
> wrote:
>
>
> PECOFF is a classic case of Microsoft's adopt-then-extend philosophy.
>
> To be fair, COFF was a rather inflexible format, though not so much as
> a.out.  Pretty much every OS that ran on MIPS used ECOFF, and AIX used
> XCOFF, both of which were extensions of COFF made even before MS made
> its own variant.
>
> That's true.  On second thought the adopt-and-extend comment is too harsh.

Coming from the IBM and VAX/VMS worlds I never understood the rationale
behind Unix using a.out for both object files and executables.  It's fine
as an executable format but it forces the creator of object files to frame
their module as though it could be executed directly.   Programs that don't
need to be linked to other modules are very rare.  Even simple things like
"Hello World" need to be linked to the C RTL.  The traditional Unix model
for compilers is that the compiler emits assembly code (.s file) and then
the assembler is invoked to build the a.out.  Thus, only one program (as)
is lumbered with framing an object module as though it could be directly
executed.  But as one who has had to write code to do direct object
generation from a compiler, framing an object module as an a.out file is a
pain in the butt.

COFF is a single file format that supports both object files and
executables, but in reality it's two separate file formats (object file and
executable) mushed together.  There are parts of COFF used only in object
files and other parts only used by executable images.  There are some
things, such as the symbol table, that are common to both objects and
exeuctables.  Ditto with ELF.  Mach-O unfortunately retained the idea of
object files needing to be cast in a form as though they were directly
executable.

-Paul W.


More information about the TUHS mailing list