In a recent post on interop in .NET framework, Jeroen Pluimers wrote “I don’t see COM as the first class citizen it was in the VB6 era.”
I always find it funny when the .NET camp start poo-pooing COM and dismissing it as yesterdays technology that some people just can’t seem to let go of (apologies to Jeroen if this was not his intention in this case).
I find it funny because .NET is essentially COM+.
Not the COM+ that was released/delivered as such, but what COM+ was supposed to be, according to a white-paper about COM+ that mysteriously disappeared before COM+ arrived in the form that it eventually did.
That white-paper talked about a lot of things that never made it into the COM+ delivery. Common type system, common language runtime etc. Some of the components in .NET were even delivered initially with the COM+ origins writ large in their identity, as shown in a screenshot of the Garbage Collector metrics available in PerfMon in this article from the early times of .NET framework:
.gif?w=895)
Garbage Collection is a strictly “.NET era” technology. COM+ as released didn’t have a GC. Yet in early .NET days the GC was listed as a “COM+ Memory” metric.
The exact same metric nowadays is listed under “.NET CLR Memory” .
Perhaps this will clear up the confusion and help explain why COM never went away, and indeed never could have.
Not Only, But Also
But how does this help us understand the Brave New World we find ourselves facing in Windows 8 ?
Well, I would suggest that talking about COM being a “first class citizen” in .NET is using a C calling convention when Pascal is required. That is, the arguments are in the wrong order. Indeed, one of the arguments isn’t even of the write type (that’s what you get for using a weakly typed language!) 🙂
The real question is whether the .NET runtime environment (and/or COM) is a “first class citizen” in the operating system.
COM is primarily nothing more than a specification, not a runtime, and Win32 implements that specification. Although lots of services are provided using COM (and expected of a COM component if it is to interoperate with other COM services nicely) and additional services implemented in compliance with the COM specification to build “macro services” that provide additional facilities that apps may take advantage of, a COM compliant application doesn’t need anything to exist in and of itself other than the core OS and to implement COM according to the spec.
Unlike .NET which is not just a specification but also a runtime environment, requiring a huge amount of scaffolding just to be able to initiate and launch even the simplest of apps.
Windows – even in Windows 8, despite the myths that the marketecture diagrams try to create – is still – at it’s core – an unmanaged, COM compliant OS.
It just happens to be provided with, and host, a .NET runtime which sits atop Win32 in exactly the same way that the Flash and Java runtimes are hosted environments on that same core OS.
It even hosts another new runtime called WinRT, which itself is an entirely new thing that takes a lot of ideas from .NET but which fundamentally builds on … yep, COM.
The Brave New World
So where does this leave us with the question of citizenship ?
Well, I would say that COM isn’t a “first class citizen”. It is far more than that (and yet also far less).
But I wouldn’t even say it is The President.
It is the Bill of Rights, where Win32 is the Constitution.
WinRT is a rewrite of the Constitution, but it is also a New Republic. A self-declared independent city state – Metro. Beyond the city limits, in The United States of Desktop the old Constitution continues to apply.
The City Republic of Metro and The Desktop States may have different constitutions (the one for Metro is much simpler – city states are much easier to govern than vast and diverse nations), but they share the same Bill of Rights. COM.
🙂
I believe that COM is every thing in Windows. It is very very deeply integrated in Windows.
So any language that does not support COM out of the box is a useless language.
Oh btw it is because of COM (in windows) that VB6 will always exist and software developed in VB6 will always run well in windows!
@Yogi Yang – ‘it is because of COM (in windows) that VB6 will always exist and software developed in VB6 will always run well in windows!’. Not really. VB5/6 sat on top of COM (every VB object was a dual interface COM object etc.), but that doesn’t guarantee anything in itself. Indeed, the fact VB5/6 had a bad habit of using not system DLLs directly, but COM wrappers of system DLLs means the old VB’er is reliant on MS not merely keeping binary compatibility with a very old versions of things like comctl32.dll, but further, various OCXs that sit on top of them. In contrast, since old (and new) VCL applications do not use COM helper libraries when the original DLLs can be called directly, they have one less thing to worry about.
@Chris, Yes probably you are right that VCL based apps being able to auto update to latest version of system based DLLs. That same case also exist for VB developers like us who always use third party ActiveX instead of default ones provided with VB. For example we always use CodeJock Xtreme Suite Pro and C1 Studio Activex.
As you may have known, almost all new system level features of windows are easier to access using their respective COM/ActiveX interface then by raw APIs.
But, but, my point was not that. My point was that because COM is very deeply embedded into windows so any development tool for Windows that does not support COM out of the box is nothing but an Oxymora.
@Yogi: my point was that a VCL application avoids the extra layer completely, unless the developer actively chose to use OCXs created for VB.
“OLE Automation is implemented on top of/using COM, but it is not *part* of COM.”
MS’ use of terminology ebbed and flowed over time. However, if you are trying to somehow equate ‘good COM support’ with ‘VB5/6’ (and you’re perfectly entitled to do so), it is surely wrong to see OLE Automation as an optional extra – remember, VB required (and VBA still requires) *dual interface* COM objects, i.e. the sort of objects designed for OLE Automation. Without an IDispatch implementation and a type library, it is impossible to use a COM object in VB. In Delphi, in contrast, you can create COM objects that don’t support IDispatch and/or have no type library, or conversely, create COM objects that *only* support IDispatch, and so cannot be accessed in an ‘early bound’ fashion.
@Yogi: gah, I slightly muddled up my replies to you and Joylon, sorry. The second point I was making to you was that while VB5/6 supported COM very well, it did so in a certain, relatively ‘high level’ way. If by ‘COM’ a person means only what Joylon does, then VB5/6 didn’t actually support it, since VB presupposed a fuller sense that incorporated technologies such as OLE Automation.
Thanks for the Opinions I asked for at http://wiert.me/2012/06/20/strong-name-for-interop-scripting-net-framework/
The main reason I don’t regard COM a first class citizen in .NET is not that COM and COM+ itself are bad, but that:
– many things written in COM are very badly developed
– investigating problems with COM is very very hard
– many people don’t know how to properly program against COM
I probably should have added that in my short post when I published it. Will add those later.
I don’t agree with your statement that .NET requires you to have a lot of scaffolding just to get started. The .NET runtime and framework includes most of what I need out of the box. Just as my other favourite environment Delphi does.
I’m not sure I follow your constitution/bill of rights thing. We only have the former. Maybe more on that later (:
The same list of problems can be applied to anything, including .net itself, so by that argument .net itself isn’t a first class .net citizen. Ooops. 🙂
The scaffolding I refer to in .net IS the framework and the runtime. Without those a .net app is a useless bunch of bytes. A COM app just needs the OS (which is also a pre requisite of the .NET scaffolding… that scaffolding is the unavoidable extra that is needed, exactly like the Flash player or Java runtime scaffolding for those environments)
Whereas COM is built right in to the OS.
The Bill of Rights/Constitution reference is US specific, where the Bill of Rights is the first 10 amendments to The Constitution. Not perhaps the best analogy, but on this occasion the usual standby of automotive analogy failed to make an obvious case for itself. 🙂
“The scaffolding I refer to in .net IS the framework and the runtime. Without those a .net app is a useless bunch of bytes. A COM app just needs the OS ”
I don’t think that’s really true, though it depends what you mean by ‘COM’ exactly. ‘COM’ in the fullest sense involves lots of ‘infrastructure’ – the difference is that you have to put up the scafolding yourself, even if the design of the building is provided by the OS/Microsoft. Do I really have to remind you of things like the COM threading model…? Even at the level of programming languages, the best experience in both the COM and .NET cases involves the language itself being reworked. D2->D3 may not have involved the breakages D7->D8 did, but the required new features were still significant.
As an aside, your ‘COM just needs the OS’ line is obviously pushing it when you go beyond Windows. Office for the Mac most certainly uses COM (OLE Automation in fact), but this is its own private fork of old Windows code, not anything provided by OS X.
“‘COM’ in the fullest sense involves lots of ‘infrastructure’”
No. You are making the mistake of considering all the “add-on” services that build and rely on the COM specification as part of COM itself. That is like considering the carpets part of the structure of a building… without the structure to hold the floors in place the carpets have nothing to rest on, but the carpets are not part of the structure.
OLE Automation is useful example, thank you. 🙂
OLE Automation is implemented on top of/using COM, but it is not *part* of COM.
Whatever you mean by “COM in the fullest sense” means something other than what COM actually is. COM is just a specification, but such a successful one that the technologies that built upon it became ubiquitous to the extent that many people now mistakenly think they were part of the original specification itself.
It also enabled some people to make some truly bad software. But that’s just true of computers in general. 🙂
You haven’t convinced my I’m afraid 😉 When Silverlight was said to have got ‘COM support’, for example, what was meant was that it could call OLE Automation servers in a ‘late bound’ fashion a la Delphi 2 in 1996 (e.g. this). Conversely, if you make use of the (very similar) COM support features built into Delphi and C# for interop purposes (on the Delphi side, safecall and WideString, together with the interfaces being all IUnknown descendants), I’d say you were leveraging COM support features, not COM itself.
On the other hand, I wouldn’t simply equate ‘COM’ with ‘OLE Automation’, like those slightly over-excited Silverlight bloggers from a few years back. Furthermore, the Delphi definition of an ‘interface’ is plainly by design the COM definition, and I wouldn’t disagree with the notion that IUnknown (and perhaps HRESULT) is all there is to ‘COM’ in a narrow sense – and a narrow sense of something is just as valid as a wide sense of the same thing.
Chris, I’m not trying to “convince” you, I’m merely stating the facts of the matter. Whether you accept them or not is up to you, but whether you do or not doesn’t materially alter the facts. 🙂
“a narrow sense of something is just as valid as a wide sense of the same thing”
Whatever “wide sense” you might be thinking of doesn’t change the fact that if that “wide sense” incorporates or rests upon a plainly false definition of something that is concretely defined in the narrow sense, then whatever else the wide sense may incorporate, a basic error is also part of that. That doesn’t mean the the wider sense – warts, errors and all – may not be sufficient in some contexts, but context is key.
i.e. when talking to a VBA macro jockey, it is simply easier to say “COM object” when you mean “OLE Automation Object”, and the distinction won’t matter because to a VBA macro jockey OLE Automation is COM. That is a misconception on their part, but it facilitates communication so we let it ride.
But when talking about development tools and technologies the context is very different, and letting such inaccuracies slide is nothing but a recipe for misunderstanding and confusion.
This blog isn’t written with VBA macro jockey’s in mind. 😉