“Now With More Crashes!”
Word 2007 crashing is a feature not a bug/DOS:
According to Microsoft developer David LeBlanc, crashes aren’t necessarily DoS situations: ‘You may rightfully say that crashing is always bad, and having a server-class app background, I agree. Crashing means you made a mistake, bad programmer, no biscuit. However, crashing may be the lesser of the evils in many places. In the event that our apps crash, we have recovery mechanisms, ways to report the crash so we know what function had the problem, and so on. I really take issue with those who would characterize a client-side crash as a denial of service.’
You can always count on Microsoft to provide a humorous bizarro-world view of software design. I don’t write to many documents with a word processor, I prefer to use wikis or some other web presentation application. But when I do use a word processor, I use OpenOffice. Every once in a while it renders a document oddly, but overall I am quite happy.
Are you an idiot or did you just misunderstand the article?
Someone purposely made a “corrupt” document in order to try to exploit Word 2007. But an Office function detected the corruption, threw an exception, Word let it go uncaught, and therefore crashed. It’s a good thing that the corruption was detected. If you don’t intentionally create corrupt documents, you’ll never run into this issue. And if someone gives you a corrupt document, then the document is already corrupt, so who cares if it causes a crash?
Sure, it would be better to catch all exceptions and dislay some appropriate error message, but anyone who knows anything about programming (which you clearly do not), knows that this is not always possible, particularly when dealing with legacy code. But detecting the error and throwing the exception is the main thing you want to do, and Word is doing that, as designed.
Pepe, relax. You’ll live longer.
—-
Years ago we got our hands on one of the first BeOS boxes at the startup where I worked. It was slick and for several of us, it was our first exposure to a dual-CPU box.
BeOS had (has?) a performance load app that showed each CPU as an activity meter, with a checkbox below. Clearing one checkbox shut off that CPU, turning it into a single-processor machine.
And clearing the other checkbox turned off the second CPU, halting the machine.
To some programmers, this was completely logical and correct behavior, no matter how hostile it seemed to an actual user.
No one uses BeOS now.
Woops. Didn’t mean for that to go to the MSDN site. Oh well.
I may be an idiot and I was being a bit hyperbolic (particularly since I wasn’t expecting the exposure) and my experience is with services not desktop applications, but
I do see this as a problem that needs to be fixed. Crashing semi-gracefully is certainly a better option than surrendering to an exploit. But it is not sufficient.
The number one rule in application design is “Don’t trust input”. Corrupt data input should not cause an application to crash! If corrupt or malicious code is detected it should be neutralized or ignored before processing/rendering occurs. This is not necessarily simple but it is a key element in secure programming.
I find it particularly disturbing that returning to a good state after invalid input is difficult. Having to do your own memory management with C obviously complicates the matter but if you check your input before processing you should be able to minimize the depth of the code stack (from exception to catch) and minimize the number of variables that are involved.
Again I may just be an idiot with no clue about desktop applications, but blind acceptance of crashing in a desktop application just encourages me to use web based apps more…
David LeBlanc originally said: “If you blew up my app, and I just don’t load that document again, big deal.”
Microsoft’s commitment to user satisfaction in a nutshell.