我想知道 .NET dll 和普通 dll 之间的确切区别是什么。
第一个问题，“普通DLL”叫什么？我用的是“正常”这个词。但好像不太对劲？
因为两者都遵循PE格式。是的，我同意 .NET DLL 有一个额外的部分。除此之外，其他一切都是一样的。
我还知道.NET代码被转换为CIL/MSIL，那么PE文件的.text部分填充了什么？微软安全实验室？因为没有二进制代码。但是如果他们将 MSIL 放在 .text 部分中。加载程序假定它是二进制代码并允许它执行。事实并非如此。我缺少什么？
我很惊讶地知道
甚至 DLL 文件扩展名也是
人造的。您可以使用 DLL
完全不同的扩展——对于
实例.OCX控件和Control
面板小程序（.CPL 文件）是 DLL。
DLL 文件还使用哪些扩展名？
但我可以理解使用不同扩展名的原因。为什么他们没有在 .NET DLLS 中做同样的事情呢？他们本可以使用新的扩展来将其与“普通”DLL 区分开来。他们甚至对 .NET 中的 dll 有不同的名称 (ASSEMBLY)，但无法更改扩展名。嗯？
另一个完全不同的问题：什么是DLL注册？他们使用 regsvr32.exe 来实现。正确的？我在安装 Windows XP SP3 时注意到了这一点。安装后&在重新启动Windows之前，我检查了启动列表，发现了很多带有大量DLL的regsvr32.exe条目。
请随意深入研究。我正在学习链接器、加载器、二进制格式。我也熟悉PE文件格式。
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.
发布评论
评论（4）
我从我自己的帖子复制并粘贴了此内容it:
.NET dll 的格式为：
PE 标头
PE 标头是所有 Win32 应用程序和库都具有的可移植可执行标头，它指示 Windows 如何处理该文件。对于 .NET 程序集，这会加载 CLR，而 CLR 又会加载程序集。
CLR 标头
这包含诸如编写 .exe 或程序集所用的 .NET 版本、任何强名称签名哈希、可以找到资源的文件中的地址（RVA 或相对虚拟地址）等信息。最重要的是应用程序的入口点，它是指向 MethodDef 元数据表或另一个文件的令牌。对于类库，该标记为 0。
CLR 元数据
这是有关存储在几种不同类型的“流”内的模块的信息。这些流通常是压缩的，#~ 除外，它可以解压缩以进行编辑并继续。流有两种形式：仅用于存储的堆和表。
DLL/程序集的各个部分根据其用途存储在不同的表中 - 例如，所有类型都存储在
TypeRef表中，所有方法都存储在Method表中。每个表都引用一个父表。表的起点是模块表，其中仅包含模块的名称和 guid 作为单行。之后是 ModuleRef 表，其中包含有关该模块（来自同一程序集）引用的所有模块的信息。对于 VS.NET 及其对 csc.exe 的使用，程序集中没有多个文件，只有一个模块。
之后是 TypeDef 表，其中包含 6 列，其中包含类型的名称、名称空间、其父级（0 表示接口和对象）、FieldDef 表中字段的起始行、MethodDef 表中其方法的起始行。
IL 和本机数据
应用程序本身。
一书《Inside Microsoft .NET IL Assembler - Serge Lidin》 介绍了更多详细信息如果你有兴趣的话。
I've copied and pasted this from my own post on it:
The format of a .NET dll is:
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
TypeReftable, all methods in theMethodtable. 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.
这是一个好问题。 .NET DLL 和普通 DLL 之间有一个至关重要的区别，为了回答这个问题，我们将术语“本机 DLL”用作不依赖于 .NET 框架的普通 DLL。
关键的区别在于 .NET PE 标头布局中有第 15 个数据目录条目，而本机 DLL 只有 14 个数据目录条目。这就是您如何区分两者之间的区别，对于本机 DLL，该条目将为零！不仅如此，.NET DLL 还将嵌入元数据，以便框架进行相应的处理，例如请求安全权限的属性等，这同样适用于 .NET EXE。
与伪装成 DLL 的不同扩展（例如 OCX 和 CPL）相关，屏幕保护程序是从 .EXE 角度来看的非 DLL 扩展的另一个示例，即。那些.SCR实际上是.EXE...听起来很奇怪，微软似乎制作了一些应用程序来使用EXE和DLL的特定扩展名，我认为这是Windows 3.1时代的遗留问题，用于控制面板的 CPL、称为对象链接和嵌入到 OCX（现在的 ActiveX）的 OLE、用于屏幕保护程序（又名 .EXE）的 SCR。如果这同样适用于 .MSCc（Microsoft 管理单元控制台中使用的服务扩展），我不会感到惊讶。DLL
注册是
regsvr32注册 DLL 的地方，它的类 ID 可以在注册表中找到键 HKEY_CLASSES_ROOT，这更可能用于 COM（组件对象模型），用于使 COM 对象对所有语言全局可见，无论开发语言/环境如何。 ActiveX DLL 也属于同一类别，已知有些会自动注册自身（包括 COM DLL），包括它们的类型库标识（typelib id）...Windows 95 之前的许多软件曾经拥有自己的 DLL周围，有些重复，我记得的最常见的是 CTL3D.DLL（还记得吗？这会给 Windows 控件带来 3D 外观 - 天哪！）。它有如此多的版本在各地重复，这种重复和版本差异导致了 Windows 95，即所谓的 DLL 地狱。正是在那里，注册表在启动时首次亮相，其设计目的是通过将所有类型库注册在一个位置来绕过 DLL 地狱，而不是在各处复制 DLL，但它没有解析版本当时，导致程序出现损坏，因为 DLL 使用了一个类 ID，该 DLL 被更新的 DLL 版本取代，导致程序损坏！
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
regsvr32registers 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!
普通 DLL
.dll 文件包含编译后的代码，您可以在应用程序中使用它来执行特定的程序功能，并且可能需要其他应用程序或模块（例如 .exe 或 .dll）通过入口点加载它。
.Net DLL
当您使用 .NET 语言（例如 C# 或 VB.NET）实现 .Net DLL（程序集），您将生成托管程序集。 Managed Assembly 是 .NET 指定的组件标准。因此，.Net 程序集只能被 Microsoft.NET 理解，并且只能在 .NET 托管应用程序中使用。
更多信息 .... 普通 DLL 和 .Net Dll 之间的区别？
Matt
Normal DLL
A .dll file contains compiled code you can use in your application to perform specific program functions and may be required by another application or module (such as .exe or .dll) to load it through an entry point
.Net DLL
When you implement a .Net DLL (Assembly) in .NET Languages such as C# or VB.NET you produce a Managed Assembly. Managed Assembly is the component standard specified by the .NET. Hence, .Net assemblies are understandable only to Microsoft.NET and can be used only in .NET managed applications.
more info .... Difference between Normal DLL and .Net Dll?
Matt
唯一需要添加到发布的其他答案中的是 ac/c++ '.dll' 文件只是一个命名约定 - 您可以将其称为任何您喜欢的名称，因此 .ocx 和 .cpl。
c/c++ dll 是一组在运行时使用 LoadLibrary 并映射到被调用者的地址空间。它仍然被编译为本机代码，但没有任何目标地址空间的概念，因为它被设计为由加载器进行修补和修复。
Only thing to add to the other answers posted is that a c/c++ '.dll' file is just a naming convention - you could call it whatever you like hence .ocx and .cpl.
A c/c++ dll is a set of code and data that gets loaded at runtime using LoadLibrary and mapped into the callee's address space. It is still compiled to native code but doesn't have any concept of it's target address space because it's designed to be patched and fixed up by the loader.