다다

속성(property)------------------------------------------------------------------------------------------------------------------------

객체지향프로그래밍에서 일반적으로 맴버에 접근하기 위한 방법으로 Get함수와 Set함수를 만드는 것이 일반적이다.

하지만 C#에서는 이를 좀더 간편하게 하기 위해서 프로퍼티라고 부르는 문법을 지원한다.

namespace ConsoleApplication1

{

    class home

    {

        int age; -> C#에서도 C++과 같이 다른 지정이 없으면 private로 선언된다.

        public int Age -> age와는 다른 Age를 property로 선언했다.

        {

            get

            {

                return age; -> 값을 가져오는 속성을 저장한다.

            }

            set

            {

                age = value; -> 값을 대입하는 속성을 저장한다.

            }

        }

    }

    class Program

    {

        static void Main()

        {

            home home1 = new home();

            home1.Age = 5; -> 자동으로 Age중 set을 호출한다.

            Console.WriteLine(home1.Age); -> 자동으로 Age중 get을 호출한다.

            int a;

            a = home1.Age; -> 자동으로 Age중 get을 호출한다.

            Console.WriteLine(a);

        }

    }

}

참 편하다. 일일이 함수를 호출할 필요가 없이 자연적으로 연산자 오버로딩을 한것처럼 사용할 수가 있다.

하지만 속성은 더욱더 간략화된 방식으로 이용이 가능하다 다음을 보자.

namespace ConsoleApplication1

{

    class Contact

    {

        // Read-only properties.

        public string Name { get; private set; } -> get은 선언을 하나로 묶는다. set은 private성향으로 아무나 접근하지 못하도록 막는다.

        public string Address { get; private set; } -> get은 선언을 하나로 묶는다. set은 private성향으로 아무나 접근하지 못하도록 막는다.

        // Public constructor.

        public Contact(string contactName, string contactAddress) -> 생성자 그런데 public

        {

            Name = contactName;

            Address = contactAddress;

        }

    }

    // This class is immutable. After an object is created,

    // it cannot be modified from outside the class. It uses a

    // static method and private constructor to initialize its properties.   

    public class Contact2

    {

        // Read-only properties.

        public string Name { get; private set; } -> get은 선언을 하나로 묶는다. set은 private성향으로 아무나 접근하지 못하도록 막는다.

        public string Address { get; private set; } -> get은 선언을 하나로 묶는다. set은 private성향으로 아무나 접근하지 못하도록 막는다.

        // Private constructor.

        private Contact2(string contactName, string contactAddress) -> 생성자 그런데 private

        {

            Name = contactName;

            Address = contactAddress;

        }

        // Public factory method.

        public static Contact2 CreateContact(string name, string address)

        {

            return new Contact2(name, address); -> 내부적으로 생성자를 막고 마치 싱글톤처럼 새로운 녀석을 리턴해 주고 있다.

        }

    }

    public class Program

    {

        static void Main()

        {

            // Some simple data sources.

            string[] names = {"Terry Adams","Fadi Fakhouri", "Hanying Feng", 

                              "Cesar Garcia", "Debra Garcia"};

            string[] addresses = {"123 Main St.", "345 Cypress Ave.", "678 1st Ave",

                                  "12 108th St.", "89 E. 42nd St."};

            // Simple query to demonstrate object creation in select clause.

            // Create Contact objects by using a constructor.

            var query1 = from i in Enumerable.Range(0, 5)

                         select new Contact(names[i], addresses[i]); -> 새로운 클래스를 집어 넣는다.

            // List elements cannot be modified by client code.

            var list = query1.ToList();

            foreach (var contact in list)

            {

                Console.WriteLine("{0}, {1}", contact.Name, contact.Address);

            }

            // Create Contact2 objects by using a static factory method.

            var query2 = from i in Enumerable.Range(0, 5)

                         select Contact2.CreateContact(names[4 - i], addresses[4 - i]);

            Console.WriteLine();

            // Console output is identical to query1.

            var list2 = query2.ToList();

            foreach (var contact in list2)

            {

                Console.WriteLine("{0}, {1}", contact.Name, contact.Address); 

-> 값을 가져오는 것은 아무런 이상이 없다. 즉 get은 이상없이 작동한다. 애초에 public였으니 하지만

                contact.Name = 0; 이런 구문을 쓰면 당근 막힌다.

            }

            // List elements cannot be modified by client code.

            // CS0272:

            // list2[0].Name = "Eugene Zabokritski"; 

            // Keep the console open in debug mode.

            Console.WriteLine();

            Console.WriteLine("Press any key to exit.");

            Console.ReadKey();

        }

    }

}

컴포지트패턴 --------------------------------------------------------------------------------------------------

  클래스를 사용할때 우리는 대부분 다형성을 기반으로 클래스를 디자인한다.

  객체를 생성하고 관리하려면 먼저 그 객체의 자료형이 클래스가 정의되어야 하는데.

  어떤때는 여러개의 틀을 하나로 모아서 사용해야할 경우가 존재한다.

  즉 하나의 클래스에 상속을 받는 부분부분을 모아서 새로운 틀을 만들어야하는 경우가 존재한다.

  이 경우 이 객체를 복합객체(composite object) 혹은 복합 클래스(composite class)라고 한다.

패턴적용 스토리 -----------------------------------------------------------------------------------------------

  당신은 메카닉 액션 게임을 만들게 되었다. 메카닉 액션게임에서 공격에 사용되는 탄환을 디자인하게 되었다.

  그런데 전탄발사라고 하는 새로운 기능을 만들게 되었다.

  기존의 만들어진 탄환들을 모아서 발사한다.

  그래서 부분이면서 전체가 될 포함할 수 있는 컴포지트 패턴을 사용하기로 했다.

uml -----------------------------------------------------------------------------------------------

보면 알겠지만 전탄발사는 Arms를 포함하면서도 Arms에 속해있다.

또한 내부에서 stl List를 통해서 Arms를 다수 포함할수 있는 구조이다.

(굳이 이런 구조가 아니어도 된다. Arms를 2개 이상 가지고 있어도 충분하다.)

또한 프로토타입 패턴이 섞여있는데 각 객체는 프로토타입에 의해서 생성된다.

코드 -----------------------------------------------------------------------------------------------

브릿지패턴 --------------------------------------------------------------------------------------------------

객체란 선언과 구현으로 나뉜다.

선언이란 외부에 공개되는 인터페이스(함수나 맴버들)을 의미하며.

구현이란 인터페이스의 실제적인 동작을 정의해 놓고 있다.

하지만 하나의 구현파일안에 조건에 따른 다른 내용으로 분류되거나 하는 일이 있을수 있다.

하나의 클래스가 어떠한 일을 하는데 조건문에 따른 코드가 너무 길어져서 가독성이 떨어지고 처리해야할 코드가 길어진다면 어떻게 해야할까?

혹은 몇개의 함수만 다른 동작을 하고 나머지는 완전히 똑같은 동작을 하는 클래스가 여러개 있을때.

이들을 어떻게 하면 효율적으로 모으고 관리할 수 있을까?

그에 대한 새로운 방식을 지원해주는 것이 브릿지 패턴이라고 할 수 있다.

패턴적용 스토리 -----------------------------------------------------------------------------------------------

당신은 몬스터의 인공지능을 맡게 되었다. 

그런데 완전히 같은 몬스터라도 인공지능이 다르게 구현될 수 있다고 한다.

즉 같은 몬스터 A라도

소심한 몬스터A

대담한 몬스터A

비열한 몬스터A

같은 식으로 구현이 될 수 있다는 이야기 이다.

그럼 그것을 효율적으로 해결하기 위한 방법을 보자.

uml -----------------------------------------------------------------------------------------------

몬스터 클래스는 내부에 브릿지를 가지고 있다. 이 브릿지는 몬스터의 AI를 담당한다.

몬스터 AI를 담당하는 브릿지가 있기 때문에 몬스터 클래스 내부에서는 실제적인 AI의 동작을

몬스터끼리 달라져야할 부분만 구성하고 다른 부분은 몬스터 내부의 메소드에서 처리하면 된다.

즉 인터페이스의 구현을 연결된 브릿지에 맡김으로 해서 한 클래스에 코드과중이나 역할을 분산시킬 수 있다.

uml의 관계 표시화살표 --------------------------------------------------------------------------------------------------

아답터패턴 --------------------------------------------------------------------------------------------------

선생님은 말하셨다. 악마같은 패턴이하나 있는데 그중 하나가 아답터 패턴이라고.

아답터 패턴은 전혀 연관이 없는 녀석을 하나의 클래스로 만들어 새로운 클래스를 창조하거나.

두개의 연관없는 기능을 하나로 묶을 수 있다는 것이다.

즉 남의 코드를 마구 가져다 쓸때 매우 도움이 될 수도 있는 패턴이다.

아답터 클래스를 만드는 방식은 2가지가 있다.

일단 클래스 Target와 클래스 Adaptee라는 전혀 다른 기능을 가진 클래스가 있다고 치자.

(물론 하나의 애플리케이션 안에 있을 것 이므로 기본적인 목표는 동일할 수 있다.)

그런데 엮일줄 몰랐던 이 클래스들의 기능이 혼합된 새로운 기능을 만들라고 한다.

새로운 클래스를 만드는 것은 의외로 간단하다. 그냥 하나의 클래스를 만들고 두 클래스의 코드를 복사해서 붙여넣고 조정좀 해주면 되니까.

하지만 이런짓은 코드의 중복을 가져온다. 코드를 중복하지 않고 기능을 추가하거나 새로운 클래스를 만들어 낼 수는 없을까?

그걸 위한 아답터패턴이고 2가지 정도의 방법이 있다.

방법1. Adapter클래스 두개의 클래스를 상속받는다. 다중 상속이다. 하지만 상속을 통해서 adapter클래스는 두개의 클래스의 기능을 모두 사용할 수 있게 되었다. 

그러면서 다형성을 사용하여 어느 패턴의 형식으로도 관리될 수 있다.

방법2. Adapter클래스가 하나의 클래스를 상속받고 다른 클래스는 포함하게 된다. 내부에 포함된 adaptee의 함수를 사용할수 있지만 

오버라이드를 통해서 상위 클래스의 함수에 새로운 기능을 추가하는 일은 힘들다.

패턴적용 스토리 -----------------------------------------------------------------------------------------------

당신은 스킬을 만들라는 요청을 받았다.

그런데 여기서 웃기는 문제가 생겼다. 기존에는 공격스킬과 자신을 회복하는스킬을 나누어 놓자고 하고는 이제는 두개가 섞여있는 체력흡수라는 스킬을 만들어 내라고 한다.

즉 CATTSkill CSelfHEALSkill클래스의 스킬이 혼합된 스킬을 만들라고 하고 있다.

CMIXSkill클래스를 새롭게 만들기로 결정했다. 하지만.

코드의 중복은 피하면서 양쪽 모두의 효과를 동시에 사용할 수 있는 방법으로 아답터 패턴을 사용해보자.

uml -----------------------------------------------------------------------------------------------

양쪽을 모두 상속받는 CMixSkillOne과 한쪽은 상속받고 한쪽을 포함하는 CMixSkillTwo는 같은 동작을 하지만 포함과 상속이라는 약간의 차이가 있습니다.

하지만 양쪽의 인터페이스를 상속받으면서도 다른 모습을 보여줍니다.

한쪽은 인터페이스를 가상함수로 오버로딩 하고 있고.

한쪽은 새롭게 재정의 해서 사용하고 있습니다.

즉 응용하기에 따라 다양한 방법으로 혼합 합성이 가능함을 보여줍니다.

결과 -----------------------------------------------------------------------------------------------

dynamic-link library(DLL)은 응용프로그램이 실행중에 로드하고 호출할 수 있는 공유된 코드와 데이터로 정의할 수 있습니다. 전형적인 DLL은 응용프로그램을 위해 루틴들을 노출(=Export)시키며, 그 내부(즉, DLL)에서 사용할(internal use) 루틴도 역시 포함되어 있습니다. 이러한 기술은 여러 응용프로그램에서 공통 기능으로 공유할 수 있게 라이브러리 형태로 재사용 가능하게 하여 필요시 로드를 할 수 있도록 해줍니다. DLL 사용의 장점은 코드가 차지하는 공간(code footprint)을 줄이고, 단일 복사본을 공유함으로서 메모리 사용량을 낮추며, 개발과 테스트가 용이하게 하고 모듈화를 가능하게 합니다.

DLL을 만드는 일은 개발자에게 많은 도전을 가져다 줍니다. DLL은 시스템을 통한 강제적인 버전관리가 이뤄지지 않습니다. 즉, 여러개의 DLL이 한 시스템에 있을때, 이러한 버전관리 체크의 부족으로 인한 overwrite는 의존성과 API 충돌을 야기합니다. 개발 환경, 로더 구현 그리고 의존성의 복잡성은 로드 순서와 응용프로그램 행위에 취약성을 만듭니다. 그래도 많은 응용프로그램들은 복잡한 의존성을 가지는 DLL에 의지하고 있습니다. 이 문서는 DLL 개발자들을 위해 가이드라인을 제공하여 견고하고 이식성 있으며 확장성 있는 DLL로 만드는데 도움을 줄 것입니다.

■ 3개의 주요한 DLL 컴포넌트 개발 모델은 다음과 같습니다.

1. Library Loader
   DLL은 가끔 복잡한 내부의존성(interdependency)을 자니는데, 이는 그들이 로드되어야 하는 순서를 정의합니다. Library Loader는 효과적으로 이러한 의존성을 분석하고, 정확한 로드 순서를 계산한뒤 그 순서대로 로드를 합니다.
2. DLLMain entry-point function
   이 함수는 Loader에 의해 호출되며, 그 시점은 DLL의 Load 혹은 Unload일때 입니다. Loader는 한 시점에 단 하나의 DLLMain만 호출하도록 연속으로 호출합니다. 더 많은 정보
3. Loader Lock
   Loader가 순서대로 로드할때 사용되는 프로세스 단위의 동기화 객체입니다. 프로세스 단위의 Library Loader Data를 반드시 읽거나 써야 하는 함수는 반드시 이 Lock을 획득해야 합니다. 물론 이러한 operation을 수행하기 전에 이뤄져야 합니다. Loader Lock은 recursive이며, 이는 같은 쓰레드에서 다시 Lock의 획득이 가능함을 의미합니다.

그림 1. DLL 로드시 어떤일이 이뤄지는가?

DLLMain에서의 부적합한 동기화 시도는 응용프로그램에게 deadlock 혹은 초기화 되지 않은 DLL의 data와 code의 접근을 야기하게 됩니다. DLLMain에서의 특정 함수 호출은 이러한 문제를 잃으킵니다.

이상적인 DLLMain은 "그냥 비우는것" 입니다. 그러나, 많은 응용 프로그램의 복잡도를 고려할때 이는 너무한 제약이 됩니다. DLLMain을 다루는 좋은 방법은 많은 초기화 과정을 가능한 뒤로 미뤄라라는 것입니다. 이러한 미뤄진 초기화는 응용프로그램을 더욱더 견고히 해주는데, 그 이유는 Loader Lock가 획득된 동안의 초기화가 이뤄지지 않았기 때문입니다. 역시 이러한 방법은 Windows API의 사용에도 훨씬 많은 안정성을 제공합니다.

몇몇 초기화 작업은 뒤로 미룰순 없을 것입니다. 예를 들어, 설정 파일에 의존성이 있는 DLL이 있는데, 해당 파일이 좋지 않거나 쓰레기 내용이 포함되었을때 그 DLL의 Load가 실패되야 하는 경우가 있을 것입니다. 이런 종류의 초기화 방식은, 다른 작업의 자원 낭비를 하느니 DLL이 그 행위를 시도해보고 빨리 실패하는 것이 좋다고 개념이라 보여집니다.

■ 다음과 같은 작업을 절대로 DLLMain에서 수행해서는 안됩니다.

• LoadLibrary 혹은 LibraryEx의 직접적 혹은 간접적 호출. 이는 deadlock 혹은 crash를 유발한다.
• 다른 쓰레드와의 동기화 시도. 이는 deadlock을 유발한다.
• Loader Lock을 획득하기 위해 기다리는 코드가 획득한 다른 사설 동기화 객제를 획득하려고 하는 시도. 이는 deadlock을 유발한다.
• CoInitializeEx 사용에 의한 COM 쓰레드 초기화. 특정 상황이 되면 이 함수는 LoadLibrary를 호출한다.
• 레지스트리 함수군의 호출. 이 함수는 Advapi32.dll에 구현되어 있는데, 만약 AdvApi32.dll이 아직 당신 DLL에서 초기화되지 않았다면, 그 DLL은 메모리를 초기화해제 하며, crash를 유발한다.
• CreateProces 호출. 이는 다른 DLL을 Load할 수 있다.
• ExitThread 호출. DLL Detach 과정에서 Exit가 진행중인 Thread는 Loader Lock을 다시 획득하려고 하는 시도가 발생하여 deadlock 혹은 crash가 발생할 수 있다.
• CreateThread 호출. 다른 Thread와 동기화 작업을 하지 않는다면, 생성중인 Thread가 할 수 있는데, 이는 위험할 수 있다.
• Named Pipe 혹은 다른 Named Object의 생성(Windows 2000만 해당). Windows 200에서는 Named Object는 Terminal Service DLL에 의해 제공되는데, 만일, 이 DLL이 초기화되지 않았다면, DLL을 로드하게 되어 crash가 유발될 수 있다.
• 메모리 관리 CRT 함수 호출. 만약 CRT DLL이 초기화 되지 않았다면, crash가 유발된다.
• User32.dll 혹은 Gdi32.dll 함수 호출. 몇몇 함수들은 아직 초기화되지 않은 DLL을 로드한다.
• 관리 코드의 사용

■ DLLMain 내에서 안전한 작업은 다음과 같습니다.

• compile time의 static data의 초기화
• 동기화 객체의 생성과 초기화
• 메모리 할당과 dynamic data의 초기화 (위 금지 함수 이외)
• Thread local storage(TLS) 초기화
• File의 열기/읽기/쓰기
• kernel32.dll 함수의 호출 (위 금지 함수 제외)
• 전역 포인터 변수를 NULL로 할당

Lock 순서의 역(Lock order inversion)에 의한 deadlock

Lock과 같은 다중 동기화 객체 사용을 구현할 때, Lock 순서를 따르는 것은 굉장히 중요합니다. 어느 시점에서 한개 이상의 Lock을 획득하는 것이 필요할때 반드시 Lock hierachy 혹은 Lock 순서라 불리는 명시적인 순서를 정의해야 합니다. 예를 들어, Lock A가 Lock B이전에 획득되었고, Lock C 이전에 Lock B가 획득되었다면 Lock 순서는 A,B,C가 되고, 이 순서는 코드에서 지켜줘야 됩니다. 만약 Lock 순서가 역으로 되는경우가 발생했다면, 예를 들어, Lock A를 획득 하기 전에 Lock B가 획득되었을 경우, 이는 Lock 순서의 역에 의한 deadlock이 발생하게 됩니다. 이렇게 발생한 deadlock은 디버깅하기 힘든 면이 있습니다. 이것을 방지하기 위해 모든 쓰레드에서는 같은 순서대로 Lock을 획득해야만 합니다.

Loader는 이미 획득한 Loader Lock으로 DLLMain을 호출한다는 사실은 굉장히 중요합니다. 그래서 Loader Lock은 Locking hierachy의 가장 높은 우선순위가 되어야 합니다. 그와 마찬가지로 적합한 동기화를 위해 요구된 Lock을 획득하해야 하는 것도 알아야 합니다. 물론 hierachy에 정의된 모든 단일 Lock을 획득해야 할 필요는 없습니다. 예를 들어, A와 C를 적합한 동기화를 위해 획득하였다면, C를 획득하기 이전에 A를 획득해야 하며, B를 획득할 필요는 없습니다. 더 나아가 설명하자면, 프로그램 코드에서는 Loader Lock을 명시적으로 획득 할 수 없습니다. 만약 사적인 Lock을 획득한 상황에서 Loader Lock을 간접적으로 획득하려는 ::GetModuleFileName(...)과 같은 API를 호출해야 한다면, 사설 Lock을 획득하기 이전에 ::GetModuleFileName(...)을 획득해야만 합니다. 이는 Load 순서를 따르게 하기 위함입니다.

그림 2. Lock 순서의 역에 의한 deadlock

그림 2. 는 이러한 Lock 순서의 역을 보여주고 있습니다. DLLMain을 포함하는 Main 쓰레드를 가지는 DLL을 생각해 보십시요. Library Loader는 Lock L을 획득했으며, DLLMain을 호출하려고 합니다. Main 쓰레드에서는 동기화 객체인 A, B 그리고 공유 데이터를 접근하기 위해 필요한 G를 생성하고 G를 획득하기 위해 시도하려고 합니다. 그와 별도로, Worker 쓰레드에서는 이미 G를 획득한 상황이며 ::GetModuleHandle(...)를 호출하여 Loader Lock인 L을 획득하려고 시도할 것입니다. 그러면, Worker 쓰레드는 L에 의해 Block 되며, Main 쓰레드는 G에 의해 Block 되며, 이로 인해 deadlock이 발생하게 됩니다.

이러한 상황을 방지하기 위해서는, 모든 쓰레드에서는 항상 순서에 맞게 동기화 객체를 획득하도록 시도해야 합니다.

동기화를 위한 최고의 습관

---

초기화의 한 부분으로 DLL이 Worker 쓰레드를 생성해야 하는 경우를 생각해 보십시요. DLL이 Cleanup되면 data의 무결성(consistent)을 확신하기 위해 모든 Worker 쓰레드의 동기화가 필요하며, 그 다음 Worker 쓰레드는 종료하게 됩니다. 오늘날, 멀티쓰레드 환경의 DLL을 종료하고 동기화하는데에는 완벽하고 정확한 방법은 없습니다. 다음은 DLL 종료를 하는 동안 이루어질 쓰레드 동기화를 위해 현재까지 나와있는 최고의 습관을 설명하고 있습니다.

■ 프로세스 종료시 DLLMain에서의 쓰레드 동기화

• 프로세스 종료시 DLLMain이 호출되었다면 모든 프로세스의 쓰레드들은 Clean up이 이뤄지며 주소 공간(Address Space)는 더이상 유지되지 않습니다. 동기화는 이런 경우에는 필요하지 않습니다. 다시 말해 DLL_PROCESS_DETACH는 비워둬도 됩니다.
• Windows Vista에서는 핵심 data들(환경 변수, 현재 디렉토리, 프로세스 힙, ...)의 유지가 보장됩니다. 그러나 다른 동적 할당된 사설 data는 망가져서 더이상 안전하지 않습니다.
• 저장이 필요한 영구 유지될 상태들은 저장 매체에 플러쉬되어야 합니다.

■ DLL UnLoad시의 DLL_THREAD_DETACH를 위한 DLLMain의 쓰레드 동기화

• DLL이 UnLoad될때 주소 공간(Address Space)는 사라지는 것은 아닙니다. 따라서 DLL은 Clean될 예정인 상태입니다. 이것은 쓰레드 동기화, Open된 핸들, 영구 유지해야 하는 상태 그리고 할당된 자원들을 포함합니다.
• 쓰레드 동기화는 종잡을 수 없는데, DLLMain에서 쓰레드의 종료를 기다리는 것은 deadlock을 유발할 수 있기 때문입니다. 예를 들어, DLL A가 Loader Lock을 획득했습니다. 그리고 Thread T를 종료시키기 위해 Signal을 보냈고 종료를 기다리도록 합니다. 쓰레드 T는 종료가 되며, Loader는 DLL A의 DLL_THREAD_DETACH 호출을 위해 Loader Lock 획득을 시도할 것입니다. 이것이 deadlock을 유발시키게 됩니다. 이러한 리스크를 최소화 하는 방법은 다음과 같습니다.
• DLL A는 DLLMain에서 DLL_THREAD_DETACH 메시지를 받고, 쓰레드 T에게 종료해라는 Signal을 보냅니다.
• Thread T는 현재의 작업을 마치고 스스로 상태를 유지하며 DLL A에게 Signal을 보냅니다. 단, 이러한 유지된 상태 체크를 위해서 DLLMain의 deadlock 회피를 위한 제약을 지켜야 합니다.
• DLL A가 쓰레드 T를 종료 시켰으며, 그것이 아직 유지된 상태임을 알수 있습니다.

만약 DLL이 그것의 모든 쓰레드를 생성하고 나서 UnLoad되었고 실행이 시작되기 전이었다면, 그 쓰레드들은 crash가 발생할 수 있습니다. 만약 DLL이 초기화의 단계로 DLLMain에서 Thread를 생성하였다면, 몇몇 쓰레드들이 아직 초기화가 완료되지 못했고 그들의 DLL_THREAD_ATTACH 메시지가 여전히 DLL에게 전달되기를 기다리고 있을 것입니다. 이런 상황에서 DLL이 UnLoad된다면 쓰레드들의 Terminate가 시작될 것입니다. 그러나 몇몇 쓰레드들은 Loader Lock에 의해 block되어 있을 겁니다. 그들의 DLL_THREAD_ATTACH 메시지들은 DLL이 unmap된 이후 진행될 것이며, 이는 crash를 유발할 것입니다.

///////////// 두번째

오랜만에 블로그에 글을 쓰고 있습니다. 일종의 생존신고랄까요? 
VS2005 로 처음 작업할때도 이런 비슷한 문제로 필요없는 삽질을 꽤 했었습니다.  여기 ㅜ.ㅜ
요즘 VS2008 로 해야할 작업이 있어서 쪼물딱 거리는 와중에 이상한 현상이 있어서 삽질하고, 구글링한 결과를 정리해 볼까 합니다.
어떤 X 같은 일이 생겼나면.. 

개발머신   : VS2008, SP1 
테스트머신: 윈도우 XP SP3 

이렇게 PC 가 두대가 있습니다. 
당연히 VS2005 에서 작업하던 대로 Debug 빌드시에는 
Microsoft Visual Studio 9.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC90.DebugCRT
아래 있는 파일들을 실행파일과 함께 테스트 머신에 복사하고, 실행을 했습니다. (private assembly 형태의 배포죠)
그런데 실행이 안되는겁니다.

뭐 요딴 메세지만 나오는 군요. 
아래 그림에서처럼 DLL 이 뭔가 없는것도 아니고요. 아무 문제 없습니다. (VLdr.exe 는 VLdr.dll 을 사용합니다)

Manifest 파일과 배포해야 하는 DLL 들도 잘 복사되어있고요.

대체 뭐가 문제란 말입니까.. ㅠ.ㅠ

한참을 원인을 찾던 중.. (뭐 딱히 구글링할 키워드도 떠오르지 않더군요. -_-)
뭐 급한대로 VLdr.exe.config 파일을 만들어서 dll 들을 redirect 시켜서 대충 해결이 되긴 하더군요. 
하지만 dll 이 앞으로 한두개도 아니고.. 3rd party library 라도 사용하게 되면 대략 난감해 지겠죠. 
config 파일로 해결이 된다는것은 결국 바인딩 되는 dll 의 버전 문제 아니겠는가 라는 결론이 나오죠.

VS 링커 옵션에 보면 minifest 를 자동생성하도록 되어있습니다.(디폴트로)
역시 평소에 VS 각 옵션 설정을 꼼꼼히 보아두었던 것이 도움이 되는군요 ^^.
바인딩되는 dll 들은 링크타임에 manifest 형태로 만들어지는 것이고요. 생성된 manifest 는 exe 나 dll 에 내장되는것이겠죠. (아님 말구요)

결국 debug 디렉토리(중간 오브젝트 생성경로)에 생성된 ****.exe.embed.manifest 를 살펴보니 (****.exe.intermediate.manifest 는 뭐 중간에 잠깐 만들어지는 넘 같으니 패스) 아래와 같은 내용이 있네요.

그런데 C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC90.DebugCRT 에 있는 minifest 파일을 열어보면 (private assembly 로 배포하던 파일이죠)

이런 ...ㅅㅂ... 욕나옵니다. -_-;; 
결국 SP 1 이 설치되었는데도 VS 는 예전 버전(시스템 런타임 버전)으로 바인딩을 하고 있는겁니다. 
이러니 당연히 실행이 안될 수 밖에요 (이해가 안되시는 분들은 WinSxS 나 Strong named assembly 라는 키워드로 검색을.. ).

결국 이런 저런 삽질과 구글링을 통해 알아낸 결과
 - VS 2008 SP1 설치 미디어에 있는 VC_x86Runtime.exe 을 디버기에서 실행하거나
 - 아래 전처리기를 stdafx.h 같은 곳에 (가능하면 가장 위에) 정의해 주는 겁니다.
#define _BIND_TO_CURRENT_MFC_VERSION 1
#define _BIND_TO_CURRENT_CRT_VERSION 1
프로젝트 속성 -> C/C++ -> 명령줄에 추가하는 것이 더 좋은것 같습니다. 
/D "_BIND_TO_CURRENT_MFC_VERSION=1"
/D "_BIND_TO_CURRENT_CRT_VERSION=1"
MFC 프로젝트에서 stdafx.h 에 추가했더니 여전히 잘못된 manifest 를 만들어내는군요. -_-;;

이 전처리기를 이용하면 정상적으로 ***.exe.embed.manifest  에 버전이 SP 1 용 MFC, CRT 의 버전으로 만들어집니다.
이게 VS 2005 와 VS2008 에서 이렇게 요상하게 다르게 동작하는 원인은 고객들의 요구에 의한거라고 하는군요. -_-

출처:VC8 의 dll binding 문제

volatile 키워드는 간단히 '코드 최적화를 막아주는 키워드'라고 설명할 수 있습니다. 즉 컴파일러의 최적화와 관련된 키워드이고 CPU 내/외부 캐시와 같은 하드웨어 최적화와도 관계가 있습니다. 지금처럼 임베디드 기반 프로그래밍이 보편화 되지 않았던 시절에는 volatile 키워드의 활용 빈도가 매우 낮았으나, 최근 임베디드 시스템이나 멀티 스레드를 고려한 프로그램이 늘어 가면서 volatile 키워드의 사용이 많아 지고 있습니다.

volatile 키워드는 주로 memory-maped I/O에서 사용됩니다. 임베디드 시스템에서는 MCU의 각종 레지스터가 메모리에 매핑되어 있는 경우가 많고 프로그램은 매핑된 메모리 주소에 값을 반복적으로 쓰게 되는데 이때 volatile 키워드가 사용됩니다. 다음의 코드로 volatile 키워드가 어떻게 동작하는지 살펴봅시다.

unsigned int *uart = 0x40700000;
*uart = 0x00080001;
*uart = 0x00080002;
*uart = 0x00080003;
*uart = 0x00080004;
*uart = 0x00080005;

위 코드를 보면 다섯 번째 메모리 쓰기가 모두 0x4070000번지에 행해집니다. 일반적인 상황에서 위 코드를 수행하고 나면 0x40700000 번지에는 가장 마지막 값인 0x00080005만 남게 될 것입니다. 따라서 똑똑한 컴파일러는 위 코드를 아래 코드처럼 최적화합니다.

unsigned int *uart = 0x40700000;
*uart = 0x00080005;

어차피 변수에는 가장 마지막 값만 남으므로 이렇게 고치는 것입니다. 일반적인 프로르매에서라면 아무런 문제 없이 동작하고 속도도 빨라집니다. 하지만 이 코드가 MMIO(Memory-Maped I/O) 상황에서 사용된다면 이것은 분명히 잘모된 최적화입니다. 각각의 메모리 쓰기 작업이 하드웨어에 특정한 작업을 명령하기 때문에 저렇게 최적화를 해 버리면 하드웨어는 오작동을 하게 됩니다. 그러므로 컴파일러에 최적화를 하지 말라는 '지시'를 내려야 합니다. 이러한 지시는 내리는 키워드가 바로 volatile입니다.

volatile unsigned int *uart = 0x40700000;
*uart = 0x00080001;
*uart = 0x00080002;
*uart = 0x00080003;
*uart = 0x00080004;
*uart = 0x00080005;

위와 같이 uart변수를 volatile로 선언하면 컴파일러는 uart변수에 최적화를 하지 않고모든 읽기 쓰기 작업을 메모리에서 직접하게 됩니다. 위 코드의 쓰기 작업 뿐만 아니라 읽기 작업도 마찬가지 입니다.

unsigned int *uart = 0x40700000;
char ch;
int i;
for(i = 0;i < 5;i++)ch = *uart;

위와 같은 코드 역시 최적화를 하면 *uart의 값을 한번만 읽어서 캐시에 저장한 다음 이것을 반복해서 사용합니다. 하지만 아래 코드처럼 uart 변수가 volatile로 선언되면 루프안에서 uart변수를 요구할 때마다 매번 메모리에서 값을 가져오기 때문에 그때 그때 변경되는 값을 읽을 수 있습니다.

volatile unsigned int *uart = 0x40700000;
char ch;
int i;
for(i = 0;i < 5;i++)ch = *uart;

---------------

가끔 일하다보면 extern "C"를 왜 써야 되는지도 모르고
사용하는 신입 코더들을 볼 수 있다. 때론 귀찮게 물어보기도 하고...
나중에 또 물어보면 이 페이지의 주소만 날려주리라. ㅋ

컴파일러는 link 작업시 오브젝트간 함수 이용 및 위치를 파악할 수 있도록,
컴파일시 사용된 함수에 관련된 정보를 오브젝트 파일에 기록하며, 이를 linkage라고 한다.

C++ 컴파일러는 컴파일 과정에서 Name mangling 이란 작업을 한다.
이는 정의되어 있는 함수명을 정해진 규칙에 의해 바꿔버리는 것이다.
(링크 에러날 때 본 적 있는가? 함수명 앞뒤에 붙은 이상한 기호와 숫자들을?)
(그리고 C++ 컴파일러가 왜 바꾸냐고? 그거 설명하려면 두꺼운 책 가져와야 된다... ㅈㅈ
굳이 목적 중에 하나를 설명하자면 override된 함수들의 구별을 위해... 이 정도)

참고로, C는 함수명 앞에 _ (underbar) 하나를 붙인다.

중요한 사실은 "코딩시 함수명과 컴파일 완료된 바이너리 코드에서의 함수명은 다르다" 라는 것이다.
이름을 바꾸는 규칙은 컴파일러에 따라 다르기 때문에 C++ 컴파일러가 다르면 호환이 되지 않는다.
즉, linkage type이 달라져 함수를 찾을 수 없게 되는 것이다.

이는 C++ 컴파일러 간에도 발생하는 문제이며 C와 C++ 컴파일러간에도 발생한다.
(당연하지 않은가, 컴파일러가 다르다니까 ㅋ)

공용의 라이브러리를 제작하였고 이 라이브러리를 사용하는 코더의 계층이 다양하다고 가정해보자.
C 환경에서도 사용을 할 것이고, 다른 C++ 환경에서도 사용할 것이다.
라이브러리 개발&배포자 입장으로써 링크 에러로 아우성치는 유저들 당황스럽다.

이를 피하기 위해 C++ 문법에서는 네임 맹글링을 막기 위해 아래 문장이 제공된다.
즉, C의 네임 형식으로 함수를 컴파일하는 것이다.

extern "C"

따라서 범용적인 라이브러리 헤더라면 아래와 같이 작성되는 것이 좋을 것이다.

// 상략
#ifdef __cplusplus
extern "C" {
#endif

// 중략
#ifdef __cplusplus
}
#endif
// 하략

자 이제 함수를 C 형식으로 컴파일 했다.
그러면 어떻게 되겠는가? name mangling 회피로 인한 link 문제는 해결이 되었다.

하지만 C 형식이므로 class의 멤버 변수가 될 수도, override가 될 수도 없다.
즉, C++ 고유 특성을 모두 잃어버리게 된다.

1. DLL의 주요 장점

2. DLL과 프로세스 주소 공간

DLL 파일의 이미지는 실행 파일이나 다른 DLL이 DLL 내 포함되어 있는 함수를 호출하기 전에

반드시 프로세스의 주소 공간에 매핑되어 있어야 한다.

이를 위해 다음 두 가지 방법 중 하나를 선택할 수 있다.

• 암시적 로드타임 링킹
• 명시적 런타임 링킹

위 방법들에 대해선 아래 챕터에서 각각 자세히 설명하도록 하겠다.

DLL 파일 이미지가 프로세스의 주소 공간에 매핑되고 나면,

DLL이 가지고 있는 모든 함수들은 프로세스 내의 모든 쓰레드에 의해 호출될 수 있게 된다.

사실 이렇게 로드가 완료되고 나면, DLL 고유의 특성은 거의 없어진다고 볼 수 있다.

프로세스 내의 쓰레드 관점에서는 DLL이 가지고 있는 코드와 데이터들은

단순히 프로세스의 주소 공간에 로드된 추가적인 코드와 데이터들로 여겨질 뿐이다.

쓰레드가 DLL에 포함되어 있는 함수를 호출하게 되면, 

호출된 DLL 함수는 호출한 쓰레드의 스택으로부터 전달된 인자 값을 얻어내고,

호출한 쓰레드의 스택을 이용하여 지역변수를 할당하게 된다.

뿐만 아니라 DLL 함수 내부에서 생성하는 모든 오브젝트들도 

DLL 함수를 호출하는 쓰레드나 프로세스가 소유하게 되며, DLL 자체가 소유하는 오브젝트는 존재하지 않는다.

예를 들어, DLL 내의 특정 함수가 VirtualAlloc 함수를 호출하게 되면,

해당 함수를 호출한 쓰레드가 속해 있는 프로세스의 주소 공간 내에 영역이 예약된다.

만일 DLL이 프로세스의 주소 공간으로부터 내려간다 하더라도

앞서 프로세스의 주소 공간에 예약했던 영역은 그대로 남게 되는데,

이는 시스템이 해당 영역이 DLL로부터 예약되었다는 사실을 특별히 관리하지 않기 때문이다.

하지만, 단일의 주소 공간은 하나의 실행 모듈과 다수의 DLL 모듈로 구성되어 있음을 반드시 알아두어야 한다.

이 중 일부 모듈은 C/C++ 런타임 라이브러리를 정적으로 링크하고 있을 수도 있으며,

또 다른 모듈은 C/C++ 런타임 라이브러리를 동적으로 링크하고 있을 수도 있다.

따라서, 단일의 주소 공간 내에 C/C++ 런타임 라이브러리가 여러 번 로드될 수 있다는 사실을 잊어버리면 곤란한다.

아래 예제를 살펴보자.

1. -- 실행 파일의 함수 --
2. void EXEFunc()
3. {
4.     void* pv = DLLFunc();
5.  
6.     // pv가 가리키는 저장소를 사용한다.
7.  
8.     // pv가 EXE의 C/C++ 런타임 힙 내에 있을 것이라고 가정한다.
9.     free(pv);
10. }
11.  
12. -- DLL의 함수 --
13. void* DLLFunc()
14. {
15.     // DLL의 C/C++ 런타임 힙으로부터 메모리를 할당받는다.
16.     return (malloc(100));
17. }

이 코드가 정상적으로 동작할 것인가?

DLL 함수 내에서 할당받은 메모리 블럭을 EXE 함수 내에서 정상적으로 해제할 수 있는가?

위 예제는 제대로 동작할수도 있고, 그렇지 않을 수도 있다.

만일 EXE와 DLL이 모두 DLL로 구성된 C/C++ 런타임 라이브러리를 사용하고 있다면, 위 예제는 정상 동작한다.

하지만, 둘 중 하나라도 C/C++ 런타임 라이브러리를 정적으로 링크하고 있다면, free 호출 과정에서 문제가 발생할 것이다.

이러한 문제는 애초에 습관을 제대로 들이면 된다.

DLL 내 메모리를 할당하는 함수가 있다면, 해제하는 함수도 DLL에 만들고 그걸 사용하는 것이다.

1. -- 실행 파일의 함수 --
2. void EXEFunc()
3. {
4.     // DLL 함수에서 할당한 메모리 블럭의 주소를 얻어온다.
5.     void* pv = DLLAllocFunc();
6.  
7.     // pv가 가리키는 메모리 블럭을 사용한다.
8.  
9.     // DLL 함수를 이용해 pv를 메모리로 반환한다.
10.     DLLFreeFunc(pv);
11. }
12.  
13. -- DLL의 할당 함수 --
14. void* DLLAllocFunc()
15. {
16.     // DLL의 C/C++ 런타임 힙으로부터 메모리를 할당받는다.
17.     return (malloc(100));
18. }
19.  
20. -- DLL의 해제 함수 --
21. void DLLFreeFunc(void* p)
22. {
23.     // DLL의 C/C++ 런타임 힙에서 메모리를 해제한다.
24.     free(p);
25. }

그리고, 실행 파일 내에 전역으로 선언된 정적 변수는 동일한 실행 파일이

여러 번 실행될 경우라도 Copy-on-write 메커니즘에 의해 공유되지 않는다.

DLL 파일 내에 전역으로 선언된 정적 변수 역시 이와 동일한 메커니즘이 적용된다.

프로세스가 DLL 이미지 파일을 자신의 주소 공간 내에 매핑하는 경우

실행 파일의 경우와 동일하게 전역으로 선언된 정적변수의 새로운 인스턴스가 생성된다.

이를 공유하게 하는 방법에 대해선 PE/COFF의 Section 문서의 챕터 4. 공유 섹션을 보기 바란다.

3. DLL과 실행 파일 작성법

이제, DLL을 생성하는 방법과 실행 파일이 어떻게 DLL 파일의 함수나 변수를 사용해야 하는지에 대해 알아보자.

1. DLL 모듈 생성

DLL은 변수, 함수, C++ 클래스를 다른 모듈에 export 할 수 있다.

하지만, 코드의 계층적 추상화를 유지하고 DLL 코드를 좀 더 쉽게 유지/관리하기 위해 

변수는 가급적 익스포트 하지 않는 것이 좋다.

또한, C++ 클래스는 export 한 C++ 클래스를 사용하는 모듈을 

동일한 회사의 컴파일러를 사용하는 컴파일한 경우에만 사용할 수 있으므로 주의하도록 하자.

DLL을 작성할 때 export 하고자 하는 변수나 함수를 포함하고 있는 헤더 파일을 먼저 작성하는 것이 좋다.

이러한 헤더 파일에는 export 할 함수나 변수가 사용하는 심벌이나 데이터 구조체도 반드시 정의되어 있어야 한다.

이 헤더는 DLL과 함께 배포되어야 하며, 이 DLL을 사용하는 모듈은 이 헤더를 반드시 인클루드 해야 한다.

또한, 유지보수의 편의성을 위해 DLL 하나당 헤더 파일 1개씩 페어로 작성하는 것이 좋다.

이제 간단한 DLL 헤더의 예제를 살펴보도록 하자.

(아래 예제는 vs2010에서 DLLTest라는 DLL 프로젝트를 생성하면 기본적으로 생성시켜주는 헤더 파일이다)

1. 
   
2. #ifdef DLLTEST_EXPORTS
3. #define DLLTEST_API __declspec(dllexport)
4. #else
5. #define DLLTEST_API __declspec(dllimport)
6. #endif
    
7. // 이 변수는 DLLTest.dll에서 내보낸 것입니다.
8. extern DLLTEST_API int nDLLTest;
9.  
10. // 이 함수는 DLLTest.dll에서 내보낸 것입니다.
11. DLLTEST_API int fnDLLTest(void);

DLLTest 프로젝트의 전처리기에는 DLLTEST_API 가 선언되어 있다.

즉, 함수나 변수, 클래스 앞에 __declspec(dllexport) 선언 지정자가 붙는 것이다.

그리고 아래 예제는 역시 DLLTest 프로젝트가 기본 생성해준 cpp 파일이다.

1. // DLLTest.cpp : DLL 응용 프로그램을 위해 내보낸 함수를 정의합니다.
2. //
3. #include "stdafx.h"
4. #include "DLLTest.h"
5.  
6. // 내보낸 변수의 예제입니다.
7. DLLTEST_API int nDLLTest=0;
8.  
9. // 내보낸 함수의 예제입니다.
10. DLLTEST_API int fnDLLTest(void)
11. {
12.     return 42;
13. }

위 cpp 예제에서 nDLLTest 변수와 fnDLLTest 함수 앞에 DLLTEST_API 매크로가 붙어 있지만,

cpp에서는 DLLTEST_API를 붙이지 않아도 무방하다.

자, 이제 위와 같이 기본 생성된 DLL 프로젝트를 빌드하고, DLL을 생성해 보자.

Output 폴더에 가보면, 다음 두 개의 파일이 생성되어 있다.

• DLLTest.lib
• DLLTest.dll

DLL 파일을 컴파일하면, 컴파일이 끝난 후 링커는 DLL의 소스코드가 

적어도 하나 이상의 함수/변수를 export 하고 있는지를 확인하고, 그 경우 .lib 파일을 생성한다.

.lib 파일은 어떠한 함수나 변수도 포함하고 있지 않기 때문에 그 크기가 매우 작으며,

단순히 DLL 파일이 export 하고 있는 함수나 변수의 심벌 이름만을 유지하고 있다.

이 파일은 DLL 파일이 export 하는 심볼을 참조하는 실행 모듈을 링크하는 과정에서 반드시 필요하다.

(이 내용은 DLL을 암시적 로드타임 링크할 때만 유효하다)

.lib 파일을 생성하는 것 외에도 링커는 DLL 파일 내에 해당 파일이 

export 하고 있는 심볼에 대한 정보를 테이블 형태로 포함시켜 준다.

export section이라고 불리는 이 테이블은 export 하고 있는 

변수, 함수, 클래스 심볼에 대한 목록을 (알파벳순으로) 가지고 있다.

링커는 이 외에도 상대 가상 주소(RVA:Relative Virtual Address)를 DLL 파일 내에 포함시키는데,

이 값은 각각의 심볼들이 DLL 모듈 내의 어느 위치에 있는지를 가리키는 값이다.

그럼 이제 DLLTest에서 export 하고자 한 변수와 함수가 제대로 export 되어 있는지를 dumpbin으로 확인해 보자.

꾸엑~ 

함수명 fnDLLTest은 ?fnDLLTest@@YAHZX로 

변수명 nDLLTest은 ?nDLLTest@@3HA로 naming 되어 있다.

이것은 C++ 컴파일러가 C++ 특성(override나 등등의)을 위해 컴파일시 함수나 변수명에 name mangling을 하기 때문이다.

물론 DLL도 C++로 작성하고, 사용 모듈 역시 C++로 작성된다면 실행에 아무런 방해가 되지 않는다.

하지만, DLL은 C++로 작성하고, 사용 모듈이 C로 작성될 수도 있는 상황이라면,

C로 작성한 사용 모듈에서 DLL 함수를 호출하면 링크 과정에서 존재하지 않는 심볼 참조 에러가 발생하게 된다.

이를 해결하기 위해선, extern "C" 를 사용하는 방법이 있다.

즉, 위 헤더를 다음과 같이 변경하는 것이다.

1. #ifdef DLLTEST_EXPORTS
2. #define DLLTEST_API extern "C" __declspec(dllexport)
3. #else
4. #define DLLTEST_API extern "C" __declspec(dllimport)
5. #endif
6.  
7. // 이 변수는 DLLTest.dll에서 내보낸 것입니다.
8. DLLTEST_API int nDLLTest;
9.  
10. // 이 함수는 DLLTest.dll에서 내보낸 것입니다.
11. DLLTEST_API int fnDLLTest(void);

하지만, extern "C" 는 C++ 클래스 사용시엔 문제가 발생하므로, 클래스는 조심해서 한정자를 사용해야 한다.

자세한 내용은 http://sweeper.egloos.com/1792976 참고

자 이제, 다시 한번 DLL 프로젝트를 빌드하고, dumpbin으로 확인해 보자.

오~ 깨끗하게 나온다.

헌데, 이 상태에서 fnDLLTest 함수의 calling convention을 __stdcall로 바꾸고 싶어졌다.

문제는 M$ C 컴파일러가 __stdcall 함수에 대해선 C++를 사용하지 않다 하더라도,

함수의 이름을 멋대로 바꾸는 작업을 수행한다는 것이다.

함수의 이름 앞에 _ (underbar)를 붙이고, 함수의 이름 뒤엔 매개변수 크기의 총합을 @와 함께 표시한다.

위 예제의 fnDLLTest 함수를 __stdcall로 호출하면, dumpbin 결과가 아래와 같이 나온다.

역시 fnDLLTest 함수명이 바뀌었기에, 

DLL을 사용하는 모듈이 타사의 컴파일러를 사용하는 경우 링크 에러를 발생시키게 된다.

다른 회사의 컴파일러에서 사용될 DLL 파일을 M$ 컴파일러를 사용해 컴파일하려 하면,

컴파일러에게 이름 변환을 수행하지 않도록 확실한 명령을 주어야만 한다.

두 가지 방법이 있으나, 두 번째 방법은 별로이므로, 한가지만 소개하겠다.

바로 .def 파일을 프로젝트에 추가하고 EXPORTS 섹션을 구성하는 것이다.

.def 파일은 DLL의 ouput name과 동일하게 맞추어야 한다.

1. LIBRARY DLLTest
2.  
3. EXPORTS
4.         fnDLLTest
5.         nDLLTest

M$ 링커는 .def 파일을 분석하는 과정에서 fnDLLTest와 _fnDLLTest@0 이라는 두 개의 함수가 export 되었음을 인지하게 된다.

그러나 이 두 함수의 이름이 서로 일치하기 때문에 (이름 변환 과정을 배제할 경우)

.def 파일에 정의되어 있는 fnDLLTest 라는 함수만 export 하고, _fnDLLTest@0 는 export 하지 않는다.

사실 .def 방식이 가장 확실하다.

.def 파일을 사용하면, 

• extern "C"를 붙이든 그렇지 않든,
• 함수의 calling convention으로 __stdcall을 사용하든

naming에 있어 아무런 문제가 되지 않는다.

만약, 자신이 만든 DLL이 널리 배포될 용도로 제작되어야 한다면,

조금 귀찮더라도 .def 파일을 프로젝트에 추가하고, EXPORTS 섹션을 구성함을 가장 추천한다.

물론, M$ 컴파일러로 DLL을 만들고, 사용 모듈 역시 M$ 컴파일러로 만들고, 둘의 환경 모두 C++이라면

아무 것도 하지 않아도 문제가 되진 않는다.

2. 실행 모듈 생성

우선, 아래 내용은 DLL을 Implicit Loadtime Link 할 경우에 초점이 맞추어져 있다.

실행 파일의 소스 코드를 개발할 때에는 반드시 DLL과 함께 제공되는 헤더 파일을 인클루드해 주어야 한다.

실행 파일의 소스 코드에서는 DLL 헤더 파일을 인클루드할 때, DLLTEST_EXPORTS 를 정의해선 안 된다.

정의하지 않은 채 코드를 컴파일하게 되면,

DLLTest.h 파일 내에서 DLLTEST_EXPORTS를 __declspec(dllimport)로 정의하게 된다.

1. // DLL 헤더 인클루드
2. #include "DLLTest.h"
3.  
4. // 테스트를 위한 암시적 로드타임 링킹
5. #pragma comment(lib, "DLLTest.lib")
6.  
7. int _tmain(int argc, _TCHAR* argv[])
8. {
9.         // DLL의 변수에 값 설정
10.         nDLLTest = 1;
11.  
12.         // DLL의 함수 호출
13.         int num = fnDLLTest();
14.  
15.         return 0;
16. }

컴파일러가 변수, 함수, C++ 클래스에 대해 __declspec(dllimport) 한정자를 발견하게 되면, 

이러한 심볼들이 다른 DLL 모듈에서 임포트된 것임을 알게 된다.

다음 단계로 링커는 실행 파일의 소스 코드에서 사용되고 있는 심볼들이 어떤 DLL로부터 export 된 것인지를 확인해야 한다.

이를 위해 링커에게 .lib 파일을 전달해 주어야 한다.

앞서 말한 것과 같이 .lib 파일은 단순히 DLL 모듈이 export 하고 있는 심볼들에 대한 목록만을 가지고 있다.

링커는 import 된 심볼을 찾는 과정에서 import section이라는 특수한 섹션을 실행 파일 내에 추가한다.

이 import section은 실행 파일이 필요로 하는 DLL 모듈과 해당 DLL 모듈에서 참조되는 심볼에 대한 목록이 포함되어 있다.

이제 실행 파일을 생성하고, dumpbin으로 내용을 확인해 보자.

DLLTester.exe의 import 섹션에서 DLLTest.dll의 fnDLLTest 함수와 nDLLTest 변수의 심볼을 확인할 수 있다.

이제 실행 파일을 실행해 보자.

실행 파일이 실행되면...

1. 운영체제의 로더는 프로세스를 위한 가상 주소 공간을 생성한다.
2. 이후, 로더는 실행 모듈을 프로세스의 주소 공간에 매핑한다.
3. 로더는 실행 파일의 import section을 확인하여 필요한 DLL 파일들을 찾아서 프로세스의 주소 공간에 추가 매핑한다.

Import section 내에 포함된 DLL 이름은 전체 경로명을 포함하고 있지 않기 때문에,

로더는 사용자의 디스크 드라이브로부터 DLL을 검색해야 한다.

아래에 로더의 검색 순서를 나타내었다.

1. 실행 파일 이미지가 있는 디렉토리
2. GetSystemDirectory 함수의 반환 값인 윈도우 시스템 디렉토리 (Windows\System32)
3. 16비트 시스템 디렉토리 (Windows\System)
4. GetWindowsDirectory 함수의 반환 값인 윈도우 디렉토리 (Windows\)
5. 프로세스의 현재 디렉토리
6. PATH 환경 변수에 포함된 디렉토리

DLL 모듈이 프로세스의 주소 공간에 매핑되면, 로더는 각 DLL 파일의 import section을 조사한다.

(DLL 역시 다른 DLL을 링크할 수 있기 때문에...)

만일 import section이 존재한다면, 로더는 계속해서 프로세스의 주소 공간에 

추가적으로 필요한 DLL 파일들을 매핑시켜 나단다.

로더는 DLL 모듈을 지속적으로 추적하여, 설사 여라 차례 참조되는 모듈이라 하더라도,

단 한번만 로드되고 매핑될 수 있도록 한다.

모든 DLL 모듈들이 프로세스의 주소 공간에 로드되고 매핑되면,

로더는 import 된 심볼의 모든 참조 정보를 수정해 나간다.

이를 위해 각 모듈의 import section을 다시 한번 살펴보게 된다.

로더는 각각의 심볼에 대해 관련 DLL의 export section을 검토하고 심볼이 실제로 존재하는지 확인한다.

로더는 심볼의 RVA 정보를 가져와서 DLL 모듈이 로드되어 있는 가상 주소 공간에 그 값을 더한다.

이후, 실행 모듈의 import section 내에 계산된 가상 주소 값을 기록한다.

이제 코드에서 import 된 심볼을 참조하게 되면 호출 모듈의 import section으로부터

import 된 심볼의 위치 정보를 가져와서 import 된 변수, 함수, C++ 클래스의 멤버 함수에 성공적으로 접근할 수 있게 된다.

애플리케이션이 새로 실행될 때마다 위와 같은 과정을 거쳐야 하므로, 초기 구동에 많은 비용을 소비하게 된다.

애플리케이션의 로딩 속도를 향상시키기 위해 실행 파일과 DLL 모듈에 대해

시작 위치 변경(rebase)과 바인딩(binding) 작업을 수행하는 것이 좋다.

Rebase와 binding에 대해서는 추후 별도로 글을 하나 더 쓰는 것이 좋을 듯 하다.

4. Implicit Loadtime Link

암시적 로드타임 링크는 static libaray를 링크하는 방법과 완전히 동일한 방법으로 수행할 수 있다.

또한, static library를 링크하는 것처럼 DLL의 export된 모든 변수와 함수, C++ 클래스가 

프로세스의 주소 공간에 매핑된다.

암시적 로드타임 링크시 어떻게 프로세스 주소 공간에 매핑되고,

프로세스에서 DLL 내 심볼에 접근하는지에 대한 과정은 위 3-2. 실행 모듈 작성 챕터에 자세히 설명되어 있다.

암시적 로드타임 링크는 역시 편안함에 기인한다.

프로세스의 주 쓰레드가 돌기 시작한 이후

별도로 DLL을 로드/해제할 필요가 없고, 심볼 역시 별도의 시작 주소를 얻어오는 과정 없이 바로 사용할 수 있기 때문이다.

Static library와 링크하는 방법이 똑같지만, 이왕 정리하는 김에 

암시적 로드타임 링크를 하는 두 가지 방법에 대해 다시 한번 소개하겠다.

1. 프로젝트 속성의 링커-입력에 .lib 추가

프로젝트 속성 - 링커 - 입력에 DLL의 .lib 파일을 추가하는 것이다.

2. comment 지시어 사용

위 3-2 예제에 나왔듯이 comment 지시어를 사용하여, 암시적 로드타임 링크를 시킬 수 있다.

1. // 암시적 로드타임 링킹
2. #pragma comment(lib, "DLLTest.lib")

개인적으로는 2번 방법을 선호하는 편이다.

위에서도 썼듯이, 프로젝트 속성에서 제어하는 방법은

공동 작업자가 꼼꼼히 속성을 살피지 않으면 지나치기 일수라,

코드에서 명백하게 링크하는 것이 경험상 훨씬 더 직관적인 것 같다.

5. Explicit Runtime Link