Re: Windows and DLLs

[David Jeske <jeske home chat net>]

On Wed, Sep 30, 1998 at 07:10:47PM -0500, Wesley Felter wrote:
> Yes, although it doesn't answer my question. I think it's OK that libraries
> have to go in certain directories, because most shared libraries will be
> preinstalled (and it probably wouldn't be too terrible if applications
> statically linked every non-preinstalled library (I'm assuming that GNOME
> will be preinstalled by most distros)).

Actually, there really are not a whole lot of reasons for this to be
true. If shlibs could really live anywhere, there would be some
important security ramifications which would have to be dealt
with. However, the only reason libs have to be either installed in
some fixed location, or described in ld.so.conf, or stuck into the
LD_LIBRARY_PATH environment variable, is that you don't want the code
in ld.so having to search your whole hard drive for an shlib. Namely,
it needs _some_ way to find it.

For example, in BeOS, the shlib loader could just ask the filesystem
for the location of the appropriate shlib by an 'shlib identifier
attribute', and it could be located anywhere. Of course, then you have
a different problem to deal with. Namely, if you have five copies of
'libc.so.4' on your machine, which one is the right one. Which one is
trusted? etc.... 

However, even with these problems, we still have the same problem I'm
going to highlight below. Namely, if the shlib has any associated
datafiles, the 'old-school' unix philosophy is to hard code the
location that these datafiles will be installed into the compiled
version of the shlib. This clearly dosn't work well, especially when
you have multiple conflicting versions of the same things and need to
choose between them at runtime, or when you want to let users install
things on the system.

> My question is about applications. Why can't I download a binary of some
> random app (let's say the GIMP), un{tar,zip} it into my home directory,
> double-click in in my filemanager, and have it just work? Or can they
> already do that? (At this point I must confess that I haven't been able to
> get GNOME to build, so this is a theoretical question...)

The biggest reason is that currently most UNIX apps hard code the
location of their 'extra datafiles' into the executable. You must
install these images in that location, or the app won't be able to
load them. This is bad, this is lazy, but this is the way it is.

We really need to move to an app-encap/wrapper standard where an
application can come in an encapsulated form with a collection of
private datafiles, where it's given the 'current locaiton' of itself
when it's launched, and where it can ask for it's private datafiles
with _relative_ paths. I've been talking about this kind of thing on
the KDE and Gnome lists for a while, but I've come upon lots of
resistance to it. I'm working with another Gnome supporter on putting
together a proposal right now, and we hope to have something for the
Gnome list very soon.

Some apps do a better job.. for example "wmprefs.app". It is wrappered
in the same style that Nextstep apps were wrappered in ".app
directories". As long as you launch it with a full path to the
executable, it can find it's datafiles, and window maker knows how to
throw it into the Doc, etc , etc...

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net