How does OS differentiate between .net dll and other dll's?

Question

DLL is Dynamic Link Library, that is limked during run time. A in a system there are dll's for different languages like C++, c, .net etc. My question is how does OS differentiate between .net dll and other dll's?

eg if I have created a.dll in C++ and a.dll in C#.net, now in a .net project I refer to a.dll(C#). how will Operating system differentiate a.dll(C#) and a.dll(C++) processes referring both are running.

Answer 1

The operating system is never involved. Managed assemblies of the DLL variety are loaded with Assembly.Load() and friends. Implicitly as needed when the jitter compiles code. Or explicitly when you use one of the Assembly.Load varieties in your code.

The only time the operating system is involved is when starting an EXE. Later Windows versions (XP and up) do have awareness of a managed EXE. The exact mechanism is undocumented, other than that mscoree.dll is an important player, it acts as a stub for the loader and is the helper DLL that actually gets the CLR loaded. Windows loads it automatically, presumably by it seeing the CLR header inside the executable.

There is no such awareness for old Windows versions (Windows 98 and 2000), the EXE contains 5 bytes of unmanaged code. Nothing but a jump to the _CorExeMain() function inside mscoree.dll. Which then does the normal job of getting the CLR loaded. The operating system needed to get involved in later versions because of the unusual feature that a 32-bit EXE can execute as a 64-bit process. The hackorama involved to modify the executable on-the-fly to create a 64-bit process is pretty elaborate.

Answer 2

Windows uses the Portable Executation Format for .Net DLLs and executables. An extract from that Wiki article:

Microsoft's .NET Framework has extended the PE format with features which support the Common Language Runtime (CLR). Among the additions are a CLR Header and CLR Data section. Upon loading a binary, the OS loader yields execution to the CLR via a reference in the PE/COFF IMPORT table. The CLR then loads the CLR Header and Data sections.

The CLR Data section contains two important segments: Metadata and Intermediate Language (IL) code:

Metadata contains information relevant to the assembly, including the assembly manifest. A manifest describes the assembly in detail including unique identification (via a hash, version number, etc.), data on exported components, extensive type information (supported by the Common Type System (CTS)), external references, and a list of files within the assembly. The CLR environment makes extensive use of metadata.

Intermediate Language (IL) code is abstracted, language independent code that satisfies the .NET CLR's Common Intermediate Language (CIL) requirement. The term "Intermediate" refers to the nature of IL code being cross-language and cross-platform compatible. This intermediate language, similar to Java bytecode, allows platforms and languages to support the common .NET CLR. IL supports object-oriented programming (polymorphism, inheritance, abstract types, etc.), exceptions, events, and various data structures.

Here is an MSDN article discussing the Portable Execution Format.

Here is part 2 of that article.

A relevant extract from that article:

Executables produced for the Microsoft .NET environment are first and foremost PE files. However, in most cases normal code and data in a .NET file are minimal. The primary purpose of a .NET executable is to get the .NET-specific information such as metadata and intermediate language (IL) into memory.

In addition, a .NET executable links against MSCOREE.DLL. This DLL is the starting point for a .NET process. When a .NET executable loads, its entry point is usually a tiny stub of code. That stub just jumps to an exported function in MSCOREE.DLL (_CorExeMain or _CorDllMain). From there, MSCOREE takes charge, and starts using the metadata and IL from the executable file.

This setup is similar to the way apps in Visual Basic (prior to .NET) used MSVBVM60.DLL. The starting point for .NET information is the IMAGE_COR20_HEADER structure, currently defined in CorHDR.H from the .NET Framework SDK and more recent versions of WINNT.H. The IMAGE_COR20_HEADER is pointed to by the IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR entry in the DataDirectory.

It talks about executables, but the PE format is also used for .Net DLLs.

See the article itself for full details. As you can see, this stuff is not straightforward!