Re: Windows and DLLs

[Tim Moore <tmoore tembel org>]

David Jeske wrote:
> 
> On Sun, Oct 04, 1998 at 12:10:57PM +0200, Nils Philippsen wrote:

[snip]

> > with exec()'s, argv[0] doesn't necessarily tell the truth.

[snip]

> > $PATH in the program and $PATH in the calling program needn't be the same.
> 
> Good point, again, that damn execvp(). :)

I think it's pretty well established that there's no perfect solution to
this problem. But we can come pretty damn close. argv[0] *usually* tells
the truth. PATH in the program and the calling program is *usually* the
same. Furthermore, if all programs in the GNOME environment use a
function from gnome_exec to launch programs, then we can be pretty sure
that for most people, everything will be OK.

> > > 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.

Yeah, that's the best way to support it. This is much like the dicussion
on how to ensure that metadata doesn't get orphaned when people use
programs that aren't aware of it. The answer was that we can't, but we
can try to make it easy to make programs which *are* aware of it, and if
someone wants to put support for metadata directly into a filesystem, we
can support it on those systems.

> 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].

Exactly. And same for anywhere else in GNOME where programs get
launched. If the panel uses full paths, and the file manager uses the
full paths of double-clicked things, and the API for opening the
preferred app for a given file type or URL protocol uses full
paths...well that just about covers probably 90% of program execution in
GNOME.

Tim