On Mon, 9 Dec 2002 vkxzjq6lg@cswebmail.com wrote: [...]
Being too free with "let the code crash" is a bad idea. Microsoft got a lot of really bad heckling in the Windows 3.1 era for GPFs. Wine doesn't want to crash if it's reasonably harmless to continue (like for a failed screen update). Does want to report the problem, of course, rather than silently ignore it, otherwise it'll never get fixed.
There is a very significant difference between Wine and Windows: if Wine crashes only one process is impacted. And if that process did something wrong then I think it's ok to let it crash. However, if Windows (3.1 or other) crashes (i.e. gives you a GPF or a blue screen of death), then: - all other applications die - all unsaved data of _other_ applications is lost - anything since the last flush to disk is lost - the filesystem may become corrupted
And it is these other effects that make GPFs and blue-screen of death unacceptable. Translated to Wine, this means that it is not acceptable for the wineserver to crash, but it's not so bad if a single wine process crashes.
That being said, if a Windows program works fine on Windows, then it should work fine in Wine, even if it does something stupid such as passing a NULL pointer to an API when it shouldn't. But for internal programming errors, crashing can be a good debug method: - it sure gets one's attention - it's supposed to generate a nice stack trace which you can use to complement the relay trace
Of course, that implies that we should promptly fix any such crash. Otherwise it just makes Wine unusable without any benefit.