.NET framework from a low level programmer's point of view

Question

When I was learning .NET I saw it as a platform that runs my .NET programs which has its own Stack & Heap.

But now after learning more about things, I see a .NET application as just like any other C/C++ native application. It is in Portable Executable (PE) file format with new data directory & .text section is filled with MSIL code instead of machine code. The only difference is few DLLs (which are considered as .NET platform) (like any other Dll dependency) are loaded.

I guess at the very entry point there is some machine code which calls into the loaded DLL(.net platform) and functions of those DLL read the MSIL from .text section (segment to be more correct) and generate equivalent machine code and put it in some kind of buffer (I don't know which area would it be it. I cannot be .text & .data as they are readonly. will they be stack or heap?). Then make the EIP point to this buffer of instructions. Last few instructions again call back into DLLs to repeat the process for rest of MSIL.

As of Managed Heap & Managed Stack they are just some portion of the processes heap & stack. its just that few functions (referred to as GC) will keep track of the memory allocations & deallocations from this portions of memory.

I like this realistic view. I don't know how far I'm true. I'm just guessing these things. Please correct me & tell me more about this. How far will is it similar to this view? Where can I learn more about .NET platform from this point of view?

Answer 1

For CLR check : CLR via C#.

It is really a great book especially if you are interested in "low level" .NET/CLR.

For JVM check : Java Virtual Machine

Answer 2

It's not 100% accurate, but I'd say you've got a decent overview of certain portions of the framework down.

If you'd like to know more, I suggest you take a look first at the .NET Framework FAQ and when you're done with that read the .NET 1.1 Inside the .NET Framework series of articles. These articles won't cover many of the advances that have occurred over the last 4 versions, but they'll give a good, solid foundation of what the .NET Framework is all about.

Answer 3

You might find this MSDN article interesting: http://msdn.microsoft.com/en-us/magazine/cc163791.aspx

As well as these books: http://www.amazon.com/Expert-NET-2-0-IL-Assembler/dp/1590596463/ref=pd_bbs_sr_1/104-0844985-7433557?ie=UTF8&s=books&qid=1175791950&sr=8-1

http://www.amazon.com/CLR-via-Dev-Pro-Jeffrey-Richter/dp/0735627045/ref=sr_1_1?ie=UTF8&s=books&qid=1277838859&sr=1-1

Answer 4

You missed one very important point - CIL code (formerly MSIL) is safe code. You cannot do arbitrary pointer voodoo, type casting or similar evil things (except for some in unsafe code regions). This is probably the most important difference to other languages like C(++), Pascal and so on. This safety guarantees are deeply build into the language, type system and runtime design.

Answer 5

CLR via C# describes some internal .NET things, including PE load process and hosting of CLR in your own process.

Answer 6

Lately I have been reading Pro C# 2008 and the .NET 3.5 Platform (there's now a VS2010/.NET 4.0 version, too), and it does a great job explaining how the .NET bytecode works on the back-end, and how you can learn about what's really being called by using the reflector, etc. It's dense and long (and sometimes more info than I wanted), but it's good informative reading.

Answer 7

Your description is missing one thing: most code in a .NET assembly is just-in-time (JIT) compiled, meaning that the MSIL isn't converted into machine code until the moment just before the method is called for the first time, at which point it's cached for the future. This greatly speeds up startup time, at the cost of a minor slowdown the first time each method is called. (I omit details like the fact that the JIT compiler may re-optimize the function after it's been called a few times.)

The JIT-compiled code lives on the heap, from the perspective of the OS. The JIT compiler will mark the code as executable and do whatever other voodoo is necessary to make it run correctly.