Proposal: to make binfmt-misc with wine workable and make Wine compadiblity modes more like Windows compadiblity mode.
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
Hi, Non-developer speaking. I think most users would expect clicking an .exe file to result in Wine executing it "as usual", i.e. in the wine prefix pointed to by WINEPREFIX, as if `wine name.exe` were called. Wine should do what the user expects. Also, not all users want the same things. Different users might want to use different prefix configurations for the same application. The user might want different applications to use the same prefix. Overrides require additional software the user might not want or might not be legally allowed to use. Compatibility databases already exist in the form of Play on Linux and similar. Their approach seems better. In the long term, users should not ever need them. Also, application developers should not target Wine. The application should not try to behave differently because it is running on Wine.
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(a)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%... 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
On Wed, Jun 24, 2015 at 9:42 PM, Damjan Jovanovic <damjan.jov(a)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(a)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%... 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
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.
On 6/26/15, Vincent Povirk <madewokherd(a)gmail.com> wrote:
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. http://stackoverflow.com/questions/2916023/app-config-vs-appname-exe-config .exe,config is part of a general .net application. .config is not for application compatibility like exe.manifest is.
Finding a .config file does not tell you if the .net applications is for Linux or for .net inside wine or what version .net.
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.
That is presuming no symbolic or hardlinks in the process. Traversing directories is not dependable. So this part of the process you most likely want to pop up a Window/text on console asking user if tranvering is correct then record the users reply. Normal case is presuming user does not alter install directory of applications. Basically this is users have to do it your way or else. Instead of making the system as tolerant as possible. Like under windows installing on D: instead of C: is acceptable users install application on z: somewhere should also be acceptable So breaking solve by Traversing. So Traversing covers only a limited number of cases and is not dependable so should have user interaction if used. Yes I don't want to have to ask a user every time they run a executable if I have the right wineprefix.
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.
Please note setcap on a file can also block permissions. So you can make a program run with Less permissions than your current user. The fact this currently cannot work its both ways. http://linux.die.net/man/3/cap_from_text Most setcap for capabilities are done using the + operator but a - operator is supported to take capabilities away. So a setcap with all-eip is fairly run without any of the users assigned capabilities. So this is a double sided tech that cannot be used at the moment.
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.
Even switching away you have to know when the application has or has not got the permission. Using binfmt-misc the wine loader program still will be run first and it can still drop the flags. This is one of the advantages of capabilities. Even switching to another method you really do need to tag what applications are using raised capabilities.
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.
Yes but the reality here is it broken. Anyone using multi prefixes there is nothing to tell wine.desktop what prefix it should be.
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.
Also running command line program by gui there is nothing to tell wine.desktop at the moment it has it wrong. So this is another thing that is broken. There needs to be somewhere to record this. Is the program commandline or is it gui. The fact it not recorded causes failures.
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.
This is the point of having a manifest file. Yes a user may not be able to alter the binfmt-misc settings themselves. But the exe.manifest file is the users file. Some else a binfmt loader can in fact check a limited amount. http://linux.die.net/man/3/isatty This only returns true if the environment is text based interactive. Something started straight form KDE/Ghome/most Linux graphic file managers this will return 0. Ok it also returns 0 when running in a script. Also you have forgot very much that xdg-open exists. So assuming wine.desktop is GUI is a balls up as someone could have done xdg-open some.exe. Reality is by either .desktop or binfmt solutions you do need to run proper execution location determination or have some file recording what mode application should be running in. Yes you should be checking isatty in the wine.desktop case that is currently not happening so that the xdg-open case is handled correctly right? Ok now with xdg-open some.exe how are you going to tell your loader program that is gui or console..
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.
Ok so we expect users to be interactive. Great.
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.
What there is now a problem with users being interactive and doing things. Sorry you cannot have this both ways. Also most exe that users would be wanting to straight on click on will most likely be the ones that have lnk files. So when the .desktop file was generated so could have been the .manifest file next to the .exe. Even if .desktop generation was disabled by user the manifest could have been generated. Currently with lnk files to desktopl or nothing. Generating a file next to the exe would give us 3 options. lnk file to ,desktop and .manifest or lnk file to just .manifest or nothing. Basically binfmt-misc configurations are broken. wine.desktop is broken. Both go ahead and make massive presumes of 1 that the user will not be using multi wine prefixes/versions. 2 that the mode of execution will be 1 way or the other instead of recording user intent and probing. Peter Dolding
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.
Please note setcap on a file can also block permissions. So you can make a program run with Less permissions than your current user. The fact this currently cannot work its both ways.
Then I should note that the limitation works both ways as well: we cannot currently protect other wine processes from one that has fewer permissions than the current user.
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.
Even switching away you have to know when the application has or has not got the permission. Using binfmt-misc the wine loader program still will be run first and it can still drop the flags. This is one of the advantages of capabilities. Even switching to another method you really do need to tag what applications are using raised capabilities.
I don't see why this is. Can't the appropriate permissions just be assigned to the user that will run this software?
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.
Yes but the reality here is it broken. Anyone using multi prefixes there is nothing to tell wine.desktop what prefix it should be.
It's intentional that we don't expose multiple prefixes in the UI of plain Wine. The idea is that it should just work "like Windows", and Windows doesn't have any concept of prefixes. You just run your installer and then run your program from shortcuts. If you've set up multiple prefixes, you've already used the command line (or an external UI) to start a program in a different prefix, so you can certainly do it again.
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.
Also running command line program by gui there is nothing to tell wine.desktop at the moment it has it wrong. So this is another thing that is broken. There needs to be somewhere to record this. Is the program commandline or is it gui. The fact it not recorded causes failures.
If you started a program from a command line via wine.desktop, you've probably used xdg-open which doesn't allow command-line arguments. There is no good reason to do this (except if you know you want to start the program in the gui mode, and don't know about 'wine start /unix'). If you started a console application (which is NOT what I mean by a command-line program) via wine.desktop, Wine will create a console window for it, just like Windows. When I say "command-line program", I mean one designed to be invoked from cmd.exe, rather than explorer.exe. This is a case where being "like Windows" is the least surprising thing we can do. Normal people don't know that cmd and explorer start executables differently. However, they DO know how their software is intended to be used and will naturally use it in that way. Being better than Windows in some weird corner cases, and then only with user configuration, doesn't seem worth the complexity here.
This is the point of having a manifest file. Yes a user may not be able to alter the binfmt-misc settings themselves. But the exe.manifest file is the users file.
This is only worth it if we want to encourage use of binfmt with Wine, which I don't think we should do, given that the only known use case for binfmt+wine is one we can't functionally support.
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.
Ok so we expect users to be interactive. Great.
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.
What there is now a problem with users being interactive and doing things. Sorry you cannot have this both ways.
Your solution requires manual intervention all of the time, while Wine currently only requires that in some cases.
Also most exe that users would be wanting to straight on click on will most likely be the ones that have lnk files. So when the .desktop file was generated so could have been the .manifest file next to the .exe. Even if .desktop generation was disabled by user the manifest could have been generated. Currently with lnk files to desktopl or nothing. Generating a file next to the exe would give us 3 options. lnk file to ,desktop and .manifest or lnk file to just .manifest or nothing.
We can't automatically put random files in application directories next to executables. That's likely to break applications.
On 7/1/15, Vincent Povirk <madewokherd(a)gmail.com> wrote:
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.
Please note setcap on a file can also block permissions. So you can make a program run with Less permissions than your current user. The fact this currently cannot work its both ways.
Then I should note that the limitation works both ways as well: we cannot currently protect other wine processes from one that has fewer permissions than the current user.
Cannot currently is mostly that those cases have not had to be considered because they were not possibilities.
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.
Even switching away you have to know when the application has or has not got the permission. Using binfmt-misc the wine loader program still will be run first and it can still drop the flags. This is one of the advantages of capabilities. Even switching to another method you really do need to tag what applications are using raised capabilities.
I don't see why this is. Can't the appropriate permissions just be assigned to the user that will run this software?
Running software in a different user is not a normal Linux solution. Like ping you don't run that as a different user. Ping works because it been granted permissions. The fact that wine does not check capabilities. http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=capsh Run as a user with a capabilities binding set. The reality here is using setcap that does not require root privilage or using capsh as root to start executable as a particular user with a reduced capset. This is basically normal Linux that a user will be running applications of different capabilities. Binfmt-misc remove root user requirement change capabilities. Basically presuming that users and capabilities under Linux align is wrong. Please note starting wine by a bash script can also have giving wine more capabilities than it normally would have if the bash script had setcap applied to it.
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.
Yes but the reality here is it broken. Anyone using multi prefixes there is nothing to tell wine.desktop what prefix it should be.
It's intentional that we don't expose multiple prefixes in the UI of plain Wine. The idea is that it should just work "like Windows", and Windows doesn't have any concept of prefixes. You just run your installer and then run your program from shortcuts.
Except it never going to. At least inside the next 5 years. Works just like Windows is so wrong. Remember Windows 7 pro had Windows XP virtual machine. How did you declare that a executable should be in the virtual machine the exe.manifest file/compatibility mode. So the XP virtual machine is example of dual prefix under Microsoft. We wish to run a broader selection of application so multi prefixes should be expected.
If you've set up multiple prefixes, you've already used the command line (or an external UI) to start a program in a different prefix, so you can certainly do it again.
You have dropped to command line because you have been forced to so application work. Wine does not have a super complex shim system with Application Compatibility Database. Without a shim system usage of custom patched versions of wine will be required at times. Microsoft Application Compatibility Database has a limited size because once it gets past a particular size it starts slowing down running any application under windows. So the Microsoft method here is busted. That this solution is busted we cannot copy how windows does it or will will copy the exact same problem. Basically goes like this under Windows. 1 you request to run an application 2 it looks up the application compatibility database and lines up to apply all shim alterations. 3 it reads all the .manifest files to find out what library the application should see and. 4 At long last Windows decides to start running the executable. All the settings in the application compatibility database to avoid the expand to hell issue is place them in a file next to the executable. Yes stacking them in the registry per executable name has the same problem or worse. Why worse what happens when you have two programs that have installed a exe file with exactly the same name requiring different tweeks. Currently wine registry method of applying per application settings is broken. Microsoft Method is half broken. Why half broken the .manifest stuff of Microsofts works.
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.
Also running command line program by gui there is nothing to tell wine.desktop at the moment it has it wrong. So this is another thing that is broken. There needs to be somewhere to record this. Is the program commandline or is it gui. The fact it not recorded causes failures.
If you started a program from a command line via wine.desktop, you've probably used xdg-open which doesn't allow command-line arguments. There is no good reason to do this (except if you know you want to start the program in the gui mode, and don't know about 'wine start /unix').
If you started a console application (which is NOT what I mean by a command-line program) via wine.desktop, Wine will create a console window for it, just like Windows. When I say "command-line program", I mean one designed to be invoked from cmd.exe, rather than explorer.exe.
Note what you said here will create a console window instead of using the already open console. Yes there is a bug here.
This is a case where being "like Windows" is the least surprising thing we can do. Normal people don't know that cmd and explorer start executables differently. However, they DO know how their software is intended to be used and will naturally use it in that way.
Being better than Windows in some weird corner cases, and then only with user configuration, doesn't seem worth the complexity here.
This is the point of having a manifest file. Yes a user may not be able to alter the binfmt-misc settings themselves. But the exe.manifest file is the users file.
This is only worth it if we want to encourage use of binfmt with Wine, which I don't think we should do, given that the only known use case for binfmt+wine is one we can't functionally support.
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.
Ok so we expect users to be interactive. Great.
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.
What there is now a problem with users being interactive and doing things. Sorry you cannot have this both ways.
Your solution requires manual intervention all of the time, while Wine currently only requires that in some cases.
Until win64 works manual intervention to prevent users install applications that will work in win32 prefix in a win64 prefix that fail. Some cases by number of applications in the appdb its over 60 percent of cases are going to need manual intervention. This is not going to change any time soon.
Also most exe that users would be wanting to straight on click on will most likely be the ones that have lnk files. So when the .desktop file was generated so could have been the .manifest file next to the .exe. Even if .desktop generation was disabled by user the manifest could have been generated. Currently with lnk files to desktopl or nothing. Generating a file next to the exe would give us 3 options. lnk file to ,desktop and .manifest or lnk file to just .manifest or nothing.
We can't automatically put random files in application directories next to executables. That's likely to break applications.
The file I am talking about creating never before caused a issue under Windows. Windows compatibility mode does .exe.manifest files. If application provided one it does exe.1.manifest and so on. Of course it marks them hidden and these files have never caused a Windows application to miss read them. Why the Windows application never reads them. So creating .manifest file for compatibility reasons is obeying how Windows does things. Only time what I am suggest could cause a issue is a portable app on a USB key being taken back to windows. Adding a .manifest file contain extra stuff that wine understands will never cause a issue for the application itself being run under wine. It SXS and Windows compatibility under windows/wine that processes the exe.manifest file. Yes putting extra data in the .config file of a .net application could be problematic as some applications open and edit this themselves. No application edits it own exe.manifest file under Windows. Peter Dolding
participants (4)
-
Damjan Jovanovic -
Florian Pelz -
Peter Dolding -
Vincent Povirk