Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!news.uu.net!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.internals Subject: Re: Shared libraries are not necessary Keywords: ISC i386 shared libraries Message-ID: <7972@auspex.auspex.com> Date: 22 May 91 18:05:29 GMT References: <202@titccy.cc.titech.ac.jp> <1991May17.075555.29787@Think.COM> <211@titccy.cc.titech.ac.jp> Organization: Auspex Systems, Santa Clara Lines: 131 >>There are two kinds of software upgrades: those which change the interface >>to the library, and those which only change the implementation. > >>Most of the common shared library designs only make the second kind simple. >>That's certainly better than nothing. > >And, my claim is that the second kind is almost nothing. > >Your (those who support shared libraries) example of DNS prove that. No, it proves no such thing. *ONE* example won't prove anything like that; you'd have to have a reasonably exhaustive list of changes of the two types listed, and that list would have to show that almost all the changes were of the first kind. Changes of the second kind include: 1) bug fixes to bugs in the implementation, rather than the specification, of a routine; 2) performance improvements that don't require specification changes; 3) functionality improvements that don't require specification changes (e.g., changing some lookup routine to check an indexed version of the file being checked, or a network database, such as changing "getpw{nam,uid}()" to use an "ndbm" database, 4.3BSD-style, or to use the NCS Registry or ONC NIS or Hesiod). And as for whether the DNS upgrade is of the first or second kind, read on.... >>I believe they also enhanced >>the /etc/hosts version of the routine to return multiple addresses (our >>/etc/hosts file has several host names with multiple addresses). > >You believe what? No. They didn't do so. No, what Berkeley did in 4.3BSD was: 1) change the specification of "gethost*()" so that, instead of them returning a structure containing, among other members, a "char *" pointing to a single network address, they returned a structure containing a "char **" pointing to the first member of an array of "char *"s pointing to network addresses, the array being terminated by a NULL pointer; 2) provided an "/etc/hosts"-based implementation of that specification that always returned a pointer to an array with one pointer to a network address, followed by a NULL pointer; 3) provided a DNS-based implementation of that specification that would return a pointer to an array with one or more pointers to network addresses; 4) modified at least some programs (e.g, "telnet" and "ftp") so that they would use elements of that array other than the first, if they were provided. Thus, you have two binary-compatible implementations of the same specification, and at least some programs capable of making use of the added capabilities of the second implementation. What Sun did in SunOS 4.0 was: 1) pick up Berkeley's change to the specification of "gethost*()"; 2) provide an "/etc/hosts"-or-NIS-based implementation of that specification that provided only one host address; 3) provided, after 4.0 came out, a version of "libc" that included a DNS-based implementation of that specification that, being based on the 4.3BSD implementation, presumably could provide more than one host address; 4) picked up, as I remember, at least some of the 4.3BSD modified versions of the programs in question, e.g. "telnet" and "ftp" - can anybody who's actually dropped in the DNS-based version of "libc", and tried to connect to a host with multiple addresses using any of those programs, verify that those programs will try more than just the first address? Thus, you have any program that uses "gethostbyname()" capable of picking up the first address for a host from the DNS simply by dropping in the new shared library; while it won't necessarily handle all the addresses, it will handle the first, which is better than nothing, and no worse than what you get with vanilla 4.3BSD. Those programs that are supplied, in 4.x, in a form that *does* know about multiple addresses - "telnet" and "ftp" might be among those programs - will be able to handle all the addresses that the DNS-based implementation gives them. >>In Multics, library design guidelines also make the first kind easy. Most >>library routines with non-trivial parameters take most of the parameters as >>a pointer to a structure. By convention, the first member of the structure >>is a version number or version string > >The only parameter for gethostbyname() is, trivially, a string. And so is the first parameter to "index()"/"strchr()". So what? He didn't say the first parameter was "a string", he said it was "a *VERSION* number or a *VERSION* string". If UNIX routines had followed a Multics-like convention, the first parameter to "gethostbyname()" would be a version number or version string, with the host name a later parameter; old programs that expect a 4.2BSD-like interface would pass in a version number of 1, and would have the returned structure contain a pointer to one host address, and new programs that expect a 4.3BSD-like interface would pass in a version number of 2, and would have the returned structure contain a pointer to an array of pointers to host addresses. This still wouldn't mean that programs - whether built for the 4.2BSD-style interface or the 4.3BSD-style interface - that don't know about the array would magically start using all the addresses they'd been provided, but they would still use the only (4.2BSD-style) or first (4.3BSD-style) address they were given, which, again, is no less than what you get with 4.3BSD. In this particular case, that version-number trick wouldn't have made a difference, as shared libraries weren't available prior to 4.0, so any programs expecting the 4.2BSD-style *binary* interface wouldn't be affected by the change to the interface. So what exactly *was* the point you were trying to make with that comment? Is it at all relevant to the discussion, or was it a random unrelated bit of information?