4 ms·

"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

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

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.