從低級程序員的角度來看.NET框架

當我在學習.NET時，我將它看作是一個運行我的.NET程序的平臺，它有自己的Stack堆棧&堆。從低級程序員的角度來看.NET框架

但是現在瞭解了更多關於事物之後，我發現.NET應用程序就像任何其他C/C++本機應用程序一樣。它採用可移植可執行文件（PE）文件格式，新數據目錄爲&。文本部分填充了MSIL代碼而不是機器代碼。唯一的區別是很少的DLL（被認爲是.NET平臺）（像任何其他的Dll依賴）被加載。

我想在入口點有一些機器代碼調用加載的DLL（.net平臺），並且這些DLL的函數從.text部分讀取MSIL（段更加正確）並生成等效機器代碼並將其放入某種緩衝區中（我不知道它是哪一個區域，因爲它們是隻讀的，所以它們不會是堆棧或堆？）。然後讓EIP指向這個指令緩衝區。最後幾條指令再次回調到DLL中，重複其餘MSIL的過程。

作爲Managed Heap & Managed Stack他們只是堆棧&棧的一部分。它只是很少的功能（稱爲GC）將跟蹤內存分配&從這部分內存中取消分配。

我喜歡這種現實的觀點。我不知道我有多遠。我只是猜測這些事情。請糾正我&告訴我更多關於此的信息。它與這種觀點有多相似？從哪裏可以從這個角度更多地瞭解.NET平臺？

來源

2010-06-29 claws

我會建議你把Java的一個單獨的問題，以得到更好的答案。而且，對於Java，所有平臺上的答案都不一樣（除非是高級別 - 代碼在虛擬機中運行）。你只關心它是如何在Windows上完成的？ – Yishai 2010-06-29 19:25:18

我同意@Yishai; Java與.NET有許多*顯着的差異，可能會混淆這個問題。保存一個單獨的問題。 – Randolpho 2010-06-29 19:27:12

對於CLR檢查：CLR via C#。

這真的是一本很棒的書，尤其是如果你對「低級」.NET/CLR感興趣的話。

對於JVM檢查：Java Virtual Machine

來源

2010-06-29 19:27:22 Incognito

通過C＃爲CLR +1。我發現關於垃圾收集的部分特別有趣，因爲CLR GC做的不僅僅是跟蹤分配。 CLR和GC協作，以便您的執行代碼實際上可以被劫持，讓您的引用指向新的內存位置，然後再次開始運行，就好像什麼也沒有發生。 – 2010-06-29 20:08:47

您的描述缺少一件事：.NET程序集中的大多數代碼是即時編譯的，這意味着直到方法出現之前，MSIL纔會被轉換爲機器代碼這是第一次呼籲，此時它將被緩存以備將來使用。這大大加快了啓動時間，每次調用方法第一次時都會以輕微減速爲代價。（我忽略了一些細節，例如JIT編譯器可能會在幾次調用之後重新優化函數這一事實。）

從操作系統的角度來看，JIT編譯的代碼位於堆上。 JIT編譯器會將代碼標記爲可執行文件，並執行其他任何必須使其正確運行的voodoo。

來源

2010-06-29 19:06:49

這不是100％準確的，但我會說你已經對框架的某些部分有了一個體面的概述。

如果您想了解更多信息，我建議您首先看看.NET Framework FAQ，當您完成後請閱讀.NET 1.1 Inside the .NET Framework系列文章。這些文章將不會涵蓋過去4個版本中發生的許多進步，但它們將爲.NET Framework的全部內容奠定良好的基礎。

來源

2010-06-29 19:09:19 Randolpho

最近我一直在閱讀Pro C# 2008 and the .NET 3.5 Platform（現在還有一個VS2010/.NET 4.0版本），並且它很好地解釋了.NET字節碼如何在後端工作，以及如何瞭解真正被稱爲使用反射器等等。它很密集且很長（有時候比我想要的更多的信息），但是它的信息量很大。

來源

2010-06-29 19:10:39 ewall