Hi,
One of the reasons why Linux distributions do not want to include Wine by default is because compatibility issues may result a bad impression of the quality of the OS. Users think Linux sucks because their Windows application does not run (as good) under Wine as it does under Windows.
Problem: Windows applications ran by Wine do not always run without issues and the user does not know why. Hence, (s)he will think this is because Linux is less stable than Windows.
What do Wine coders think about solving the issue by adding a user feedback interface to Wine? It may for instance work like this:
* By default open a user feedback dialog after the application is closed (or crashes). In this dialog, the user will be explained why this dialog is shown, and why he might have experienced bugs or crashes in the Windows application. The user also can provide text feedback and other types of feedback (e.g. a checkbox saying "The application crashed"). * The user has the option to send this information to the Wine project by hitting a button. Gathered information will be integrated in the Wine application database and can be helpful for Wine coders and users.
Advantages: * Users will better understand why their application did not run as well on Linux as on Windows. * Wine will become more interesting to be actively supported by Linux distributors. * Users will feel they easily can contribute to the Wine project. * The Wine project will receive more feedback.
Other subidea: Create a database with hashes of .exe files. Wine can consult this database *before* it executes a Windows binary and provide the user with feedback like this: "Remark that 60% of users were not satisfied when running this application in this Wine version. Do you want to proceed?" Or like this: "This application has these issues: ... Do you want to proceed?"
-- Kind Regards, Sander Devrieze.
2008/12/16 Sander Devrieze s.devrieze@linux.be:
Hi,
One of the reasons why Linux distributions do not want to include Wine by default is because compatibility issues may result a bad impression of the quality of the OS. Users think Linux sucks because their Windows application does not run (as good) under Wine as it does under Windows.
Problem: Windows applications ran by Wine do not always run without issues and the user does not know why. Hence, (s)he will think this is because Linux is less stable than Windows.
What do Wine coders think about solving the issue by adding a user feedback interface to Wine? It may for instance work like this:
- By default open a user feedback dialog after the application is
closed (or crashes). In this dialog, the user will be explained why this dialog is shown, and why he might have experienced bugs or crashes in the Windows application. The user also can provide text feedback and other types of feedback (e.g. a checkbox saying "The application crashed").
- The user has the option to send this information to the Wine project
by hitting a button. Gathered information will be integrated in the Wine application database and can be helpful for Wine coders and users.
Advantages:
- Users will better understand why their application did not run as
well on Linux as on Windows.
- Wine will become more interesting to be actively supported by Linux
distributors.
- Users will feel they easily can contribute to the Wine project.
- The Wine project will receive more feedback.
Other subidea: Create a database with hashes of .exe files. Wine can consult this database *before* it executes a Windows binary and provide the user with feedback like this: "Remark that 60% of users were not satisfied when running this application in this Wine version. Do you want to proceed?" Or like this: "This application has these issues: ... Do you want to proceed?"
-- Kind Regards, Sander Devrieze.
Sander,
This conversation has been had many times before. Some of the issues mentioned previously for why this hasn't been done are as follows:
1) User generated crash reports are not always high enough quality to be usable 2) Users capable of putting in the effort to help fix issues generally already use the AppDB and are indeed helpful. 3) No development area has claimed a need to simply have a ton of crash dumps or user information in order to help make progress.
The problem is that Wine is developed by first understanding the problem of a specific function via blackboxing windows with a test and then making wine conform to that blackbox behavior. Often which function to chose is either motivated by a specific application malfunction that a developer is already working on or just to in general improve a specific library. In other words most devs have lots of itches to scratch already and are working on those. Simply throwing more input of the form 'this doesn't work' sadly doesn't help this form of project most of the time. To allow users to "Send Error Report" (in the microsoft sense) would be a sham I think.
Regression tests are very helpful to fix specific problems users face however most users are not willing to provide that due to skill/time/lazyness/etc.
--Zach
Sander Devrieze wrote:
Hi,
One of the reasons why Linux distributions do not want to include Wine by default is because compatibility issues may result a bad impression of the quality of the OS. Users think Linux sucks because their Windows application does not run (as good) under Wine as it does under Windows.
Problem: Windows applications ran by Wine do not always run without issues and the user does not know why. Hence, (s)he will think this is because Linux is less stable than Windows.
What do Wine coders think about solving the issue by adding a user feedback interface to Wine? It may for instance work like this:
- By default open a user feedback dialog after the application is
closed (or crashes). In this dialog, the user will be explained why this dialog is shown, and why he might have experienced bugs or crashes in the Windows application. The user also can provide text feedback and other types of feedback (e.g. a checkbox saying "The application crashed").
- The user has the option to send this information to the Wine project
by hitting a button. Gathered information will be integrated in the Wine application database and can be helpful for Wine coders and users.
Advantages:
- Users will better understand why their application did not run as
well on Linux as on Windows.
- Wine will become more interesting to be actively supported by Linux
distributors.
- Users will feel they easily can contribute to the Wine project.
- The Wine project will receive more feedback.
Other subidea: Create a database with hashes of .exe files. Wine can consult this database *before* it executes a Windows binary and provide the user with feedback like this: "Remark that 60% of users were not satisfied when running this application in this Wine version. Do you want to proceed?" Or like this: "This application has these issues: ... Do you want to proceed?"
Let's be careful about what problem we're trying to solve.
If it's that users blame the distro when it's a Wine problem, then we can present them with some sort of information before installing (or perhaps running) Wine. After that we should get out of the way and let them use Wine as normal.
If the problem is that we're not getting enough feedback, then a default feedback nag might not be the best answer either. Writing an elaborate system to tell us about known problems isn't particularly helpful; reports from stable or nonlatest versions would be largely ignored, and users of the latest beta can be asked to contribute in other ways, such as on the download page itself.
Remember, it doesn't take much work for us to know that an application doesn't work - a single bug report can do that. Once we have that, we don't need to ask a million other users (literally) for confirmation.
Thanks, Scott Ritchie
2008/12/17 Scott Ritchie scott@open-vote.org: <snip>
If it's that users blame the distro when it's a Wine problem, then we can present them with some sort of information before installing (or perhaps running) Wine. After that we should get out of the way and let them use Wine as normal.
Wine should go out of way when the Windows application is known to run very well under Wine or when the user submitted feedback for this application in the past. Also, the user easily can skip the dialog.
If the problem is that we're not getting enough feedback, then a default feedback nag might not be the best answer either.
Writing an elaborate system to tell us about known problems isn't particularly helpful;
It shouldn't be an elaborate system: it can be as easy as asking the user to click on a button to send a list of API calls, used DLLs, a hash of the .exe binary, some critical information of his system, amongst others to the Wine project. User based input in the feedback form may or may not be a good thing; I just gave this as an example; it is no necessary element in what I am proposing.
I guess this kind of feedback can be very powerful to Wine coders to create statistics like these: * Most popular API calls * Least popular API calls * Most common API calls that make applications fail * Unimplemented features used by very uncommon software (e.g. custom-built applications within companies) * Predicting the likelihood that a specific API call will be used when another API call is used in an application
Maybe this information can be useful to detect which applications are affected by a bug in Wine. When this is known, testers can verify in multiple applications if the bug really is fixed in all applications.
reports from stable or nonlatest versions would be largely ignored, and users of the latest beta can be asked to contribute in other ways, such as on the download page itself.
Remember, it doesn't take much work for us to know that an application doesn't work - a single bug report can do that. Once we have that, we don't need to ask a million other users (literally) for confirmation.
Only geeks file good bug reports. Normal people don't care and will not spend energy on this.
-- Mvg, Sander Devrieze.
On Wed, Dec 17, 2008 at 2:10 PM, Sander Devrieze s.devrieze@linux.be wrote:
2008/12/17 Scott Ritchie scott@open-vote.org:
<snip> > If it's that users blame the distro when it's a Wine problem, then we > can present them with some sort of information before installing (or > perhaps running) Wine. After that we should get out of the way and let > them use Wine as normal.
Wine should go out of way when the Windows application is known to run very well under Wine or when the user submitted feedback for this application in the past. Also, the user easily can skip the dialog.
If the problem is that we're not getting enough feedback, then a default feedback nag might not be the best answer either.
Writing an elaborate system to tell us about known problems isn't particularly helpful;
It shouldn't be an elaborate system: it can be as easy as asking the user to click on a button to send a list of API calls, used DLLs, a hash of the .exe binary, some critical information of his system, amongst others to the Wine project. User based input in the feedback form may or may not be a good thing; I just gave this as an example; it is no necessary element in what I am proposing.
I guess this kind of feedback can be very powerful to Wine coders to create statistics like these:
- Most popular API calls
- Least popular API calls
- Most common API calls that make applications fail
- Unimplemented features used by very uncommon software (e.g.
custom-built applications within companies)
- Predicting the likelihood that a specific API call will be used when
another API call is used in an application
Maybe this information can be useful to detect which applications are affected by a bug in Wine. When this is known, testers can verify in multiple applications if the bug really is fixed in all applications.
It would take developer time and effort to analyze all these logs, and that time is better spent actually implementing those features and fixing bugs.
In a few years when Wine is more developed and has most the API implemented, this may be useful, but there's still a lot to do, and we don't need more reports to tell us this.
2008/12/17 Austin English austinenglish@gmail.com: <snip>
Writing an elaborate system to tell us about known problems isn't particularly helpful;
It shouldn't be an elaborate system: it can be as easy as asking the user to click on a button to send a list of API calls, used DLLs, a hash of the .exe binary, some critical information of his system, amongst others to the Wine project. User based input in the feedback form may or may not be a good thing; I just gave this as an example; it is no necessary element in what I am proposing.
I guess this kind of feedback can be very powerful to Wine coders to create statistics like these:
- Most popular API calls
- Least popular API calls
- Most common API calls that make applications fail
- Unimplemented features used by very uncommon software (e.g.
custom-built applications within companies)
- Predicting the likelihood that a specific API call will be used when
another API call is used in an application
Maybe this information can be useful to detect which applications are affected by a bug in Wine. When this is known, testers can verify in multiple applications if the bug really is fixed in all applications.
It would take developer time and effort to analyze all these logs, and that time is better spent actually implementing those features and fixing bugs.
Everything takes time and time also can be invested to save time in the long run.
In a few years when Wine is more developed and has most the API implemented, this may be useful,
It's better to already start gathering this information even if you don't want to look at it as it is like website statistics: it becomes more valuable when you have more data.
but there's still a lot to do, and we don't need more reports to tell us this.
A database is no report. It is something you can consult at any time, for example when you want to see if the bug that just has been reported also can be tested in other applications. I guess this can become very interesting when the bug reported found problem in a very expensive proprietary application and the database indicates the same bug may also cause a similar problem in another freely available application. This would make it easier for a developer without the very expensive application of the bug reporter to fix the bug.
-- Mvg, Sander Devrieze.
2008/12/17 Austin English austinenglish@gmail.com:
On Wed, Dec 17, 2008 at 2:10 PM, Sander Devrieze s.devrieze@linux.be wrote:
2008/12/17 Scott Ritchie scott@open-vote.org:
<snip> > If it's that users blame the distro when it's a Wine problem, then we > can present them with some sort of information before installing (or > perhaps running) Wine. After that we should get out of the way and let > them use Wine as normal.
Wine should go out of way when the Windows application is known to run very well under Wine or when the user submitted feedback for this application in the past. Also, the user easily can skip the dialog.
If the problem is that we're not getting enough feedback, then a default feedback nag might not be the best answer either.
Writing an elaborate system to tell us about known problems isn't particularly helpful;
It shouldn't be an elaborate system: it can be as easy as asking the user to click on a button to send a list of API calls, used DLLs, a hash of the .exe binary, some critical information of his system, amongst others to the Wine project. User based input in the feedback form may or may not be a good thing; I just gave this as an example; it is no necessary element in what I am proposing.
It would take developer time and effort to analyze all these logs, and that time is better spent actually implementing those features and fixing bugs.
Any logs like this would only be useful if they were automatically processed. For example, a list of top crashers could be produced, or something like the Kernel Oops report statistics.
In a few years when Wine is more developed and has most the API implemented, this may be useful, but there's still a lot to do, and we don't need more reports to tell us this.
The use in statistics here would be to know what crashes are most frequent (via automated tools). If these could be given an id (e.g. a sha1 hash) they could be associated with a bug report to show which crashes (that have a bug report) are more active. This could help with retesting a bug and testing if a bug is still active in the latest version of wine.
Taking a step back... there was a patch a few days ago to add a winewatson application similar to the drwatson program in Windows. This is a better way to go (at least initially) as it serves several purposes: 1. it shows people running wine applications directly instead of going via a command shell that something went wrong; 2. it allows wine to gather information such as terminal output and stack trace that the user can copy and paste in a bug report; 3. it allows the user to be pointed at the wine bugzilla page to report a bug if one does not already exist (including the terminal outbut and stack trace captured by winewatson), or confirm that the bug is still valid.
I think that this is all that is necessary and should satisfy the needs outlined here without being a burden to developers and fitting into the current way that bugs are triaged and processed. It should also help the more novice users create better bug reports.
- Reece
On Wed, 17 Dec 2008, Austin English wrote:
In a few years when Wine is more developed and has most the API implemented, this may be useful, but there's still a lot to do, and we don't need more reports to tell us this.
Keep in mind that the Windows API is a moving target. In a few years, the API will be no more completely implemented than it is today -- it will just be a different set of calls that aren't done than it is today.
Steve Brown sbrown7@umbc.edu
On Thu, Dec 18, 2008 at 8:07 AM, Steve Brown sbrown7@umbc.edu wrote:
On Wed, 17 Dec 2008, Austin English wrote:
In a few years when Wine is more developed and has most the API implemented, this may be useful, but there's still a lot to do, and we don't need more reports to tell us this.
Keep in mind that the Windows API is a moving target. In a few years, the API will be no more completely implemented than it is today -- it will just be a different set of calls that aren't done than it is today.
Steve Brown sbrown7@umbc.edu
Of course, didn't meant to imply that it will be complete at that time, but will be moreso than it is now, especially in regards to older API functions.
Austin English wrote:
On Thu, Dec 18, 2008 at 8:07 AM, Steve Brown sbrown7@umbc.edu wrote:
On Wed, 17 Dec 2008, Austin English wrote:
In a few years when Wine is more developed and has most the API implemented, this may be useful, but there's still a lot to do, and we don't need more reports to tell us this.
Keep in mind that the Windows API is a moving target. In a few years, the API will be no more completely implemented than it is today -- it will just be a different set of calls that aren't done than it is today.
Steve Brown sbrown7@umbc.edu
Of course, didn't meant to imply that it will be complete at that time, but will be moreso than it is now, especially in regards to older API functions.
I'm pretty sure we're catching up at this point. Wine development is getting faster, and the Windows API is changing slower - Microsoft does, after all, have to preserve backwards compatibility.
So, it's fair to say that even with the release of Windows 7 Wine's implementation of the API will be more complete. Especially the API for running the apps we care about.
Thanks, Scott Ritchie
-
Austin English -
Reece Dunn -
Sander Devrieze -
Scott Ritchie -
Steve Brown -
Zachary Goldberg