Proposal: to make binfmt-misc with wine workable and make Wine compadiblity modes more like Windows compadiblity mode.

[Vincent Povirk]

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