Re: Windows and DLLs

[Tim Moore <tmoore tembel org>]

On Thu, 1 Oct 1998, Christopher Curtis wrote:

> On Thu, 1 Oct 1998, David Jeske wrote:
> 
> > On Thu, Oct 01, 1998 at 11:10:18AM -0400, Christopher Curtis wrote:
> > > THe Windows problem is self inflicted by releasing different versions of
> > > the same library without changing the name.  *nix has already circumvented
> > > this problem by properly using library naming conventions.  It can
> > > basically be represented as:
> > > 
> > > lib<library>.[a|so].<major>.<minor>.<micro>
> > 
> > This does not solve the problem. What happens when:
> > 
> > 1) a user wants to use an app which only works with a newer
> > lib. (i.e. he can't install it easily unless he's administrator, or a
> > unix wizard)
> 
> He puts the library in his home directory and adds $HOME to his
> LD_LIBRARY_PATH.  Do you want users downloading apps and installing
> unknown libraries in system locations?  That's Part II of the Windows
> Problem.  Rarely do programs the user downloads require special shared
> libraries anyway.  That's how it is when programs ship as source code.

David's message should have read:

> a) a *normal* (i.e., non-geeky) user wants to use an app...

Normal people don't want to compile programs from source code. Normal
people don't want to run ldconfig.

In addition, RPM doesn't distinguish between system-wide installs and user
installs. In fact, I don't think there's any good way for normal people to
install libraries in their home directory.

Libraries should be made as simple as possible. The simplest library, IMO,
is a single object which just gets thrown in either a system directory or
a user directory and just *works*. Multiple versions can be installed, and
apps will bind to which ever one works for them. Deleting the library
should be no more complicated than throwing the library object in the
trash. That's what it should look like to the user. They (and I) don't
care how it's implemented. IMO, the easiest implementation uses NeXT-style
bundles.

Tim