Wine Executes Locally, But Not With Absolute Path

[winepunk]

I have an uninstalled portable Windows .exe.

When I type the absolute path, it doesn't work:

wine /home/ubuntu/appDir/myApp.exe

but, if I cd to the application directory and execute it locally, it works:

Code: Select all

cd /home/ubuntu/appDir/

wine myApp.exe

I'm trying to include it in my Docky dock via a .desktop shortcut I've made in /usr/share/applications/. I don't mind the command line for under the hood stuff, but not for launching typical user apps.

[jjmckenzie]

On Wed, Feb 1, 2012 at 9:21 AM, winepunk <[email protected]> wrote:

I have an uninstalled portable Windows .exe.

When I type the absolute path, it doesn't work:

wine /home/ubuntu/appDir/myApp.exe

but, if I cd to the application directory and execute it locally, it works:


Code:
cd /home/ubuntu/appDir/

wine myApp.exe

This is how Windows does it and this is how Wine does it. This is not
going to change.

 I'm trying to include it in my Docky dock via a .desktop shortcut I've made in /usr/share/applications/. I don't mind
the command line for under the hood stuff, but not for launching typical user apps.

You need to ask on the Ubuntu forums how to do this.

James

[dimesio]

I have an uninstalled portable Windows .exe.

When I type the absolute path, it doesn't work:

wine /home/ubuntu/appDir/myApp.exe

but, if I cd to the application directory and execute it locally, it works:

Code: Select all

cd /home/ubuntu/appDir/

wine myApp.exe

I'm trying to include it in my Docky dock via a .desktop shortcut I've made in /usr/share/applications/. I don't mind the command line for under the hood stuff, but not for launching typical user apps.

KDE allows you to set the working directory for launchers, but I don't think Gnome does and I have no idea about Unity. You could try using

Code: Select all

wine start /Unix /path/to/myApp.exe

and if that doesn't work, just write a shell script that changes the directory and launches the app and use the launcher for that.

[winepunk]

Had no idea Windows required you drop down locally.

And as far as a script, already shebanged it out.

Well it makes no sense anyway guys. I have other .desktop shortcuts that execute absolute paths and launch with no complaint.

Here is an actual line from the shortcut file:

Exec=wine "/home/artist/Adobe Photoshop CS5/ps.exe"

[winepunk]

I meant to say that line works. Why should Wine be finicky?

[Martin Gregorie]

On Wed, 2012-02-01 at 16:41 -0600, winepunk wrote:

I meant to say that line works. Why should Wine be finicky?

Its the Windows app thats finicky, not Wine.

Many Windows apps are written to assume that they'll be started in the
directory that contains things they need to run, such as app-specific
DLLs, .ini files etc. In *nix terminology this is called the current
working directory. *nix, i.e. Linux and OS/X, programs, on the othyer
hand, are written on the assumption that the data files the program will
use are in the current working directory and the program itself will be
somewhere else in the search path (defined in by $PATH).

Wine, being a *nix program, naturally uses the conventions of its host
OS. As a result, running

wine path/to/app/dir/app.exe

will leave the current working directory set to where you issued the
command from ($HOME if you just logged in) and some Windows apps may
work, but most will complain that they can't find stuff that's in their
installation directory. OTOH running

cd path/to/app/dir; wine app.exe

will first change directory to path/to/app/dir, make it the current
working directory and then run app.exe in that directory. Since that's
effectively what Windows always does, it will work with all Windows
apps.


Martin

[winepunk]

Ok, now I get it. Thanks Martin. Unix is passing the absolute path to the Windows app.

[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