views:

470

answers:

7

In other words, does the .NET framework eventually make calls somewhere to get its work done? Or did Microsoft completely re-create all the functionality of the win32 library in their .NET framework.

Thanks!

+5  A: 

In some cases (most, perhaps? I haven't reflected through the entire framework) the .NET framework makes calls to win32. Most controls are simply win32-controls wrapped with a few new features.

J. Steen
+6  A: 

A .NET application is just another Win32 process, so there is no magic and obviously it is going to use the underline operating system. Even the .NET libraries use Win32 to a great extent.

Examples:

  • Memory management is handled internally for managed code, but for the process itself it is handled just like any other Win32 process.

  • Currently managed threads are implemented as OS threads as well.

Brian Rasmussen
+17  A: 

It is a mix. Obviously, things like winforms are largely wrappers around Win32 functionality (or a mix of both worlds), but WPF is a lot more managed (in terms of the actual control code; under the hood, as Mash notes, it may use DirectX for the rendering). Likewise, things like file/network access are (by necessity) wrappers around the OS objects, as are the unmanaged lock objects like Mutex - but many other things are 100% managed.

So it isn't a simple answer.

(edit) Also - keep in mind that ".NET" is a very vague term; Compact Framework, Micro Framework, Silverlight etc may have different, non-win32 implementations.

Marc Gravell
It's debatable whether WPF lot more managed, while internally it's heavily relies on DirectX...
Mash
@Mash - Good point
Marc Gravell
So because .NET largely relies on win32 to get its work done, it could never "replace" it as the primary WINAPI, right? Or is that the eventual goal?
tyler
the whole "managed OS" debate is a tricky one. I don't expect we'll see such a thing any time soon (if ever). It relies on some external services, which (for windows/.NET) is the Windows API. Others are possible, though - look at mono on linux, or Micro Framework on, heck, a wrist watch.
Marc Gravell
+2  A: 

Yes, it calls win32 functions internally. For example the OpenRead method in File class contains:

    return new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read);

and it will eventually call:

    SafeFileHandle handle = CreateFile(lpFileName, dwDesiredAccess, dwShareMode, securityAttrs, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile);

which is a win32 native function, deep down in the method.

yuku
+1  A: 

It does call the .NET API as all Windows applications do. But it is more than just a simple wrapper or map, it is more accurately described as an abstraction.

Craig
+6  A: 

Update: realised I answered the wrong question (you said runtime not class library)...oh well I'll keep the guff below in anyway!

It depends on the part of the library:

  • System.Xml library doesn't use MSXML
  • System.Reflection won't as it's all IL based
  • System.Text does and doesn't. There are some 'fast' calls for string manipulation
  • System.Text.RegularExpressions doesn't, like the XML namespace it's all custom using a RegexRunner internal class.
  • System.Diagnostics uses kernel32.dll calls such as CreateProcess
  • System.IO namespace does pinvoke also
  • System.Threading uses internal method calls which will eventually (inside the CLR) call winapi methods
  • System.Windows.Forms is a mixture but eventually uses GDI
  • System.Net (NetworkStream) uses ws2_32.dll such as WSARecv(..)

That's just from fiddling with Reflector. Obviously being a COM server the Microsoft CLR relies heavily on win32 too.

Chris S
Great! Thank you!
abatishchev
+2  A: 

Mono is an implementation of the .net runtime, and it certainly doesn't map to win32 function calls (at least on linux)

I guess your question was referring to Microsoft implementation of the .net runtime.

Brann