[Wine] Wine Executes Locally, But Not With Absolute Path

[Martin Gregorie]

On Thu, 2012-02-02 at 18:55 -0600, winepunk wrote:
> Ok, now I get it.  Thanks Martin.  Unix is passing the absolute path to the Windows app.
> 
> 
Not quite. All unices work the same way when they start a program:
  - look for the program using $PATH and load it (and its its not there,
    say so). This can be overridden: if you use a relative or absolute
    pathname for the program instead of its basename, the loader will
    ignore $PATH and only look for the exact name you supplied 

  - find dynamic libraries (DLL equivalent) by searching
    $LD_LIBRARY_PATH, /etc/ld.so.cache, /lib and /usr/lib

  - sets the program's current working directory to the shell's current
    working directory, usually a directory belonging to the user that
    is running the program and starts the program.

  IOW the directories that contain the program and any dynamically
  loaded libraries it needs are irrelevant to the program because they
  are on the search path and have been used to load binary stuff before
  the program starts to run.

  The current working directory is the usual start point for finding
  data files and, by convention, any configuration files it needs can
  be found by looking: 
  - 1st: where command line arguments say they are
  - 2nd: in the current working directory
  - 3rd: in /usr/local/etc  (this is where a well-behaved program that
         isn't part of the distro should look
  - 4th: in /etc

Windows uses different conventions:
  - the loader starts by setting the current working directory to the 
    directory that contains the program and starts it running.

  - the program looks for DLLs in its current working directory and will
    also look in wellknown places, e.g. c:\WINNT\SYSTEM, for standard
    DLLS that are part of Windows

  - many/most programs expect to find .INI files etc in its current
    working directory. 

  - the name of the directory the run command was issued from is passed
    to the program by the loader so, if it wishes to do so, it can
    change its reference point to there before finding data files
    passed to it as command line parameters 
    *** I'm unsure of this *** so if anybody knows better, tell me.

The upshot for Wine users is that, if you're running a simple Windows
app that uses only standard (builtin) Windows DLLs and does not expect
to find .INI files in its current working directory, it *may* work if
you start it with 
	wine path/to/install/directory/TheApp.EXE"

but if it expects to find even one DLL or configuration file in its
current working directory, then the only way you can run it is with

	cd part/to/install/directory; wine TheApp.EXE

I hope this clarifies the situation and that the above will help with
other programs in the future.

I think the difference in approach is because UNIX, and hence its clones
and derivatives such as Linux and OS/X was design, was designed from the
outset to support many users and to allow many people to make
simultaneous use of any program that has been published for general use
while at the same time protecting each user's files from unwanted access
by others. Windows, OTOH was designed to be used by one person at a time
and this shows in various ways such as no real access controls on files
and programs and the way many programs screw up if more than one Wine
user tries to run an app thats in a common prefix.


Martin