What are the `exact` differences between .NET dll and a normal dll?
I want to know what are the exact differences between .NET dll and a normal dll.
First question, what is "normal DLL" called? I'm using the word 'normal'. But it doesnt seem right?
Because both follow the PE format. Yeah, I agree that .NET DLL has an extra section. Other than that every thing else is same.
I also know that in .NET code is converted into CIL/MSIL then what is filled in .text section of PE file? MSIL? because there is no binary code. But if they put MSIL in .text section. Loader assumes that its a binary code and allows it to execute. Which is not the case. What am I missing?
I'm surprised to know that
Even the DLL file extension is artificial. You can have DLLs with entirely different extensions—for instance .OCX controls and Control Panel applets (.CPL files) are DLLs.
What else extensions are used for DLL files?
But I can understand the reason for using different extensions. Why didn't they follow do the same thing in case of .NET DLLS? they could have used a new extension to differentiate it from the "normal" DLL. They even have a different name (ASSEMBLY) for dlls in .NET but couldn't change the extension. huh?
Another completely different question: What is DLL registration? they use regsvr32.exe for it. right? I noticed it when I installed Windows XP SP3. After the installation & before restarting windows, I checked startup list and found lot of regsvr32.exe entries with lot of DLLs.
Please feel free to dive into as much depth as you like. I'm learning about linkers,loaders,binary formats. I'm familiar with PE file format also.
Answer
I've copied and pasted this from my own post on it:
The format of a .NET dll is:
- PE header
- CLR header
- CLR metadata
- CLR IL code
- Native data
PE header
The PE header is the portable executable header that all Win32 applications and libraries have, and instructs Windows what to do with the file. With .NET assemblies this loads the CLR which in turn loads the assembly.
CLR header
This contains information such as the .NET version the .exe or assembly was written with, any strong name signature hash, the address (RVA or relative virtual address) in the file that the resources can be found. And most importantly the entry point for the application which is a token pointing to the MethodDef metadata table, or another file. This token is 0 for class libraries.
CLR metadata
This is information about the module that is stored inside several different types of "streams". These streams are typically compressed, with the exception of #~ which can be uncompressed for edit and continue. The streams come in two forms, a heap which is just used for storage, and tables.
The various parts of your DLL/assembly are stored in different tables based on what they do - for example all types are stored in the TypeRef table, all methods in the Method table. Each of the tables references a parent table.
The start point of the tables is the Module table which contains just the name and guid of the module as a single row. After this is the ModuleRef table which contains information about all modules that are referenced by this module (from the same assembly). In the case of VS.NET and its use of csc.exe there aren't multiple files in the assembly, just one module.
After this is the TypeDef table which contains 6 columns holding the type's name, namespace, its parent (0 for interfaces and Object), the start row for its fields in the FieldDef table, start row for its methods in the MethodDef table.
IL and native data
The app itself.
The book Inside Microsoft .NET IL Assembler - Serge Lidin goes into a lot more detail if you're interested.