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

[Vincent Povirk]

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



-- 
Vincent Povirk