By adding a exe.mainfest with wine data or exe.winemainfest file marks the application as clearly to be opened by wine.
FWIW Mono currently uses .exe.config files.
Also just using MINE type does not tell you want WINEPREFIX the application owns to.
In any normal case, an exe file that "belongs to" a wineprefix will be located in its C drive. That shouldn't be hard to find by traversing parent directories.
Yes setting up binfmt-misc requires root. But binfmt-misc is where non native Linux applications requiring Linux security permissions should start their execution path.
We shouldn't condone assigning security permissions to specific win32 exe files beyond what the user naturally has. Currently, we cannot protect the exe process from anything else the user does, so it's effectively the same as giving that permission to any user that can execute the file.
Of course, giving special permissions to wineloader is ALSO the same as doing that, but the solution is to give the permissions to the target program in some way that actually works, rather than switch to a different way that doesn't.
I would suggest running these programs in a dedicated account.
Really the MINE type usage by .desktop to run wine should disappear for Linux other than to tell the system to directly execute the exe.
The use of wine.desktop to run executable files is intentional and necessary. This is because Windows runs executables differently depending on whether they are invoked from the command-line or from the GUI (windows explorer). There are several differences, but the most important is that running from the GUI sets the working directory to the parent directory of the executable. Many applications rely on this behavior and won't be able to find their own files if they are executed from a different directory. Use of wine.desktop runs executables the way explorer does, which is appropriate when a user double-clicks the file.
We don't want to change the working directory when running an exe via the command line because windows doesn't do that, and because it can be important.
It's not possible for binfmt to determine how it was invoked, and thus which behavior it should use. AFAIK binfmt is generally configured for the command-line mode and is not suitable for GUI applications.
Binfmt can't tell us which interpreter to use with any more accuracy than the desktop environment, unless it's specifically configured by the user, and in fact binfmt has a harder problem to solve because it doesn't know whether to treat the exe as a GUI application (whereas we can assume anyone using wine.desktop to run a .exe file wants the GUI mode). At least with wine.desktop, this can be configured through the same GUI that will be used to run the file, which wouldn't be possible with binfmt. For most users, that one setting will be enough.
For users that need to use something other than wine for only some .exe files, the sensible thing to do is create a shortcut (.desktop file, shell script, or whatever is most convenient) that does it in the right way. That has the advantages of being a generally useful skill that users are likely to already know or at least use again, and of not relying on the user to have binfmt configured in a specific way.
Even .desktop files to run programs under Linux should become super simple. Path to executable as enough. All the extra complexity in the .desktop files for Linux is a bug.
Generally .desktop files correspond to .lnk files, not .exe files. Links to executables are just one specific case. And more importantly, putting some configuration file next to a .exe would require user intervention, while we can create .desktop files automatically.