Re: Windows and DLLs

[Nils Philippsen <nils wombat dialup fht-esslingen de>]

On Sat, 3 Oct 1998, David Jeske wrote:

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

Read my reply to my reply to your mail on this :-).

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

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

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

> 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 */

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.

Bye,
Nils
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nils Philippsen                  @college: nils@rhlx01.rz.fht-esslingen.de
Vogelsangstrasse 115             @home:    nils@wombat.dialup.fht-esslingen.de
D 70197 Stuttgart                phone:    +49-711-6599405
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Maybe I should patent stupidity so every lawyer will owe me BIG !!
(mpare@cadvision.com)