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

[Peter Dolding]

On Wed, Jun 24, 2015 at 9:42 PM, Damjan Jovanovic <damjan.jov at gmail.com> wrote:
> Hi
>
> In addition to being the popular Win32/Win64 PE executable format,
> .exe files can also be DOS 16 bit ME or NE executables, OS/2 32 bit LE
> executables, Win16 NE executables, as well as contain .NET code in the
> PE format. It's thus not even clear that Wine should open .exe files,
> as at least Mono and DOSBOX are better candidates for some of them.
This is a reason todo why I am suggesting.

By adding a exe.mainfest with wine data or exe.winemainfest file marks the
application as clearly to be opened by wine.

Technically Win32/Win64,  Win16 NE Dos ME or NE or .Net code could have
to be opened with wine.   Now out of these list Dos ME or NE and .Net at times
should not be run as wine and some must be run in wine or you break programs.
There is no marker.

Yes part of the wine data in a manifest will have to include flag this
is not wine.

Also just using MINE type does not tell you want WINEPREFIX the
application owns to.

> Additionally on the desktop we can use wine.desktop to open .exe files
> via MIME type match without needing root permissions to set this up,
> so I am not sure why binfmt-misc is necessary.
>
The reason why binfmt-misc format is failing is it is only a MIME match.
So the wine.desktop has all the same issues as binfmt-misc and a extra weakness.

Part of the reason why binfmt-misc requires root to set it up is the fact it
can assign permissions like file capabilities and LSM attributes from
what is recorded on the .exe file.   The.desktop solution cannot do this.

The result of using wine.desktop and .desktop files instead of being operational
with binfmt-misc is the use of CAP_NET_RAW and CAP_NET_BIND_SERVICE
on the wineloader program instead of on the .exe files themselves.

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.

I do not have windows to test with and I need someone to test is I can
place non Microsoft
schema in a .mainfest file without risking major trouble.  Or someone
suggest another way
I can tag the executable so the executable can in fact be run the
correct solution every single time.

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.

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.

Peter Dolding

>
> On Tue, Jun 23, 2015 at 8:44 AM, Peter Dolding <oiaohm at gmail.com> wrote:
>> For binfmt-misc to be workable a few things need to be known.
>>
>> 1) What version of wine
>> 2) What wineprefix
>> 3) What setting overrides.
>>
>> None of these can be done by environmental vars because binfmt-misc
>> might be directly executing the file.
>>
>> Windows compadiblity mode does not use the registry like wine does.
>> Instead it done in two horible halves.
>>
>> Half 1.   The   application manifest file.   The mainfest file may be
>> embedded in the .exe file or be .exe.mainfest
>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh848036%28v=vs.85%29.aspx
>> Yes this is where you set what version of Windows application was
>> designed to run with.   So running XP mode on Windows 7 is here.
>>
>> Half 2. Application Compatilibity Database
>> This is where it gets horible using shims on particular executables to
>> make broken executables work.   Also when this gets too large starts
>> slowing windows down as it searching the database to make applications
>> work.   Yes reason some old applications don't work with Windows 10
>> that worked with 7 is that their entries were deleted from this
>> database.
>>
>> To solve the problem I think we could get away with just Half the
>> manifest can include library overrides and some windows configuration
>> tweaks.   But we have problems the include library information wine
>> needs because of native and built-in libraries.   Due to the fact wine
>> is running on Linux and other OS's some of the configuration tweaks
>> are going to be wine dependant.   So we need another schema.
>>
>>
>> http://wiki.winehq.org/UsefulRegistryKeys
>> Because if Microsoft manifest would tolerate alien schema  really
>> everything under software\wine\appdefaults could be moved from the
>> registry to the manifest.   Advantage 1 this can be write protected
>> per application and second advantage possibility of embedding in the
>> exe itself.
>>
>>
>> Also for binfmt-misc support have in the schema the means to record
>> wineprefix and wine to use.   So the program starting wine
>> applications by binfmt-misc looks for either a mainfest or a
>> winemainfest file in the same directory as the exe to see what wine
>> environment the application should be running with.   If there is no
>> configured environment possibly ask user what wineprefix they do what
>> to run the application with.
>>
>> What I do not know is if Microsoft application manifest file will
>> tolerate an alien schema.   Don't have different versions of Windows
>> to test if Microsoft application manifest with a alien schema parts
>> works or just causes windows to throw error or just results in the
>> manifest being complete ignored.
>>
>> Now if Microsoft application manifest will not tolerate alien I have
>> to ask would creating own own like exe.winemainfest be acceptable.
>>
>> I do hope Microsoft application manifest will tolerate alien because
>> it would be really useful to have applications with a manifest a
>> values saying what versions of wine they were tested with by the
>> maker.   Currently there is no way for a application vendor to record
>> in the application they tested with wine.
>>
>> A lot of ways putting what shim modifications the application need in
>> the manifest would also remove having to look up a huge database.
>>
>> Getting binfmt-misc working also will remove having to use setcap on
>> wineloader instead of the .exe.   Also would make if someone set a
>> capicapity  limitation by logind not break every wine application just
>> because a few application where needing privileged operation..
>>
>> So this alteration would be getting closer to how Windows does stuff
>> and in the process making Linux integration better.
>>
>> Peter Dolding
>>
>>