<a href="https://creazier.tistory.com/" title="삶의 모든 순간을 즐겨라!" class="link_logo"> 삶의 모든 순간을 즐겨라!

virtual HRESULT __stdcall QueryInterface

(

/* in

*/ REFIID riid,
/* iid_is

virtual ULONG __stdcall AddRef

*/ void** ppv) = 0;

(void) = 0;
virtual ULONG __stdcall Release(void) = 0;

}

C++ 언어에서 가상 함수를 포함하는 클래스에서 생성된 인스턴스는 가상 함수 테이블 포인터를 갖게 된다.
이 가상 함수 테이블 포인터를 인터페이스 포인터라 하며, 인터페이스 포인터를 갖는 클라이언트는

가상 함수 테이블을 통해 멤버 함수를 호출할 수 있다.

COM은 인터페이스를 통하여 다형성(polymorphism)을 지원하게 되는 것이다.

그러나 COM은 상속성(inheritance)는 지원하지 않는다.

문제점은 구현된 코드를 다시 사용할 수 없기 때문에 이 문제는 포함(containment)과 통합(aggregation)이라는 해결 방법을 제공한다. 11장으로

COM 컴포넌트

COM 컴포넌트를 COM 서버(COM Server)또는 COM 객체 서버(COM object server)라고 부른다.

COM 컴포넌트의 위치에 따라 인-프로세스 서버(in-process server)와 아웃-오브-프로세스 서버(out-of-process server)로 구분된다.

인-프로세스 서버는 클라이언트와 같은 프로세스 안에서 생성되고 실행되는 서버
아웃-오브-프로세스 서버는 클라이언트와 다른 별도의 프로세스가 생성되어 실행되는 서버

따라서

인-프로세스 서버는 DLL로 구성되며
아웃-오브-프로세스 서버는 EXE로 구성.

이 아웃-오브-프로세스는 다시 로컬 서버(local server)와 리모트 서버(remote server)로 구분
로컬 서버는 서버가 클라이언트와 같은 시스템에서 실행되는 것을 뜻하며
리모트 서버는 서로 다른 시스템 즉, 네트워크를 통해 커뮤니케이션을 하는 것을 말한다.
리모트 서버를 대리 프로세스(surrogate process, dllhost.exe)안에서 실행되는 인-프로세스 서버로 구현할 수도 있지만 일반적으로 아웃-오브-프로세스 서버로 구현하는 것이 일반적이다.

GUID

OSF(open software foundation)가 제공하는 GUID(globally unique identifier)을 사용한다.
GUID(globally unique identifier)를 사용한다. GUID는 128비트(16바이트)의 크기를 갖는 구조체로 전세계적으로 시간과 장소에 관계없이 고유하다고 보장할 수 있는 값을 나타내는 식별자이다.
인터페이스 GUID를 IID(interface identifier)라고 하고 COM객체의 GUID를 CLSID(class identifier)라고 한다.
GUID는 UUID(universally unique identifier)라고도 하며 guiddef.h헤더 에 정의 되어 있다.

typedef struct _GUID
{

unsigned long Data1;
unsigned short Data2;
unsigned short Data3;
unsigned char Data4[8];

} GUID;

윈도우에서는 GUID를 생성하는 두가지 툴을 제공한다.
콘솔 명령어 행에서 사용하는 UUIDGEN.EXE와 GUI를 제공하는 GUIDGEN.EXE이다.
이들 툴은 COM 라이브러리인 CoCreate ?GUID함수를 호출하고 Win32 RPC API함수인 UUIDCreate를

호출하여 내부 알고리즘으로 GUID를 생성하여 준다.

GUID구조체에는 서로 다른 GUID를 비교하는 operator == 함수가 정의어 비교할 수 있다.
그리고 같은 기능을 하는 IsEqual?GUID(), IsEqual?IID(), IsEqual?CLSID()등이 있다.

그리고 구조체의 크기가 크기때문에 레퍼런스 형태로 매개변수를 사용한다.

GUID를 문자열로 변환하는 StringFrom?GUID2()도 제공된다.

닷넷으로 넘어가면서 COM을 구현하는 일은 완전히 Visual C++과 ATL의 몫이 되었다.

제2장 COM 컴포넌트 사용

COM 컴포넌트 등록

먼저 사용하기 전에 시스템 레지스트리에 등록이 되어 있어야 한다.

DLL파일은 (in-process server) regsvr32.exe 툴을 사용하면 쉽게 등록할 수 있다.
EXE파일의 경우 (out-of-process server) 파일이름.exe /regserver 옵션을 통해 등록을 한다.

COM 컴포넌트 생성 과정

1. COM 라이브러리를 초기화 한다.
2. COM 객체의 CLSID를 구한다.
3. COM 객체의 인스턴스를 생성한다.
4. COM 객체가 지원하는 인터페이스 포인터를 구하여 해당 인터페이스가 제공하는 메서드를 호출함으로 COM객체를 사용한다.
5. COM 객체의 상요이 끝나면 COM라이브러리 초기화를 해지한다.

COM 라이브러리 초기화

COM라이브러리는 COM객체에 대한 서비스 요청을 중개하는 ORB(object request broker)이며 COM을 사용하는 모든 애플리케이션들이 유용하게 사용할 수 있는 컴포넌트 관리 서비스를 제공한다.

COM라이브러리는 모든 COM 컴포넌트에 필요한 몇가지 필수 API를 제공하며 Co-의 접두어를 가진다.

objbase.h 헤더 파일에 선언되어 있다.

HRESULT CoInitializeEx?(

void *pvReserved, // 예약됨 무조건 0
DWORD dwCoInit

// COINIT 열거형 값. 당분가 COINIT_APARTMENTTHREADED를 지정하면 된다고....

);

이 함수를 사용하기 위해서는 DCOM이 사용가능한 윈도우NT4.0 이상이나 윈98이상

윈95에 DCOM이 깔려진 경우 이다.

선행 매크로는

#define _WIN32_DCOM
이거나

#define _WIN32_WINNT 0x0400

DCOM 이전에는 CoInitialize ?()함수가 사용되었다.

내부적으로 COINIT_APARTMENTTHREAD를 호출하지만 지금은 사용 안한다.

HRESULT

HRESULT 함수 호출 결과를 나타내는 32비트 값이다.
성공시는
S_OK 0x00000000L 성공

실패시는

에러코드	값	설명
E_NOTIMPL	0x800040001L	인터페이스 메서드가 구현되지 않음
E_OUTOFMEMORY	0x8007000EL	요청한 메모리를 할당하지 못함
E_INVALIDARG	0x80070057L	인터페이스 메서드에 잘못된 인수가 넘어옴
E_NOINTERFACE	0x80004002L	요청한 인터페이스를 지원하지 않음
E_ACCESSDENIED	0x80070005L	요청한 컴포넌트에 접근할 수 없음

SUCCESSED와 FAILED매크로로 단순한 성공 실패를 구별할 수도 있다.

COM 객체의 CLSID 구하기

1. OLE/COM 개체 뷰어(OLE/COM object viewer)를 사용

2. 프로그램ID(ProgID) 하지만 중복될 가능성이 존재한다.

참고로 엑셀의 ProgID는 Excel.Application.10이다. 버저 번호를 생략할 수 있으며

버전 독립적 ProgID라고 한다. Excel.Application과 같이

3. 레지스트리에서는 HKEY_CLASSES_ROOT 키 밑에 존재 한다.

CLSIDFromProg ?ID함수

HRESULT CLSIDFromProg?ID(

LPOLESTR lpszProgID, // ProgID 문자열 값
LPCLSID pclsid // 반환된 CLSID값을 저장할 CLSID 포인터

);

COM 에서의 문자열 사용

내부적으로 유니코드(unicode)사용. 유니코드가 아닐경우 변환을 해주어야 한다.

앞의 LPOLESTR와 같은 경우 싹다 유니코드 결국 wchar_t 형이다.

WIN32API와 C 런타임 라이브러리에는 ANSI문자열과 유니코드 문자열의 상호 변환 함수가 존재한다.

MultiByteToWideChar ?함수는 ANSI문자열을 UNICODE로 변환
WideCharToMultiByte?함수는 역변환하여주는 Win32API

mbstowcs함수는 ANSI문자열을 UNICODE로 변환
wcstombs함수는 역변환 하여주는 C 런타임 라이브러리

유니코드 사용시
#define UNICODE

COM 객체 인스턴스 생성

STDAPI CoCreateInstance?(

REFCLSID rclsid, // COM 객체의CLSID
LPUNKNOWN pUnkOuter

, // 외부 COM객체의 IUnknown 포인터. 일반적으로 null, 11장 컴포넌트 재사용에 사용
DWORD dwClsContext

, // 서버 컨텍스트, 일반적으로 CLSCTX_ALL사용시 문제 없음. 레지스트리에서 COM 컴포넌트를 찾는 위치(in-process > out-of-process 순)
REFIID riid, // 요청 인터페이스의 IID
LPVOID* ppv // 리턴될 인터페이스 포인터

);

CLSID로 식별되는 COM객체의 인스턴스를 생성하고 해당 COM 객체로부터 IUnknown 인터페이스 포인터를 리턴하여줌. 이 함수는 내부적으로 CoGetClassObject ?() API를 호출하고 clsid와 dwClsContext? 인수값을 넘겨준다.

STD CoGetClassObject?(

REFCLSID rclsid,
DWORD dwClsContext

,
COSERVERINFO* pServerInfo

, // NULL
REFIID riid,
LPVOID *ppv

);

결국

// CoCreateInstance?() 내부에서는

IClassFactory?* pClassFactory? = NULL;
::CoGetClassObject?(rclsid, dwClsContext?, NULL, IID_IClassFactory?, (void**)&pClassFactory?);

pClassFactory?->CreateInstance?(NULL, riid, ppv);
pClassFactory?-Release();

이 함수 내부에서는 시스템 프로세스에 rpcss.dll로 구현된 SCM(service control manager)에게

COM 컴포넌트를 찾아 로드하고 SCM이 요청한 COM 컴포넌트를 찾아 로드한 후에는 SCM은 물러나고

클라이언트와 COM 컴포넌트는 직접 커뮤니케이션 한다.

구체적으로는 먼저 CLSID에 해당하는 COM 객체 정보를 레지스트리에서 찾고 dwClsContext?에 해당하는
CLSCTX_INPROC_SERVER 레지스트리에서 CLS문자열 서브키 밑에 있는 InprocServer32?서브키에서 COM 컴포넌트의 실제 경로명을 구하고 CLSCTX_LOCAL_SERVER 이라면 LocalServer32? 서브키에서

실제 경로명을 구한다.

위치 투명성이 확실이 제공된다면 CLSCTX_ALL을 사용해 먼저 InprocServer32?에서 찾고 없으면 LocalServer32?에서 찾는다. 또한 내부적으로 CoLoadLibrary?() API 함수를 호출한다.

HINSTANCE CoLoadLibrary?(

LPOLESTR lpszLibName

, // 실제 컴포넌트 파일 이름
BOOL bAutoFree

) // TRUE

{

return ::LoadLibrary

(lpszLibName

); // Win32API

}

// CoGetClassObject?() 내부에서는

HINSTANCE helloDll = ::CoLoadLibrary?(L"helloserver.dll", TRUE);

// typedef HRESULT (__stdcall *PFNDLLGETCLASSOBJECT)(REFCLSID clsid, REFIID riid, void **ppv)
PFNDLLGETCLASSOBJECT DllGetClassObject? = (PFNDLLGETCLASSOBJECT)GetProcAddress?(helloDLL, "DllGetClassObject?");
DLLGetClassObject?(rclsid, riid, ppv);

결국 DLL이나 EXE로 존재하는 하는 파일에서 DllGetClassObject?라는 함수 포인터를 얻어와 riid에

해당하는 IClassFactory? 인터페이스를 얻어오는 형식이다.

이렇게 얻어온 IClassFactory? 인터페이스에서 CreateInstance?() 메서드를 호출하여 자신에 해당하는

(클라이언트가 요청한) COM 객체 인스턴스를 넘겨주게 된다.

이렇게 IUnknown 인터페이스 포인터를 구했다면 이제 COM 객체가 제공하는 서비스를 사용할 준비가

된 것이다.

IUnknown 인터페이스

COM인터페이스는 반드시 IUnknown에서 파생된다.

interface IUnknown
{

virtual HRESULT __stdcall QueryInterface

(

/*in

*/ REFIID riid,
/*iid_is

virtual ULONG __stdcall AddRef

*/ void **ppv) = 0;

(void) = 0;
virtual ULONG __stdcall Release(void) = 0;

}

이렇게 사용하는 이유는

CreateInstance ?() 함수는 인터페이스로 변환 가능한 클래스를 생성시킨다. 그리고 해당 인터페이스로 업캐스팅하여 반환한다. 이렇게 사용하는 이점은 실제 객체가 바뀐다고 하더라도 일괄적으로 CreateInstance?()함수를 통해 사용자에게 사용법에 해당하는 인터페이스를 반환할 수 있다는 점이다.

여러 인터페이스를 지원하는 클래스가 존재한다면 하나의 인터페이스에서 다른 인터페이스의 호출은 사실상 막혀 있는 셈이다. 상속 받는 객체에서 같이 존재할뿐 사실상 다른 인터페이스는 서로의 존재를 알 수 있는 방법이 없다.

그러므로 다시 객체에 접근을 하여 다른 인터페이스를 호출 할 수 있다.

그게 바로 QueryInterface?()의 역할이다.

그리고 객체는 하나이지만 사용되는 인터페이스의 개수는 여러개가 될 수 있다.
하나의 인터페이스에서 인터페이스를 사용하고 종료를 하면서 객체를 소멸시킨다면..
그외 인터페이스를 통해 접근하고 있는 다른 객체들은 Access Violation과 같은 오류에 빠진다.

그럼으로 객체 카운트가 있는 스마트 포인터를 사용하여 객체 카운터가 0가 되는 시점에 실제 객체를

삭제 시킬수 있도록 한다. 이때 사용되는 함수가 AddRef?()와 Release()인 것이다.

위의 COM 컴포넌트를 만들때는 CLSID를 참조해서 만들면 되지만
Interface를 만들때는 IID가 레지스트리에 존재하지 않는다.
그렇기 때문에 COM 컴포넌트의 인터페이스를 제공할 때는 IID까지 같이 제공해야 한다.

일반적으로 COM컴포넌트가 제공하는 인터페이스는 IDL구문으로 정의하고 MIDL(microsoft IDL) 컴파일러를 사용하여 컴파일한다. MIDL 컴파일러는 xxxh.h 헤더파일에 C++ 클래스로 정의한 코드를 제공하며 xxx.i_c 파일에 인터페이스의 IID를 제공해 준다. 실제로 COM 컴포넌트에 인터페이스를 만들려고 한다면
IUnknown을 통해 다시 QueryInterface?()를 호출할 필요는 없다.

CoCreateInstance?()를 호출할때 실제 IID를 통해 인터페이스를 구하는 편이 낫다.

COM 컴포넌트 사용시 컴포넌트 내부에서 생성된 메모리의 경우 결국 클라이언트가 해지를 해주어야 한다.
같은 프로세스라면 낫지만 아웃-오브-프로세스 서버라면 이런 방법으로 안되고 반드시 COM라이브러리가

제공하는 CoTaskMemFree?()와 같은 함수를 사용하여 해지 하여야 한다.
반대로 컴포넌트 내부에 메모리를 할당하는 CoTaskAlloc?()도 존재한다.

COM 라이브러리 초기화 해제

void CoUninitialize?();

제3장 COM 객체 구현

COM 구현은 어렵다.
하지만 맨바닥부터 할 필요는 없으니 그나마 낫다.

인터페이스는 가상 함수 테이블(virtual function table) 형식의 메모리 구조를 정의하는 것이 된다.

COM/DCOM은 IDL과 인터페이스를 통해 컴포넌트가 언어 독립적인 특징을 갖도록 한다.

표준 인터페이스

두가지 종류가 있다.
1. 표준 인터페이스(standard interface)
대표적인 경우로 IUnknown과 IClassFactory ?가 있고 이외에 OLE, ActiveX, OLE DB와 같은 COM기반 기술에서 사용되는 IDispatch, IConnectionPointContainer?, IConnectionPoint?, IOleControl?기타 등등이 있다.
이들 표준 인터페이스 IDL 파일은 마소에의해 미리 정의되어 SDK(software development kit)안에서 제공되므로 굳이 IDL을 정의할 필요없다. 예를 들면 IUnknown 인터페이스는 unknwn.idl 파일에 다음과 같이 정의 되어 있다.

[

local,
object,
uuid(00000000-0000-0000-C000-000000000046),
pointer_default(unique)

]

interface IUnknown
{

typedef unique

IUnknown *LPUNKNOWN;

HRESULT QueryInterface?(

REFIID riid,
out, iid_is(riid)

void **ppvObject);

ULONG AddRef

();
ULONG Release();

}

2. 커스텀 인터페이스(custom interface)
개발자가 자신의 필요로 정의하여 사용하는 인터페이스를 말한다.
COM에서 사용하는 IDL은 OSF의 RPC에서 사용하던 IDL을 확장시킨것으로 C++과 매우 흡사한 구문을 제공한다.

[

object,
uuid(783964A0-A074-11d1-B20C-0060970A3516)

]

interface IHello : IUnknown
{

import!! "unknwn.idl";
HRESULT sayHello(in, string

wchar_t* name, out, string

wchar_t** message);

};

각 인터페이스는 헤더와 본체로 구성된다.
헤더에는 전체 인터페이스에 해당하는 어트리뷰트 정보가 포함된다.
어트리뷰트(attribute)는 인터페이스의 전체 또는 데이터와 메서드가 갖는 특징을 지정하는 키워드로서

대괄호(, ?)안에 정의 된다.

IDL목적 중의 하나는 COM이 클라이언트와 COM 객체 사이에 메서드의 인수값을 전달하는데 필요한 정보를 제공하는데 있으며, 이것의 위의 예제의 in, out, string 어트리뷰트의 목적이다.
정확히 이야기 하자면 in, out, string등의 어트리뷰트는 MIDL 컴파일시 생성되는 프록시(proxy)/스텁(stub) 코드의 최적화에 필요한 특성 정보를 제공한다.

즉, 메서드가 프로세스 사이에 마샬링(marshaling)되는 필요한 충분한 정보를 제공함으로 필요한 데이터만 마샬링되어 최적화가 목적이다. in은 readonly 값으로 사용되고 out은 클라이언트로 반환되며 string은 null문자로 끝나는 문자열이 전달된다는 뜻으로 보면된다.

MIDL 컴파일러

midl.exe FILENAME.idl

위의 명령은 4개의 파일을 만들어 낸다.

FILENAME.h // c와 c++에서 사용할 수 있는 인터페이스 클래스 코드
FILENAME_i.c // 모든 인터페이스의 GUID
FILENAME_p.c // 커스텀 인터페이스의 마샬링 코드가 정의된 프록시/스텁 코드가 저장된다.
dlldata.c

midl /h FILENAME_h.h FILENAME.idl

인터페이스 클래스의 코드가 저장되는 헤더파일 이름은 위의 명령으로 바꿀 수 있다.

아까 보았던 IDL 코드의 컴파일후 인터페이스 클래스의 예이다.

// Hello_h.h
MIDL_INTERFACE("783964A0-A074-11d1-B20C-0060970A3516")
IHello : public IUnknown
{

virtual HRESULT STDMETHODCALLTYPE sayHello( /*string

*/ wchar_t* name, /*string

#define MIDL_INTERFACE(x) struct DELCLSPEC_UUID(x) DECLSPEC_NOVTABLE
#define STDMETHODCALLTYPE __stdcall
#define DECLSPEC_UUID(x) __declspec(uuid(x))
#define DECLSPEC_NOVTABLE __declspec(novtable)

*/ wchar_t** message)=0;

};

몇가지 매크로가 정의 되엉 있는데

결국 확장시키면

// Hello_h.h
struct
__declspec(uuid(783964A0-A074-11d1-B20C-0060970A3516))
__declspec(novtable)
IHello : public IUnknown
{

virtual HRESULT STDMETHODCALLTYPE sayHello( /*string

*/ wchar_t* name, /*string

HRESULT STDMETHODCALLTYPE CHello::CImplIHello::QueryInterface?(REFIID riid, LPVOID *ppv)
{

*/ wchar_t** message)=0;

};

__declspec 비주얼C++ 확장 키워드가 uuid 애트리뷰트화 함께 지정되면 해당 인터페이스 클래스에 uuid 애트리뷰트의 인수에 지정된 GUID가 부착된다. 따라서 나중에 __uuidof 비주얼C++ 확장 키워드를 사용하여 인터페이스 클래스에 부착된 GUID를 구할 수 있게 되는 것이다.
나머지 확장 키워드는 6장에 계속

novtable 애트리뷰트의 의미는 순수 가상함수만 있는 추상 클래스에서는 가상 함수 테이블이 포함될 필요가 없다는 이야기. 결국 메모리 공간을 가질 필요가 없고 생성자나 소멸자의 역활 또한 막는다.

__stdcall의 경우 Win32 API들에 광범위하게 사용되는데 결국 callee에서 스스로 스택을 제거하는 것을의미한다. 결국 제거할 스택을 계산하는 시간과 용량을 줄일 수 있다. (가변인자를 사용하는 C의 printf문과 같은 경우 __cdecl는 함수 콜하는 쪽에서 인자가 넘어가는 갯수를 계산하여 넘겨주면 된다. unstack하면 되는 것이다.) 결국 다 효율이다.

COM 객체 클래스 구현

인터페이스 포함 방법

간단히 말하자면 인스턴스를 생성할 클래스는 IUnknown을 상속 시키고, 인스턴스 클래스를 다시 상속 받는 이너 클래스를 만들어 멤버로 포함시킨다.
그리고 그 멤버에 friend 설정을 하여 내부 멤버를 참조할 수 있도록 만들어 사용한다.

return m_pHello->QueryInterface

(riid, ppv); // m_pHello는 CHello에 대한 포인터이다.

}

...

HRESULT STDMETHODCALLTYPE CHello::CImplIHello::sayHello(...)
{

...

}

인터페이스 상속 방법

일반적인 상속과 같다. QueryInterface ?()호출시 riid에 따라 this 포인터를 형변환으로 반환하여 주면 된다.

IUnknown 인터페이스를 상속받는 IHello 인터페이스를 다시 상속받는 CHello 클래스가 있다고 하면

인터페이스	가상 함수 테이블 영역
IUnknown	QueryInterface?(),AddRef?(),Relase()의 영역
IHello	위의 메소드 + sayHello() 결국 모든 영역

다중 인터페이스 구현

인터페이스 포함 방법

inner 클래스를 여러개 만들고 각각 상속을 받는다.

인터페이스 상속 방법

위의 인터페이스 상속 방법과 상속 방법은 같은데
결국 형변환을 시킬때 C++ 컴파일러가 오프셋 계산을 훌륭하게 처리하느냐에 달려있다고 한다.
Visual C++ ATL(Active Template Library)도 이와 같은 상속 방법을 사용하여 COM 클래스를 구현한다.

클래스 팩토리의 구현

CoCreateInstacne ?() 함수를 호출하면 내부적으로 CoGetClassObject?() 함수를 호출하고 이때 레지스트리에서 해당 COM 객체의 정보를 찾아 CoLoadLibrary?() 함수를 호출하고 해당 COM 객체를 구현한 인-프로세스 서버DLL을 로드한다.

로드된 Dll로 부터 DllGetClassObject?()익스포트 함수를 호출하고 생성하고자 하는 COM 객체의 CLSID를

넘겨준다. DllGetObject?()함수에서 인수로 넘어온 CLSID값에 대응되는 클래스 팩토리 COM 객체의 인스턴스를 생성하고 클래스 팩토리 COM객체의 IClassFactory? 인터페이스 포인터를 구하여 리턴해준다.

CoGetClassObject?()로 넘어오고 다시 리턴하여 CoCreateInstance?() 함수로 돌아가서 IClassFactory?

클래스의 CreateInstance?()를 호출함으로써 COM 객체의 인스턴스를 생성하게 된다.

위의 내용에서 알수 있듯이 결국 클래스 팩토리란 IClassFactory? 인터페이스를 구현하는 COM 객체이다.

MIDL_INTERFACE("00000001-0000-0000-C000-000000000046")
IClassFactory? : public IUnknown
{

public:

virtual /*local

*/ HRESULT STDMETHODCALLTYPE CreateInstance

(/*unique

*/IUnknown *pUnkOuter

,/*in

*/REFIID riid, /*iid_is

out

*/void **ppvObject) = 0;
// pUnkOuter

는 반드시 NULL(뒤의 11장에 COM 컴포넌트 재사용에서 나온다.),

NULL이 아니면 CLASS_E_NOAGGREGATION의 반환값이 나온다.
// 만약 new 연산자를 통해 인스턴스 생성이 실패하게되면 E_OUTOFMEMORY를 반환하고

QueryInterface

() 메서드 호출이 실패하면 E_FAIL값을 반환한다.
virtual /*local

*/ HRESULT STDMETHODCALLTYPE LockServer

(/*in

*/BOOL fLock) = 0;

}

CreateInstance?() 메서드의 인자에는 CoCreateInstance?() COM 라이브러리 함수와 아주 유사한데

클라이언트가 생성하고자 하는 COM객체의CLSID가 매개변수로 전달되지는 않는다.
이 사실은 결국 클래스 팩토리는 생성되는 COM객체와 1:1 관계이라는 점이다.

제4장 인-프로세스 서버 COM 컴포넌트

DLLMain 함수

BOOL APIENTRY DllMain?(HINSTANCE hModule, DWORD dwReason, LPVOID lpReserved)
{

switch(dwReason)
{

case DLL_PROCESS_ATTACH:

case DLL_THREAD_ATTACH:

case DLL_THREAD_DETACH:

case DLL_PROCESS_DETACH: