> "scottelloco" <scottell***@yahoo.com> wrote in message
> news:1150324966.067703.146440@u72g2000cwu.googlegroups.com...
> > 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/details.aspx?FamilyId=8C09FD61-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

> 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
>
> Carl Daniel [VC++ MVP] wrote:
>
>> "scottelloco" <scottell***@yahoo.com> wrote in message
>> news:1150324966.067703.146440@u72g2000cwu.googlegroups.com...
>>
>>> 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/details.aspx?FamilyId=8C09FD61-3F2
>> 6-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
>>

> "GhostInAK" <ghosti***@gmail.com> wrote in message
> news:be1391bf6bde8c85eb00fa2c57c@news.microsoft.com...
> > 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

> 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,
> >
> > 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
> >
> > Carl Daniel [VC++ MVP] wrote:
> >
> >> "scottelloco" <scottell***@yahoo.com> wrote in message
> >> news:1150324966.067703.146440@u72g2000cwu.googlegroups.com...
> >>
> >>> 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/details.aspx?FamilyId=8C09FD61-3F2
> >> 6-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
> >>