programs: add winestartfile for starting files from the unix path (for file managers)

Vincent Povirk madewokherd+d41d at gmail.com
Mon Feb 18 08:18:44 CST 2008


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 at 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 at 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



More information about the wine-devel mailing list