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