How can we improve WINE?

James Mckenzie · Post by **James Mckenzie** » Fri Apr 03, 2009 11:49 am

Martin Gregorie <[email protected]> on April 3rd wrote:

On Fri, 2009-04-03 at 10:49 -0500, Austin English wrote:
This has been proposed a few times before, mostly a Dr. Watson type
debugger. A simple window to tell the user the program crashed,
however, doesn't sound as familiar. I don't think, however, you'd find
much support for it, and hardly anyone would want to spend time coding
it. If you've got a patch, however, the odds are improved.

Austin,

Is there any profiling information about the costs of generating
debugging output?

By that I mean the relative costs of generating the debugging lines,
writing them to a file/displaying on a console.

This is an interesting concept that you are exploring. I've never heard
of doing a cost analysis for providing users with error messages. I've
read of the opposite, the cost of not providing this information. The old
joke about the Mac error message "Like dude something went wrong and I
have to reboot to fix it" would in this day be considered insufficient for
troubleshooting. However, filling up a screen with a PE dump is just about
as useful to the average end user.

If the cost of generating the lines is insignificant compared to normal
Wine non-debugged operation, then I have an suggestion of a way to
proceed. I also have tested ANSI C code that I've used in other
projects and which may be useful.

I think the question is will a user be as happy running Wine in debug mode
where information is written to files as they would be with no debugging code.
Of course, running without is faster and more user friendly as you are not writing
constantly to the drive or screen. I like the method that WineHelper (one of the
more useful pieces from the Darwine project) uses: It does not do anything until
an error occurs as most programs do not output anything to stdin/stdout in graphical
mode. Thus program operation is not interfered with. An additional feature is that
the output of stdout/stderr can be dumped.

I would like to see better error handling, aka the Windows/MacOSX dump which captures
to a file and allows the user to report to Microsoft/Apple. The ignore feature is
one thing to be added.

James McKenzie

Martin

austin987 · Post by **austin987** » Fri Apr 03, 2009 11:52 am

On Fri, Apr 3, 2009 at 11:48 AM, James Mckenzie
<[email protected]> wrote:

I would like to see better error handling, aka the Windows/MacOSX dump which captures
to a file and allows the user to report to Microsoft/Apple. Â The ignore feature is
one thing to be added.

This has been discussed several times and dismissed on the fact that
no developers want to sort through that info. Plus, with the speed of
Wine development, that information would quickly be useless.

--
-Austin

fcmartins · Post by **fcmartins** » Fri Apr 03, 2009 1:32 pm

> I would like to see better error handling, aka the Windows/MacOSX dump which captures
> to a file and allows the user to report to Microsoft/Apple. Â The ignore feature is
> one thing to be added.

There are already plenty of bugs in the database waiting for attention

Which is not to say there is no room for improvement in the handling of crashes and user support. At least, the crashes should not be silent: a dialog box with some explanation, a text box where to copy output info from (alternatively show how to use terminal), point people to this forum. Make a bridge between appdb and wine, so that when a certain app crashes, an howto could be displayed, and/or a link to the appdb page is provided.

James Mckenzie · Post by **James Mckenzie** » Fri Apr 03, 2009 2:17 pm

fcmartins <[email protected]> wrote on Apr 3rd:

I would like to see better error handling, aka the Windows/MacOSX dump which captures
to a file and allows the user to report to Microsoft/Apple. Ã‚ The ignore feature is
one thing to be added.
There are already plenty of bugs in the database waiting for attention

I agree. The appdb should have enough intelligence to figure out when a duplicate report is submitted through this method. We don't have enough folks to triage bugs if this were the case.

Which is not to say there is no room for improvement in the handling of crashes and user support.

That is correct.

At least, the crashes should not be silent: a dialog box with some explanation, a text box where
to copy output info from (alternatively show how to use terminal), point people to this forum.

That might make people upset. However, they will have a place to send in reports.

Make a bridge between appdb and wine, so that when a certain app crashes, an howto could be
displayed, and/or a link to the appdb page is provided.

This is a good thought, but what happens when the application is not in the AppDB? Users are trying to use new programs all the time. Should we allow them to create a new entry and provide input? These are items for discussion.

James McKenzie

austin987 · Post by **austin987** » Fri Apr 03, 2009 2:24 pm

On Fri, Apr 3, 2009 at 2:17 PM, James Mckenzie
<[email protected]> wrote:

Make a bridge between appdb and wine, so that when a certain app crashes, an howto could be
displayed, and/or a link to the appdb page is provided.
This is a good thought, but what happens when the application is not in the AppDB? Â Users are trying to use new programs all the time. Â Should we allow them to create a new entry and provide input? Â These are items for discussion.

It's been discussed quite a bit on both wine-users and wine-devel. The
consensus was it's very hard to detect what program it is, e.g., even
for many common programs you have different versions/languages/etc. Do
you bundle the information with Wine? If so, it gets outdated quickly.
If you don't, what happens when a user doesn't have an internet
connection?

Looking up the information on AppDB isn't THAT hard, and developers
time is better spent fixing bugs rather than making an appdb bridge.

--
-Austin

fcmartins · Post by **fcmartins** » Fri Apr 03, 2009 2:45 pm

James Mckenzie wrote: I agree. The appdb should have enough intelligence to figure out when a duplicate report is submitted through this method. We don't have enough folks to triage bugs if this were the case.

In the case of a crash, the backtrack could be used as a sort of signature to spot duplicate reports. This in connection with context information (system, registry, wine specific config, hardware) could be fed into a database for pattern matching/extraction. Not exactly a minor task, but I guess there is already stuff out there that could be reused, and could make an interesting student project (or Google Summer of Code).

At least, the crashes should not be silent: a dialog box with some explanation, a text box where
to copy output info from (alternatively show how to use terminal), point people to this forum.
That might make people upset. However, they will have a place to send in reports.

I don't follow this one. A silent crash is annoying for everyone, no?

I don't think there is a need to have to go to a browser to, open forums page, register if not yet done, etc.. Ideally, this could be done directly from "wine crash assistant". And while the user is typing in information, a search could be done on the background to retrieve forum entries and/or appdb entries. Yeah, I know, ideas are cheap

Make a bridge between appdb and wine, so that when a certain app crashes, an howto could be
displayed, and/or a link to the appdb page is provided.
This is a good thought, but what happens when the application is not in the AppDB? Users are trying to use new programs all the time. Should we allow them to create a new entry and provide input? These are items for discussion.

Sure, anyone can already create an entry. I think the only issue here is the registration, but I suppose this could be done in a single step (register+and create entry). Ideally, registration information would be kept in th user's wine registry? Actually, this could also be defined with winecfg.

James McKenzie · Post by **James McKenzie** » Sat Apr 04, 2009 9:50 pm

Austin English wrote:

On Fri, Apr 3, 2009 at 2:17 PM, James Mckenzie
<[email protected]> wrote:

Make a bridge between appdb and wine, so that when a certain app crashes, an howto could be
displayed, and/or a link to the appdb page is provided.

This is a good thought, but what happens when the application is not in the AppDB? Users are trying to use new programs all the time. Should we allow them to create a new entry and provide input? These are items for discussion.

It's been discussed quite a bit on both wine-users and wine-devel. The
consensus was it's very hard to detect what program it is, e.g., even
for many common programs you have different versions/languages/etc. Do
you bundle the information with Wine? If so, it gets outdated quickly.
If you don't, what happens when a user doesn't have an internet
connection?

That, my friend, is the user's loss. I don't report every crash for
Thunderbird/Mac because I believe (rightfully so) that the bug is with
my Mac and not Thunderbird. We can provide the ability to send in
reports to Bugzilla, and even provide appropriate information, but we
cannot force users to utilize this method.

Looking up the information on AppDB isn't THAT hard, and developers
time is better spent fixing bugs rather than making an appdb bridge.

This may be considered a shortcoming of Wine. However, you are correct
in the fact that we need to concentrate on fixing the bugs that already
exist. I was looking for a simple "me too" without having to go through
the interface that Bugzilla provides and how hard it is to use by
newcomers. The idea is to reduce the number of duplicates without
presenting an interface like the APAR one used by IBM (it is horrible.)

James McKenzie

fcmartins · Post by **fcmartins** » Sun Apr 05, 2009 11:32 am

James McKenzie wrote: This may be considered a shortcoming of Wine. However, you are correct
in the fact that we need to concentrate on fixing the bugs that already
exist.

Obviously there are already plenty of bugs to be fixed and features to be implemented, but this is actually a resource problem, i.e.. how to get more.

I have the impression that at this time Wine's implementation is quite useful and many more people could be benefiting from it than actually are. The point being, a bigger user base brings more resources (people & money), and it could actually pay off at this stage to invest on improving Wine's usability (like suggested by Warren Dumortier and further ideas).

Warren Dumortier · Post by **Warren Dumortier** » Sun Apr 05, 2009 11:44 am

Little note...

On forums you can see a lot of users prefer to use PlayOnLinux, CrossOver,
Wind Doors, Cedega because of that. The first impressions for user with Wine
are not always positive, so we need to improve it...

Also, some long-existing bugs are still not fixed, for example the bug
"Mouse "escapes" window or is confined to an area in the full screen
program" is very annoying!

[Whining mode on]
Please can someone fix the bug with OffscreenrenderingMode to fbo and far
Cry 2?
^_^
[/off]
2009/4/5 fcmartins <[email protected]>

James McKenzie wrote:
This may be considered a shortcoming of Wine. However, you are correct
in the fact that we need to concentrate on fixing the bugs that already
exist.

Obviously there are already plenty of bugs to be fixed and features to be
implemented, but this is actually a resource problem, i.e.. how to get more.

I have the impression that at this time Wine's implementation is quite
useful and many more people could be benefiting from it than actually are.
The point being, a bigger user base brings more resources (people & money),
and it could actually pay off at this stage to invest on improving Wine's
usability (like suggested by Warren Dumortier and further ideas).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-us ... chment.htm>

DaVince · Post by **DaVince** » Mon Apr 06, 2009 4:48 am

austin987 wrote:On Fri, Apr 3, 2009 at 2:17 PM, James Mckenzie
<[email protected]> wrote:
Make a bridge between appdb and wine, so that when a certain app crashes, an howto could be
displayed, and/or a link to the appdb page is provided.
This is a good thought, but what happens when the application is not in the AppDB? Â Users are trying to use new programs all the time. Â Should we allow them to create a new entry and provide input? Â These are items for discussion.
It's been discussed quite a bit on both wine-users and wine-devel. The
consensus was it's very hard to detect what program it is, e.g., even
for many common programs you have different versions/languages/etc. Do
you bundle the information with Wine? If so, it gets outdated quickly.
If you don't, what happens when a user doesn't have an internet
connection?

Looking up the information on AppDB isn't THAT hard, and developers
time is better spent fixing bugs rather than making an appdb bridge.

--
-Austin

Could the AppDB possibly accept a hash of the executable file for identification on what program it is? That would solve this problem of linking through it from a crash window, except in the case of the entry not existing, of course. But then the user would get a quick option to enter the basic application data (name, executable file, language, version) so at least that (+ the app's hash for identification) is in place until a real entry is made.

austin987 · Post by **austin987** » Mon Apr 06, 2009 10:55 am

On Mon, Apr 6, 2009 at 4:48 AM, DaVince <[email protected]> wrote:

Could the AppDB possibly accept a hash of the executable file for identification on what program it is? That would solve this problem of linking through it from a crash window, except in the case of the entry not existing, of course. But then the user would get a quick option to enter the basic application data (name, executable file, language, version) so at least that (+ the app's hash for identification) is in place until a real entry is made.

Theoretically, sure. But you'd quickly have tons of duplicates,
especially for programs like WoW that change often.

--
-Austin

fcmartins · Post by **fcmartins** » Mon Apr 06, 2009 12:54 pm

austin987 wrote: Theoretically, sure. But you'd quickly have tons of duplicates,
especially for programs like WoW that change often.

I'm not sure I see a big issue here. AppDB already has the main section for the application and then entries for different versions. This is useful in general and for the majority of the applications. wow would fall under a minority of applications, not?

Of course the issue would be to bring all the versions under a same main application. I think some heuristics could help here, e.g. use the file name for grouping.

Warren Dumortier · Post by **Warren Dumortier** » Mon Apr 06, 2009 12:56 pm

2009/4/6 fcmartins <[email protected]>:

austin987 wrote:
Theoretically, sure. But you'd quickly have tons of duplicates,
especially for programs like WoW that change often.

I'm not sure I see a big issue here. AppDB already has the main section for the application and then entries for different versions. This is useful in general and for the majority of the applications. wow would fall under a minority of applications, not?

Of course the issue would be to bring all the versions under a same main application. I think some heuristics could help here, e.g. use the file name for grouping.

And everybody that will use a no-cd crack for example, this will
generate a ton of differente exe's for one program, but why not...

fcmartins · Post by **fcmartins** » Mon Apr 06, 2009 1:20 pm

Warren Dumortier wrote: And everybody that will use a no-cd crack for example, this will
generate a ton of differente exe's for one program, but why not...

Er, I had forgotten about the cracks. The hash could be done only on parts of the exe (e.g. 1st 1000 bytes) but then versions would not be correctly identified. Anyway I'm not sure it would be wise, for legal reasons, to report in appdb one is using a crack...