5 ms·

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 thi

by andreyf 17y ago

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?

sriramk 17y ago
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
sachinag 17y ago
OTOH, this is why Apple locks down its platforms.
- pyre 17y ago
  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.
  - _pi 17y ago
    I think he was talking more about hardware.
    - rbanffy 17y ago
      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.
      - _pi 17y ago
        >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.
        rbanffy 17y ago
        Me neither. I can't call OSX core locked down except it doesn't go out of its way to provide hooks for malware.
        _pi 17y ago
swolchok 17y ago
"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?
- fh 17y ago
  Let's suppose that, for reasons of security and integrity, that's a really stupid idea?
  - rbanffy 17y ago
    Let's assume, from the current Windows security state of affairs, that this is precisely what was done.
    - potatolicious 17y ago
      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.
      - rbanffy 17y ago
        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.
- andreyf 17y ago
  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.
pavlov 17y ago
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).
- rbanffy 17y ago
  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.

by andreyf 17y ago

sriramk 17y ago

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

sachinag 17y ago

OTOH, this is why Apple locks down its platforms.

pyre 17y ago
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.
- _pi 17y ago
  I think he was talking more about hardware.
  - rbanffy 17y ago
    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.
    - _pi 17y ago
      >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.
      - rbanffy 17y ago
        Me neither. I can't call OSX core locked down except it doesn't go out of its way to provide hooks for malware.
        _pi 17y ago

swolchok 17y ago

"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?

fh 17y ago
Let's suppose that, for reasons of security and integrity, that's a really stupid idea?
- rbanffy 17y ago
  Let's assume, from the current Windows security state of affairs, that this is precisely what was done.
  - potatolicious 17y ago
    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.
    - rbanffy 17y ago
      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.
andreyf 17y ago
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.

pavlov 17y ago

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).

rbanffy 17y ago
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.