Wird die .NET-Laufzeitumgebung intern zu win32-Funktionsaufrufen zugeordnet?

Question

Mit anderen Worten, macht das .NET Framework irgendwann Aufrufe, um seine Arbeit zu erledigen? Oder hat Microsoft die gesamte Funktionalität der win32-Bibliothek in ihrem .NET-Framework vollständig neu erstellt.

Danke!

Answer 1

Es ist eine Mischung. Offensichtlich sind Dinge wie Winforms weitgehend um die Win32 - Funktionalität herum (oder eine Mischung aus beiden Welten), aber WPF ist viel mehr verwaltet (in Bezug auf den eigentlichen Steuerungscode; unter der Haube, wie Mash anmerkt, kann es DirectX für die Wiedergabe). Ebenso sind Dinge wie Datei-/Netzwerkzugriff (notwendigerweise) Wrapper um die OS-Objekte, wie auch die nicht verwalteten Sperrobjekte wie Mutex - aber viele andere Dinge werden zu 100% verwaltet.

So ist es keine einfache Antwort.

(bearbeiten) Auch - denken Sie daran, dass ".NET" ist ein sehr vager Begriff; Compact Framework, Micro Framework, Silverlight usw. können verschiedene nicht-win32-Implementierungen haben.

Answer 2

In einigen Fällen (die meisten, vielleicht? Ich habe nicht durch das gesamte Framework reflektiert) das .NET-Framework Aufrufe an win32. Die meisten Steuerelemente sind einfach win32-Steuerelemente, die mit ein paar neuen Funktionen versehen sind.

Answer 3

Eine .NET-Anwendung ist nur ein weiterer Win32-Prozess, also gibt es keine Magie und offensichtlich wird das Unterstreichungs-Betriebssystem verwendet. Sogar die .NET-Bibliotheken verwenden Win32 zu einem großen Teil.

Beispiele:

• Speicherverwaltung wird intern für verwalteten Code behandelt, aber für der Prozess selbst ist nur wie jeder andere Win32-Prozess behandelt.

• Gegenwärtig verwaltete Threads sind , die ebenfalls als OS-Threads implementiert sind.

Answer 4

Ja, es ruft win32 Funktionen intern auf. Zum Beispiel in File-Klasse die Openread-Methode enthält:

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

und es wird schließlich nennen:

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

die eine win32 native Funktion ist, tief unten in dem Verfahren.

Answer 5

Es ruft die .NET API wie alle Windows-Anwendungen. Aber es ist mehr als nur ein einfacher Wrapper oder eine Map, es wird genauer als Abstraktion beschrieben.

Answer 6

Update: realisierte ich die falsche Frage beantwortet (Sie sagte Laufzeit nicht Klassenbibliothek) ... oh, ich werde die Guff unten halten in jedem Fall!

Es hängt von dem Teil der Bibliothek:

• System.XML Bibliothek nicht Verwendung MSXML
• System.Reflection wird nicht, wie es alle IL basiert
• -System.Text tut und tut es nicht. Es gibt einige "schnelle" Aufrufe für die Zeichenfolgenmanipulation.
• System.Text.RegularExpressions ist nicht wie der XML-Namespace benutzerdefiniert, sondern verwendet eine interne RegexRunner-Klasse.
• System.Diagnostics verwendet kernel32.dll Anrufe wie Create
• System.IO Namespace
• System.Threading verwendet interne Methodenaufrufe denen schließlich (in den CLR) Aufruf winapi Methoden
• -System pinvoke auch der Fall ist. Windows.Forms ist eine Mischung, aber schließlich verwendet GDI
• System.Net (Network) verwendet ws2_32.dll wie WSARecv (..)

Das gerade ist aus mit Reflektor Hantieren. Da es sich bei Microsoft CLR offensichtlich um einen COM-Server handelt, ist sie auch stark auf win32 angewiesen.

Answer 7

Mono ist eine Implementierung der .NET-Laufzeit, und es sicher ist kein win32 Funktionsaufrufe (zumindest unter Linux)

Ich denke, Ihre Frage zu Microsoft-Implementierung der .NET-Laufzeit bezog.