Lionel Ulmer wrote:
Hi all,
There are just two (unrelated) points that I would like to discuss:
= the possibility to add a 'wine' launcher. Basically what happens is that some (maybe only one :-) ) application takes as an assumption that it is started via 'double clicking' on the .EXE file or via the installed link. From what I know, both these actions will start the game from its .EXE directory and with the full qualified path as the exe name.
So the application crashes if you start it with 'wine foo.exe', you need to type 'wine D:\Foo\foo.exe' to get it running.
One could then imagine having either 'wine' be a launcher that qualifies the name, changes to the good directory and just start the 'real' wine or do the reverse: publicize to new users that they should use 'winelaunch' to start applications and keep 'wine' how it is now.
Changing the directory is not a correct solution. Consider what would happen if user wants to perform an operation on a file in the current directory, and specifies the filename as a relative path. The program would start in the wrong directory and would not find the file.
Maybe the program is checking the base directory of the EXE file from argv[0] in its main function, in order to load some resource from itself or from a companion file. However this is something that should be done inside wine (that is, providing a full DOS path to the executable file for the program's argv[0]), not via a launcher. Could you please indicate which application has this behavior? Can you provide a download URL? Have you tested booting Windows, then opening a DOS window, switching to the program directory and running it as in:
C:> D: D:> cd Foo D:\Foo>Foo
If the program works like this in native, then this should also be done in wine, and you have discovered an application that relies on an (still) unimplemented behavior in Wine.
BTW, have you tried "wine ./foo.exe", as opposed to "wine foo.exe"?