> 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" <scottelloco@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" <ghostinak@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.

GhostInAK wrote:
> 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" <scottelloco@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
> >>