I was very surprised when I first heard at //build/ conference that the heart of Windows 8 and its Windows Runtime (WinRT) wasn’t based on the .NET Runtime but… on COM – the good old Component Object Model. Microsoft had “parked” this technology for more than 10 years and pushed other technologies. Now this old beloved dinosaur is back. And then again – this is no surprise at all if you think about it. This step has many reasons and root-causes. I’ll try to show you some of them in this little blog post series…
Disclaimer: I don’t work for Microsoft and have no deeper insights, but that might help to get an objective opinion why things came the way they came.
To show that I need to go back to the beginning of my professional career as a software developer, when I learned the advantages and disadvantages of C++ and COM:
Part 1: In the beginning there was COM…
I started to program in the late 80s. My first system was an Amiga and my first programming language was Basic. Later on I tried out several other languages during my studies of computer science. I used Pascal, C and Foxpro for several jobs, before I got a friend of C++ and its OO and templating capabilities. I started to work with Borland OWL in 1993 before I became part of the Microsoft developer ecosystem in 1996 (Visual Studio 6, C++, MFC).
At the time I was part of a great team that was or at least felt “ahead of time”: we attended every TechEd in Europe and became big friends of component oriented software design with COM and ATL (ActiveX Template Library). Add STL (Standard Template Library) for some great containers. These technologies were our basis to create quite a big editing system which our small software company sold successfully to some major German newspapers.
We were big fans of COM-hero Don Box. Don still worked for DevelopMentor and held excellent talks about COM. I remember an inspiring COM talk of him while he was sitting in a bath tub on stage – legendary.
My team knew every single line of source code of the ATL libraries. Our system had well over one million lines of C++ code, divided into more than 50 COM components. The complete system was able to start up in about 3-4 seconds – fully functional, with a decoupled and cohesive design. We used nice features like “Edit & Continue” in our Visual Studio tool chain – we changed source files during a debugging session and the changes were applied while the system was running (try this in VS 2010 with a big C# solution…). Features like that were important for productivity. No, we didn’t use TDD at the time – that wasn’t yet “en vogue” in the late 90ies. Developer’s life was different – more experimental than nowadays.
Yet we had some pains with COM: you constantly had to convert between different string types like CString, BSTR, _bstr_t and char-Arrays. There even was a wild mixture of Unicode and ANSI strings with language dependent code-pages. COM features like VARIANTs and HRESULTs helped to bridge between C++ and VB, but caused a constant clash between the COM and C++ type systems. Yes – some of those dangers might come back at you with Metro-style apps – but I’m positive Microsoft will try to reduce that pain. But: you are still crossing language and runtime boundaries and you know: boundaries should be explicit…which they aren’t if too much “type projection” happens under the hood.
But back to the 90ies: COM uses reference counting instead of garbage collection. That means COM objects die exactly in the moment, when the last reference on it gets released. And: They never die if someone forgets to release its reference. But this was no problem in our projects, because we had defined strict rules, when to use smart or raw pointers. We just knew very well when to AddRef and Release interface pointers to keep resource handling clean. Boundaries were explicit – thanks to COM IDL (Interface Definition Language). But it was a lot of code to write.
Then there came .NET and many things became much, much simpler – and some got worse – but it took us some time to become aware of that point.
One thing in .NET was strange to me as an old COM veteran in the first minute: why do we need a garbage collector instead of strong and weak references and the good-working ref-counting? And why isn’t there a reliable built-in concept to manage resource types like file handles, windows handles and the like? Everything else was fine for me, but I didn’t like this new-up and forget concept. Yes, Microsoft introduced IDisposable, but that was half-hearted – a high-level framework concept for a missing feature in the .NET runtime. We as developers couldn’t enforce correct resource management anymore, if resources were shared. We also couldn’t enforce memory management if we needed it in restricted environments such as embedded systems. That was a lack of control and may be a tick too much abstraction.
I wrote emails to my heroes (Don Box and others) at the time, because I saw the limitations to build systems with low memory footprint or exact resource management, but nobody wanted to see the problems.
