Import Library는 어떻게 작동합니까?상세 정보?
괴짜들에게는 이게 꽤 기본적인 것처럼 보일 수도 있다는 걸 알아.하지만 분명히 하고 싶군요
Win32 DLL을 사용하는 경우 보통 LoadLibrary()나 GetProcAdders() 등의 API를 호출합니다.하지만 최근 DirectX9로 개발 중이어서 d3d9.lib, d3dx9.lib 등의 파일을 추가해야 합니다.
LIB는 정적 링크용이고 DLL은 동적 링크용이라고 충분히 들었습니다.
따라서 현재 LIB에는 메서드의 구현이 포함되어 있으며 링크 시 최종 EXE 파일의 일부로 정적으로 링크되어 있는 것으로 알고 있습니다.DLL은 런타임에 동적으로 로드되며 최종 EXE 파일의 일부가 아닙니다.
그러나 DLL 파일과 함께 제공되는 LIB 파일이 있을 수 있으므로 다음과 같이 하십시오.
- 이 LIB 파일의 용도는 무엇입니까?
- 그들이 원하는 것을 어떻게 달성할 것인가?
- 이 LIB 파일의 내부를 조사할 수 있는 툴이 있습니까?
업데이트 1
위키피디아를 확인해보니, 이 LIB 파일을 Import Library라고 합니다.하지만 메인 어플리케이션과 DLL을 동적으로 로드하는 방법이 궁금합니다.
업데이트 2
RBerteig가 말한 것처럼 DLL과 함께 태어난 LIB 파일에 stub 코드가 있습니다.따라서 콜 시퀀스는 다음과 같습니다.
메인 어플리케이션 --> LIB의 stub --> 실제 타깃 DLL
그렇다면 이러한 LIB에는 어떤 정보가 포함되어야 할까요?나는 다음과 같이 생각할 수 있었다.
- LIB 파일에는 대응하는 DLL의 풀패스가 포함되어 있어야 합니다.따라서 런타임에 의해 DLL이 로드될 수 있습니다.
- 각 DLL 내보내기 메서드엔트리 포인트의 상대 주소(또는 파일오프셋?)를 stub로 인코딩해야 합니다.따라서 올바른 점프/메서드 호출이 이루어질 수 있습니다.
내 말이 맞나?더 할말 있나?
BTW : Import Library를 검사할 수 있는 툴이 있습니까?내가 그걸 볼 수 있다면, 더 이상 의심할 여지가 없을 거야.
DLL 파일에 대한 링크는 다음 위치에서 암묵적으로 수행될 수 있습니다.
컴파일하다 링크 시간 또는 실행 시간에 명시적으로 지정합니다.어느 쪽이든 DLL은 프로세스 메모리 공간에 로드되고 내보낸 모든 진입점을 응용 프로그램에서 사용할 수 있게 됩니다.
시 " "를 사용합니다.LoadLibrary() ★★★★★★★★★★★★★★★★★」GetProcAddress()DLL을 수동으로 로드하여 호출해야 하는 함수에 대한 포인터를 가져옵니다.
프로그램이 빌드될 때 암묵적으로 링크되어 있는 경우 프로그램에서 사용되는 각 DLL 내보내기용 스터브는 Import 라이브러리에서 프로그램으로 링크되며 프로세스 시작 시 EXE 및 DLL이 로드되면 이러한 스터브가 업데이트됩니다.(네, 여기서는 조금 이상 단순화했습니다.)
이러한 스텁은 어딘가에서 가져와야 하며 Microsoft 툴 체인에서는 특수한 형식의 에서 가져옵니다.Import 라이브러리라고 불리는 LIB 파일.필수.LIB는 보통 DLL과 동시에 구축되며 DLL에서 내보내는 각 함수의 스터브를 포함합니다.
혼란스럽지만, 같은 라이브러리의 스태틱버전은 로도 출하됩니다.LIB 파일DLL용 Import 라이브러리인 LIB는 일반적으로 일치하는 스태틱 LIB보다 훨씬 작다는 것을 제외하고 이들을 구별하는 간단한 방법은 없습니다.
참고로 GCC 툴체인을 사용하는 경우 DLL을 일치시키기 위해 Import 라이브러리가 실제로 필요하지 않습니다.Windows에 포팅된 Gnu 링커 버전은 DLL을 직접 인식하며 필요한 스터브 대부분을 즉시 합성할 수 있습니다.
갱신하다
모든 너트와 볼트가 실제로 어디에 있는지, 그리고 실제로 무슨 일이 일어나고 있는지 알 수 없다면 MSDN에는 항상 도움이 되는 무언가가 있습니다.Matt Pietrek의 기사 "An In-Depth Look in the Win32 Portable Executive File Format"은 EXE 파일의 형식과 로드 및 실행 방법에 대한 매우 완전한 개요입니다.에 대해서도 업데이트 되었습니다.MSDN Magazine ca. 2002에 처음 게재된 이후 NET 등.
또한 프로그램에서 사용되는 DLL을 정확하게 학습하는 방법도 도움이 됩니다.이를 위한 도구는 Dependency Walker(일명 dependency.exe)입니다.Visual Studio에는 버전이 포함되어 있지만 최신 버전은 작성자(http://www.dependencywalker.com/에서 구할 수 있습니다.링크 시 지정된 모든 DLL(초기 로드 및 지연 로드 모두)을 식별할 수 있으며 프로그램을 실행하여 런타임에 로드되는 추가 DLL을 감시할 수도 있습니다.
업데이트 2
나는 MSDN과의 정합성을 위해 재독해할 때 그것을 명확히 하고 암묵적이고 명시적인 링크의 예술 용어를 사용하기 위해 이전 텍스트 중 몇 가지를 다시 썼다.
라이브러리 기능을 프로그램에서 사용할 수 있도록 하는 방법은 세 가지가 있습니다.분명한 후속 질문은 "어느 쪽을 선택할 것인가?"입니다.
정적 링크는 프로그램 자체의 대부분을 연결하는 방법입니다.모든 오브젝트 파일이 리스트 되어 링커에 의해 EXE 파일로 수집됩니다.이 과정에서 링커는 모듈이 서로의 함수를 호출할 수 있도록 글로벌 심볼에 대한 참조를 수정하는 등의 사소한 잡무를 처리합니다.라이브러리는 정적으로 링크할 수도 있습니다.라이브러리를 구성하는 오브젝트파일은 라이브러리 관리자가 함께 수집합니다.링커가 필요한 기호를 포함하는 모듈을 검색하는 LIB 파일.정적 링크의 한 가지 효과는 프로그램에서 사용되는 라이브러리의 모듈만 링크되고 다른 모듈은 무시됩니다.예를 들어, 기존의 C 수학 라이브러리에는 많은 삼각함수가 포함되어 있습니다.하지만 만약 당신이 그것에 대해 링크하고cos()의 코드의 카피가 되는 일은 없습니다.sin()또는tan()그 함수를 호출하지 않는 한 말이죠.풍부한 기능을 갖춘 대규모 라이브러리의 경우 모듈을 선택적으로 포함하는 것이 중요합니다.임베디드 시스템과 같은 많은 플랫폼에서는 라이브러리에서 사용할 수 있는 코드의 총 사이즈는 디바이스에서 실행 파일을 저장할 수 있는 공간에 비해 클 수 있습니다.선별적으로 포함시키지 않으면 해당 플랫폼용 프로그램 구축에 대한 세부사항을 관리하는 것이 더 어려워집니다.
그러나 실행 중인 모든 프로그램에 동일한 라이브러리의 복사본이 있으면 일반적으로 많은 프로세스를 실행하는 시스템에 부담이 생깁니다.올바른 종류의 가상 메모리 시스템을 사용하면 동일한 내용을 가진 메모리의 페이지가 시스템에 한 번만 존재하면 되지만 많은 프로세스에서 사용할 수 있습니다.이것에 의해, 코드를 포함한 페이지가 가능한 한 많은 다른 실행 프로세스에서 일부 페이지와 같을 가능성이 높아집니다.그러나 프로그램이 런타임 라이브러리에 정적으로 링크되어 있는 경우, 각각 다른 위치에 있는 프로세스 메모리 맵에 배치되어 있는 함수의 혼합이 서로 다르며, 프로세스 이상의 프로세스로 실행되는 프로그램이 아니면 공유할 수 있는 코드 페이지가 많지 않습니다.그래서 DLL이라는 아이디어는 또 다른 큰 이점을 얻었습니다.
라이브러리의 DLL에는 클라이언트 프로그램에서 사용할 수 있는 모든 기능이 포함되어 있습니다.많은 프로그램이 해당 DLL을 로드하면 모두 코드 페이지를 공유할 수 있습니다.DLL을 새 버전으로 업데이트하기 전까지는 모든 사람이 승리합니다. 하지만 그건 이 이야기의 일부가 아닙니다.Google DLL Hell (구글 DLL Hell을 참조하십시오.
따라서 새 프로젝트를 계획할 때 가장 먼저 해야 할 큰 선택은 동적 링크와 정적 링크입니다.정적 링크를 사용하면 설치할 파일이 줄어들고 사용하는 DLL을 제삼자가 업데이트하지 않아도 됩니다.그러나 프로그램이 더 크고 Windows 에코시스템에 대한 좋은 시민은 아닙니다.동적 링크를 사용하면 설치할 파일이 더 많아지고 사용하는 DLL을 서드파티가 업데이트하는 데 문제가 있을 수 있지만 일반적으로 시스템상의 다른 프로세스에 대해 더 우호적입니다.
DLL의 큰 장점은 메인 프로그램의 재컴파일이나 재링크 없이 로드하여 사용할 수 있다는 것입니다.이것에 의해, 서드 파티의 라이브러리 프로바이더(예를 들면 Microsoft 나 C 런타임)가 라이브러리의 버그를 수정해 배포할 수 있습니다.최종 사용자는 업데이트된 DLL을 설치하면 해당 DLL을 사용하는 모든 프로그램에서 버그 수정의 이점을 즉시 얻을 수 있습니다(단, 문제가 발생하지 않는 한).DLL의 Hell을 참조해 주세요).
또 다른 장점은 암묵적 부하와 명시적 부하 간의 차이에서 비롯됩니다.명시적 로딩의 추가 노력을 기울이면 프로그램이 작성되고 게시될 때 DLL이 존재하지 않을 수 있습니다.이를 통해 예를 들어 플러그인을 검출하고 로드할 수 있는 확장 메커니즘이 허용됩니다.
은 다음 속성에서 됩니다.LIB 가져오기 라이브러리 파일은 다음 프로젝트 속성에 사용됩니다.Linker->Input->Additional DependenciesImport 라이브러리에서 제공되는 링크 시 추가 정보가 필요한 다수의 dll을 빌드하는 경우.LIB " dll의파일을 ."DLL" A, B, C의 DLib (를 ( " )에 해야 할 수 .Linker->General->Additional Library Directories그렇지 않으면 제공된 lib 파일을 찾을 수 없다는 빌드 오류가 발생합니다.)
경우는, 「」아래에 되는 참조 하는 것으로, 이인 의존 관계 할 수 가능성이 .Common Properties->Framework and References대화.이러한 플래그는 *.lib 파일을 사용하여 자동으로 사용자를 대신하여 링크를 수행하는 것으로 나타납니다.
단, 이는 설정이나 플랫폼 고유의 것이 아닌 Common Properties라고 기재되어 있습니다.애플리케이션처럼 혼합 빌드 시나리오를 지원해야 하는 경우 정적 빌드를 렌더링하는 빌드 구성과 동적 라이브러리로 배포된 어셈블리의 서브셋을 제한적으로 빌드하는 특수 구성이 있습니다.사용했었어요.Use Library Dependency Inputs ★★★★★★★★★★★★★★★★★」Link Library Dependencies플래그가 true로 설정된 것은 빌드할 것을 가져오고 나중에 심플화를 실현하기 위해서입니다만, 스태틱 빌드에 코드를 도입했을 때는 링커 경고가 많이 나왔기 때문에 스태틱 빌드에 대한 빌드 속도가 매우 느렸습니다.결국 이런 경고들을 많이 소개하게 됐는데...
warning LNK4006: "bool __cdecl XXX::YYY() already defined in CoreLibrary.lib(JSource.obj); second definition ignored D.lib(JSource.obj)
''을 되었습니다.Additional Dependencies동적 빌드를 위한 링커를 만족시키는 동시에 정적 빌더를 느리게 만드는 공통 속성을 사용하지 않음으로써 만족도를 유지할 수 있습니다.다이내믹 서브셋빌드를 전개할 때는 dll 파일만 전개합니다.이러한 lib 파일은 링크 시에만 사용되며 런타임에는 사용되지 않습니다.
이 질문에 대답하기 위한 MSDN 관련 토픽을 다음에 나타냅니다.
라이브러리에는 정적 라이브러리, 공유 라이브러리 및 동적으로 로드된 라이브러리의 세 종류가 있습니다.
스태틱 라이브러리는 링크 단계에서 코드에 링크되므로 메인 함수가 호출되기 전에 실행 시 로드되는 공유 라이브러리 파일에서 찾는 스터브(심볼)만 있는 공유 라이브러리와는 달리 실제로 실행 파일에 있습니다.
동적으로 로드된 것은 사용자가 작성한 코드로 인해 필요할 때 로드된다는 점을 제외하면 공유 라이브러리와 매우 유사합니다.
언급URL : https://stackoverflow.com/questions/3573475/how-does-the-import-library-work-details
'programing' 카테고리의 다른 글
| Java 기본 생성자 (0) | 2022.06.13 |
|---|---|
| 이 Nuxt-Socket-io 이미터는 왜 그 액션을 트리거하지 않는가? (0) | 2022.06.13 |
| Vue 구성 요소에서 경로를 지정하는 올바른 방법 (0) | 2022.06.13 |
| vue-material 구성 요소의 임의 로드 오류 (0) | 2022.06.12 |
| Vuex: 알 수 없는 변환 유형: 드롭다운 상태 (0) | 2022.06.12 |