[Bug 12464] New: ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

Summary: ShellExecute does not integrate well with external
                    handlers
           Product: Wine
           Version: CVS/GIT
          Platform: Other
        OS/Version: other
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: shell32
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

ShellExecute does not integrate well with external handlers.

For example; my GNOME desktop has a PDF viewer, but when an application that is
run via wine calls ShellExecute on a PDF file, wine is only capable of opening
this file with PDF handlers that are installed within the wine environment.

I think the best way to handle this would be to replace the implementation with
an xdg-open(1) wrapper.

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

Robert Millan  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |integration

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

Dripple  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1

--- Comment #1 from Dripple   2008-05-28 06:49:49 ---
*** This bug has been confirmed by popular vote. ***

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

Andrea Denzler  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #2 from Andrea Denzler   2008-09-11 11:15:29 ---
Is there any workaround? What source code of the Windows Application would open
a PDF file correctly under Windows and under Wine too?

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|CVS/GIT                     |unspecified

--- Comment #3 from Austin English   2009-01-19 15:15:01 ---
Removing deprecated CVS/GIT version tag. Please retest in current git. If the
bug is still present in today's wine, but was not present in some earlier
version of wine, please update version field to earliest known version of wine
that had the bug. Thanks!

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

--- Comment #4 from Andrea Denzler   2009-06-02 04:56:12 ---
I can confirm this behaviour with Wine 1.1.22.
- Shell execute on a PDF file does not invoke the native Linux PDF Viewer.
- Shell execute on a HTML link does not invoke the default Linux Web Browser.

Distros tested:
* Ubuntu 9.04 (Wine 1.1.22)
* SUSE 11.0 (Wine 1.1.22-2.1)
* Fedora 9 (Wine 1.1.14)
* Linux Mint (Wine 1.1.22)
* Mandriva Linux 2009 (Wine 1.1.22)

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

--- Comment #5 from Robert Millan   2009-06-02 07:34:48 ---
(In reply to comment #4)
> I can confirm this behaviour with Wine 1.1.22.
> - Shell execute on a PDF file does not invoke the native Linux PDF Viewer.
> - Shell execute on a HTML link does not invoke the default Linux Web Browser.

Hi,

Just to point out: the API to do this is not in Linux, it's userland stuff. You
need to check the FreeDesktop xdg-open(1) utility.

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

--- Comment #6 from Andrea Denzler   2009-06-02 08:48:43 ---
> Hi,
>
> Just to point out: the API to do this is not in Linux, it's userland stuff. You
> need to check the FreeDesktop xdg-open(1) utility.

Hi,

Would it be a good idea for Wine to run the associated default program
(xdg-open) when under Wine-Windows there exists no file association for a PDF
file (for example)? Instead of getting an error the document would be openend.

Right now if I double click on a PDF file from WineFile.exe then I am getting
the message "Success" but nothing happens.

For me it sounds logical, but I admit that this missing feature isn't really a
bug, but a improvement for a better integration between Wine-Windows and Linux.

Andrea

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #7 from [e-mail]  2009-11-14 21:14:57 ---
Hi. I think Wine applications live too much of their own lives now, making Wine
too much of an emulator. They have their own registry, their own themes, their
own menu as a sub-menu of the system menu. There is a "users" folder in the
wine sub-folder of a single user. They are installed and uninstalled in a
completely different way. There is even a stub of its own system panel. In
other words, they are second-class citizens on the Linux desktop. They are
totally unintegrated. So the above suggestion, which implies separate
associations in wine programs from native Linux programs, seems unwise to me. I
think even folders should open with xdg-open, not the crippled clone of
Explorer.exe as it does now.

So, here's my vote that this bug is fixed soon. :)

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

--- Comment #8 from Dmitry Timoshkov   2009-11-16 12:46:50 ---
(In reply to comment #7)
> Hi. I think Wine applications live too much of their own lives now, making Wine
> too much of an emulator. They have their own registry, their own themes, their
> own menu as a sub-menu of the system menu. There is a "users" folder in the
> wine sub-folder of a single user. They are installed and uninstalled in a
> completely different way.

Once you understand that it's *Windows applications* not Wine ones you
will see how much efforts Wine actually have done to perform that kind of
integration which it currently supports.

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |download

--- Comment #9 from Austin English   2010-05-19 16:04:30 ---
Still present.

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #10 from [e-mail] 2012-05-17 15:32:03 CDT ---
This bug has not been updated for two years and OP by three. Is this still an
issue i current (1.5.4) or newer wine ? You may also close this as abandoned if
you feel that that this is issue is no longer relevant to you.

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

Erik van Pienbroek  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #11 from Erik van Pienbroek  2012-05-30 08:11:35 CDT ---
With wine 1.5.4 it still isn't possible to have ShellExecute call xdg-open (or
use another centralized native file association database) as a fallback path
when no file association in the windows registry could be found for the
requested extension.

Take for example the .pdf extension. On my Linux environment I've got evince
installed which can open .pdf files. In my wine environment there's no pdf
reader installed and therefore no file association mentioned in the wine
windows registry.

If I try to open some random .pdf file using wine start.exe then the following
error is returned:

Application could not be started, or no application associated with the
specified file.
ShellExecuteEx failed: Success.

The expected behaviour is that ShellExecute also tries to search a centralized
native file association database (like the one from xdg-open) when no direct
file association could be found in the windows registry

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

Dan Kegel  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

--- Comment #12 from Dan Kegel  2012-05-30 12:59:10 CDT ---
Created attachment 40341
  --> http://bugs.winehq.org/attachment.cgi?id=40341
An old patch that does something similar

Here's an old patch from Jeff Miller that did something similar
(though it uses gnome-open instead of xdg-open, maybe you'd want to
try one and then the other).

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

--- Comment #13 from Erik van Pienbroek  2012-05-30 13:14:22 CDT ---
The patch sure looks interesting.
If the wine developers approve this kind of approach I'm willing to update it
to use xdg-open and improve the error handling a bit more so it can be merged
in the wine git

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

--- Comment #14 from Erik van Pienbroek  2012-06-01 03:49:20 CDT ---
Created attachment 40357
  --> http://bugs.winehq.org/attachment.cgi?id=40357
shell32: Make ShellExecute use native file association databases

I just proposed attached patch to the wine-patches mailing list.
This patch is based on initial work from Jeff Miller

This change adds a fallback path where an attempt is done to
open a file using the native file association databases before
giving up. On Linux environments the tool 'xdg-open' is used
for this, for Mac OS X environments the tool 'open' is used

Tested succesfully on a Fedora 17 environment using the start.exe
command and Outlook 2007 by trying to open a .pdf file (where there
is no file association registered inside the wine prefix)

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

--- Comment #15 from Dan Kegel  2012-06-01 09:19:16 CDT ---
If xdg-open is not present, probably want to fall back to the old gnome and
then kde equivalents.

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

--- Comment #16 from Erik van Pienbroek  2012-06-01 09:45:54 CDT ---
(In reply to comment #15)
> If xdg-open is not present, probably want to fall back to the old gnome and
> then kde equivalents.

I don't see the benefit of duplicating the logic which is in the xdg-open
script ( http://cgit.freedesktop.org/xdg/xdg-utils/tree/scripts/xdg-open.in )
inside wine. xdg-open was first introduced in 2006 and became part of most
Linux distributions around 2008. All mainstream Linux distributions should have
it installed by default these days. The question here is whether we want
provide support for native file associations integration for Linux
distributions from before 2008 (and thus also obsolete environments like KDE3)

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

--- Comment #17 from Andrea Denzler  2012-06-01 10:12:33 CDT ---
I think the first question is
1) Do we want Wine to be an independent OS within the Host environment?
or
2) Do we want the best possible integration between Wine and the Host
environment?

Both approaches can be correct, it's a question of philosophy. Actually I think
Wine developers prefer path 1). Under that viewpoint this here is not a bug,
since there is no default PDF association (unless you install a PDF viewer
within Wine). It is correct that Shell Execute does nothing.

The first approach is useful for replicating Windows applications under a Linux
Host. I want a Windows PDF viewer, a Windows Browser, a (horrible) Windows File
Manager.

The second approach is IMHO more useful for the End-User who wants to run some
Windows programs under his preferred OS, probably because there are no
available alternatives. Under this viewpoint ShellExecute should search for a
Host file association (run xdg-open) unless a different file association is
defined under Wine.

For my personal needs I just added a lot of registry entries (within the wine
environment) all pointing to xdg-open, so for example the Host PDF Viewer /
File Manager is actually used. But this is a viable solution only when the
application and wine settings/configuration files are distributed within a
independent container. This is not the default case under Linux where you
usually have just one wine configuration.

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

--- Comment #18 from Dan Kegel  2012-06-01 11:10:44 CDT ---
The common use case is "I've got this one windows app...", not "I want to
simulate an entire windows system".

We can't rely on xdg-open being there yet because there are a lot of RHEL 5
systems out there.   Just yesterday I got grief from someone with a lot of
RHEL 5 deployed (and unable to upgrade to RHEL 6 for now), who was upset that
wine didn't build and run properly there.   So, until the installed Linux base
really does uniformly have xdg-open, we should support falling back to
gnome-open and kde-open.  It's not hard.

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

Julian Rüger  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

Erik van Pienbroek  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #40357|0                           |1
        is obsolete|                            |

--- Comment #19 from Erik van Pienbroek  2012-06-19 14:36:20 CDT ---
Created attachment 40611
  --> http://bugs.winehq.org/attachment.cgi?id=40611
shell32: Make ShellExecute use native file association databases (try 2)

Second attempt at the patch.
This revision adds support for detecting GNOME and KDE and using gnome-open or
kde-open when xdg-open isn't available.
Also a situation which could possibly introduce an infinite loop (which was
mentioned by Francois Gouget on the wine-devel mailing list) is now resolved

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

Erik van Pienbroek  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #40611|0                           |1
        is obsolete|                            |

--- Comment #20 from Erik van Pienbroek  2012-06-20 17:20:37 CDT ---
Created attachment 40631
  --> http://bugs.winehq.org/attachment.cgi?id=40631
shell32: Make ShellExecute use native file association databases (try 3)

Previous patch contained a possible race condition, should be resolved with
this revision

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

MestreLion  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #21 from MestreLion  2012-10-08 17:38:56 CDT ---
I would LOVE to see this bug/enhancement in Wine. It would surely make
integration a LOT better.

2 points to consider:

- The detection of a native association pointing back to wine (to avoid
infinite loop, as mentioned in comment #19) must be smart enough to allow
associations to *different wine containers*. This would allow, for example, an
Eudora user to open psd attachments if Photoshop is installed in a different
wine "bottle"

- The behavior of ShellExecute to try native associations should be easily
disabled (via custom wine registry flag?), for those who want wine to remain as
an independent OS (as mentioned by comment #17, path 1).

IMHO, this enhancement should be enabled by default, but not not giving the
user an easy way to revert back to previous behavior would seriously hamper the
acceptance of this patch in wine.

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

--- Comment #22 from MestreLion  2013-04-28 23:35:14 CDT ---
I've made a small utility that scans MIME database (both system and user) and
register *all* known native mime-types in Windows registry.

It uses xdg-open to open if there is a default (native) application for that
mime type, otherwise uses packagekit to search for a package that can handle
that file (just like what Nautilus does)

By default it only registers native types that have no handler in windows
registry, but it can also override such associations (so, for example, jpeg
files are opened in native viewer instead of the default Gecko wine browser).
It can also ignore some extensions even if they have no handler in windows.

It tries its best to be winemenubuilder-friendly, meaning all associations it
creates is not published as native associations (or as x-wine-extension
mimetypes) by winemenubuilder, which would be ugly and potentially cause loops.
This is very tricky and not yet perfect, specially with mixed-case extensions
(.C and .c for example)

That said, I hope this script is helful for everyone:

https://github.com/MestreLion/wine-tools/blob/master/wine-import-extensions

Improvements welcome!

[Bug 12464] ShellExecute does not integrate well with external handlers

http://bugs.winehq.org/show_bug.cgi?id=12464

Maciej Kacper Jagiełło  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 12464] ShellExecute does not integrate well with external handlers

https://bugs.winehq.org/show_bug.cgi?id=12464

André H.  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #23 from André H.  ---
The original problem regarding PDF files is fixed by:
https://source.winehq.org/git/wine.git/commitdiff/3e997a75d3cae811e0f90c760c...

See also: https://bugs.winehq.org/show_bug.cgi?id=29916