The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Paul Winalski <paul.winalski@gmail.com>
To: segaloco <segaloco@protonmail.com>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: [TUHS] Re: Origins of the SGS (System Generation Software) and COFF (Common Object File Format)
Date: Thu, 23 Feb 2023 15:40:30 -0500	[thread overview]
Message-ID: <CABH=_VT4XzQYGpV_bkqS7Rq2HHz6SCcLZmSWfOYKkQG2yp3Uug@mail.gmail.com> (raw)
In-Reply-To: <x7rmoMB4lj5jA0FSHksytL-PJPBoEEhviD1DBBMF3pNGyT99QI1CZNF5eGVx5Y8SJ_70fSnVIM7iQSLUApXub7JXxT__oLR_jSF8hCeJFzg=@protonmail.com>

One property of a.out is that the format of an executable image is
identical to that of an object file.  One could write an assembly
program that was self-contained and did not need to be linked to any
other modules, run that through as(1).  The resulting a.out file would
be executable.  No need to involve ld(1).

MACH-O retained this concept of supporting self-contained object files
as executables.  COFF departed from that tradition.  A COFF (or
PECOFF) executable requires a data structure in the file called the
optional header that contains important instructions to the program
loader.  This second header is "optional" only in the sense that
non-executable object files do not have one.  The optional header is
created by ld(1).  I'm almost certain that versions of as(1) that
generate COFF output do not generate an optional header.

In ELF, executable images have several sections such as the program
header table section that contain the information present in COFF's
optional header.

Traditionally, operating systems such as IBM's OS for System/360/370/Z
and DEC's VMS have very different formats for object files and
executable programs.  OpenVMS for Itanium and x86-64 use ELF for both
objects and executables--a departure from the practice used on VAX and
Alpha.

-Paul W.

  reply	other threads:[~2023-02-23 20:40 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-22 20:16 [TUHS] " segaloco via TUHS
2023-02-22 22:20 ` [TUHS] " Clem Cole
2023-02-23  0:17   ` segaloco via TUHS
2023-02-23  6:30   ` Lars Brinkhoff
2023-02-23 14:25     ` KenUnix
2023-02-23 19:37     ` Warner Losh
2023-02-24 17:01       ` Rich Salz
2023-02-23 16:49   ` Paul Winalski
2023-02-23 18:38     ` segaloco via TUHS
2023-02-23 20:40       ` Paul Winalski [this message]
2023-02-24 12:45     ` arnold
2023-02-24 13:13       ` Arno Griffioen via TUHS
2023-02-25 19:28         ` arnold
2023-02-25 19:34           ` Steffen Nurpmeso
2023-02-24 14:01       ` Harald Arnesen
2023-02-25  2:07     ` Dave Horsfall
2023-02-25 15:30       ` Clem Cole
2023-02-25 17:29         ` Paul Winalski
2023-02-23 15:13 Noel Chiappa
2023-02-23 21:37 Paul Ruizendaal
2023-02-23 22:11 ` segaloco via TUHS
2023-02-24  0:07   ` segaloco via TUHS
2023-02-25 20:14 Brian Walden
2023-02-26 15:51 Paul Winalski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABH=_VT4XzQYGpV_bkqS7Rq2HHz6SCcLZmSWfOYKkQG2yp3Uug@mail.gmail.com' \
    --to=paul.winalski@gmail.com \
    --cc=segaloco@protonmail.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).