This is now attempt 4, not that anyone's counting.
Adding winelib programs is a bit involved, and I imagine I've screwed something up along the way. If you know how to add them properly, please say something, even if it's to tell me I did it right.
This patch adds a winelib program called winestartfile for starting files given the unix path. It attempts to mimic what windows explorer does to start files and provide some visible (gui) feedback when it doesn't work. The idea is that wine.desktop can then be modified to use winestartfile instead of wine, solving the following problems when starting exe files from file managers: * File managers typically do not set the working directory to the directory that contains an exe when they start it. Setting the working directory is the default behavior for windows explorer, and many windows programs rely on it. * File managers naturally use the unix path to start files, and the wine binary passes the unix path along to the exe it starts, rather than translating it to a windows path (this can and probably should also be fixed somewhere else). * Windows explorer always starts exe files with quotes around the path in the command-line, even if the path does not contain spaces. The wine binary does not (and probably should not) add quotes in this situation. A few apps rely on the quotes. See http://bugs.winehq.org/show_bug.cgi?id=5224#c14
As explorer.exe is always running could you do something like extend it so that that KFM and friends could call 'explorer.exe filename' directly? It seems redundant to add another winelib application when you are trying to emulate explorer functionality anyway and explorer is always running. You could extend it to use messaging to connect to an existing explorer.exe process also.
Thanks Steven
On 2/17/08, Vincent Povirk madewokherd+d41d@gmail.com wrote:
This is now attempt 4, not that anyone's counting.
Adding winelib programs is a bit involved, and I imagine I've screwed something up along the way. If you know how to add them properly, please say something, even if it's to tell me I did it right.
This patch adds a winelib program called winestartfile for starting files given the unix path. It attempts to mimic what windows explorer does to start files and provide some visible (gui) feedback when it doesn't work. The idea is that wine.desktop can then be modified to use winestartfile instead of wine, solving the following problems when starting exe files from file managers:
- File managers typically do not set the working directory to the
directory that contains an exe when they start it. Setting the working directory is the default behavior for windows explorer, and many windows programs rely on it.
- File managers naturally use the unix path to start files, and the
wine binary passes the unix path along to the exe it starts, rather than translating it to a windows path (this can and probably should also be fixed somewhere else).
- Windows explorer always starts exe files with quotes around the path
in the command-line, even if the path does not contain spaces. The wine binary does not (and probably should not) add quotes in this situation. A few apps rely on the quotes. See http://bugs.winehq.org/show_bug.cgi?id=5224#c14
-- Vincent Povirk
The odd thing about wine's explorer is that it doesn't seem to copy any UI that's handled by explorer on windows. It seems to be some sort of service and have something to do with HAL (and controlling virtual desktops for some reason). I must admit I don't understand the reasoning behind any of the current things that are or are not handled by explorer, but I think this is probably not the right place.
The reason for trying to emulate explorer functionality is that some apps depend on being called exactly the way they would be called by explorer. AFAIK they do not care if they're called by explorer.exe or some other program.
I imagine this wouldn't be too difficult to add, but I'd have to make explorer depend on shell32 (and possibly shlwapi). I'm also not sure how this would interact with /desktop functionality (come to think of it, explorer would read any path starting in a / as a command-line switch..).
On Feb 18, 2008 5:07 AM, Steven Edwards winehacker@gmail.com wrote:
As explorer.exe is always running could you do something like extend it so that that KFM and friends could call 'explorer.exe filename' directly? It seems redundant to add another winelib application when you are trying to emulate explorer functionality anyway and explorer is always running. You could extend it to use messaging to connect to an existing explorer.exe process also.
Thanks Steven
On 2/17/08, Vincent Povirk madewokherd+d41d@gmail.com wrote:
This is now attempt 4, not that anyone's counting.
Adding winelib programs is a bit involved, and I imagine I've screwed something up along the way. If you know how to add them properly, please say something, even if it's to tell me I did it right.
This patch adds a winelib program called winestartfile for starting files given the unix path. It attempts to mimic what windows explorer does to start files and provide some visible (gui) feedback when it doesn't work. The idea is that wine.desktop can then be modified to use winestartfile instead of wine, solving the following problems when starting exe files from file managers:
- File managers typically do not set the working directory to the
directory that contains an exe when they start it. Setting the working directory is the default behavior for windows explorer, and many windows programs rely on it.
- File managers naturally use the unix path to start files, and the
wine binary passes the unix path along to the exe it starts, rather than translating it to a windows path (this can and probably should also be fixed somewhere else).
- Windows explorer always starts exe files with quotes around the path
in the command-line, even if the path does not contain spaces. The wine binary does not (and probably should not) add quotes in this situation. A few apps rely on the quotes. See http://bugs.winehq.org/show_bug.cgi?id=5224#c14
-- Vincent Povirk
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
I talked to Alexandre Julliard on irc, and he thinks moving this to explorer is a good idea (I still don't understand what goes into this, but I'll accept it).
I'm supposed to use delayed imports for shell32 and shlwapi. I'll need to add a switch for this (so you'd do something like wine explorer /startfile ~/whatever.exe), and it'll probably be easier for users if I assume only things that contain a / are unix paths (instead of treating everything like one).
On Feb 18, 2008 9:18 AM, Vincent Povirk madewokherd+d41d@gmail.com wrote:
The odd thing about wine's explorer is that it doesn't seem to copy any UI that's handled by explorer on windows. It seems to be some sort of service and have something to do with HAL (and controlling virtual desktops for some reason). I must admit I don't understand the reasoning behind any of the current things that are or are not handled by explorer, but I think this is probably not the right place.
The reason for trying to emulate explorer functionality is that some apps depend on being called exactly the way they would be called by explorer. AFAIK they do not care if they're called by explorer.exe or some other program.
I imagine this wouldn't be too difficult to add, but I'd have to make explorer depend on shell32 (and possibly shlwapi). I'm also not sure how this would interact with /desktop functionality (come to think of it, explorer would read any path starting in a / as a command-line switch..).
On Feb 18, 2008 5:07 AM, Steven Edwards winehacker@gmail.com wrote:
As explorer.exe is always running could you do something like extend it so that that KFM and friends could call 'explorer.exe filename' directly? It seems redundant to add another winelib application when you are trying to emulate explorer functionality anyway and explorer is always running. You could extend it to use messaging to connect to an existing explorer.exe process also.
Thanks Steven
On 2/17/08, Vincent Povirk madewokherd+d41d@gmail.com wrote:
This is now attempt 4, not that anyone's counting.
Adding winelib programs is a bit involved, and I imagine I've screwed something up along the way. If you know how to add them properly, please say something, even if it's to tell me I did it right.
This patch adds a winelib program called winestartfile for starting files given the unix path. It attempts to mimic what windows explorer does to start files and provide some visible (gui) feedback when it doesn't work. The idea is that wine.desktop can then be modified to use winestartfile instead of wine, solving the following problems when starting exe files from file managers:
- File managers typically do not set the working directory to the
directory that contains an exe when they start it. Setting the working directory is the default behavior for windows explorer, and many windows programs rely on it.
- File managers naturally use the unix path to start files, and the
wine binary passes the unix path along to the exe it starts, rather than translating it to a windows path (this can and probably should also be fixed somewhere else).
- Windows explorer always starts exe files with quotes around the path
in the command-line, even if the path does not contain spaces. The wine binary does not (and probably should not) add quotes in this situation. A few apps rely on the quotes. See http://bugs.winehq.org/show_bug.cgi?id=5224#c14
-- Vincent Povirk
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
-- Vincent Povirk
-
Steven Edwards -
Vincent Povirk