Geek Answers Handbook

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

When I studied .NET, I saw it as a platform on which my .NET programs are running, which have their own stack and heap.

But now, having learned more about things, I see the .NET application just like any other native C / C ++ application. It is in Portable Executable (PE) format with a new data directory, and the .text section is populated with MSIL instead of machine code. The only difference is that several DLLs (which are considered to be the .NET platform) are loaded (like any other Dll dependency).

I think that at the entry point itself there is some machine code that calls the loaded DLL (.net platform), and the functions of these DLLs read the MSIL from the .text section (segment to be more correct) and generate equivalent machine code and put it into some kind of buffer (I don’t know what area it will be in. I cannot be .text and .data, since they are read-only, will they be a stack or a heap?). Then enter EIP in this instruction buffer. The last few commands return to the DLLs again to repeat the process for the rest of MSIL.

As with the Managed Heap and Managed Stack , this is just part of the process heap and stack. its only a few functions (called GC) will track memory allocation and release from this part of the memory.

I like this realistic look. I don’t know how right I am. I just guess about it. Please correct me and tell me more about this. How much will this look like this? Where can I learn more about the .NET platform from this perspective?

+7
c #
source share
7 answers

To test CLR: CLR via C # .

This is a really great book, especially if you are interested in the low level of .NET / CLR.

To test the JVM: Java Virtual Machine

+3
source share

You missed one very important point - the CIL code (formerly MSIL) is safe code. You cannot do arbitrary voodoo pointers, type casting, or similar evil things (with the exception of some in insecure areas of the code). This is probably the most important difference from other languages ​​such as C (++), Pascal, etc. These security guarantees are deeply embedded in the system language, type and runtime.

+4
source share

The CLR through C # describes some of the internal things of .NET, including the PE boot process and the hosting of the CLR in your own process.

+3
source share

One thing is missing in your description: most of the code in the .NET assembly runs on time (JIT), which means that MSIL is not converted to machine code until the method is called for the first time, and at that point it is cached in the future . This greatly speeds up startup time, due to a slight slowdown on the first call of each method. (I omit the details, like the fact that the JIT compiler can re-optimize a function after calling it several times.)

JIT-compiled code lives on the heap, from an OS perspective. The JIT compiler will mark the code as an executable and do whatever it takes to make it correct.

+2
source share

This is not 100% accurate, but I would say that you have a decent overview of some parts of the frame.

If you want to know more, I suggest you take a look at the .NET Framework FAQ first and when you read the .NET 1.1 Inside this .NET Framework series of articles. These articles will not cover many of the achievements that have occurred over the past 4 versions, but they will provide a good, solid foundation for what the .NET Framework is.

+2
source share

I read Pro C # 2008 and the .NET 3.5 platform recently (now VS2010 / .NET 4.0 is there , and it does a great job explaining how .NET bytecode works in the background, and how you can find out about what is really called using a reflector, etc. It is dense and long (and sometimes more information than I wanted), but it is a good informative read.

+1
source share

More articles:


All Articles