Engineering Windows 7: What we do with a bug report? | Hacker News Reader

Engineering Windows 7: What we do with a bug report?

blogs.msdn.com

29 pointstlrobinson17 comments

Summary: we still can't reproduce the issue, but we're trying all kinds of things.

Nice to see how a large organization handles these kinds of reports, but this part really bothered me:

...one day unexpectedly Word started crashing for people. We hadn’t changed anything. It turned out a new version of a popular add-in released and the crash was happening in the add-in, but of course end-users only saw Word crashing.

Yeah, stupid users. They only saw Word crashing... but wait, Word was crashing. Sounds like there's a bug in the plugin system - just as applications shouldn't crash the OS, plugins shouldn't crash an application.

Hell, GMail warns me about slowdowns when I load it with Firebug is enabled - taking responsibility and acting on a brower add-on which is affecting a web app's user experience seems the wiser way of dealing with issues than blaming the user.

Summary of last part:

Please don't hate us, interwebs. You messed up Vista's PR glory, please don't mess up Windows 7. Did we mention it might be a hardware problem?

"Yeah, stupid users. They only saw Word crashing... but wait, Word was crashing. Sounds like there's a bug in the plugin system - just as applications shouldn't crash the OS, plugins shouldn't crash an application."

Let's suppose that, for reasons of performance and plugin developer convenience, you really want plugins to run in-process. How do you propose to prevent them from crashing the application?

Let's suppose that, for reasons of security and integrity, that's a really stupid idea?

Let's assume, from the current Windows security state of affairs, that this is precisely what was done.

I'm not sure - besides the "I told you so" suggestion of having not done something stupid like that, the only other solution is to fix a showstopper crash is to issue a patch that will blacklist (and thus not load) the plugin, and inform the user.

Perhaps, another solution would be to custom build a plug for blacklisted extensions that isolates the main process better with some added processing overhead, something like a "fake in-process" thing.

I'm not sure if I understand what you mean by "developer convenience" - it seems that to maximize developer convenience, it's best to write plugins in an interpreted language like JavaScript (or as might be more appropriate for the time/place he's talking about, VB6).

As far as performance, the tradeoff just doesn't seem worth it - sure, interprocess communications have overhead, but at least Word doesn't crash because someone else wrote bad code ;) This seems really obvious once you get your head out of the technology - for a computer user, the crashing of a word processor is probably pretty high on the "worst things that can happen" list. A plugin not working fast enough is really, really low.

The Firebug analogy isn't valid since Gmail hardcodes a check. I would be surprised if Gmail detects it even if you renamed the extension to something else and still produced the same behavior. The meta point here is that you can only warn for known bad plugins

Binary plugins have the ability to crash the host application regardless of platform. Sometimes they can be contained in a separate process (I think Apple does this with 10.5's QuickLook plugins to prevent them from crashing Finder), but that's not always an option due to interprocess communication overhead or shared state that can't be easily distributed (e.g. windows on OS X).

If the interprocess communication makes it too slow, then you should change tem implementation. Running unknown code in-process is a no-no by my book and it is a big cause for a whole lot of security problems.

OTOH, this is why Apple locks down its platforms.

So that Apps don't cause the OS to crash? 'OSX' on the iPhone must be pretty flakey then... The only time I can ever remember OS crashes on OSX were from the smbfs driver (and sometimes the nfs driver) which would regularly cause kernel panics on earlier versions of OSX.

I think he was talking more about hardware.

I don't think so.

Apple has enjoyed the fact less companies target OSX and, assuming the same competent to incompetent developer ratio for both platforms (something risky in itself, because the barriers of entry for Windows are much lower), it would be no surprise if there were less buggy programs for OSX.

Also, OSX is a bit older than the current Windows platforms. Don't forget OSX is a direct evolution of the NeXT operating system and that makes if a good four years older than Windows NT. It also builds on both the Mach microkernel and the BSD more conventional kernel, so, its plumbing is a tad more mature too.

>Apple has enjoyed the fact less companies target OSX and, assuming the same competent to incompetent developer ratio for both platforms (something risky in itself, because the barriers of entry for Windows are much lower), it would be no surprise if there were less buggy programs for OSX.

You can't say there's less buggy programs because it's hard to break through. You can say there's less buggy programs because there's less programs in general, which is a much more rational assumption considering you assumed that there's the same ratio for competent to incompetent developers thus making about the same ratio of buggy to polished programs.

However I don't see how Apple's Kernel really is "locked down", I interpret that as a forced cull of functionality for safety or in terms of things like DRM. The only thing I'd consider is the lockdown of the hardware because of forced lack of choice.

Me neither. I can't call OSX core locked down except it doesn't go out of its way to provide hooks for malware.

Depends what you'd call "hooks". In terms of the Windows API there are some really cool really useful dynamic features in the toolkit, but they're obviously borderline virus/malware type functions. (IE read the text of the entire window if you have a WID).

Stuff like that is standard to any toolkit. However what you may be talking about is that bullshit they call the Windows directory and Windows Protective Service where it doesn't let you modify it directly but it's easily modified programmatically.

Reply on news.ycombinator.com