Len Holgate's Curriculum Vitae
More detailed information on some key projects I've been involved with.
From DLL's to COM

CardMaster - a COM application

Whilst working at Interlink I did some pretty low level COM work. We set out to write a replacement for an MS-DOS based card production system which was to run on Windows NT and 95. One of the biggest problems we had with the old system was that it was difficult to add support for new card production machines, or to adjust the software to make a new kind of card - smartcards for example. We wanted to be able to add support for new devices and card types as easily as you could add new printers to Windows.

The plan was simple. We already supported lots of devices and those drivers could be made into C++ classes relatively easily. All we needed to do was make these drivers into C++ classes and then wrap them in a DLL and load them when they were needed. At first I didn't know much about COM - the band wagon hadn't really started to roll at that point. I planned to use the technology that I knew - explicitly linking with DLLs that presented a uniform interface to the application. This approach worked, to a point, but there were problems. In the initial design it was difficult to know when it was safe to unload the driver, and the interface between the drivers and the application were cast in stone and the same for all devices no matter what functionality they supported. At that point, whilst I was beginning to design ways around these problems I attended a Microsoft Developer's Conference. COM was the big thing at the conference and it seemed to solve all of my problems. I returned from the conference and decided to investigate COM a little further. After a week of scouring web sites and reading MSDN articles I decided that COM was the way to go and that we should turn all of our drivers into COM objects.

The problem with COM at that time was that there were no really good, really straight to the point, introductory texts available. Since we didn't want all of our programmers to have to fight their way to COM mastery I decided to write a C++ class framework to make the creation of drivers for our product easier. At the time the ATL was not widely available and did not provide an easy enough route into COM for the uninitiated. The plan was the same and now we had some devices that we supported with C++ drivers. We didn't want to lose any of this work. We didn't want everyone to have to know COM inside out and we didn't want to use MFC to do the COM for us. So the COM Driver Library was born...

The initial goal of the COM Driver Library was to make it easy to turn any existing C++ object into an in process server. After all, all you should need to do is provide an interface to the object and stick it in a DLL, it's hardly complex. I didn't want us to have to change the code we already had too much so the standard Microsoft routes to COM were out - both multiple inheritance and nested classes were too invasive.

The end result was a class library that provided the developer with proxy classes that would allow existing classes, and classes derived from specific library base classes, to expose COM interfaces in an easy to code manner. In addition, "COM manager" classes linked with the library's support for the standard in-process server DLL entry points to provide an easy way to add multiple COM objects to a single DLL package. The COM manager's also handled registry registration to standard COM requirements and additional registration for each different type of driver that was supported. This allowed the applications to locate all of the drivers of a particular type; card production device drivers, encryption device drivers, card making drivers, report printing driver, etc.

One major advantage in the resulting design was that the knowledge about various aspects of the card production process was localised. Device drivers knew how to speak to their devices and supported a set of interfaces for connection to an application. The knowledge about what went into making up a particular kind of card e.g. a VISA standard magnetic stripe cards or totally proprietary smart cards, was also kept isolated in a single COM object. This object could support several interfaces that the application would know about, but would likely communicate with any devices that it required through interfaces that only the card making object and the device driver object knew of. This allowed us to add new kinds of card that required new device drivers with completely unexpected interfaces between the two without having to alter the code of the application.

The library also supplied standard object factories, including the licensing support of IClassFactory2 if required; templatised interface implementations - so that developers didn't often need to code up the standard interfaces for their object proxies and provided an easy way to write an extensible application. Of course, looking back I'd do some things a little differently, but then isn't that always the case?

Since leaving Interlink I've continued to use COM via home-brew class libraries, MFC, and the ATL. I think it's great for building applications from self-contained components.

Copyright (c) 1998 - 2000 JetByte Limited.
Comments and suggestions to the Webmaster.