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

Damjan Jovanovic damjan.jov at gmail.com
Wed Jun 24 06:42:39 CDT 2015


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.

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.

Damjan


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



More information about the wine-devel mailing list