Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.windows.x
Subject: Re: Shared libs with X, Frame (Was: Re: Xkernel)
Keywords: shared libs, X, Frame maker
Message-ID: <5056@auspex.auspex.com>
Date: 5 Jan 91 08:51:01 GMT
References: <80@tdatirv.UUCP> <1990Dec19.191336.14848@agate.berkeley.edu> <1990Dec26.214324.28624@eng.umd.edu>
Organization: Auspex Systems, Santa Clara
Lines: 47

In article <1990Dec19.191336.14848@agate.berkeley.edu>, stolcke@ICSI.Berkeley.EDU (Andreas Stolcke) writes:
> The reason for Frame's using statically linked binaries is probably that
> they want to prevent against someone getting smart and breaking their
> license control scheme by `patching' libc.so.  I'm not familiar with the
> details of their implementation, but suppose it gets the host id to
> match it against a built-in licence.  It would be easy to fudge the
> relevant system calls to always provide the `right' host id...

As the other poster who followed up noted, you can fudge the relevant
system call by replacing the "/vmunix" shared library (:-) :-) :-)) and
break even statically-linked-in host-ID-checking licensing schemes.

And note also:

	auspex% file maker
	maker:          symbolic link to maker2.exe
	auspex% file maker2.exe
	maker2.exe:     sparc demand paged dynamically linked executable
	auspex% ldd maker
        -lsuntool.0 => /usr/lib/libsuntool.so.0.40
	-lsunwindow.0 => /usr/lib/libsunwindow.so.0.40
	-lpixrect.2 => /usr/lib/libpixrect.so.2.4
	-lc.1 => /usr/lib/libc.so.1.3

This is Frame 2.0, with network licensing, so at least for *that*
version they either didn't know about the risk of breaking the licensing
scheme, didn't care, or somehow arranged that it couldn't be broken
(dunno if the floating license stuff uses "gethostid()") 'cuz they sure
used dynamic linking out the wazoo, "libc" and all.... 

In article <1990Dec26.214324.28624@eng.umd.edu> stripes@eng.umd.edu (Joshua Osborne) writes:
>A (more) valid point is that it is a real pain for support.  They would need to
>find out the libc, libX11 version numbers, and god help them if someone (like
>us) has a non-standard shared lib!

This sounds a bit more plausible, as until recently SunOS didn't come
standard with Open Windows (4.0[.x] didn't, I think 4.1 did only if you
got one of the diskful machines with SunOS pre-installed, 4.1.1 seems to
come standard with it).  They'd either have to build with the OW
versions - one built against the OW 2.0 libraries might work when run
against the MIT version, but perhaps with warnings, as I've heard the OW
2.0 libraries have the same major version numbers as the MIT libraries,
but a marger minor version number, perhaps because of some of the stuff
like compose-key support added to Xlib in OW 2.0 - or build with the MIT
versions.  Perhaps they were nervous about having to deal with both the
MIT and OW version....  ("libc" is presumably not an issue, given that
the SunView version uses a shared "libc".)