Com Is Love

This page has resonable discussion about COM / ComPlus and their role in MicrosoftDotNet. Maybe time for renaming it as ComLovedbyDotNet?

With the benefit of hindsight it is easy to say some observations made here in the past was a big sigh, a change done by Ward in Dec 2003.

We now (in Feb2004) know that COM will last well after the implementation of MicrosoftIndigo in WindowsVista, and with full confidence that editors in 2006 will find these statements tiring.

--dl

Like all good quotes, the following is quoted out of context:

COM is love. It is a religion.

COM is good for you.

But the opposite of love is not hate, it is indifference.

I posit that very few engineers are IndifferentToCom?.

ComIsLove is generally attributed to DonBox.

Com is NOT love, of course. Love is perfect. Com isn't. (by far)

Love is perfect?? That's interesting.

The word obviously has several uses in the English language. But even in matters of love (romantic), it is mostly misunderstood. Love can be perfect -- AgapeLove -- is. -- BrucePennington

COM, it would seem, is obsolete....

COM is dead, long live DotNet

The CommonLanguageRuntime which looks pretty new. For instance, it has a generational sweep and compact GarbageCollector (GenerationalGarbageCollection) - that's not something that you can build on top of COMs reference counting scheme. .NET also features installation technologies that do not require you to put anything into the registry, again that's pretty much anathema to COM. But later this afternoon I'm attending a PDC session entitled "Using Existing Code in the .NET Framework" - maybe I'll become more enlightened there. In the meantime I must say that everything I've seen here so far indicates strongly that COM is nothing more than a legacy now.

I think that the deal is that .NET is definitely not COM, but .NET isn't the whole story either. It seems that MTS is still completely COM based for instance. Still I wouldn't be surprised to find more and more Microsoft based on .NET and less and less based on COM going into the future. -- PhilGoodwin

Yup... the .NET platform really has nothing to do with COM anymore. Iterop with COM is however, 100% possible. .NET is really the next evolution of COM. Because a .NET object can be exposed as a COM(+) object, they are able to take advantage to ComPlus services such as JITA, object pooling, transaction voting, etc. Language interop is now handled by all languages being compiled to the same intermediate language called MIL or MicrosoftIntermediateLanguage. Overall, MicroSoft demonstrated over 15 languages running on the .NET platform ranging from CobolLanguage to EiffelLanguage to CeePlusPlus. -- DrewMarsh

From a Microsoft .Net developer regarding COM, COM+ in a CLR world: One little nit on this statement - the access of the COM+ 1.0 services (and all other services moving forward) will be seamlessly used by the CLR.

We are committed to making the CLR work as best as it possible can with the COM+ services. That sometimes means that we will rewrite them in managed code. That sometime means we won't.

com interop becomes something "bad" because it takes a few cycles (~50 I believe). If the work done *after* the COM interop switch is small (say again~50 cycles), then the COM interop layer is expensive, and should be avoided.

But when you are talking about services, there are typically multiple thousands of instructions (in fact transactions will typically cost you 2 disk writes)...so the cost of the COM interop is basically nothing, and the reasons to avoid it become something other than performance.

If the reason is that doing the interop "costs" you something (ie becomes less natural, there is some feature of the CLR that you have to give up, etc.) then we fix that.

-- Joe

Where did you get that COM and COM+ are not being carried forward into .Net technologies?

*sigh*

I own COM and COM+. Brian Harry owns the CLR. Both of us have been saying as loud as we possibly can that this is absolutely 100% *wrong*.

I know the message was somewhat muddled at the PDC (if it wasn't we wouldn't have to be saying it over and over again! <G>)

The problem is the definition of COM. Here is a summary of how COM/COM+ are affected by the .Net Framework.

COM and COM+ are many different things. It is a low level API based infrastructure that consists of APIs like CoSetProxyBlanket, AddRef, Release, QueryInterface, etc. It is a programming model that revolves around creating objects and calling methods on those objects (procedure oriented). And it is a set of services that sit on top of both of these things that apply and provide behavior to the objects such as synchronization, pooling, transactions, etc.

Over time, the .Net framework will replace the underlying goo. Everybody agrees that this is good.

However, the programming model is here to stay. The way it is implemented might change - for example, the procedural programming model might be built on top of a messaging layer, which programmers also might have access to. I believe the installed base of applications that depend on this type of programming (e.g. VBScript for Office, ASP pages, etc.) and the familiarity that programmers have with it means that this is here to stay.

The services are definitely here to stay. The requirements for them are not going to go away - anybody who writes a business app will likely need to use these services when they use the .NET framework. Our goal is to make accessing the services from the .Net framework as seamless and as easy as possible. We've made great strides for this in V1 of the .Net framework - there are custom attributes for virtually all of the services, we do automatic registration when unregistered components are created, etc. We plan to make this even better in subsequent releases of the products. We recognize that some of the benefits of the .Net Framework (like XCOPY install/uninstall, automatic memory management, etc) are currently reduced when using some of the COM+ services inside the .Net Framework. However this is a function of schedule and not intent. We will be working diligently to integrate these services with the .Net infrastructure and create a seamless experience for our customers to use the whole of the .Net platform.

It is important to understand that we are not throwing out the old and bringing in the new. We are refocusing our platform to empower the next generation of the web. In doing so we are leveraging all of the assets we currently have and the existing COM+ features are key to this platform. The DCOM protocol is an interesting issue. Clearly our story for the Internet is HTTP and SOAP. Some intranet scenarios will use this too because there is increasing use of firewalls to partition corporate Internets. That said, DCOM is a high performance binary remoting protocol and is valuable in some tightly-coupled scenarios. In fact the common language runtime object remoting services use DCOM for some remoting. We will have to see how this evolves in the future, but there will likely always be a need to a higher performance protocol than HTTP and XML.

If you have any more questions about this, I'm happy to answer them.

-- Joe

Thanks for the post. I read some of the other responses, and I hope everybody understands that I'm not trying in anyway to stifle any discussion or stop anybody from expressing their opinion. I was trying get my point across that "COM" means a lot of different things to a lot of different people. You gave a very coherent description of what I called the "goo" in my original post. This goo is evolving away. This is goodness. People will be able to build their applications in a much better environment. But I believe that COM is a lot more than that, and therefore saying "COM is Dead" doesn't make a lot of sense.

-- Joe

 -----Original Message-----

From: Jason Whittington [mailto:jasonw@DEVELOP.COM] Sent: Wednesday, July 26, 2000 12:17 PM To: DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [DOTNET] .Net and IUnknown

[inline]

> Jason - you are certainly welcome to your opinion. I'll just point out that > your opinion causes you to think in certain ways, and say certain things. > Other people are then influenced by your opinions (as witnessed by the > people who read these mail messages).

That's what opinions are ;). I hope you don't think I'm naysaying any of your efforts. .Net is finally bringing us high-quality RTTI. I think one of the most important innovations in the late 90s is the realization that you can do a lot with high-fidelity typeinfo at runtime, things like MTS/COM+, and I will cheerlead that idea no problem. Code signing and assemblies - wonderful stuff that probably is more evolutionary than revolutionary. However...

> The danger in this is that when I say "This is what COM is", and my "opinion" > differs from yours, it's worth trying to figure out why.

Is Merced evolutionary or revolutionary? The difference between Merced / 8086 core is similar to COM -> .NET.

To me, classic COM is primarily about the COM vtbl Interface. That's the core idea. As COM evolved the OS picked up more and more services, from the class loader to the apartment support, to Context and all the goodies that came with that. The focus has thus been shifting over the past few years to the capabilities of the runtime, and I can see how you could view .NET as sort of the ultimate extension to the runtime, to where even object lifetime and dynamic call invocation are handled there. Even as the runtime picked up new capabilities, however, the concept of opaque objects implementing vtbl interfaces alwats remained constant. Everything in classic COM builds on this platform. Heck even the interception magic could be viewed as a natural way to simply add more value to the interface proxy. A stunningly great idea, but the basic mechanics of how COM works today remains more or less constant to COM circa 1994.

With .NET, this changes fairly radically, to where the runtime knows the intimate underthings of your object. If I write CLR code I can determine everything about a class via GetType?(). This allows the EE to do all kinds of neato new things like persistence, MBV, GC, and other special effects, but it also represents a large shift in COM and how it interacts with your code, larger than MTS or COM+1.0. One's expertise in the classic COM techniques doesn't necessarily carry over into the CLR world. From a very far out view I suppose things haven't changed - at the end of the day we're all still writing DLLs. The way client code interacts with an object in the CLR world is fundamentally different enough from classic COM that I don't think it's too off-base to call it "revolutionary" over "evolutionary". It's a total discontinuity in how things work.

> My opinion on what COM is turns into some fundamental assumptions Microsoft > makes when we build the software that you use. It might be easy for > somebody who gets a hold of you post to read it and then conclude "Oh, COM > really is dead. OK, I'll stop using it" or some such nonsense. > COM is not dead. Interfaces are not dead. To me, COM is a lot more than > what you say it is.

I won't say that "COM is dead", that's a pretty obviously silly statement. Unless the EE is a huge flop for some reason though I think it's accurate to say "COM as we know it" is going to be far less important in 3-5 years than it is now if everyone jumps into the CLR sandbox.

IDL? Type libraries? proxy/stub DLLs? GUIDs? Class factories? Registration? dual/dispinterfaces? AddRef / Release? IDispatch? QI (well, QI stays around as typecasting. QI was a hack, anyway ;) ).

All the basic COM mechanics are irrelevant within the CLR runtime unless you're talking to legacy code. It's great that the backwards compatibility is so strong and seamless, but it's hardly the "same" technology. Heck, somewhere I have a post from a MS employee saying that the CLR/EE technologies did not really start with COM as a precept. (Please consider this last statement to be FUD until I can find the post back).

For posterity's sake let me state that I'm an enthusiastic supporter of .NET and think it's very important. I think Sun screwed up by wanting to hold onto Java the language _and_ java the runtime, and I think MS is totally doing the right thing by holding the runtime constant and ignoring the source language. The writing has been on the wall for a few years now that JIT-compiled languages are probably the future. With CPU's as fast as they are it makes sense - why compile to native code and throw away all kinds of interesting information? Perhaps the _compiler_ as we know it is going to be a relic of the past in 5 years. Heck with Merced around the corner perhaps runtime adaptive tweaking will be the only realistic way to maximize that CPU.

Warmest regards, Jason

Personally, I found P/Invoke a better way to interface native and .NET code anyway. All you have to do is know not to let exceptions propagate across the managed/native stack barriers unless the native code is ready to handle them. -JH

CategoryComponentObjectModel