Versioning and plug-ins

Wow, quite a response to that last post!  And I was worried that nobody would read it...

PatriotB pointed out that role-forward is the only option if you support [in-process] plug-ins.  Plug-ins are another interesting topic; here, I think the long-term direction is clearer, even though there are serious short-term questions.  Long-term, consensus seems to be we should move towards putting plug-ins into a separate process or app domain.  Versioning and security play into this, but the biggest reason is reliability.  The biggest source of crashing bugs and hangs in Internet Explorer, by a large margin, is bugs in plug-ins and ActiveX controls.  Similarly, the biggest source of blue screens in Windows is device drivers.  Windows Shell has similar numbers, and I suspect the same is true of most of Microsoft's major plug-in models.  But when these plug-ins go bad, users don't know it was the plug-in caused the problem, so they just suffer and can't take any steps to rectify the problem. 

Security is also a reason, there's extremely limited mechanisms for mixing levels of trust within the same app domain, much better to put things into different processes/domains so you can give each of those plug-ins least privilege.  And of course there's the versioning aspects -- if it's in a separate process, the plug-in can use whatever versions of DLLs it feels like.  Now, that's not a panacea, because the plug-in still needs to talk to the main application through some version-independent interface, but an explicit cross-process interface is much more likely to be smaller and better designed for versioning than the typical in-process interface with lots of implicit semantics.  Finally, for managed code, processes and app domains are the only units for unloading a DLL from memory.  So for all these reasons, there's a general desire to go towards cross-process plug-in models.  That said, there's performance issues to overcome before that's a realistic option for all plug-ins, and obviously there's a pretty big compatibility consideration with existing plug-ins.  But I think that's the direction Windows will evolve in over the coming versions.

Marc suggests that some of these applications are doing stupid things and deserve to be broken.  I'll admit, sometimes it's hard to muster a lot of sympathy.  But I try fairly hard not to make these value judgments when doing compat work, because the end-user doesn't know anything about how the application was written -- all they know is app worked on Windows XP but doesn't work on Windows Vista, therefore I'm not upgrading to Windows Vista.  And that doesn't really help any of us...  The other thing that helps me get through the day is to realize all the hacks I've done -- none of us write perfect software, because the ultimate standard is whether it solves the customer problem at hand, not whether it's elegant/pretty/by the book.  That said, the more gross the compat change the more likely we are to make it a shim rather than part of the core product.  And part of the shimming process is an agreement from the application writer to fix the problem the right way in future versions.

Comments

• Anonymous
  November 02, 2005
  Indeed... we have entered a time where hardware is powerful and cheap enough such that we can move away from in-process extensibility to out-of-process extensibility. Performance and simplicity was really the only reason for in-process to begin with; security and in this case versioning will definitely require out-of-process.
  
  Looks like the shell is continuing to move in that direction. Over time they've remote-enabled many of the core interfaces (moving them from being hand-coded in shlobj.h to be generated in shobjidl.idl), and it looks like it's being continued in Vista.