Computer Science

Regsvr32 유틸리티 - 이 유틸리티를 이용하여 DLL을 레지스트리에 등록한다.


등록 : DLL의 export된 DllRegisterServer함수를 수행한다.

해제 : DLL의 export된 DllUnregisterServer함수를 수행한다.

 
실행 방법 -  regsvr32 “DLL파일경로”
                 Option : DLL 해제 : /u

Com Library

COM Library를 사용하여 반복되는 일련의 과정을 편리하게 사용가능(등록,객체생성,interface 포인터획득)

함수 앞에 Co가 붙으면 Com Library이다.

COM Library의 초기화
 HRESULT CoInitialize( LPVOID pvReserved  //Reserved; must be NULL );

COM Library의 해제
 void CoUninitialize( );


STDAPI DllGetClassObject( REFCLSID rclsid, REFIID riid, LPVOID * ppv);
CLSID를 넘겨주면 그 CLSID와 연결된 ClassFactory를 리턴한다


클라이언트에서 서버의 IClassFactory의 인터페이스의 포인터를 얻을 수 있다.
내부적으로 DllGetClassObject를 호출한다.

첫번째 : 생성하고자 하는 CoClass의 CLSID
두번째 : COM 서버를 IN서버로 할것인지 OUT서버로 할 것인지
세번째 : NULL
네번째 :  IID_IUnknown을 얻어오겠다.
마지막 : 매개변수로 넣어준 포인터에 이 CoClass를 생성하는데 사용되는 클래스 팩토리의 인터페이스 포인터를 넘겨 받는다.

//unknwn.h 파일에 선언됨

interface IUnknown

{

  virtual HRESULT __stdcall QueryInterface(REFIID riid, void **ppv)=0; //Interface 얻어오기 !!

  virtual ULONG  __stdcall AddRef()=0; //개체 참조 카운트 증가 !!

  virtual ULONG  __stdcall Release()=0;  // 개체 참조 카운트 감소 !!

}

COM   - MS에서 소프트웨어(컴포넌트) 를 만들 때 지켜져야할 규칙 혹은 명세
(A와 통신하기 위해서는 어떠한 통신하기위한 약속(Com)이 필요하다.)

컴포넌트 : 소프트웨어를 구성하는 모듈

CoClass : 인터페이스를 실제 구현하는 코드(소프트웨어 컴퓨넌트를 구현하는 기본단위)

COM 오브젝트 : CoClass가 인스턴스화 되어 메모리에 생성된 것을 말한다.

예.

생성할때는
 
1. XX상속 받아야한다.
     2. XX 함수를 구현
     3. XX Key값을 가져야 한다.

이런 규칙들을 정해놓는다.

가져올때는

1. xx 통해 생성
2. xx 포인터는 xx 통해서 가져온다.


인터페이스(통신할수있는 규약) == 가상함수테이블

레고(COM)
{
Virtual 꼽힌다() = 0;
Virtual 꼽다()  = 0;
}

레고가 꼽히는게 아니라 레고에서 상속받은 나무나 사람이 꼽히는 것이다.
레고에서 상속받은 모든 것들은 공통적으로 가상함수테이블에 2개의 함수를 가지고있다.
여기서 꼽힌다와 꼽다 가 인터페이스가 된다.

COM 에서는 아래 3개의 함수가 인터페이스이다.

QueryInterface();
Addref();
Release();

Test.zip

OutBitmap(hdc,x,y,비트맵 이름);

이런 함수가 있다면 무척 편리하게 비트맵을 출력할 수 있겠지만 안타깝게도 이런 함수는 없다. 왜냐하면 비트맵은 크기가 큰 데이터 덩어리이며 따라서 출력 속도가 형편없이 느리기 때문에 화면으로 곧바로 출력할 경우 여러 가지 꼴사나운 현상이 발생할 수 있기 때문이다. 게다가 다른 좋은 대안이 있기 때문에 직접 화면으로 출력하는 방법은 쓰지 않는다. 그 대안이 바로 여기서 논하고자 하는 메모리 DC이다.

메모리 DC란 화면 DC와 동일한 특성을 가지며 그 내부에 출력 표면을 가진 메모리 영역이다. 메모리에 있기는 하지만 화면 DC에서 사용할 수 있는 모든 출력을 메모리 DC에서도 할 수 있다. 선, 면, 원 등의 작도 함수는 물론 화면 DC에서는 불가능한 것까지도 가능하다. 그래서 메모리 DC에 먼저 그림을 그린 후 사용자 눈에 그려지는 과정은 보여주지 않고 메모리 DC에서 작업을 완료한 후 그 결과만 화면으로 고속 복사하는 방법을 많이 사용한다.

사용자 눈에 화면이 그려지는 과정을 보여주는 것은 그리 깔끔한 모양은 아니다. 여기서 우리가 하고자 하는 비트맵 출력을 위해서도 반드시 메모리 DC를 사용해야 한다. 비트맵도 일종의 GDI 오브젝트이지만 화면 DC에서는 선택할 수 없으며 메모리 DC만이 비트맵을 선택할 수 있다. 그래서 메모리 DC에서 먼저 비트맵을 읽어온 후 화면 DC로 복사하는 것이다. 메모리 DC를 만들 때는 다음 함수가 사용된다.

인수로 화면 DC의 핸들을 주면 이 화면 DC와 동일한 특성을 가지는 DC를 메모리에 만들어 그 핸들값을 리턴해 준다. 동일한 특성을 가진다(=호환된다)는 말은 사용하는 색상수, 색상면(plane)이 같다는 뜻이다. 호환되지 않는 DC끼리는 정보를 공유할 수 없기 때문에 화면 DC와 호환되는 메모리 DC를 만들어야 한다.

메모리 DC를 만든 후에는 비트맵을 읽어온 후 이 비트맵을 메모리 DC에 선택해 준다. 선택하는 방법은 여타의 GDI 오브젝트와 마찬가지로 SelectObject 함수를 사용하며 비트맵을 읽어올 때는 LoadBitmap 함수를 사용한다.

첫번째 인수는 비트맵 리소스를 가진 인스턴스의 핸들이며 두번째 인수는 비트맵 리소스의 이름이다. 읽어온 비트맵을 SelectObject 함수로 메모리 DC에 선택하면 메모리 DC의 표면에는 리소스에서 읽어온 비트맵이 그려져 있을 것이다.
이제 남은 일은 메모리 DC에 그려진 비트맵을 화면으로 복사하기만 하면 된다.

출처 : http://www.winapi.co.kr

 디버그 빌드와 릴리즈 빌드에서 서로 실행 결과가 다른 경우, 특기 디버그 빌드에서는 괜찮은데 릴리즈 빌드에서만 오류가 발생하여 프로그램이 죽는 경우가 있는데 이런 경우는 대부분 메모리가 깨진 경우에 발생한다. 두 모드에서 동적으로 메모리를 할당하면 힙 영역에 요청한 크기만큼 메모리를 할당 받게 되는데 그 초기값이 다르다.

릴리즈 빌드의 경우 할당된 메모리 영역을 초기화하지 않는 경우 바로 할당되기 직전의 쓰레기 값이 그대로 사용되는 반면 디버그 빌드의 경우 디버거로 디버깅하는데 블록을 구분하기 위해 0xCC, 0xDD와 같은 값으로 초기화된다.

디버그 모드

 실행 파일에 디버깅 정보를 삽입하여 언제든지 디버깅을 할 수 있도록 하며 프로젝트 디렉토리 아래에 Debug 서브 디렉토리에 실행 파일을 만들어 준다. 디버깅 정보가 들어가 있기 때문에 실행 파일의 상태를 확인할 수 있다.

릴리즈 모드

 일체의 디버깅 정보를 삽입하지 않을 뿐만 아니라 코드를 최적화하여 실행 파일 크기를 최대한 줄여준다. 릴리즈 모드로 만든 실행 파일로는 디버깅을 할 수 없지만 속도나 크기면에서는 디버그 모드로 만든 실행 파일보다 월등히 유리하다. 모든 버그를 잡고 개발이 완료되었을 때는 릴리즈 모드로 컴파일해야 한다.

출처 www.winapi.co.kr