Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!uw-beaver!ubc-vision!alberta!bjorn
From: bjorn@alberta.UUCP
Newsgroups: comp.arch,comp.lang.c
Subject: Re: String Handling and run-time libraries
Message-ID: <291@pembina.alberta.UUCP>
Date: Thu, 2-Apr-87 17:45:28 EST
Article-I.D.: pembina.291
Posted: Thu Apr  2 17:45:28 1987
Date-Received: Sun, 5-Apr-87 00:57:40 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP> <15694@sun.uucp> <6042@mimsy.UUCP> <16014@sun.uucp>
Organization: U. of Alberta, Edmonton, AB
Lines: 31
Xref: utgpu comp.arch:764 comp.lang.c:1448

In article <16014@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes:
>>Since Sun is working on making their system SVID compatible
>>the wait shouldn't be too long now.
> 
>This does not follow at all.  The SVID does not describe shared
>libraries;

I don't know what you mean by "doesn't follow at all" (B-).

SVID specifies shared memory.  The point is that having shared
memory implies ease of shared library implementation but not
vice versa.  For systems that have neither it is probably easier
to just add shared library support than it is to go whole hog
and provide shared memory.

If I end up working at a Sun shop when I finish my degree here (about
two months from now), and Sun does not deliver shared libraries at
the time they distribute an OS with shared memory, you can be sure
that I will implement same right away.

Remember:

	+--------------------------------------------+
	| shared memory => shared resident libraries |
	|                                            |
	| The arrow does not go the other direction  |
	+--------------------------------------------+


				Bjorn R. Bjornsson
				alberta!bjorn