Does the .NET framework always call the API?

  • Thread starter Thread starter Peter Olcott
  • Start date Start date
P

Peter Olcott

I want to double check my understanding about how the .NET framework works. From
what I understand every call to the .NET framework is ultimately translated into
one of more API calls, is this correct?
 
"Peter Olcott" <olcott@att.net> a écrit dans le message de DlEAf.68924$QW2.46682@dukeread08...

|I want to double check my understanding about how the .NET framework works.
From
| what I understand every call to the .NET framework is ultimately
translated into
| one of more API calls, is this correct?

The .NET framework is a massive library mainly written in managed code.
where the framework needs to , it calls existing APIs but there is a lot of
brand new code that doesn't need the old APIs.

Joanna
 
I would expect it to only call any API's when its handling calls within the
Microsoft namespace, as this touches more on microsoft operating system
functionality - whereby the remaining namespaces are cross platform and
would be very unlikely to drop into API's.
 
Whooo. Interesting. OK, folks, the OP just sent me on a mission to find
out. The very first thing that comes to mind is to spy on the system and
look at who is invoking whom. I cannot seem to find it on my system, but
there used to be a cool utility called APIMON.EXE that would list (log?) api
calls as they are called. It had a cartoon-like Frankenstein icon. Anyone
remember it?

It is the first step to the OP question, but now that I can't find the
thing, I would be grateful for any hints on how to *legitmately* acquire it.
 
I am referring to those cases that result in API functionality, for example GDI
output to the display screen. Did MS write a whole new way to output things to
the screen, or merely wrap these calls in the .NET framework?
 
John Timney ( MVP ) said:
I would expect it to only call any API's when its handling calls within the
Microsoft namespace, as this touches more on microsoft operating system
functionality - whereby the remaining namespaces are cross platform and
would be very unlikely to drop into API's.
Click to expand...
That isn't totally complete by any means. While the remaining namespaces
are designed tobe platform independent, many still rely on platform
dependent mechanisms. Take the System.IO namespace for example. On Windows
it is likely using CreateFile and its ilk and on Linux perhaps the posix IO
system and on a third system whatever it uses. Same goes for
System.Windows.Forms(although that doesn't port very well), some of
System.Security(WindowsIdentity definatly uses windows APIs, Identity
classes for other systems would use that API as well, System.Threading(which
may or may not use system threads depending on implementation and how it is
hosted), and many other namespaces.

That is why Mono had to rewrite the class library instead of just copy it.
Large portions do rely on the underlying system, otherwise the framework
would have to replace everything from device drivers up. That doesn't mean
that every call, the string editing functions, large pieces of ASP.NET, much
of if not all of System.Xml for example, result in API calls, but many
things do..
 
The framework classes and the run-time (the CLR) both wrap the Win32 API's
to call into OS and related services (like GDI+).

The framework (mostly written in C#) uses PInvoke to perform these API
calls, while the CLR (unmanaged C++) can directly call any API it
likes/needs. The framework and the CLR also call into system services
through COM interop, the CLR debugging, profiling and unmanaged hosting
interfaces are all COM interfaces. Some classes in the framework are thin
wrappers around COM services like ADSI, WMI, COM+., others use a mixture of
PInvoke and COM interop and a majority don't need to call into external
native code at all, but they might call into the CLR through the
internalcall interface. Some classes in v2 are written in managed C++ and
use C++ interop to call into unmanaged code.



Willy.


|I am referring to those cases that result in API functionality, for example
GDI
| output to the display screen. Did MS write a whole new way to output
things to
| the screen, or merely wrap these calls in the .NET framework?
|
| | > "Peter Olcott" <olcott@att.net> a écrit dans le message de | > DlEAf.68924$QW2.46682@dukeread08...
| >
| > |I want to double check my understanding about how the .NET framework
works.
| > From
| > | what I understand every call to the .NET framework is ultimately
| > translated into
| > | one of more API calls, is this correct?
| >
| > The .NET framework is a massive library mainly written in managed code.
| > where the framework needs to , it calls existing APIs but there is a lot
of
| > brand new code that doesn't need the old APIs.
| >
| > Joanna
| >
| > --
| > Joanna Carter [TeamB]
| > Consultant Software Engineer
| >
| >
|
|
 
Peter Olcott said:
I want to double check my understanding about how the .NET framework works.
From what I understand every call to the .NET framework is ultimately
translated into one of more API calls, is this correct?
Click to expand...
hmmm... your question doesn't makes much sense.
I don't really know what you mean so here are some various element of
response:


API: "Application Program Interface", basically that the set of all classes
/ method / library available as a single unit from a third party, in your
case you refer the .NET API as being all the classes by default in the
framework.

an API call: when you call 1 method of the framework. When you do 1 call you
do 1 call (and not 0 or 2).

Could an API call itself?
as much as you refer your own method in your own code.


Maybe you mean: The .NET API ultimately calls into the Win32 API ?

well not always, depending on the situation.
For exemple string.Format() simple manipulate and hardly need to call any
win32 code
On the other hand Form.Show() certainly call ShowWindow() and other win32
functions.
 
Peter,

In my opinion is it not important what Net uses.

Net provides a system that let you call the underlying OS parts. If this is
Win32, WinFX or Linux should not be important.

If that are called API's so what, for you that should not be important.

Just my thought,

Cor
 
John said:
I would expect it to only call any API's when its handling calls
within the Microsoft namespace, as this touches more on microsoft
operating system functionality - whereby the remaining namespaces are
cross platform and would be very unlikely to drop into API's.
Click to expand...

I don't think you've thought this through John.

For example, the classes in System.EnterpriseServices are almost all
direct wrappers around the COM+ APIs. Then there are classes in
System.Net.Sockets where many classes are wrappers around Winsock 2.0,
and then there's classes in System.Threading that are wrappers around
Win32 threads and synchronization objects, do I need to go on?

Yes there are classes that are pure IL and don't make any calls to Win32
or Windows COM objects, but many classes do. I have done an analysis of
various versions of .NET by checking metadata to see which methods are
COM, pinvoke, or embedded native code, and which are internalcall. I
have also 'walked' through all IL in every IL method to see the method
calls it makes and then analyse the type of method called. The results
are shown here:

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

For .NET v2.0 I find that there are

Methods in the framework:

IL Methods 92.8%
COM methods 4.2%
pinvokeimpl methods 2.5%
internalcall methods 0.40%
native methods 0.04%

Thus the implementation of almost 7% of methods is not in IL.

Method calls within the assembly:

IL Methods 56.3%
COM methods 0.18%
pinvokeimpl methods 0.98%
internalcall methods 0.80%
native methods 0.02%

Method calls outside the assembly:

IL Methods 38.3%
COM methods 0.03%
pinvokeimpl methods 0.01%
internalcall methods 2.3%
native methods 0%

This is better, just over 1% of calls is to non-IL methods.

Of course, my analysis does not take in to account how often methods are
called. AFAIK the method calls implemented through pinvoke may be the
most called methods <g>

Richard
 
John said:
I don't think you've thought this through John.
Click to expand...
I assume that what you give is for Linux. Most of us know what it is for
current Windows Win32 systems. In my opinion is John however talking about
other systems. Of course is Net mainly a layer upon the OS. It would be very
crazy when it would gives other results way called by Net than direct by
other use of that.

Dit you think about that as John obiously did.

Cor
 
Cor said:
I assume that what you give is for Linux.
Click to expand...

Why would you assume that? It seems unlikely given that the title of
the page Richard is ".NET as a Win32 Wrapper".
Most of us know what it is for current Windows Win32 systems.
In my opinion is John however talking about other systems.
Click to expand...

Again, I'm not sure where you get that impression from.

Jon
 
Jon,
Why would you assume that? It seems unlikely given that the title of
the page Richard is ".NET as a Win32 Wrapper".


Again, I'm not sure where you get that impression from.
Click to expand...

I am not blind and I can read.

It was the way it was written to John to give an answer in the same way as
it was in my idea given to John, while in my idea Johns answer was very
correct.

Cor
 
Cor said:
I am not blind and I can read.
Click to expand...

In that case I'm *very* confused by why you would assume Richard's
response was about Linux. Note that the .NET framework itself doesn't
exist on Linux in the first place. .NET is a Windows-specific
implementation of the CLI etc.
It was the way it was written to John to give an answer in the same way as
it was in my idea given to John
Click to expand...

Not at all sure what you mean by that. Could you rephrase it?
while in my idea Johns answer was very correct.
Click to expand...

No, John's answer was *not* correct. Classes like System.IO.FileStream
are bound to call into native APIs somewhere - either that, or they'd
have to call into CLR-implementation-specific classes which in turn
would call into APIs; either way it's not cross-platform.

Are you suggesting that Richard's research was inaccurate? I suggest
you look at FileStream using Reflector - look at methods such as
WriteFile, which import kernel32.dll - very Windows specific.

Jon
 
Jon,

Maybe is it that John and I are looking in an abstract way to this question.

"Does the .Net framework *always* call the API", what is as well in time.

And you and Richard look to it concrete related to current Win32.

Cor
 
My suggestion: download Reflector and take a look under the hood. You
will see almost all windows forms workings are ultimately winapi calls.
And getting the .NET SDK you can view the source of the CLR (which is
C++) which reveals a great deal. For example string.Equals (==) boils
down to a basic binary comparison with the first part checking the two
strings are equal length and returning false if they're not.

And the .NET "virtual machine" is a COM server too as far as I
understand it.
 
Cor said:
Maybe is it that John and I are looking in an abstract way to this question.

"Does the .Net framework *always* call the API", what is as well in time.

And you and Richard look to it concrete related to current Win32.
Click to expand...

I agree that the .NET framework doesn't always call into an API. No-one
has stated that it does.

However, John expected that it would *never* call into an API from
classes outside the Microsoft.* namespace hierarchy. That's
demonstrably untrue for existing versions of .NET.

(I'm still baffled as to why you assumed Richard's post was about
Linux.)

Jon
 
| Jon,
|
| Maybe is it that John and I are looking in an abstract way to this
question.
|
| "Does the .Net framework *always* call the API", what is as well in time.
|
| And you and Richard look to it concrete related to current Win32.
|
| Cor
|
|

Even if you look at it in an abstract way, you have to admit that the
framework is nothing else than a runtime (CLR/CLI) and a set of libraries
presenting an OO API to the users of the containing classes.
The CLR uses the platform (Win32) services to perform it's specific tasks
(memory allocator, thread allocator, timer and synchronization services
etc...) and offers some of these services to the framework classes in top of
it.
A large part of framework classes themselves, are also wrapping the platform
specific API's (think file I/O, Security service API's )or some specialized
API's (think ADO.NET, SQL Server etc..), or are calling into COM based
services to present an OO view of the services to the user of the framework.
The classes that wrap the OS or specialized services are not restricted to a
specific namespace or assembly, and that's what John implied, but he is
wrong.
Only a few of the framework classes are not calling into the 'unmanaged'
API, simply because they are self contained, they don't need any auxiliary
services.


Willy.
 
Back
Top