Message from discussion Is .Net Framework biult on top of COM?

From: "Richard Grimes" <richa...@mvps.org>
References: <O8j6x81#FHA.2264@tk2msftngp13.phx.gbl>
Subject: Re: Is .Net Framework biult on top of COM?
Date: Thu, 8 Dec 2005 16:55:33 -0000
Lines: 60
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
X-RFC2646: Format=Flowed; Original
Message-ID: <Om#aYrB$FHA.1172@TK2MSFTNGP10.phx.gbl>
Newsgroups: microsoft.public.dotnet.framework
NNTP-Posting-Host: grimes.gotadsl.co.uk 62.3.255.233
Path: g2news1.google.com!news3.google.com!news.glorb.com!newshub.sdsu.edu!msrtrans!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP10.phx.gbl

laurence chang wrote:
> Hi,
>
> I'm just wondering what's behind of .Net Frameworks. Is .Net Framework
> biult on top of COM?

It depends on what you mean by 'built on COM'. It is certainly built 
upon the lessons learned from COM, and COM features like interface 
programming are a part of .NET. Rotor, the shared source version of .NET 
shows that the runtime is written in unmanaged C++, using C++ objects 
not COM objects. However, the internal workings of the runtime are 
available through COM: Microsoft provide a COM object that gives access 
to the runtime, and unmanaged code calling this object can do some 
things that managed code cannot do (one example is to get access to the 
default appdomain).

The framework library is between 88% and 96% managed (depending on the 
version). I have analysed various versions of the library and present my 
results here:

http://www.grimes.demon.co.uk/dotnet/dotnetWrappers.htm

It is interesting to analyse remainder of the library (ie the code that 
is not managed). There are several options: platform invoke, COM 
interop, embedded native code or internalcall. The internalcall methods 
are unmanaged and are provided by the unmanaged DLLs in the runtime. 
Embedded native code are actual x86 machine code in an assembly and 
although there are a few methods like this, they are actually calls to 
unmanaged DLLs, so they are equivalent to platform invoke. Platform 
invoke are calls to unmanaged DLLs, mostly the Win32 system DLLs. And 
finally there are calls to unmanaged COM objects.

My analysis of the use of COM in the .NET library is:

v1.0
3.4% of methods are implemented as COM interop calls, but 0.35% of 
method calls in the IL methods are to COM methods.

v1.1
8% of methods are implemented as COM interop calls, but 0.42% of method 
calls in the IL methods are to COM methods.

v2.0
4.2% of methods are implemented as COM interop calls, but 0.21% of 
method calls in the IL methods are to COM methods.

As a comparison I have also analysed the Sept CTP of the WinFX runtime 
components (6.0.5070) and I found that 2.3% of methods are implemented 
as COM interop calls, but 0.2% of method calls in the IL methods are to 
COM methods.

From all of this you can see that COM *is* used by the framework 
library, but the usage is very low.

Richard
-- 
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm