Hosting .Net takes me back to the 'Good ol' days of COM'

| 0 Comments
It's interesting, no, really, how the more things change the more they stay the same... I've been doing COM for a long time. I first discovered COM back at Interlink when I was writing a windows version of a product call CardMaster which did credit card production. The system supported lots of different machines and each of these machines needed different drivers, the drivers were written in C and usually spoke to the machine via a serial port. In the DOS (actually Concurrent DOS, but...) version of the product I'd used structures of function pointers that the driver populated during an 'open()' call and which were returned to the application so that the application could use this 'opaque' structure to access these machines polymorphically... Think v-tables without the rest of C++...

Moving on to the windows version I knew that I wanted to package each driver in a dll so that we could ship new drivers to users without needing to send them a complete new build of the product... I'd worked through the whole LoadLibrary(), GetProcAddress() malarky and had a rather nice design that provided multiple interfaces to drivers but had two small holes in it; it was hard to manage the lifetime of the dlls so that they stayed loaded for the right amount of time and I had to come up with a couple of interfaces that would represent all drivers forever as it would be a pain to have to change all the drivers if I changed the interfaces.

Just at this point in the development I went to a Microsoft conference. The hot new thing was COM, it seemed very similar to what I'd been designing and solved the dll unload problem with reference counts on the interfaces and the interface evolution problem with dynamic discovery using QueryInterface(). I bought Inside COM, ripped out my custom dll loading system and embraced COM; complete with tear off interfaces and my own COM library that provided the boilerplate implementations for factories and IUnknown, etc. COM was easy then, most, or maybe all of it was in process and marshalling was easy... So easy that often the rules of COM were broken and we developed in process interfaces that could never be marshalled out of process due to data types or design features used...

Time passed. I worked at CSFP which became CSFB and we did a lot of COM. Things were getting more complex, marshalling mattered, most of the time, dodgy designs started to fall away and things were good; well, most of the time, developing OLE-DB providers was definitely not a 'good' period ;). COM contiunued to get gnarly and hairy and more complex and eventually had a + added on the end...

I haven't done much COM recently, but hosting the CLR in The Server Framework requires COM to communicate with it... What I'm finding is that working with the CLR COM interfaces and exposing C++ code to the CLR via COM makes me feel like I'm working back in the, ahem, good ol' days of COM, that is right back at the start before it got all hairy... I'm not quite sure why...

Leave a comment

About this Entry

VS2008 Beta 2 first impressions was the previous entry in this blog.

See the "What About .NET?" sidebar... is the next entry in this blog.

I usually write about C++ development on Windows platforms, but I often ramble on about other less technical stuff...

Find recent content on the main index or look in the archives to find all content.

I have other blogs...

Subscribe to feed The Server Framework - high performance server development
Subscribe to feed Lock Explorer - deadlock detection and multi-threaded performance tools
Subscribe to feed l'Hexapod - embedded electronics and robotics
Subscribe to feed MegèveSki - skiing