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 \'norm

Answer 1

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!