Re: Windows and DLLs

[David Jeske <jeske home chat net>]

On Sun, Oct 04, 1998 at 12:10:57PM +0200, Nils Philippsen wrote:
> > 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.
> > 
> 
> with exec()'s, argv[0] doesn't necessarily tell the truth.

True.. damn that execvp()

> > 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)
> 
> $PATH in the program and $PATH in the calling program needn't be the same.

Good point, again, that damn execvp(). :)

> > 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.
> 
> Be it a syscall or a workaround (as the scheme you described above) this
> should have a common api like:
> 
> const char * path_to_binary (void); /* returns full path to the binary */
> const char * path_to_binary_dirname (void); /* returns the directory where
>                                              * the binary is located */

I think this should be a Gnome API. We're not going to be changing
POSIX. That way we can implement as best we can for each system, and
if anyone puts it into their kernels, we can implement it with that.

> My opinion is: To achieve the goals you mentioned this would have to be a
> syscall implemented in all current unices. Therefore it has to be in a
> standard like POSIX, otherwise we would have difficulties to convince the
> manufacturers of commercial unices to adapt it into their systems. They
> don't like the free unices (they lose market share) and won't be very
> cooperative, I fear.

I think the reasons commercial unicies won't change is completely
different than what you state here. For them it requires quite a bit
of money to do a new release, because they have to test and QA every
feature and change. They certainly won't change now. However, if Gnome
apps all used the above relative-path stuff, and Gnome apps became
prevalant, then eventually other unicies would follow suit. 

As it turns out, in the case of most GUI apps, we can make sure that
the GUI app launcher just uses the full path and sticks that full path
in argv[0].

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