내 남자의 길~!

Static Linked Library, 정적 링크 라이브러리

컴파일시 실행파일에 라이브러리의 함수코드가 추가되어 작성되기 때문에 실행파일이 커지는 단점이 있으나 별도의 DLL이 필요없다.

VC++6에서는 New Projects에 Win32 Static Library로 작성하고 2005에서는 Win32 콘솔 응용프로그램에서 정적라이브러리(미리 컴파일된 헤더 해제)를 선택하여 작성한다.
명령줄에서 작성하려면 cl.exe /c /EHsc 파일명.cpp(/c 옵션은 링크없이 컴파일) 로 컴파일 하여 obj 파일 생성후 lib.exe ~.obj 으로 ~.lib 파일을 생성한다.

만들어진 LIB(~.lib파일)과 ~.h(header파일)을 작성하고자 하는 Project 생성후라이브러리는 Project->Setting->Library modules에서 ~.lib를 추가하고 헤더는 원하는 코드에 추가하여 빌드한다.

Dynamic Linked Libarary(DLL), 동적 링크 라이브러리

우리가 흔히 말하는 DLLs 이다. 컴파일시 실행파일에 라이브러리의 함수코드를 넣지 않고 DLL 이라는 파일에 따로 두어 모듈화를 통해 관리와 테스트가 용이하며 공유를 통해 코드의 낭비를 줄이고 다국어버전등의 리소스교체를 용이하게 한다.

New Projects에서 Win32 Dynamic-link library로 작성한다. 2005에서는 win32 응용프로그램작성에서 DLL 을 선택하면 된다.

Header파일을 공통적으로 사용하기 위한 예시

~.DEF 파일 
예전에는 ~.def 파일을 통해 dll을 export 하였지만 VC++에서는 __declspec(dllexport)를 통해서 dll 의 함수들을 export한다. 반대로 import시에는 __declspec(dllimport)를 사용한다.

Implicit Linkage, 암시적 링크
LoadLibrary를 사용하지 않는다. 따라서 프로그램이 실행될때 dll이 로드된다.
그러기 위해서는 Static Library와 같이 ~.lib파일과 ~.h 파일이 필요하고 실행시는 같은 폴더 또는 시스템폴더(dll을 찾는 정책에 따라)에 dll 파일이 존재하여야 한다. 없을시 찾을수 없다면 에러가 발생한다.
dll을 생성하고 나면 생성된 폴더에 lib 파일도 같이 생성되는데 Static Library와는 달리 함수의 코드가 없다. 다만 함수형이 정의되어 있을뿐이다. 실행파일의 implict section에서 실행시 로드되어야 할 dll을 추가하여 나중에 프로그램이 실행되면 dll이 로드된다.

Explicit Linkage,  명시적 링크
  LoadLibrary로 명시적으로 dll을 로드한다. GetProcAddress로 사용하고자 하는 함수의 주소를 얻어서 사용한다. dll이 load되는 시점은 프로그램이 실행되는 순간이 아니고 LoadLibrary가 호출되는 시점이다.

Delay Linkage, 지연 링크
빌드시 옵션에 /delayload:dllname 으로 작성한다.
로드되는 시점은 프로그램 실행시가 아니라 함수가 사용되는 시점이 된다.
/delay 옵션도 참고할것

확장DLL
MFC 클래스에서 파생된 재사용 가능한 클래스를 구현한 DLL. 따라서 MFC로 만든 응용 프로그램에서만 확장 DLL이 사용되어 질수 있다.
이 DLL로부터 익스포트할 클래스에 대해서 여러분이 해줄일은 클래스 선언문에 AFX_EXT_CLASS란 매크로만 붙여준다.

예시

DLL - 함수 호출시 __declspec(dllimport)의 사용

Level of Difficulty 1 2 3

DLL을 통해서 API를 제공하기 위해서 DLL(PE)의 Export Table에 함수를 나타내도록 __declspec(dllexport)지시자를 사용합니다.
반면에 함수를 호출하는 쪽에서는 특별히 __declspec(dllimport)으로 정의된 함수원형을 사용하지 않아도 DLL에서 제공된 함수를 사용 할 수 있습니다.


결론 부터 말씀드리면 DLL에서 제공되는 함수를 사용할 때에는 함수선언 앞에 __declspec(dllimport) 지시자를 사용할 것을 강력히 권합니다.

대부분 DLL의 API는 헤더에서 다음과 같이 선언 되어있습니다.

// API Export/Import Header

#ifdef CALLEE_EXPORTS
#define CALLEE_API __declspec(dllexport)
#else
#define CALLEE_API __declspec(dllimport)
#endif

CALLEE_API DWORD __stdcall no_no_stdcall(DWORD); // WINAPI
CALLEE_API DWORD __cdecl no_no_cdecl(DWORD); // CDECL
CALLEE_API DWORD __fastcall no_no_fastcall(DWORD);
위 헤더의 핵심은 동일한 헤더를 공유해서 사용하게 되는 것입니다.
(특히 ThirdParty 벤더에서 제공되는 API모듈이라면 더욱더 그렇겠죠)

즉, Preprocessor definitions에 CALLEE_EXPORTS가 선언되어 있지 않다면 헤더는 함수를 __declspec(dllimport)형식으로 정의하게 되겠죠.
(위의 API 제공하는 벤더는 프로젝트 설정에 CALLEE_EXPORTS를 정의해서 컴파일하고 있을 것입니다.)

위의 예는 가장 확실하게 __declspec(dllimport)를 선언해서 사용할 수 있는 경우이고 헤더가 중복해서 관리해야하는 어려움도 필요없는 최적의 케이스 입니다.

하지만 내부 프로젝트 모듈이건 다른 벤더의 모듈이던 이렇게 사용되지 않고 다음과 같이 import용으로 별도로 정의되어서 사용되는 경우가 많이 있습니다.

// API Import Header

DWORD __stdcall no_no_stdcall(DWORD); // WINAPI
DWORD __cdecl no_no_cdecl(DWORD); // CDECL
DWORD __fastcall no_no_fastcall(DWORD);
이 경우는 헤더 관리의 복잡성을 떠나서 별로 좋지 않은 케이스 입니다.
(최소한 다른 DLL에 선언되어 있는 함수를 호출하는 경우에...)

DWORD __stdcall no_no_stdcall(DWORD);
__declspec(dllimport) DWORD __stdcall no_no_stdcall(DWORD);
DLL을 static link 할 경우에 위의 두가지 경우 모두 정상적으로 수행됩니다.
그렇다면 차이점이 무엇일까요?


DWORD __stdcall no_no_stdcall(DWORD);
위와 같이 선언된 상태에서 링커는 DLL에서 생성된 빈 Lib에서 가르키고 있는 Stub을 직접 호출하도록 합니다. 왜냐하면 컴파일러는 no_no_stdcall() 이라는 함수가 내부에 선언된 함수인지 다른 모듈(DLL)에 선언되어 있는 함수인지를 구별 할 수 없기 때문입니다.

그렇다면 이 경우 실제 해당 DLL의 함수가 어떻게 호출 될까요?
DLL생성시 함께 생성되는 빈 Lib의 Stub내부에는 실제 모듈(DLL)의 함수로 점프할 수 있는 코드가 컴파일 타임에 이미 생성되서 Stub안에 존재하기 때문에 가능한 것입니다.
즉 해당 Stub을 내부 함수처럼 호출하면 그곳에서 실제 모듈(DLL)의 함수를 가르키는 IAT(Import Address Table)를 참조해서 실제 API가 점프하게 되는 코드가 수행되는 것입니다.


정리해서 말씀드리면, DLL의 함수를 호출할 경우에 아래와 같은 두가지 형태의 코드가 생성될 수 있습니다.

// 1. 함수원형 앞에 __declspec(dllimport) 지시자를 사용할 경우
0xXXXXXXXX : CALL DWORD PTR [0x56780000]; // CALL DWORD PTR[_imp__MyFunc];


// 2. 지시자 없이 그냥 사용할 경우
0xXXXXXXXX : CALL 0x12340000;
0x12340000 : JMP DWORD PTR[0x56780000];


(0x5678000 : 실제함수주소를 가르키고있는 IAT의 주소)
위에서 설명드렸듯이 당연히 1번의 경우 DLL 함수호출시 훨씬 효과적인 것을 알 수 있습니다.
2번의 경우에는 JMP를 위한 추가적인 5Byte의 코드가 더 필요하게 되는 경우이므로 비효율적이겠죠.

__declspec(dllimport)지시자를 사용함으로서 1번의 코드형태로 DLL함수가 호출 되는 것을 알았습니다.
좀 더 설명드리면 컴파일러는 __declspec(dllimport) 지시자를 보았을 경우에 실제함수 MyFunc을 참조하지 않고 __imp__MyFunc을 참조하는 코드를 만들어 놓습니다.
그후에 링커는 __imp_ Prefix를 보고 실제 DLL에 존재하는 함수를 직접 호출하는 것임을 알게 되는 것입니다.

즉, 컴파일리가 링커에게 DLL에 존재하는 함수를 호출한다는 것을 알려주기 위해 __imp_ Prefix를 함수앞에 추가해 주는 것입니다.


: error LNK2001: unresolved external symbol __imp__MyFunc

: fatal error LNK1120: 1 unresolved externals
위의 에러를 보면 실제 함수앞에 __imp__ Prefix가 존재하는 것을 알 수 있습니다.

그런데 이 경우에 링크에러가 발생했는데 링크에러가 발생하지 않으려면 빈 Lib안에 __imp__MyFunc에 대한 Stub이 존재하고 있어야 겠죠.
DLL생성시 만들어진 Lib의 내용을 보면 MyFunc, __imp__MyFunc에대한 두가지 Stub이 모두 존재하고 있음을 볼 수 있습니다.

----------------------------------------------------------------------------------
// 확장DLL사용시 참고 사항

AFX_EXT_CLASS는  요렇게 정의되어 있습니다..

#ifdef _AFXEXT

    #define AFX_EXT_CLASS    __declspec(dllexport)

#else

    #define AFX_EXT_CALSS    __declspec(dllimport)

#endif // _AFXEXT

이 선언은 Extended DLL에서 export, 다른 프로젝트에서는 import로 해석됩니다...

그래서 결론만 말하면...........

#ifdef _MYEXT

    #define MY_EXT_CLASS    __declspec(dllexport)

#else

    #define MY_EXT_CLASS    __declspec(dllimport)

#endif

이렇게 헤더파일 처음에 정의하고,

class AFX_EXT_CALSS AAA

{

};

를

class MY_EXT_CLASS AAA

{

};

이렇게 선언합니다.......

그리고 DLL의 프로젝트 Setting에서 _MYEXT를 선언합니다.

(Project Menu의 Setting 다이얼로그에서 C++ tab의 Preprocessor

definitions에 _MYEXT를 추가합니다.)

이렇게 하면 class AAA는 DLL에서는 export, 다른 곳에서는 import가

됩니다.....

__declspec(extended-decl-modifier-seq) : 데이터나 모듈의 저장형태를 지정.

align(#)

    자주 사용되는 데이터를 특정 프로세서의 캐시라인 크기로 정렬해 캐시성능을 높인다. #값은

    1부터 8192 (바이트) 까지 2의 거듭제곱 수 즉 2, 4, 8, 16, 32, 64.

    Visual C++은 기본적으로 데이터 크기에 따라 경계정렬을 한다. 가령 4바이트 정수는 4바이트

    경계, 8바이트 더블은 8바이트 경계에 정렬되며, 클래스나 구조체의 데이터들은 현재 패킹 설정

    (#pragma pack(n) 또는 /Zp 옵션)에 따라 클래스나 구조체 내에 최소크기로 정렬된다.

    구조체, 공용체, 클래스, 변수에 대해 사용할 수 있지만, 스택변수에는 사용불가.

    #define CACHE_LINE      32

    #define CACHE_ALIGN    __declspec(align(CACHE_LINE))

    struct CACHE_ALIGN S1

    {

        int a, b, c, d;                // 이 타입의 모든 인스턴스는 32바이트 경계에서 시작해야하며,

    };                                    // sizeof(struct S1)는 32. 뒤따르는 16바이트는 채우기용

    __declspec(align(8)) struct S2

    {

        int a, b, c, d;               // sizeof(struct S2)는 16

    };

    struct S3

    {

        int a;                          // 4바이트 뒤를 잇는 28 바이트가 채우기용으로 쓰이며,

        struct S1 s1;              // s1은 오프셋 32에서 시작. sizeof(struct S3)는 64

    };

    // 배열의 시작주소는 32바이트로 정렬되지만, 각 배열멤버는 그렇지 않다.

    CACHE_ALIGN int array[128];

    // 배열의 각 멤버를 정렬하는 예

    typedef CACHE_ALIGN struct { int a; } S4;

    S4 array[10];

    TLS(Thread Local Storage : 정적변수가 스레드마다 다른 값을 갖도록 윈도우에서 제공

    하는 메모리 영역)에서 데이터 정렬

    __declspec(thread) 속성으로 만들어지고, 이미지에서 .tls 섹션에 놓인 TLS는 일반적인 정적

    데이터와 똑같이 정렬된다. 운영체제는 .tls 섹션 크기만큼 데이터를 할당하고 .tls 섹션 정렬

    속성을 고려해 TLS 데이터를 만든다.

    아래는 TLS에 정렬된 데이터를 놓는 다양한 방법들이다.

    __declspec(thread) __declspec(align(32)) int a;    // TLS에 정렬된 정수 놓기

    // 정렬된 구조체를 정의하고 구조체 타입의 변수를 TLS에 놓기

    __declspec(thread) __declspec(align(32)) struct F1 { int a; int b; } a;

    데이터 패킹과 함께 정렬하는 방식

    /Zp 옵션과 #pragma pack(n)은 구조체와 공용체 멤버 데이터를 패킹하는 효과가 있다.

    /Zp 옵션과 __declspec(align(#))을 같이 사용한 예와 각 멤버의 오프셋

    struct S{                                // 변수        /Zp1    /Zp2    /Zp4    /Zp8

        char a;                               //   a            0          0         0         0

        short b;                              //   b           1          2         2         2

        double c;                            //   c            3          4         4         4

        CACHE_ALIGN double d;    //   d           32        32       32       32

        char e;                               //   e           40        40       40        40

        double f;                            //    f           41        42       44        48

    };                                           //sizeof(S)  64        64       64        64

    따라서 객체의 오프셋은 객체가 __declspec(align(#)) 속성을 갖지 않으면, 이전 객체의

    오프셋과 현재 패킹 설정에 따라 결정되며, 그렇지 않으면 이전 객체의 오프셋과 객체의

    __declspec(align(#)) 값에 따라 결정된다.