.NET Frameowrk's interaction with the Windows OS

[scottelloco]

Hi,

A colleague and I are in a dicussion about how exactly the .NET
Framework interacts with the underlying OS. We've looked around online
and haven't found much information to explain this interaction. We of
course know the the Framework is a layer which sits on top of the OS,
but we're curious about how the Framework makes calls to and interacts
with the underlying OS.

For example, does the .NET Framework itself use p/inovoke to call
functions in the underlying Windows API libraries when, for example,
capturing mouse events? We're thinking that basically .NET takes lower
level Windows API libraries and "packages" them into .NET libraries. We
think that these .NET libraries then make p/invoke calls to the
underlying Windows API libraries (keeping in mind that there may be
another layer of abstraction there between the .NET libraries and the
Windows API), thereby allowing the developer more time to concentrate
on implemenation rather than dealing with a bunch of low-level API
calls.

Any information on this subject or links to white papers, documentaion,
etc. would be greatly appreciated.

Thanks, -Scott

 

[Carl Daniel [VC++ MVP]]

Hi,

A colleague and I are in a dicussion about how exactly the .NET
Framework interacts with the underlying OS. We've looked around online
and haven't found much information to explain this interaction. We of
course know the the Framework is a layer which sits on top of the OS,
but we're curious about how the Framework makes calls to and interacts
with the underlying OS.

The best, most detailed reference on how the CLR interacts with the OS is
the Shared Source CLI implementation for which you can download source code
and examine it at your leisure.

http://www.microsoft.com/downloads/...61-3F26-4555-AE17-3121B4F51D4D&displaylang=en

For example, does the .NET Framework itself use p/inovoke to call
functions in the underlying Windows API libraries when, for example,
capturing mouse events? We're thinking that basically .NET takes lower
level Windows API libraries and "packages" them into .NET libraries. We
think that these .NET libraries then make p/invoke calls to the
underlying Windows API libraries (keeping in mind that there may be
another layer of abstraction there between the .NET libraries and the
Windows API), thereby allowing the developer more time to concentrate
on implemenation rather than dealing with a bunch of low-level API
calls.

You're pretty close - the .NET framework classes do wrap and build on top of
Win32 APIs. The native code is typically invoked using a special,
undocumented, internal mechanism rather than P/Invoke, but the end result is
the same. The internal interop requires extensive support on the native
side (think Java JNI), while P/Invoke nearly wraps up all the marshalling
goo letting you seamlessly call any existing C API.

-cd

 

[scottelloco]

Carl,

Thanks very much. I'll take a look at the link you sent.

Our discussion came about because we were thinking about making some
p/invoke calls from our C# code to some C++ code that we have, but
we've read that there is a perfmorance hit when doing p/invoke calls.
We'll be making so few calls that I doubt that this performance hit
will be an issue, but that led to a discussion of how the Framework
makes calls to the OS API's.

Our theory was that if the Framework was making p/invoke calls, then
our code making explicit p/invoke calls wouldn't mean anymore of a
performance hit than the perfoamce hit the Framework itself takes when
making these calls to underlying OS API's.

Your link will defeinitely help clear things up.

Thanks, -Scott

 

[GhostInAK]

Hello scottelloco,

Pop open the framework in Reflector and you can see exactly how the managed
classes are put together. I looked at just System.Diagnostics.Process and
found that yes indeed it uses p/invoke extensively.

-Boo

 

[Carl Daniel [VC++ MVP]]

Hello scottelloco,

Pop open the framework in Reflector and you can see exactly how the
managed classes are put together. I looked at just
System.Diagnostics.Process and found that yes indeed it uses p/invoke
extensively.

I haven't looked at most of the framework (obviously). The places I have
looked, in the BCL (e.g. System.Decimal, System.String) use the internal
mechanism I mentioned.

I'm not surprised to hear that higher level parts of the framework just use
P/Invoke - it's much easier and less error prone, and frankly, the
performance overhead of going through P/Invoke to call CreateProcess (for
example) is really of no significance.

-cd

 

[scottelloco]

Thanks very much Boo. I'll check it out.

-Scott

Hello scottelloco,

Pop open the framework in Reflector and you can see exactly how the managed
classes are put together. I looked at just System.Diagnostics.Process and
found that yes indeed it uses p/invoke extensively.

-Boo

 

[scottelloco]

Thanks again Carl.

I haven't looked at most of the framework (obviously). The places I have
looked, in the BCL (e.g. System.Decimal, System.String) use the internal
mechanism I mentioned.

I'm not surprised to hear that higher level parts of the framework just use
P/Invoke - it's much easier and less error prone, and frankly, the
performance overhead of going through P/Invoke to call CreateProcess (for
example) is really of no significance.

-cd