2009/1/29 alex@centroidcafe.com:
Hi, I've been lurking on this list for awhile, thinking about how I could contribute to Wine.
I wanted to weigh in because I think this overall proposal is on the right track. Graceful handling of errors and crashes would provide a better user experience and potentially help increase the adoption of Wine by more casual users.
I don't know much about application fault/exception handling, but couldn't Wine just install its own top-level fault handler on each Wine thread/process? That way, each API call in Wine can mimic the crash behavior of Windows to satisfy applications like InstallShield, but if the application doesn't handle the exception, the global Wine handler will pick it up and handle it gracefully.
Please excuse me if I am totally off track here.
Microsoft did this kind of thing with XP (you can find documents mentioning this on the net, I don't have any references to hand at the moment).
With Vista they have gone the other way. In fact, in order to meet the Windows Logo requirements on Vista you need to turn off structured exception handling (SEH) in C++ exceptions and let the program crash without disabling the Microsoft crash dialogs [1]. That is, if you had:
try { ((int *)0) = 10; } catch (...) { print("null pointer dereference!\n"); }
using SEH trry/catch (/EHs) causes 'null pointer dereference' to be printed on the console window and without (/EHa) causes the application to crash, bringing up a "Report this problem to Microsoft" dialog. Therefore, Microsoft are now advocating a crash early approach to error handling.
Why is this important?
If you have an application that produces an error in method A that sends a return code back to B that passes it back to C that returns a different error code back to D where you report the issue, if that is caused by a bug in method B (i.e. by passing a NULL to A because a memory allocation failed) *how do you know*. All you know is that D reported an error foo.
If you instead did not do a NULL pointer check on the argument, you would have easily found that B is passing A a NULL argument - just attach a debugger to the program.
I had some code that worked perfectly happily on XP, but crashed on Vista. That was a bug in my code. I wouldn't have found it if Vista had kept to trapping errors.
This is not to say that it should crash everywhere -- a lot of the coverity issues are actually issues. In fact, these static analysis and valgrind tools do a better job at spotting issues because of the null pointer dereferences. These tools can track the issues back to the call site and tell you exactly where the problem occurred. You then check for null *there*.
- Reece
[1] http://www.google.co.uk/search?q=Windows+vista+guidelines+logo+crash&btn... -- "Certified for Windows Vista Requirements", section 3.2