DLL에는 무엇이 있으며 어떻게 작동합니까?

DLL에는 무엇이 있으며 어떻게 작동합니까?

---

나는 항상 내 C # 코드에서 DLL을 참조하고 있지만, 분명히 밝히고 싶은 미스터리로 남아 있습니다. 이것은 DLL에 관한 일종의 두뇌 덤프입니다.

DLL이 동적으로 연결된 라이브러리라는 것을 이해합니다. 즉, 다른 프로그램이 "기능"을 얻기 위해 런타임에이 라이브러리에 액세스 할 수 있음을 의미합니다. 그러나 Web.dll및 Business.dll( Web.dll는 프런트 엔드 기능이며 Business.dll형식 및 메서드에 대한 참조)가 있는 다음 ASP.NET 프로젝트를 고려하십시오 .

1. 어떤 시점에서 Web.dll동적으로 연결 Business.dll됩니까? Word (등)를 사용할 때 겉보기에 작은 작업으로 인해 Windows HDD에서 많은 스 래싱이 발생하고 Word가 작동하지 않고 다른 DLL의 기능이 동적으로 연결되는 것으로 생각합니까?

   1a. 또한 DLL (OS 또는 .NET 프레임 워크와 같은 일부 런타임 프레임 워크)을로드하고 링크하는 것은 무엇입니까?

   1b. "연결"과정은 무엇입니까? 호환성 검사가 이루어 집니까? 동일한 메모리에로드 하시겠습니까? 실제로 연결이란 무엇을 의미합니까?

2. 실제로 DLL에서 코드를 실행하는 것은 무엇입니까? 프로세서에 의해 실행됩니까, 아니면 프로세서가 DLL 내부의 코드를 이해하기 전에 다른 번역 또는 컴파일 단계가 있습니까?

   2a. C # .NET으로 빌드 된 DLL의 경우, 이것을 실행하는 것은 무엇입니까 : .NET 프레임 워크 또는 운영 체제 직접?

3. Linux의 DLL이 Windows 시스템에서 작동합니까 (존재하는 경우), 아니면 운영 체제별로 고유합니까?

4. DLL은 특정 프레임 워크에 고유합니까? C # .NET을 사용하여 빌드 된 DLL을 예를 들어 Borland C ++로 빌드 된 DLL에서 사용할 수 있습니까?

   4a. 4에 대한 답이 "아니오"이면 DLL의 요점은 무엇입니까? 다양한 프레임 워크가 링크 된 파일에 대해 고유 한 형식을 사용하지 않는 이유는 무엇입니까? 예를 들어, .NET에 내장 된 .exe는 .abc의 파일 유형이 코드에 링크 될 수 있다는 것을 알고 있습니다.

5. Web.dll/ Business.dll예제로 돌아가서 참조해야하는 클래스 유형의 고객을 가져 Business.dll옵니다 Web.dll. 이것은 Business.dll고객 클래스가 실제로 무엇인지에 대한 일종의 사양 을 포함하고 있음을 의미합니다 . Business.dll예를 들어 Delphi에서 파일을 컴파일 했다면 C #이이를 이해하고 고객 클래스를 생성 할 수 있습니까? 아니면 일종의 헤더 정보 또는 "이봐 죄송합니다. 다른 Delphi DLL에서만 사용할 수 있습니다." ?

   5a. 방법에도 동일하게 적용됩니다. CreateInvoice()DLL에 메서드를 작성하고 C ++로 컴파일 한 다음 C #에서 액세스하여 실행할 수 있습니까? 이 작업을 중단하거나 허용하는 것은 무엇입니까?

6. DLL 하이재킹의 주제에서 대체 (나쁜) DLL에는 하이재킹되는 것과 동일한 메서드 서명 및 유형이 포함되어야합니다. 원래 DLL에서 사용 가능한 메서드를 찾을 수 있다면 이것이 어렵지 않을 것이라고 생각합니다.

   6a. 내 C # 프로그램에서 다른 DLL에 액세스 할 수 있는지 결정하는 것은 무엇입니까? 납치 된 DLL에 원본과 동일한 메서드 및 유형이 포함되어 있지만 다른 언어로 컴파일 된 경우 작동합니까?

DLL 가져 오기 및 DLL 등록이란 무엇입니까?

---

우선, 매우 다른 두 종류의 DLL 간의 차이점을 이해해야합니다. Microsoft는 .NET (관리 코드) 및 네이티브 코드와 함께 동일한 파일 확장명 (.exe 및 .dll)을 사용하기로 결정했지만 관리 코드 DLL과 네이티브 DLL은 내부에서 매우 다릅니다.

1) web.dll은 어떤 시점에서 business.dll에 동적으로 연결됩니까? Word 등을 사용할 때 겉보기에 작은 작업으로 인해 Windows HDD에서 많은 스 래싱이 발생 하고이 Word가 작동하지 않고 다른 DLL의 기능에서 동적으로 연결되는 것으로 생각합니까?

1) .NET의 경우, DLL에서 액세스를 시도하는 첫 번째 메소드가 실행될 때 일반적으로 요청시 DLL이로드됩니다. 이것이 DLL을로드 할 수없는 경우 코드의 어느 곳에서나 TypeNotFoundExceptions를 얻을 수있는 이유입니다. Word와 같은 것이 갑자기 HDD에 많이 액세스하기 시작하면 스와핑 (스왑 된 데이터를 RAM의 공간을 확보하기 위해 디스크로 가져옴) 일 수 있습니다.

1a) 추가적으로 DLL (O / S 또는 .Net 프레임 워크와 같은 일부 런타임 프레임 워크)을로드하고 링크하는 것은 무엇입니까?

1a) 관리 DLL의 경우 .NET 프레임 워크가로드되고 JIT가 컴파일 (.NET 바이트 코드를 네이티브 코드로 컴파일)하고 DLL을 연결합니다. 네이티브 DLL의 경우 DLL을로드하고 연결하는 것은 운영 체제의 구성 요소입니다 (네이티브 DLL에는 이미 네이티브 코드가 포함되어 있으므로 컴파일이 필요하지 않습니다).

1b) "연결"과정은 무엇입니까? 호환성이 있는지 확인합니까? 동일한 메모리에로드 하시겠습니까? 실제로 연결이란 무엇을 의미합니까?

1b) 링크는 호출 코드의 참조 (예 : 메서드 호출)가 DLL의 심볼 (예 : 메서드)에 대한 참조가 DLL에있는 사물의 실제 주소로 대체되는 경우입니다. 이것은 DLL에있는 사물의 최종 주소를 메모리로로드하기 전에 알 수 없기 때문에 필요합니다.

2) 실제로 DLL에서 코드를 실행하는 것은 무엇입니까? 프로세서에 의해 실행됩니까, 아니면 프로세서가 DLL 내부의 코드를 이해하기 전에 다른 번역 또는 컴파일 단계가 있습니까?

2) Windows에서 .exe 파일과 .dll 파일은 상당히 동일합니다. 네이티브 .exe 및 .dll 파일에는 네이티브 코드 (프로세서가 실행하는 것과 동일한 항목)가 포함되어 있으므로 번역 할 필요가 없습니다. 관리되는 .exe 및 .dll 파일에는 첫 번째 JIT 컴파일 (네이티브 코드로 변환) 된 .NET 바이트 코드가 포함되어 있습니다.

2a) C # .net에서 빌드 된 DLL의 경우 이것을 실행하는 것은 무엇입니까? .Net 프레임 워크 또는 운영 체제 직접?

2a) 코드가 JIT 컴파일 된 후에는 다른 코드와 똑같은 방식으로 실행됩니다.

3) Linux의 DLL이 Windows 시스템에서 작동합니까 (존재하는 경우) 아니면 운영 체제에 특정한 것입니까?

3) 관리 DLL은 두 플랫폼의 프레임 워크가 최신 상태이고 DLL을 작성한 사람이 네이티브 호출을 사용하여 고의적으로 호환성을 깨뜨리지 않는 한 그대로 작동 할 수 있습니다. 네이티브 DLL은 형식이 다르기 때문에 그대로 작동하지 않습니다 (둘 다 동일한 프로세서 플랫폼 용인 경우 내부의 기계어 코드가 동일하더라도). 그런데 Linux에서 "DLL"은 .so (공유 개체) 파일로 알려져 있습니다.

4) 특정 프레임 워크에 고유합니까? C # .Net을 사용하여 빌드 된 DLL을 Borland C ++로 빌드 된 DLL에서 사용할 수 있습니까 (예제 만 해당)?

4) 관리 DLL은 .NET 프레임 워크에 특화되어 있지만 자연스럽게 호환되는 모든 언어와 함께 작동합니다. 모든 사람이 동일한 규칙 (호출 규칙 (기계 코드 수준에서 함수 인수가 전달되는 방식), 기호 이름 지정 등)을 사용하는 한 네이티브 DLL은 호환됩니다.

5) web.dll / business.dll 예제로 돌아갑니다. 클래스 유형의 고객을 얻으려면 web.dll에서 business.dll을 참조해야합니다. 이것은 business.dll에 고객 클래스가 실제로 어떤 종류인지에 대한 사양이 포함되어 있음을 의미합니다. 내 business.dll 파일을 Delphi가 C #에서 이해하고 고객 클래스를 생성 할 수 있다고 말한 경우-또는 일종의 헤더 정보 또는 "이봐 죄송합니다. 다른 delphi dll에서만 사용할 수 있습니다." .

5) 관리 DLL에는 포함 된 모든 클래스, 메서드, 필드 등에 대한 전체 설명이 포함되어 있습니다. AFAIK Delphi는 .NET을 지원하지 않으므로 .NET에서 간단하게 사용할 수없는 네이티브 DLL을 생성합니다. PInvoke를 사용하여 함수를 호출 할 수 있지만 클래스 정의는 찾을 수 없습니다. 델파이를 사용하지 않아서 DLL과 함께 유형 정보를 저장하는 방법을 모르겠습니다. 예를 들어 C ++는 유형 선언을 포함하고 DLL과 함께 배포되어야하는 헤더 (.h) 파일에 의존합니다.

6) DLL 하이재킹의 주제에 대해 대체 (나쁜) DLL에는 하이재킹되는 것과 같은 정확한 메서드 서명 유형이 포함되어야합니다. 원래 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.

---

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

---

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

참고URL : https://stackoverflow.com/questions/3628798/what-is-in-a-dll-and-how-does-it-work