Hi
We have 2 problems in wine:
1. When you run "wine /path/to/app.exe", argv[0] is "/path/to/app.exe" which is definitely wrong. The most serious consequence of this is that apps run through file browser double-clicking can break.
2. Whether you run "wine D:\setup.exe" or "wine /media/cdrom/setup.exe", the current directory is never "D:" and when you double-click an .exe the current directory is $HOME so it's always wrong. You can't "cd /media/cdrom && wine setup.exe" either because that stops ejecting the CD for multi-CD installs.
Can we kill 2 birds with 1 stone here and do something like
if (argv[0] is a unix path) { make argv[0] a windows path SetCurrentDirectory(directory of argv[0]); }
before starting the app? Since Windows never uses UNIX paths this can't break any Windows app, and it will fix double-click startups and multiple CD installs.
Any thoughts? Damjan Jovanovic
Damjan Jovanovic wrote:
Hi
We have 2 problems in wine:
- When you run "wine /path/to/app.exe", argv[0] is "/path/to/app.exe"
which is definitely wrong. The most serious consequence of this is that apps run through file browser double-clicking can break.
- Whether you run "wine D:\setup.exe" or "wine
/media/cdrom/setup.exe", the current directory is never "D:" and when you double-click an .exe the current directory is $HOME so it's always wrong. You can't "cd /media/cdrom && wine setup.exe" either because that stops ejecting the CD for multi-CD installs.
Can we kill 2 birds with 1 stone here and do something like
if (argv[0] is a unix path) { make argv[0] a windows path SetCurrentDirectory(directory of argv[0]); }
before starting the app? Since Windows never uses UNIX paths this can't break any Windows app, and it will fix double-click startups and multiple CD installs.
First of all there are extensive tests for this in kernel32 process test. Which shows exactly opposite from what you stated here - windows does support use of unix path.
Second, your approach will brake lots of new programs that can not be started from their directory. They can only be started from _outside_ directory they are in with 'start app.exe'.
Vitaliy.
On 7/21/07, Vitaliy Margolen wine-devel@kievinfo.com wrote:
Damjan Jovanovic wrote:
Hi
We have 2 problems in wine:
- When you run "wine /path/to/app.exe", argv[0] is "/path/to/app.exe"
which is definitely wrong. The most serious consequence of this is that apps run through file browser double-clicking can break.
- Whether you run "wine D:\setup.exe" or "wine
/media/cdrom/setup.exe", the current directory is never "D:" and when you double-click an .exe the current directory is $HOME so it's always wrong. You can't "cd /media/cdrom && wine setup.exe" either because that stops ejecting the CD for multi-CD installs.
Can we kill 2 birds with 1 stone here and do something like
if (argv[0] is a unix path) { make argv[0] a windows path SetCurrentDirectory(directory of argv[0]); }
before starting the app? Since Windows never uses UNIX paths this can't break any Windows app, and it will fix double-click startups and multiple CD installs.
First of all there are extensive tests for this in kernel32 process test. Which shows exactly opposite from what you stated here - windows does support use of unix path.
Second, your approach will brake lots of new programs that can not be started from their directory. They can only be started from _outside_ directory they are in with 'start app.exe'.
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.
Vitaliy.
Damjan
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.
On 21.07.2007 18:05, Vitaliy Margolen wrote:
First of all there are extensive tests for this in kernel32 process test. Which shows exactly opposite from what you stated here - windows does support use of unix path.
Unix paths or unix-style paths? If a program is started as /home/user/myapp and would see the directory /home/user in argv[0] I'd guess it would interpret that as "C:\home\user", while seeing something like "Z:\home\user" or "Z:/home/user" would perhaps me more correct. That said, perhaps an absolute unix path in argv[0] should be converted to a "Windows" path.
-f.r.
Vitaliy Margolen wine-devel@kievinfo.com writes:
First of all there are extensive tests for this in kernel32 process test. Which shows exactly opposite from what you stated here - windows does support use of unix path.
That's true for apps started from another Win32 process; in that case we clearly cannot mess with argv[0]. For apps launched from the Unix command line we do have a bit more freedom, and setting argv[0] to a full Windows path is certainly feasible.
-
Alexandre Julliard -
Damjan Jovanovic -
Frank Richter -
Vitaliy Margolen