Usually I run windows applications by just creating a .desktop file which contains exec=wine /path/to/program.exe.
But recently, I came across a program that doesn't start that way. For some reason, it runs fine, though, if I right-click on the program.exe in thunar and select "wine windows program starter" (or whatever the name is on a system set to english).
So, now, I wonder, what does "wine windows program starter" do (different from invoking "wine program.exe")? I.e., which commands would one have to execute (through a .desktop file) to emulate what "wine windows program starter" does?
I did some testing and found out that I can also start the program successfully if instead of executing "wine program.exe" from terminal, I execute in the terminal "wine cmd" and then call the program.exe. But I wouldn't know how to execute this chain of commands via a .desktop file. The usual && connector doesn't work, probably "obviously", as after calling "wine cmd", the rest of the commands are running under wine which the .desktop file might not have any access to.
What does "wine windows program starter" do?
Re: What does "wine windows program starter" do?
Some good news.
I just found out that using wineconsole instead of wine in the .desktop file (or from terminal) starts the program. Unfortunately, wineconsole seems to ignore the program-specific windows version and uses the global windows version. Now I have to find a way to somehow inject the windows version into the command / force wineconsole to adhere to the settings for the specific program. As wineconsole is (also) a linux program - the one that gets executed -, I'm not really surprised that setting a different windows version for the wineconsole program in ~/.wine doesn't change anything... But even if I run "wine /usr/home/[user]/.wine/drive_c/windows/system32 [or syswow64]/wineconsole.exe /path/to/program.exe" the windows version settings for wineconsole.exe and program.exe get ignored, unfortunately...
Adding --backend=user or curses to wineconsole just leads to cmd showing up and giving an error. Neither does trying to execute the "winwconsole /path/to/program.exe" command above as a chain of commands (wineconsole + then "emulating" going to the device (which is not "c:\"), then to the folder and then executing the exe) work.
I just found out that using wineconsole instead of wine in the .desktop file (or from terminal) starts the program. Unfortunately, wineconsole seems to ignore the program-specific windows version and uses the global windows version. Now I have to find a way to somehow inject the windows version into the command / force wineconsole to adhere to the settings for the specific program. As wineconsole is (also) a linux program - the one that gets executed -, I'm not really surprised that setting a different windows version for the wineconsole program in ~/.wine doesn't change anything... But even if I run "wine /usr/home/[user]/.wine/drive_c/windows/system32 [or syswow64]/wineconsole.exe /path/to/program.exe" the windows version settings for wineconsole.exe and program.exe get ignored, unfortunately...
Adding --backend=user or curses to wineconsole just leads to cmd showing up and giving an error. Neither does trying to execute the "winwconsole /path/to/program.exe" command above as a chain of commands (wineconsole + then "emulating" going to the device (which is not "c:\"), then to the folder and then executing the exe) work.
