none
.Net Internals,whether it runs in usermode using Win32API or Kernel mode RRS feed

  • Question

  •  

    Hello ,
                      I've lots of doubts about .NET framework internal working.I did enough search before asking for ur time..... sorry if it doesn't make sense........

                     Iam having a doubt of .NET framework running in usermode or kernel mode. How .NET framework is replacement for Win32 API. 

          

               If it runs in user mode it must use Win32 API for interacting with windows or it must use the undocumented API ( the api starts with ZW......) .Then,it is not so different than mere MFC to wrap up win32 difficulties ( I know it is completly object oriented and lots of productivity,but iam talking about internal working) . Lets assume that it runs in usermode,so it must use API at least in its low levels , then why lots of books strongly discourages the use of win32 api from .net framework and gives one of the reason as performance issue with marshalling .

     

              .NET framework shouldn't run in KERNEL mode as it is not a operating system component.Some people say frameworks shouldn't run on kernel mode. Iam sure .NET framework running in kernel mode is complete non-sense.

     

     

    sorry if iam talking nonsense.....

    can anybody tell what happens internally.....

    Tuesday, February 19, 2008 9:04 AM

Answers

All replies


  • Hello ,
                      I've lots of doubts about .NET framework internal working.I did enough search before asking for ur time..... sorry if it doesn't make sense........

                     Iam having a doubt of .NET framework running in usermode or kernel mode. How .NET framework is replacement for Win32 API. 

          

               If it runs in user mode it must use Win32 API for interacting with windows or it must use the undocumented API ( the api starts with ZW......) .Then,it is not so different than mere MFC to wrap up win32 difficulties ( I know it is completly object oriented and lots of productivity,but iam talking about internal working) . Lets assume that it runs in usermode,so it must use API at least in its low levels , then why lots of books strongly discourages the use of win32 api from .net framework and gives one of the reason as performance issue with marshalling .

     

              .NET framework shouldn't run in KERNEL mode as it is not a operating system component.Some people say frameworks shouldn't run on kernel mode. Iam sure .NET framework running in kernel mode is complete non-sense.

     

           

             can anybody tell what happens internally

    Tuesday, February 19, 2008 9:15 AM
  • First of all .NET Framework runs on CLR (Common Language Runtime).

     

    CLR in its turn runs in the user mode. So, any managed code that is being executed by it runs in the user mode.

    Yes, it is discouraged to use P/Invoke (invoke unmanaged methods) if there is managed alternative.

     

    Here's the information that will help you clarify the subject

    http://msdn2.microsoft.com/en-us/library/a4t23ktk(VS.71).aspx

    http://msdn2.microsoft.com/en-us/library/ddk909ch(VS.71).aspx

    http://www.dotnetspider.com/kb/Article47.aspx

     

    HTH

    --
    With best regards, Vadym Stetsiak.
    Blog: http://vadmyst.blogspot.com

     

    Tuesday, February 19, 2008 3:49 PM
  • Hello!

     

    .NET has nothing to do with Kernel Mode. It is also no replacement for the Win32 API. There are already APIs which have to be programmed within managed code (e.g. some SQL2005 Features, or IIRC the WCF, WPF and WF stuff), but not so the Win32 Core API (this would break thousands of applications).

     

    The System.Windows.Forms API uses the default Win32 API (mainly USER32), the System.Drawing wraps the GDI(+) unmanaged APIs.

     

    Why do you meen, that undocumented "low-level" APIs are used? By the way: the "Zw..." APIs are _kernel_ Exports from ntoskrnl.exe which has nothing to do with Windowing.

     

    Using DllImports for something that can be done in managed Code is not nessersary and shall be avoided. Not because the .NET Framework cannot handle it, but because it's harder to write correct code. The Marshalling-Overhead is only measurable in high performance scenarios.

    Tuesday, February 19, 2008 4:12 PM
  • In additional, lots of classes in .net have nothing to do with Windows APIs. String and StringBuilder and Generic classes are example.
    Wednesday, February 20, 2008 4:14 AM
  • u still doesn't address why we shouldn't use win api in .net framework,

             for Opening files,Creating Threads,RPC mechanisms etc.. even though u use .NET framework equalent api, CLR is goint to use the same win32 api at its lower levels... then why shouldn't I
    Wednesday, February 20, 2008 12:31 PM
  • Sure you can use Win32 API to open files and etc.

     

    BUT how about simplicity? Try to compare CreateFile Win32 API function with FileStream class constructor - you'll see why doing this via .NET means is simpler.

     

    .NET is managed world while Win32 API is unmanaged? If you have some specific requirements or constraints that can't be met within .NET Framework then there is no problem doing that on Win32 level that is in unmanaged code.

     

    HTH

    --
    With best regards, Vadym Stetsiak.
    Blog: http://vadmyst.blogspot.com

     

    Wednesday, February 20, 2008 1:08 PM
  • Stability of your application is one thing you have to take into consideration, another aspect will be security. Managed world is a different execution environment with the native programming environment.

    Yun Jin's WebLog show some cases of how dangerous interacting with unmanaged world could be:
    Dangerous PInvokes - string modification

    OutOfMemoryException and Pinning

    Another factor is performance, check out How to make interop calls as fast as the BCL for an example.

    In addition, not every concept in Windows OS is exactly same as in the managed environment. Thread is an example, for more details, please visit
    ExitThread() in managed program?

    After all, I'm not aware of any words that you shouldn't use P/Invoke. We just recommend you to use managed class if possiable. And using P/Invoke is also supported in .net framework.


    Thursday, February 21, 2008 12:46 AM