DLL 中有什么? 它是如何工作的？

我总是在我的 C # 代码中引用 DLL，但是它们仍然有些神秘，我想澄清一下。这是一种关于 DLL 的问题的大脑转储。

我知道 DLL 是一个动态链接的库，这意味着其他程序可以在运行时访问这个库来获得“功能”。然而，考虑下面的 ASP.NET 项目，它包含 Web.dll和 Business.dll(Web.dll是前端功能，它在类型和方法中引用 Business.dll)。

  1. Web.dll在什么时候动态链接到 Business.dll？在使用 Word (等等)时，你注意到 Windows 硬盘对于看似小的任务有很多不同的处理方式，我认为 Word 正在从其他 DLL 中动态链接功能？

    1a.此外，什么加载和链接 DLL-操作系统或某些运行时框架，如。NET 框架？

    1B.什么是“连接”的过程？是否进行了兼容性检查？进入同一段记忆？链接到底意味着什么？

  2. 什么实际执行 DLL 中的代码？是由处理器执行，还是在处理器理解 DLL 中的代码之前，还有另一个翻译或编译阶段？

    2a.在 C # 中内置 DLL 的情况下。NET，什么是运行这个:。NET 框架还是直接操作系统？

  3. 来自 Linux 的 DLL 是否可以在 Windows 系统上工作(如果存在的话) ，或者它们是特定于操作系统的？

  4. DLL 是特定于特定框架的吗？可以使用 C # 构建 DLL 吗。NET 被一个 DLL 所使用，例如，Borland C + + ？

    4a.如果4的答案是“否”，那么 DLL 的意义何在？为什么不同的框架使用自己的链接文件格式？例如:。内建的 exe。NET 知道文件类型为。是它可以链接到它的代码的东西。

  5. 回到 Web.dll/Business.dll例子-为了获得客户的类型，我需要从 Web.dll引用 Business.dll。这肯定意味着 Business.dll包含某种关于客户类实际上是什么的规范。如果我已经编译了我的 Business.dll文件，比如说，Delphi: C # 能够理解它并且能够创建一个客户类，或者有一些类型的头信息或者说“嘿，对不起，你只能从另一个 Delphi DLL 使用我”？

    5a.方法也是如此; 我是否可以在 DLL 中编写 CreateInvoice()方法，然后在 C + + 中编译它，然后从 C # 访问并运行它？是什么阻止或允许我这么做？

  6. 关于 DLL 劫持问题，当然替代(坏) DLL 必须包含被劫持的方法签名和类型。如果您能找出原始 DLL 中有哪些方法可用，我想这并不难做到。

    6a.在我的 C # 程序中，是什么在决定我是否可以访问另一个 DLL？如果我劫持的 DLL 包含与原始 DLL 完全相同的方法和类型，但它是用另一种语言编译的，它会工作吗？

什么是 DLL 导入和 DLL 注册？

69610 次浏览
小开

A .dll file contains compiled code you can use in your application.

Sometimes the tool used to compile the .dll matters, sometimes not. If you can reference the .dll in your project, it doesn't matter which tool was used to code the .dll's exposed functions.

The linking happens at runtime, unlike statically linked libraries, such as your classes, which link at compile-time.

You can think of a .dll as a black box that provides something your application needs that you don't want to write yourself. Yes, someone understanding the .dll's signature could create another .dll file with different code inside it and your calling application couldn't know the difference.

HTH

小开
最佳答案

First of all, you need to understand the difference between two very different kinds of DLLs. Microsoft decided to go with the same file extensions (.exe and .dll) with both .NET (managed code) and native code, however managed code DLLs and native DLLs are very different inside.

1) At what point does web.dll dynamically link to business.dll? You notice a lot in Windows HDD thrashing for seemingly small tasks when using Word etc and I reckon that this Word going off and dynamically linking in functionality from other DLL's?

1) In the case of .NET, DLLs are usually loaded on demand when the first method trying to access anything from the DLL is executed. This is why you can get TypeNotFoundExceptions anywhere in your code if a DLL can't be loaded. When something like Word suddenly starts accessing the HDD a lot, it's likely swapping (getting data that has been swapped out to the disk to make room in the RAM)

1a) Additionally what loads and links the DLL - the O/S or some runtime framework such as the .Net framework?

1a) In the case of managed DLLs, the .NET framework is what loads, JIT compiles (compiles the .NET bytecode into native code) and links the DLLs. In the case of native DLLs it's a component of the operating system that loads and links the DLL (no compilation is necessary because native DLLs already contain native code).

1b) What is the process of "linking"? Are checks made that there is compatibility? Loading into the same memory? What does linking actually mean?

1b) Linking is when references (e.g. method calls) in the calling code to symbols (e.g. methods) in the DLL are replaced with the actual addresses of the things in the DLL. This is necessary because the eventual addresses of the things in the DLL cannot be known before it's been loaded into memory.

2) What actually executes the code in the DLL? Does it get executed by the processor or is there another stage of translation or compilation before the processor will understand the code inside the DLL?

2) On Windows, .exe files and .dll files are quite identical. Native .exe and .dll files contain native code (the same stuff the processor executes), so there's no need to translate. Managed .exe and .dll files contain .NET bytecode which is first JIT compiled (translated into native code).

2a) In the case of a DLL built from C# .net what is running this? The .Net framework or the operating system directly?

2a) After the code has been JIT compiled, it's ran in the exact same way as any code.

3) Does a DLL from say Linux work on a Windows system (if such a thing exists) or are they operating system specific?

3) Managed DLLs might work as-is, as long as the frameworks on both platforms are up to date and whoever wrote the DLL didn't deliberately break compatibility by using native calls. Native DLLs will not works as-in, as the formats are different (even though the machine code inside is the same, if they're both for the same processor platform). By the way, on Linux, "DLLs" are known as .so (shared object) files.

4) Are they specific to a particular framework? Can a DLL built using C# .Net be used by a DLL built with Borland C++ (example only)?

4) Managed DLLs are particular to the .NET framework, but naturally they work with any compatible language. Native DLLs are compatible as long as everyone uses the same conventions (calling conventions (how function arguments are passed on the machine code level), symbol naming, etc)

5) Going back to the web.dll / business.dll example. To get a class type of customer I need to reference business.dll from web.dll. This must mean that business.dll contains a specification of some sort of what a customer class actually is. If I had compiled my business.dll file in say Delphi would C# understand it and be able to create a customer class - or is there some sort of header info or something that says "hey sorry you can only use me from another delphi dll".

5) Managed DLLs contain a full description of every class, method, field, etc they contain. AFAIK Delphi doesn't support .NET, so it would create native DLLs, which can't be used in .NET straightforwadly. You will probably be able to call functions with PInvoke, but class definitions will not be found. I don't use Delphi so I don't know how it stores type information with DLLs. C++, for example, relies on header (.h) files which contain the type declarations and must be distributed with the DLL.

6) On the subject of DLL hijacking, surely the replacement (bad) DLL must contain the exact method signatures, types as the one that is being hijacked. I suppose this wouldnt be hard to do if you could find out what methods etc were available in the original DLL.

6) Indeed, it's not hard to do if you can easily switch the DLL. Code signing can be used to avoid this. In order for someone to replace a signed DLL, they would have to know the signing key, which it kept secret.

6a) A bit of a repeat question here but this goes back to what in my C# program is deciding if I can access another DLL? If my hijacked DLL contained exactly the same methods and types as the original but it was compiled in another lanugage would it work?

6a) It would work as long as it's a managed DLL, made with any .NET language.

  • What is DLL importing? and dll registration?

"DLL importing" can mean many things, usually it means referencing a DLL file and using things in it.

DLL registration is something that's done on Windows to globally register DLL files as COM components to make them available to any software on the system.

小开

1) At what point does web.dll dynamically link to business.dll? You notice a lot in Windows HDD thrashing for seemingly small tasks when using Word etc and I reckon that this Word going off and dynamically linking in functionality from other DLL's?

1) I think you are confusing linking with loading. The link is when all the checks and balances are tested to be sure that what is asked for is available. At load time, parts of the dll are loaded into memory or swapped out to the pagefile. This is the HD activity you are seeing.

Dynamic linking is different from static linking in that in static linking, all the object code is put into the main .exe at link time. With dynamic linking, the object code is put into a separate file (the dll) and it is loaded at a different time from the .exe.

Dynamic linking can be implicit (i.e. the app links with a import lib), or explicit (i.e. the app uses LoadLibrary(ex) to load the dll).

In the implicit case, /DELAYLOAD can be used to postpone the loading of the dll until the app actually needs it. Otherwise, at least some parts of it are loaded (mapped into the process address space) as part of the process initilazation. The dll can also request that it never be unloaded while the process is active.

COM uses LoadLibrary to load COM dlls. Note that even in the implicit case, the system is using something similar to LoadLibrary to load the dll either at process startup or on first use.

2) What actually executes the code in the DLL? Does it get executed by the processor or is there another stage of translation or compilation before the processor will understand the code inside the DLL?

2) Dlls contain object code just like .exes. The format of the dll file is almost identical to the format of an exe file. I have heard that there is only one bit that is different in the headers of the two files.

In the case of a DLL built from C# .net, the .Net framework is running it.

3) Does a DLL from say Linux work on a Windows system (if such a thing exists) or are they operating system specific?

3) DLLs are platform specific.

4) Are they specific to a particular framework? Can a DLL built using C# .Net be used by a DLL built with Borland C++ (example only)?

4) Dlls can interoperate with other frameworks if special care is taken or some additional glue code is written.

Dlls are very useful when a company sells multiple products that have overlapping capabilities. For instance, I maintain a raster i/o dll that is used by more than 30 different products at the company. If you have multiple products installed, one upgrade of the dll can upgrade all the products to new raster formats.

5) Going back to the web.dll / business.dll example. To get a class type of customer I need to reference business.dll from web.dll. This must mean that business.dll contains a specification of some sort of what a customer class actually is. If I had compiled my business.dll file in say Delphi would C# understand it and be able to create a customer class - or is there some sort of header info or something that says "hey sorry you can only use me from another delphi dll".

5) Depending on the platform, the capabilities of a dll are presented in various ways, thru .h files, .tlb files, or other ways on .net.

6) On the subject of DLL hijacking, surely the replacement (bad) DLL must contain the exact method signatures, types as the one that is being hijacked. I suppose this wouldnt be hard to do if you could find out what methods etc were available in the original DLL.

6) dumpbin /exports and dumbin /imports are interesting tools to use on .exe and .dlls


提交答案