Unavailable

의존성 검사 프로그램인 Dependency Walker는 다음과 같은 타입의 의존성을 검사할 수 있다.

1. Implicit Dependency (다른 말로는 load-time dependency): 굳이 직역하자면 '암묵적 의존'이라고 할 수 있겠다. 모듈 A가 컴파일 혹은 링크시에 모듈 B를 사용하기 위해 하나의 라이브러리 파일 (LIB)을 암묵적으로 내포했다면 모듈 A의 소스코드는 실질적으로 모듈 B의 함수들을 불러다 사용하는 것이다. 고로 모듈 B는 모듈 A의 '로드 타임 디펜던시'이다. 한국어로 설명하자면 모듈 B는 모듈 A를 실행하는 시점에 반드시 로딩 되어야 하는 필수적인 놈이다라는 말... 고로 모듈 B에 있는 함수를 실행중 (Run-time)에 사용하고 말건 간에 모듈 A는 반드시 모듈 B를 로딩해야 한다. 모듈 B는 모듈 A의 import table에 포함된다. 

2. Delay-load Dependency: '지연 로딩 의존'. 이 녀석은 1번과 거의 동일한데 한 가지 중요한 차이점이 있다면 모듈 A가 진짜로 모듈 B의 함수를 호출하면 그제서야 모듈 B를 로딩한다는 점! 고로 이름이 'Delay-load' (늦게 로딩)이다. 이 경우에는 모듈 A의 'Delay-load import table'에 모듈 B가 포함된다. 

3. Forward Dependency: '전진형 의존' (가수 전진 아님) ㅋㅋ 한국어로 바꾸자니 참 어이없네. 이 녀석의 경우 모듈 A가 모듈 B를 컴파일 혹은 링크시에 LIB 파일로 연결하고 모듈 A의 소스코드가 모듈 B의 함수를 호출하는 경우를 말하는데, (여기까지는 1과 2와 같다) 모듈 B의 함수가 실질적으로는 또 다른 모듈인 모듈 C의 함수를 연결해서 호출하는 경우를 말한다. 모듈 B와 모듈 C 둘 다 실질적으로 모듈 A의 필요한 라이브러리들이지만 모듈 B만 모듈 A의 import table에 이름을 올린다.

4. Explicit Dependency (혹은 다른 말로 다이나믹 의존 or 런타임 의존): '명시적 의존' 모듈 A가 모듈 B와 컴파일 혹은 링크 타임에 연결되지 않았으나 런타임에 모듈 A가 동적으로 모듈 B를 LoadLibrary() 같은 함수를 통해 소스코드 내부에서 임의로 호출하여 연결하는 경우를 말한다. 자, 이런 경우에는 모듈 B는 모듈 A의 'Run time dependency'이다. 즉, 모듈 B는 모듈 A를 실질적으로 실행하는 시점에 요구되는 것이라는 말. 하지만 모듈 A의 import table에는 모듈 B가 당연히 없다. 왜냐면 소스 코드 내부에서 임의로 사용자 맘대로 호출하니까. 이런 타입의 대표적인 것들이 OCXs, COM object 그리고 Visual Basic 어플리케이션들이다. 

5. System Hook Dependency (다른 말로 '주입된 의존'): 이 타입의 의존성은 다른 어플리케이션이 특정 이벤트를 프로세스 내에서 '후킹'할때 발생한다. 그 프로세스가 해당 이벤트를 발생시킬 때, 운영체제는 해당 이벤트를 처리하기 위해 해당 프로세스로 모듈을 'Inject' 즉, '주입'하게 된다. 이렇게 주입된 모듈을 다른 어떤 모듈에 의존적이진 않지만 주입된 프로세스의 주소 공간에 머무른다. 

1,2 그리고 3번의 경우는 쉽게 찾아낼 수 있다. 왜냐면 import table에 자신들의 이름을 당당히 밝히기 때문이다. 4번과 5번은 찾아내기 쉽지 않은데 Dependency Walker 2.0이후 버전의 Runtime Profiling을 이용하면 검색 가능하단다. 

http://www.dependencywalker.com/help/html/dependency_types.htm

http://msdn.microsoft.com/en-us/library/dd293574(v=vs.100).aspx

Visual C++ 2010에서 작성한 C++ 프로그램을 다른 컴퓨터에서 실행하기 위해서는 작성한 어플리케이션, 그리고 어플리케이션을 돌리기 위해 필요한 라이브러리 파일을 같이 제공해야만 한다. 요렇게 하기 위한 방법이 세가지 있다.

1. Central Deployment 

중앙 배포 방식이다. 컴퓨터의 운영체제가 설치된 하드 디스크의 Windows 폴더 안에 보면 System32 폴더가 있다. 요 폴더에 들어가면 각종 DLL들이 무수히 많은데 바로 여기가 윈도우즈 운영체제가 사용하는 '중앙 통제 센터'이다. 여기다가 어플리케이션을 돌리는데 필요한 DLL들을 복사해 넣으면 내가 만든 어플리케이션이 문제 없이 작동한다. 바로 이때 사용되는 것이 VCRedist_archtecture.exe 파일인데 인터넷에서 Visual C++ 2010 Redistribution Package 라고 치면 좌롸롸롹 뜨는 것들이다. 단순히 exe 파일이므로 그냥 다운 받아서 더블 클릭하면 알아서 설치한다. 

이 방식의 장점은 중앙의 통제된 한 곳에 모든 것을 다 집어 넣기 때문에 업데이트나 갱신이 용이하다는 점이다. 보안 취약점이 발견되었을때 단순히 DLL 파일 하나를 업데이트 함으로써 그 DLL을 사용하는 모든 프로그램의 보안 취약점을 한 방에 해결할 수 있다.

2. Local Deployment

지역 배포 방식이다. 어플리케이션이 존재하는 폴더 내부에 필요한 파일들을 복사해서 넣는 방법이다. 

이 방식은 쉽고 간단하지만 문제점으로는 업데이트가 자동으로 안되므로 유지 보수를 위해서는 DLL을 업데이트 하는 방법을 제공해야 한다는 점...

3. Static Linking

이건 정적 링크 방식이다. 어플리케이션 자체에 라이브러리를 심어버리는 방식이다. 장점은 당연히 DLL 문제에서 완전 해방 된다는 점이다. 다만 문제점은 마이크로소프트 업데이트가 만약 내가 링크한 라이브러리를 업데이트 해버리면 어플리케이션이 업데이트된 라이브러리를 사용할 수 없다는 점이다. 결론적으로 보안 취약성이 문제이군.

참, 그리고 재미있는 부분이 있는데, Visual C++ 2008과 2010의 가장 큰 차이점을 설명하고 있는데, 재미있는군.

우선, Visual C++ 라이브러리는 더이상 manifest에 의존하지 않는다. 그리고 더이상 WinSxS 폴더에 설치되지 않는다. 헐, 그래? 그러고 보니 2010으로 컴파일한 실행 파일 폴더에 manifest 가 없네? 

또한 작성된 응용 프로그램이 더이상 manifest 정보를 요구하지 않는단다. 흠, 그렇다면 필요한 라이브러리의 정보가 어디에 포함되는 걸까? 명세서 (manifest) 파일이 존재 하지 않는다면 아마도 실행파일 내부에 어딘가 설명되는가 본데?

앞서 커널 오브젝트에 대해서 알아보았는데 이중에 가장 사용하기 쉬운 녀석이 이벤트 오브젝트이다. 

우선 이벤트 오브젝트를 설명하기 앞서 대기 함수에 대해서 설명하자. 대기 함수라 함은 인자로 전달한 커널 오브젝트가 시그널 상태 (파란불)가 될 때까지 (혹은 타임 아웃 제한 시간동안) 이 함수를 호출한 스레드를 대기상태로 빠뜨린다. 

바로 WaitForSingleObject() 함수이다. 원형은 다음과 같다.

DWORD WINAPI WaitForSingleObject(
  _In_  HANDLE hHandle,
  _In_  DWORD dwMilliseconds
);

첫번째 인자로 전달된 hHandle (커널 오브젝트의 핸들)이 시그널 상태가 될때까지 기다리되 두번째 인자로 전달된 시간만큼 최대한 기다렸다가 만약 제한 시간안에 소식이 없으면 그냥 포기하고 대기 상태를 푼다.

커널 오브젝트가 정상적으로 시그널 상태가 되어 대기 함수를 깨우는 경우에는 WaitForSingleObject() 함수의 리턴 값은 WAIT_OBJECT_0가 된다. 만약 기다리다 지쳐 포기하고 리턴하는 경우네는 WAIT_TIMEOUT이 리턴된다. 

고로 다음과 같은 형식의 코드로 작성이 가능하다.

DWORD dwWaitResult;

dwWaitResult = WaitForSingleObject(ghReadyEvent, 5000);

if (dwWaitResult == WAIT_OBJECT_0) 

{

}

자 그러면 이제 대표적인 커널 오브젝트인 이벤트 오브젝트를 이용하는 방법을 보자. 우선 이벤트 오브젝트를 생성하는 방법은 다음과 같다.

HANDLE WINAPI CreateEvent(
  _In_opt_  LPSECURITY_ATTRIBUTES lpEventAttributes,
  _In_      BOOL bManualReset,
  _In_      BOOL bInitialState,
  _In_opt_  LPCTSTR lpName
);

여기서 주의해야 할 부분은 두 번째 인자와 세 번째인데 이것은 '수동 리셋 이벤트 (TRUE)' 로 이벤트 오브젝트를 만들지 아니면 '자동 리셋 이벤트 (FALSE)'로 만들지 설정하는 부분이다. 세 번째 인자는 초기 상태를 시그널 상태 (TRUE)로 만들지 아니면 논시그널 상태 (FALSE)로 만들지 설정하는 부분이다.

수동 리셋 이벤트는 시그널 상태가 되면 대기중인 모든 스레드가 시그널 상태가 되는 반면 자동 리셋 이벤트를 대기중인 스레드 중 한개만 신호상태가 되어 CPU를 점유하고 나머지는 계속 대기한다.

일반적으로 시작하면서 바로 파란불로 만드는 경우는 드물기 때문에 세 번째 인자는 FALSE로 간다고 보고 두 번째 인자는 사용자의 의도에 따라 TRUE 혹은 FALSE로 셋팅해야 한다.

그리고 이제 중요한 함수인 시그널 상태 혹은 논시그널 상태로 이벤트 오브젝트를 만들어주는 함수인데 바로 SetEvent() 와 ResetEvent() 함수이다.

SetEvent()와 ResetEvent() 함수 둘 다 커널 오브젝트인 이벤트 오브젝트의 핸들을 인자로 받아 상태를 변경한다. 

이름이 쪼금 헷갈리게 되어 있다. 왜 SetEvent 대신 GoEvent() 라던가 ReadyEvent() 라든지 좀 더 직관적으로 이해 되기 쉬운 함수 이름을 사용 안했는지 모르겠다.

암튼, SetEvent() 함수를 호출하게 되면 전달된 이벤트 오브젝트를 시그널 상태 (즉, 파란불: 준비되었다)로 변경한다. 반면 ResetEvent()는 이벤트 오브젝트를 논시그널 상태 (즉, 빨간불: 아직 멀었어!)로 변경한다.

이제 실제 코드 예제를 보자.

스레드의 동기화가 필요한 프로그래밍에서는 이벤트를 이용한 동기화가 제법 효과적이다. 테스트를 해보진 않았지만 프로세스간에 커널 오브젝트가 공유 되므로 서로 다른 프로그램끼리 같은 이벤트 핸들을 이용해서 서로 작업이 완료되었거나 준비되었음을 알려주면 아주 멎진 멀티-프로세스 프로그램을 만들수 있을 것 같다. 하지만 굳이 그렇게 분리된 형태의 프로그램을 작성해야 할 필요가 있나 하는 의문이 들긴 하지만... 뭐 어쨌든 된다고 하니까 어딘가 필요하지 싶다. 

다만 주의해야 할 것은 대기함수를 호출할때 대기 시간을 무제한으로 하게 되면 코딩의 오류나 어떤 문제로 인해 이벤트 오브젝트가 시그널 상태가 영원히 되지 않으면 대기함수를 호출한 스레드는 영원히 잠자게 된다. 데드락은 아니지만 대략 좋지 않은 상태다... 이걸 주의 해야 한다.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms724485(v=vs.85).aspx

Kernel Object (줄여서 KO) 핸들은 프로세스 한정적이다. 즉, 각각의 프로세스마다 고유하다는 말인데, 그말인 즉슨, 임의의 프로세스는 하나의 커널 오브젝트 핸들을 얻기 위해서는 반드시 오브젝트를 생성하거나 혹은 이미 존재하고 있는 오브젝트를 열어야 한다는 말이다. 하나의 프로세스 당 만들수 있는 최대의 커널 핸들의 갯수는 2의 24승이다. 뭐, 무제한이라고 보면 되겠네. 그러나, 핸들들은 Paged Pool에 저장되므로 결론적으로 사용가능한 메모리에 따라 생성할 수 있는 핸들의 갯수는 제한된다. 32 비트 윈도우즈 시스템의 경우 생성할 수 있는 핸들의 갯수는 2의 24승 보다 훠어얼씬 적다. 

프로세스는 오브젝트의 이름과 접근 권한을 가지고 있다면 이미 존재하고 있는 커널 오브젝트에 새로운 핸들을 할당하는 것이 가능하다. 심지어 그 커널 오브젝트가 다른 프로세스에 의해 만들어 졌다고 해도 가능하다. 커널 오브젝트 핸들은 그 자체에 접근 권한을 설정하는 속성을 가지고 있어서 접근을 허용 또는 차단을 할 수 있다. 보안 속성이라고도 한다. 각각의 커널 오브젝트는 고유의 접근 권한을 가지는데 예를 들자면 이벤트 핸들 같은 경우에는 'Set' 혹은 'Wait'를 가질 수 있고 파일 핸들 같은 경우에는 'Read' 혹은 'Write' 같은 접근 권한을 가질 수 있다.

아래의 그림을 보면 어플리케이션이 하나의 이벤트 오브젝트를 생성하는데 CreateEvent 함수가 이벤트 오브젝트를 생성하고 오브젝트 핸들을 리턴하고 있다.

이벤트 오브젝트가 생성된 후, 어플리케이션은 이벤트 핸들을 이용해 이벤트를 Set 혹은 Wait 시킬 수 있다. 이 핸들은 어플리케이션이 핸들을 닫거나 어플리케이션 자체가 종료될 때 까지 유효하다. 

대부분의 커널 오브젝트들은 하나의 오브젝트를 위해 다수의 핸들을 제공할 수 있다. 예를 들자면 아래 그림처럼 CreateEvent로 핸들을 하나 생성한 후 다시 OpenEvent로 같은 이벤트 오브젝트를 위한 핸들을 생성할 수 있다는 말이다. 

이런 방법으로 어플리케이션은 여러개의 핸들에게 다른 속성의 접근 권한을 부여 할 수 있다. 예를 들자면 Handle 1은 Set과 Wait 모두를 할 수 있게 접근 권한을 주고 Handle 2는 오로지 Wait만 가능하도록 설정 가능 하다는 말이다.

만약 다른 프로세스가 어떤 이벤트의 이름과 그 이벤트로의 접근 권한을 가지고 있다면 그 프로세스는 자신만의 이벤트 오브젝트 핸들을 OpenEvent 함수를 이용해서 생성 할 수 있다. DuplicateHandle을 이용하면 같은 프로세스 내에서 핸들을 복사 하여 생성할 수도 있고 다른 프로세스로 복사해서 전달 할 수도 있다.

하나의 오브젝트는 최소한 한개의 오브젝트 핸들이 존재하는 한 메모리에 계속 상주한다. 아래 그림처럼 어플리케이션이 CloseHandle함수를 사용해서 모든 오브젝트 핸들을 닫게 되면 비로서 오브젝트는 메모리상에서 사라지게 된다. 

흠, 이것은 마치 COM 오브젝트가 스스로를 관리하는 카운터를 가지고 있다가 0이되면 자폭하는 것과 같은 원리다. 제법 능동화된 메모리 관리 기법이지만 제대로 해제하지 않으면 어플리케이션이 종료되기 전까지는 절대 사라지지 않는 메모리 누수를 가지는 위험성이 존재한다.

윈도우 시스템은 다른 커널 오브젝트와는 조금 다른 방식으로 파일 오브젝트를 관리한다. 파일 오브젝트는 파일 포인터를 가지고 있다. 이 포인터는 파일내부의 읽혀질 혹은 쓰여질 다음 바이트의 위치를 가리키는 포인터이다.  어플리케이션이 새로운 파일 핸들을 생성할 때 시스템은 새로운 파일 오브젝트를 생성한다. 그러므로 하나 이상의 파일 오브젝트는 디스크 상의 한개의 파일을 가리킬 수 있는데 다음 그림과 같다. 

Duplication 이나 Inheritance (상속)을 통하면 한개 이상의 파일핸들이 같은 파일 오브젝트를 가리킬 수 있다. 다음 그림처럼.

사실 위 두개의 그림의 차이가 뭔지 잘 느낌이 안온다. 아마도 같은 파일 오브젝트를 공유하는 경우에 좀 더 자원경쟁에 안정적인 구현이 가능하다는 점이 다를까? 여러개의 다른 파일 오브젝트가 동시 다발적으로 한개의 파일에 접근하는 경우를 예방할 수 있다는 것이 장점일까? 

다음 도표를 보면 다양한 커널 오브젝트들이 나열되어 있다. 보면 생성 함수와 파괴 함수가 나열되어 있다. 시스템은 커널 오브젝트를 가리키는 최후의 핸들이 닫히면 자동으로 메모리에서 커널 오브젝트를 날려 버린다.

내가 내 생각대로 정리하자면, 커널 오브젝트는 보안 속성 (접근 제한)과 상태를 가지고 시스템에 의해 관리를 받는 일종의 구조체이다. 이런 커널 오브젝트가 중요한 이유는 시스템의 모든 중요 업무는 이런 커널 오브젝트를 통해서 이루어지고 있기 때문에다. 왜냐면 시스템이 이런 커널 오브젝트를 체계적으로 관리하여 사용자의 삽질을 막고 동시에 안전성을 높인다. 하지만 나에게 지금 커널 오브젝트가 중요한 이유는 바로 '상태' 때문이다. 커널 오브젝트가 상태를 가지기 때문에 스레드 간의 동기화에 요긴하게 쓰인다. 다름 글에서 어떻게 사용하는지 써보겠다.

WinForms는 작업 (예를 들자면 윈도우 디스플레이, 이벤트 처리 등등)을 하기 위해서 Native Windows System Assembly들을 사용한다. 

Thread Safe 하다는 것은 Multiple Threads 들이 하나의 오브젝트의 상태를 동시에 접근하여 변경하려고 하더라도 그 오브젝트의 '상태 (State)'를 '일관성있게' (Consistent) 유지한다는 것을 의미한다. 

Windows 폼 컨트롤의 "State" (상태)라고 하는 것은 텍스트 박스 안의 텍스트 같은 것을 말한다. 체크 박스를 예로 들자면 체크 상태를 말하는 것이다.

Multithreaded 환경에서 스레드에 안전하지 않은 (Non-Thread-Safe) 오브젝트를 사용하는 것은 상태의 오염 (State Corruption)을 가져 올 수 있다. 

이런 점을 피해가기 위해서 등장한 것이 바로 "Thread Apartment"라고 불리는 컨셉이다. 이것은 두가지 종류가 있는데 하나는 Single Threaded (STA)이고 다른 하나는 Multithreaded (MTA) 이다. A는 Apartment의 약자이다. .NET의 기본적인 디폴트 값은 MTA이다.

프로세스가 STA (Single Threaded Apartment) 모드로 작동한다고 가정하면 그 코드는 오직 하나의 스레드에서만 돌아간다는 말이다. 이런 STA 모드는 UI Application의 경우 아무런 효용 가지가 없다. 왜냐면 백그라운드 스레드로 작업을 할 수가 없기 때문이다. 

그래서 .NET은 WinForms Application을 Multithreaded로 생성하는 대신 폼의 내부에 속한 각각의 컴포넌트(예를 들자면 텍스트 박스)에 대해 그 컴포넌트가 생성되었던 스레드를 기억해 두었다가 사용자가 생성되었을 당시 사용되었던 스레드가 아닌 다른 스레드를 이용해서 해당 컴포넌트를 호출하거나 사용하려 하면 Exception이 발생하게 된다. 

InvokeRequired() 함수는 기본적으로 컴포넌트가 생성될 당시의 스레드 ID와 현재의 스레드 ID를 비교하는 함수이다.