Re: Windows and DLLs

[David Jeske <jeske home chat net>]

On Sat, Oct 03, 1998 at 08:37:39AM -0400, John Kodis wrote:
> On Sat, Oct 03, 1998 at 11:57:14AM +0200, Nils Philippsen wrote:
> > On Fri, 2 Oct 1998, David Jeske wrote:
> > > We need a standard way for an app to find the full path to it's
> > 
> > This simply is not really possible -- think of hard links. the only thing
> > you might get would be an inode number and a device which wouldn't help.

Anything is possible if you _make_ it possible. My assertion is that
we need to make this possible, to whatever degree it is possible, on
the different UNIXies available.

> Hard links allow there to be more than one fully qualified path to a
> given file.  This isn't a problem, however, as all of these paths will
> point to the same directory.

We would be 'best off' if we could ask the system for the full path to
the executable which was 'exec()ed' into our process. Of course, on
most UNIX systems we can't do this, but we should be able to
approximate it with an appropraite abstration API and some number of
conventions.

For example:

1) look at argv[0], if it's an absolute path, resolve if it points to
   a symlink or hardlink, and there you have it.

2) look at argv[0], if it has a relative path specifier in it, combine
   it with the current working directory, resolve if it points to
   a symlink or hardlink, and there you have it.

2) if it's not a relative path (i.e. it's just a program name) then search
   the current path specification in order, looking for the name, then
   resolve any symlinks or hardlinks, and there you have it. (this is the
   slowest and worst case)



Then if applications use _that_ path, with relative paths to their
datafiles, apps would be pretty much location
independent. "wmprefs.app" does 1 and 2 but not 3. I think
xemacs/emacs do all of them, but I'm not sure.


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