Martin Gregorie <martin at gregorie.org> 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 > > >
On Fri, Apr 3, 2009 at 11:48 AM, James Mckenzie <jjmckenzie51 at earthlink.net> 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
> 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.
fcmartins <wineforum-user at winehq.org> 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> > > > >
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 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).
austin987 wrote:> On Fri, Apr 3, 2009 at 2:17 PM, James Mckenzie > <jjmckenzie51 at earthlink.net> 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. > > -- > -AustinCould 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 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 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...