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
