On Wed, Jun 24, 2015 at 9:42 PM, Damjan Jovanovic damjan.jov@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@gmail.com wrote:
For binfmt-misc to be workable a few things need to be known.
- What version of wine
- What wineprefix
- 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%... 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