On 21.07.2007 22:44, Damjan Jovanovic wrote:
If a double-click starts an app in Windows, it should do the same in wine, and the semantics of a double-click on Windows seem to be "start this app in the file browser's current directory".
Now if wine cannot tell a true unix path from a windows unix path, then we either need a separate process to be called on a double-click that can translate argv[0] and chdir() before exec()ing wine, or a command-line switch/environment variable to tell wine it was started by a double-click and it should translate argv[0] and SetCurrentDirectory() appropriately.
Note that "double-click behaviour" is up to the application that actually receives the double click and invokes wine (a file manager, presumably), and not wine itself. So when 'wine' should be started with a certain current directory, you need to fix the app that starts wine to change to the right directory.
Perhaps create something like a wrapper script that pulls the application's directory, converts that to a Windows path, and invokes "start" with that directory as the "Starting directory" parameter. That should nicely handle your problem of wine being executed in some other directory after a double-click in your application, as well as the CD media change prohibited by a "cd" (assuming, since the directory change happens in Wine, unmounting isn't prevented).
-f.r.