Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!cs.titech!titccy.cc.titech!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.unix.internals
Subject: Re: Shared libraries are not necessary
Keywords: ISC i386 shared libraries
Message-ID: <228@titccy.cc.titech.ac.jp>
Date: 22 May 91 12:04:30 GMT
References: <202@titccy.cc.titech.ac.jp> <1991May17.075555.29787@Think.COM> <211@titccy.cc.titech.ac.jp> <1991May21.055103.25680@Think.COM>
Sender: news@titccy.cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 33

In article <1991May21.055103.25680@Think.COM> barmar@think.com writes:

>If the structure to be filled in were an in-out parameter, as we generally
>did in Multics, then the version number could be put there.  For library
>routines that allocate their output structure we would pass the expected
>version as a separate parameter.  The Multics calling sequence also
>includes the number of arguments, and often includes the argument types
>(whenever the function is "varargs" or any of the arguments has variable
>length), so a function could look at the number and types of arguments and
>infer the version of the caller.

That's overly complex. Such interface will increase code size considerably.

If you think you need shared libraries because your code size is important,
well, ...

>No, it's not easy to retrofit these calling conventions onto an established
>system. These problems are, in my opinion, a legacy of Unix's simplistic
>original design.

You reversed order in time.

Because it's not easy to retrofit simple calling conventions onto an
established system: Multics, UNIX was born (there are many other reasons
of course).

BTW, I don't mind what multics did. Many OS has done many wrong things or
right things in a wrong manner.

This is comp.unix.internals and what I have been saying is don't put
shared libraries into Unix.

						Masataka Ohta