What are the `exact` differences between .NET dll and a normal dll?

Question

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 1

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.

Answer 2

This is a good question. There is one crucial difference between .NET DLL's and ordinary DLL's, for the sake of this answer, let's use the terminology native DLL's as normal DLL's that are not dependent on the .NET framework.

The crucial difference is that there is a 15th data directory entry within the .NET PE header layout, native DLL's only have 14 data directory entries. That is how you can tell the difference between the two, for the native DLL, that entry will be zero! And not alone that, .NET DLL's would have metadata embedded into it for the Framework to handle it accordingly such as attributes requesting security permissions etc, the same applies for .NET EXE's.

In relation to different extensions masquerading as DLL's such as OCX, and CPL, Screen Savers are another example of a non-DLL extension in the sense of the word from an .EXE perspective, ie. those that are .SCR are really .EXE's...bizarre as it sounds, it seems that Microsoft made some applications to use a specific extension for an EXE and DLL, I reckon that was the hold-over from the days of Windows 3.1, CPL for Control Panel, OLE known as Object Linking and Embedding to OCX now ActiveX, SCR for Screen Savers aka .EXE's. It would not surprise me if the same applies to .MSCc (service extensions used in Microsoft Snap In Consoles)

DLL Registrations is where regsvr32 registers the DLL and it's class id's which would be found in the registry under the key HKEY_CLASSES_ROOT, this would more likely be for COM (Component Object Model) for making the COM objects globally visible to all languages irrespective of development language/environments. ActiveX DLL's would also fit in that same category, some are known to automatically register themselves (including COM DLL's), including their type library identification (typelib id's)...

A lot of software before Windows 95, used to have their own DLL's lying around, some duplicated, the common one I can remember was CTL3D.DLL (Remember? That would give Windows Controls a 3D look - gawd!). There was so many versions of it duplicated everywhere, this duplication and version differences was to lead on into Windows 95, known as DLL hell. It was there, that the registry made it's debut appearance when it was launched, that was designed to get around DLL hell by getting all the typelibs registered in one spot instead of duplicating the DLL's all over the place, but it did not resolve the versions at the time, leading to programs appearing broken as there was a class id in use by a DLL, which was replaced by a newer DLL version which caused the programs to break!