While Windows lives, it's hard to see how COM will ever die.

| 5 Comments

This is a nice piece by Tim Anderson on why COM is still alive and kicking despite what all the .Net-heads would have you believe...

It always seemed to be pretty obvious to me that all the "COM is dead, long live .Net" hype was just that, hype. Whilst there are obvious advantages to using .Net for new projects there are a lot of projects out there in the wild where you can't just throw away all of the investment that has been made in COM. Also, as Tim points out, .Net doesn't really have replacements for all of the ways that COM has been used over the years... It doesn't come as much of a surprise to me that Vista still has COM deeply entwined and that new stuff coming out of Microsoft itself still makes heavy use of COM; just as I'm not at all surprised that the hype machines were off target about how Longhorn/Vista would be managed code from the ground up. This stuff may be "legacy" as far as Microsoft's hype generation crowd is concerned but it's going to be there for a long, long, time and don't be too surprised if Microsoft keeps using these legacy things in their own applications.

5 Comments

Hype machines eh? That's funny! Not really - I'm just a graphics enthusiast, as will be pretty clear if you take a look through my blog.

WinFX is pretty much as I described it in that article I wrote almost 2 years ago for ONDotNet.com. It is still true today that significant new chunks of functionality are written in managed code. The lowest layers of WCF (formerly 'Avalon') are still unmanaged, but a) that's a thin slice of the functionality and b) there's no documented unmanaged user mode API. (There's a documented driver API of course... But that's neither a COM nor a Win32 thing. It's much the kind of layering that I discussed in the article.) If you want to use WCF, the only published API at the moment is managed.

In principal they could document the boundary between the managed and unmanaged bits of WCF. But so far they haven't. I'm not familiar enough with WPF to know if that's even possible. The impression I've got from reading about WPF (formerly 'Indigo') is that there isn't a meaningful split that it would be useful to document there, although I could well be wrong - I'm not an expert on that bit.

The main thing that has changed between me writing that article and today is that managed APIs have turned out to be so important that Microsoft responded to customer demand to make these new managed APIs available on Windows XP and Windows 2003. Back when they first unveiled WinFX, the idea was the this transition to these new managed APIs would only be possible once you were running Longhorn - this meant it was likely to take on the order of a decade to before the transition got as far as the transition from DOS to Win32 has got so far. So if anything, the move in this direction has been accelerated - it means the transition to managed APIs is possible without Longhorn becoming widespread, and this has been enabled entirely because of customer demand.

That's not to say it'll happen terribly fast. It took DOS and Win16 an extremely long time to become irrelevant once Win32 became available. There's no reason to suppose the next phase will happen any faster once WinFX ships. (Particularly not given the way that the WinFX feature set has had to shrink as it lumbers towards release.)

Having read through that article just now with the benefit of almost 2 years of hindsight now, I think it stands up pretty well, particularly given how far off WinFX was at the time. As far as I can tell, the only substantial thing I got wrong is that I characterised WinFX as a Longhorn-only thing. It's certainly pretty misleading of you to imply that the article gets it completely wrong.

Note that I only ever said that "much of the new functionality in Longhorn" would be managed. You seem to be mischaracterising my article by suggesting I claimed that everything would be managed. If I had said that, I would have been wrong. But I didn't. I said much of it would be - specifically the new functionality exposed in WinFX.

And you're right about one thing - COM will never die. Neither will DOS. Some people are still actively developing DOS apps, because for some people the benefits of staying put outweighed the benefits of moving over. The same will be true of COM - it will live on alongside DOS for decades after its prime.

Ian

From your article.

"But just as DOS and 16-bit Windows applications were superseded by Win32 applications, so in Longhorn will Win32 become the "old way" of doing things. In Win32's place is a new API called WinFX (pronounced "Win Effects")."

I agree about the layered aspect and I quite expect that in the future more and more .Net code will be in a "managed subsystem" that doesn't build on top of Win32, what I don't really expect is that it's going to be the only way to access that functionality; even if it is at the start. Whilst Microsoft itself continues to build so much that isn't based on .Net I just can't believe that "managed only" will be a viable route.

In fairness your article was just one example of how the original 'first wave' of hype about Longhorn portrayed things; but I feel it was fairly representative of the general approach at the time. I realise that you were simply reporting on what was coming out of Microsoft at the time and that now that they've scaled things back a bit these early articles are effectively being taken out of context. That said, it always seemed obvious that Microsoft were biting off more than they could chew with the original Longhorn announcements; or at least spinning them into something bigger than they were...

The fact that COM and DOS and Win32 will all live on is something that some parts of Microsoft and some of the more vocal .Net fans seem to be keen to ignore. Sure the new stuff is good and it lots and lots of situations it's a really good choice (and I'm sure it sells lots of books and courses and consultancy) but one size doesn't fit all and for some situations a non-.Net route is the correct choice. If more .Net advocates acknowledged this fact then I'd be happier to take the hype with a pinch of salt.

I certainly agree that .NET is not the right solution for all situations. And I still do a mixture of .NET and non-.NET consultancy and development.

However, I find myself recommending non-.NET solutions less and less often. And that's not just blatant self-interest. :-) Quite the opposite in fact - if I'm on an hourly or daily rate, I make more money out of C++ solutions simply because it takes so much longer to get anything done... When I recommend .NET, it's always because I believe it offers better value for money for a client. (Or it enables me to make a more competitive bid for a project, depending on the nature of the engagement.) When I recommend a Win32 or COM solution (it's been a while since I recommended DOS...) it's usually because there was no choice.

In other words, it tends to be a case of ".NET unless you have a really good reason not to." And there are often good reasons, the number 1 reason being that there are some areas of functionality in the platform that .NET just doesn't reach. (Number 2 is: .NET not ubiquitous on your target systems and deploying it would be too painful. Number 3 is: target machines are old and decrepit, and the overhead of .NET is too high. This ranking is my anecdotal experience - your mileage may vary.)

I think of the managed/unmanaged distinction as being very similar to the user mode/kernel mode distinction. That may seem like an odd thing to say, but my background was originally in device drivers and real-time embedded systems, and I got into Windows through a hardware kind of a route. Back in the days when DOS was common and Windows NT a rarity, there was a whole world where writing code that poked around directly with the hardware was the norm. This in turn came with a bit of an anti-user-mode culture - people who were used to being able to twiddle bits in hardware resented the strait jacket of user mode. But as NT and its successors gained ground, the benefits of being protected from shooting yourself in the foot became more widely recognized in the Microsoft world, and nowadays, you only put the code you really have to into kernel mode.

I see dropping into unmanaged code as being not so very different from dropping into kernel mode: sometimes you have to, but it's a dangerous place to be, and you don't want to be spending any more time there than you have to. You might not be able to BSOD the machine with user-mode unmanaged code, but if you trash a server process, the effect is much the same: your service becomes unavailable. Users don't really notice much difference between "Service offline due to bsod" and "Service offline due to user-mode fault". And more insidiously, an exploitable buffer overflow bug in a user-mode process can be every bit as damaging as one in kernel mode if the user-mode process in question happens to contain sensitive data.

So just as I'd still recommend writing a kernel mode device driver where it's needed, I'd recommend COM and/or Win32 where appropriate. I regard both as fairly drastic, but sometimes unavoidable measures.

Given that, I stand by the section you highlighted. :)

As for "managed only" functionality - I'd argue that's already present. For example, ASP.NET does things for you that are not built into any of Microsoft's COM-based or Win32-based platforms. (Of course with sufficient effort you can get the IIS/C++ combo to do anything ASP.NET can do. But that's ultimately true of all the platform functionality in Windows - you can always write your own OS...) WPF and WCF enlarge the set of features implemented as managed code, but they're just further examples of this very slow but apparently steady trend that started three years ago.

Automation in general and Office in particular is an interesting one. Today, there isn't really a good managed story for this - the current VSTO doesn't feel like a clean solution, and it's not wholly clear how we're supposed to provide equvilant programmability for our own applications. As of Whidbey, it looks somewhat more convincing, but it still feels like managed code is a bit of a 2nd class citizen, and it also still feels like Office is the special case here. (WPF introduces a managed-only automation framework, so perhaps that's the long-term direction of this kind of thing, although I've not looked into that in enough detail to know for sure. It hasn't yet been proven to be able to support something as powerful as Office.) I don't know what the plans are for the next version of Office, but I would be very surprised if it didn't show clear signs of a gradual move towards deprecating the COM way of doing things though. I guess we'll get to find out soon enough though - I'll revise my outlook if it turns out that COM is pushed as the perferred way of customizing the next version of Office!

But whatever happens, I confidently expect to be able to drive Office with COM 10 years from now.

I agree with you regarding your position on recommending .Net. I think, perhaps, my client-base is a bit behind yours. Most of my clients either have a huge investment in existing COM solutions and little experience in .Net or are still working on rather older hardware than I'd like them to be. Some just have some serious performance requirements for TCP/IP based server systems (and in some cases I'd like to be able to tell them of a managed solution but right now there doesn't seem to be a particularly good "managed story" for that either).

I like the user mode/kernel mode analogy and I see your point. Where a managaged solution is viable it's certainly likely to be a safer route to take for many developers. The problem is working out where it is viable and the excessive hype and hoopla doesn't help.

Thanks for your feedback.

As an aside...wonder how long it's going to take for WPF (formerly 'Avalon') and WCF (formerly 'Indigo') to actually be usable without the "formerly X" appendages. I'm guessing...a long time.

Leave a comment