In article <199802210515.AAA14468@papaya.CES.CWRU.Edu> you write:
> doesn't? Are you saying that the kernel pulls in only the executable
> itself, and the code to pull in the shared libs is inside it (put in there
> by the toolchain at build time)? I have never thought of this approach...

That's basically it.

> If this were true, it would very easy to explain why the hp300 and sparc
> ports of 4.4BSD can run native HP-UX and SunOS binaries which require
> shared libs, even though Berkeley UNIX(R) apparently has never used them
> itself (and sure enough, 4.4BSD's toolchain cannot generate them).

Bad reasoning.  The COMPAT code _could_ always emulate the necessary
kernel kludges of those OSes even while not supporting shared libraries
itself.  It just so happens that it doesn't in the SunOS case (I don't
know about HPUX).  In the COMPAT_LINUX case, code to emulate kernel
involvement in shared libraries _is_ included, because that's how Linux
shared a.out binaries work.

>    [A side note.] I know for sure that 4.4BSD doesn't use shared libs, and
> I have always thought that 4.3BSD is no different. However, the total size
> of all system binaries increases by a factor of 3 between 4.3BSD-Tahoe and
> 4.4BSD (dunno about Reno and Net/2). This change is so drastic that I have
> a hard time explaining it without the theory that 4.3BSD did use shared
> libs after all. The toolchain has changed almost completely between 4.3BSD-

Perhaps it's due to a switch from [ON]MAGIC to ZMAGIC as the default
executable format?

>    Ty Sarna <tsarna@endicor.com> wrote:
> > Which kludge would this be...  that evil, new-fangled mmap() system call?
>    
>    Could you enlighten me on what that is?

Wow... how can you hate modern BSD and yet know so little about it (or
maybe I've just answered my own question).

mmap() maps files or devices into memory. See "man mmap" on 4.4BSD,
NetBSD, SunOS, Solaris, or just about any recent UNIX.

mmap() is the foundation of SunOS-style (which is the NetBSD style)
shared libraries. It's also incredibly useful for all sorts of things.
I'd go so far as to say it's the most important system call added to
UNIX since the introduction of networking, and it's had a radical effect
on the way people write UNIX software. So, I'm sure you'll hate it.

> > /dev/zero?

It's sort of like /dev/null, but read as an endless stream of zero
bytes, instead of immediate EOF.  On SunOS it was used with COW to
allocate address space backed by swap.  On 4.4BSD type systems, MAP_ANON
is used instead, but /dev/zero still exists (it still has other uses,
like making NFS swapfiles, as a "don't care" input to dd(1), etc).