Drivers, plugins and other extensibility panacea

I’ve been always fascinated about drivers, plugins, etc. They allow you either to extend a system with new functionality or to use a system with pieces of hardware or software from different providers:
  • Back in the early 90′s when I was in college I wrote a program to make crosswords that I sent to a company which published them. I pressed a button once a month to make dozens of crosswords, the program sent them to my dot-matrix printer, I carried them to the publishing company and I got the money in my bank account some weeks later. When I graduated and I started to work in a real company I had to work 40 hours per week for the same money at the end of the month so life has not been so great in that regard since then ;-). The first versions of that MS-DOS program were monolithic, with all the code to generate different crosswords and to print to different printers inside the code. In MS-DOS you didn’t have the luxury of Windows drivers for printers, you had to send escape codes to the printer, which were different for IBM, Epson or HP emulations. Later I moved that code into driver files for crosswords and printers so the actual code of the program was reduced to the half.
  • Later in the college for graduating I had to make a MS-DOS program for digital imaging and again I spent a lot of time writing a mouse driver which worked with different graphic cards in resolutions higher than VGA (640×480), when Windows and its card drivers did not exist yet.
  • Later, then in the corporate world, I learnt about databases and the ODBC drivers. In fact, I gained a lot of experience working with the ODBC API.
  • Then I learned about source code control (SCC) systems and the MSSCCI plugins which allows an IDE to work with different SCC providers.
  • Then I learned about Visual Basic and Visual Studio add-ins and when I made the .NET version of my own MZ-Tools add-in I made it extensible through an MZ-Tools SDK and DLL plugins.
  • Visual Studio .NET allows you to use projects and code in different languages (VB.NET, C#, C++, etc.) and provides a unified extensibility model for all them so theoretically your add-in does not have to worry about the target language.

And so on… In a broad sense, you can also think about a kind of reverse plug-in: you have a piece of code and it works on different platforms. For example, a Java J2ME game to be played in different phones (I did a crossword J2ME game a couple of years ago) or an HTML page to be viewed in different browsers. In this case, the operating system or the browser are like plug-ins for your piece of code.

So, all this stuff of drivers, plugins and the such are great and make our life easier, don’t they? Well, not exactly:
  • If you have tried to make your program work with, say, Oracle and SQL Server you know that you cannot be database-agnostic. Despite all efforts put in ODBC, OLE DB, ADO, ADO.NET, etc. you have to know which database vendor you are using to deal with different server behavior, database driver or SQL syntax (despite ANSI SQL or ODBC syntax). And if you have tried to test your app with different ODBC drivers for the same database, for example the drivers for Oracle made by Oracle and the ones made by Microsoft, you know that they behave differently. The only solution for these two scenarios is to write your own abstraction database layer on top of the database driver to deal with the peculiarities of each database or driver.
  • Your experience printing to an HP Laserjet printer can be quite different in performance or output if you are using drivers from Microsoft or from HP. Technicians know what is a driver, what is a manufacturer, how to replace a driver, etc. but the end user doesn’t.
  • According to Eric Sink from SourceGear, which makes Vault (a replacement for SourceSafe), the planet will certainly be a nicer place to live when MSSCCI is a distant memory. In fact the new extensibility model for source code control providers in VS 2005 to overcome the problems of MSSCCI is to make your own provider from scratch, which is what Team Foundation Server does and what SourceGear plans to do
  • If you are going to use the extensibility model of Visual Studio .NET for a serious add-in, you are better off creating your own abstraction layer on top of it, with your own classes like SolutionEx, ProjectEx, ProjectItemEx, CodeElementEx, and so on because things are not the same with a VB.NET project or a C# project, not to mention a C++ project. You will find exceptions when calling methods in some languages, but not in others, or bugs in how a language implements its extensibility, etc.
  • The new Document Outline feature of Visual Studio 2005 theoretically should work with all kind of visual designers, since all components implement the IComponent interface and .NET 2.0 introduced the new ITreeDesigner interface to know the children of a control (better than Control.Controls). But it you look closely, you will notice that the document outline treeview is not the same for Windows forms and for HTML/Web forms. And even further, the document outline treeview for the new Visual Studio 2005 extensions for Windows Workflow Foundation (WWF) is also provided separately by the WWF packages. My MZ-Tools add-in provides a Control Explorer feature that mimics the Document Outline feature, but adds value with more options and a handy “most used properties” feature, so I spent a lot of time studying the Document Outline feature and trying to catch up with the new visual designers of VS 2005.
  • If you try to run a J2ME midlet in those actual phones of Nokia, SonyEricsson, Siemens (BenQ) or Motorola you will notice it does not work exactly the same (you can’t even rely on the software emulator of a phone) and you have to identify the phone brand and sometimes the model to deal with specific behaviors.
  • And what to say about different Internet browsers or different versions from the same manufacturer? …

So, drivers and plugins and extensibility are not the panacea, it’s quite tough, not for the faint of heart, but it is the price to pay for open (and cheap) systems and it is still an exciting world for a developer :-)