4

On a 16-bit system with at most 64K of RAM available for a user program, one would think of having an executable overlay mechanism as an indispensable tool to maximize the amount of memory available for data. For example, the 2.11 BSD a.out format has a provision for overlays:

     #define  NOVL      15        /* number of overlays */
     struct   ovlhdr {
          int       max_ovl;      /* maximum overlay size */
          unsigned int  ov_siz[NOVL]; /* size of i'th overlay */
     };

     struct   xexec {
          struct exec e;
          struct ovlhdr o;
     };

     #define  A_MAGIC1      0407      /* normal */
     #define  A_MAGIC2      0410      /* read-only text */
     #define  A_MAGIC3      0411      /* separated I&D */
     #define  A_MAGIC4      0405      /* overlay */
     #define  A_MAGIC5      0430      /* auto-overlay (nonseparate) */
     #define  A_MAGIC6      0431      /* auto-overlay (separate) */

That looks quite late (the first BSD UNIX release was in 1978); so the question is, what was the chronologically first release of a UN*X for a computer with the PDP-11 instruction set with support for overlays at any level (an overlay linker + runtime library to load overlays would be sufficient)?

[rhetorical] If it was not from AT&T, what were they thinking? [/rhetorical]

Improve this question

1 Answer 1

Reset to default
3

Doing a search on The UNIX Historical Society for 'overlay', the earliest reference I could find was on 2.9BSD. There seemed to be a system call designed specifically to support overlays.

No doubt the life span was limited, as Virtual Memory pretty much eliminated any need for overlays.

Improve this answer
10
  • I'm surprised that people were using UNIX on 16-bit machines without overlays for about 10 years.
    – Leo B.
    Jan 12, 2022 at 0:32
  • @LeoB. - they had processes. An early Bell System Technical Journal (that unfortunately I can't put my finger on right now) described an audio processing system - a very early voice response system I think? - that was specifically multi-process due to address space issues, and that wasn't the only such system described in various BSTJs. There were plenty of IPC methods to use. (IMO, multiprocessing w/IPC would have been safer and easier than working with overlays, so why would they have wanted support for overlays?)
    – davidbak
    Jan 12, 2022 at 0:55
  • 1
    @LeoB. - and overlays don't have I/O overhead of their own? There are always tradeoffs. Unix programming emphasized processes as the tool for the job and that was the way developers - including the system builders - looked at it at the time. Other systems had other tradeoffs. And, yes, Unix was not oriented to scientific computing, it was oriented to business computing (in the context of telephone company back end systems). Overlays were used for systems that didn't make processes trivial to create/use/communicate between. I've used overlays, I know what they're for.
    – davidbak
    Jan 12, 2022 at 4:04
  • 1
    For example, overlays were BIG on IBM 360 operating systems - business oriented! - because their OSs programming models, though it included what we would call "processes" today because of their address space and control flow isolation from other things, was largely batch oriented based on single jobs (or multiple jobs communicating strictly through files - disk or tape). There processes == tasks == jobs were expensive beasts and you didn't have processes/tasks/jobs talking with each other simultaneously. So, overlays stretched your programming space.
    – davidbak
    Jan 12, 2022 at 4:06
  • 1
    It appears that a reason to add the overlay capability to the linker was the need to have an overlaid kernel: bsdimp.blogspot.com/2020/07/…
    – Leo B.
    Jan 12, 2022 at 18:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .