나의 COM(Component Object Model) 경험담 #9
저의 글을 누군가가 기다리고 있다는 것은 참으로 기분 좋은 일입니다.
하지만, 그만큼 부담되는 일이기도 합니다. 친구에게 컴포넌트에 대한 궁금한 사항을 물어 볼 때마다 프로그래머의 한계를 느낍니다. 과연 프로그래머가 밑바닥까지 원리를 알 필요가 있을까? 라고 반문하고는 합니다. 하지만, 가장 큰 문제는 COM 관련서적을 봐도 이해를 할 수가 없었다는 겁니다. 도대체가 무슨 말인지 이건 또 뭐야? 도저히 알 수 없는 말들 뿐이 라는 것이 가장 큰 문제점이었습니다. COM을 처음 접하시는 분들 대부분이 저와 같은 경험 을 하셨을 거라고 생각합니다. 기본 원리를 모르는 상태에서 또는 이 말뜻을 모르고서는 책 을 읽어가면서 코딩을 하는 것이 아무런 플러스가 되지 않았죠. 오히려 시간만 축내는 결과 를 가져오죠. 제가 하는 내용의 가장 큰 중점은 COM을 알고자 하는 것이 아닙니다. 여러분 이 공부할 때 조금이라도 책을 이해하는데 도움이 되었으면 하는 겁니다. 제가 COM을 자 세히 다루면 얼마나 자세히 다루겠습니까? 코딩을 하면 얼마나 잘 할 수 있겠습니까? 대충 제 말뜻 아시겠죠?
그리고, 많은 분들께서 책의 내용보다는 이해할 수 있는 심층(?)적인 부분을 요구 하셨습니 다. 저 역시 일반적인 코딩방법이 적힌 책은 지루합니다. 제가 깊은 부분까지는 알지 못하 지만, 제가 아는 부분에 한해서는 최대한 자세히라기 보다는 쉽게 설명하려고 합니다. (사실, 쥐뿔도 모릅니다. 눈치 채신 분들도 이제는 많아 지셨습니다. 들키기 전에 그만 뒀어야 했 는데. 이미지 관리는 제 체질이 아닌가 봅니다.)
그럼 시작하겠습니다.
이제 몇 가지만 더 공부하면 COM의 기초는 대충 끝이 날 것이다. 그 다음은 COM+로 넘 어가야 한다. 사실, COM에서 COM+을 빼고 말한다는 자체가 우스운 일이다. 왜 그런지를 생각해 보았는가? COM 컴포넌트를 왜 만들고 있는가? 결국 모듈화가 가장 큰 목적이었다.
하지만, 이것은 기존의 DLL 이라던가 소스차원에서도 충분히 가능한 일이 아니었는가?
지금의 컴퓨팅환경은 예전과 많이 틀려졌다. 로컬에서만 돌아가는 프로그램은 의미가 없어 졌다는 얘기도 된다. 앞으로의 프로그래밍 방향은 인터넷환경과 네트웍환경을 빼놓고는 빈 껍데기에 불과하다. 즉, 분산환경이 그만큼 중요해졌다는 말이다. COM의 한 부분을 차지하 고 있는 ActiveX가 그렇고 DCOM 역시 분산환경을 빼놓고는 말하는 것이 불가능하다.
COM+ 역시 COM을 좀더 잘 활용해 보려는 의도에서 나온 것이다. 아직 확실한 결정이 나 온 것은 아니지만, COM을 #10쯤에서 끝낼 생각이다. 그리고 새롭게 COM+에 대해 #1에서 다시 시작하려고 한다. 물론 COM에서 나왔던 얘기가 반 이상이 되지 않을까 생각한다. 거 기서 COM에서 부족했던 내용을 보완할까 생각중이다. 그것이 끝나면 다시 .NET에서는 컴 포넌트의 발전 방향이 어떻게 흘러가는 지 할 예정이다. 현재의 내 실력으로는 어림도 없는 일이란 것을 난 잘 알고 있다. 하지만, 한번도 해보질 않은 사람과 이제 시작하려는 사람에 게는 조금은 도움이 될 것이라는 것이 내 생각이다. #10은 너무 내용이 모자란다고 생각하 는 사람이 있을 것이다. 하지만, COM+에서 부족한 부분을 다룰 예정이니 시간을 가지고 천 천히 지켜 봐주길 바란다. (‘COM+를 하지 않고서는 COM을 하는 의미가 없다’라고 자신 있 게 말할 수 있을 것 같다)
그건 그렇고 오늘 할 것에 대해 해야 한다.
오늘은 IDispatch 인터페이스와 스래딩 방법에 대해 알아보려고 한다. 역시 개념상 어려운 부분이다. IDispatch는 자동화, 즉, 오토메이션과 직접적인 관련이 있는 인터페이스이다. 한 번쯤은 다들 들어 봤을 것이다. 나 역시 이 부분을 수도 없이 들어왔다. 하지만, 이것을 이 해 한다는 것은 정말 힘든 부분이었던 걸로 기억한다. 그리고 나머지 한가지인 아파트먼트.
이것도 귀에 딱지가 앉을 만큼 들어 봤으리라 생각한다. 하지만, 이것 역시 뭘 하는 놈인지 알 길이 없다. 급하게 생각하지 말자. 천천히 생각해 보면 답이 나올 것이다.
오토메이션. 너무 막연하지 않은가? 자동화라고 번역해도 막연하기는 마찬가지 이다. 그럼 우리가 알고 있는 오토메이션은 무엇인가? 예전에 OLE 자동화라고도 불리었다. 직관적인 정의를 보면, 자동화는 한 어플리케이션에서 다른 어플리케이션을 구동 시키는 것으로 클라 이언트와 서버가 서로 자동적으로 통신을 하며 실행되는 방법이다.
여기서도 서버와 클라이언트 개념이 존재한다. 자 한번 보자. 자동화 클라이언트는 자동화 컨트롤러라고도 불리우며 다른 어플리케이션의 객체를 이용하는 어플리케이션이다.
자동화 서버 또는 자동화 컴포넌트는 자신의 객체를 제공해 주는 어플리케이션이다. 엄밀히 말하면 서비스를 제공해주는 어플리케이션이라고 해야 할 것 같다. 예를 들면 워드에서 액 셀 시트를 끌어와서 워드의 한 기능인양 쓰는 것이 예가 될 것 같다.
그리고 자동화 서버는 메서드, 속성, 이벤트 이 세가지 형태로 자동화 클라이언트에게 기능 을 제공하는데, 이것은 비주얼 베이직에서 일반적으로 사용하는 ActiveX 컨트롤과 틀리지 않다. 예를 들어 어떤 차트를 보여주는 컨트롤이 있다고 하자. 그 차트컨트롤에는 값을 계 산해주는 메서드가 있을 것이고 차트를 보여주는 여부를 결정하는 visible 속성이 있을 것이 다. 그리고 마우스가 클릭 되거나 값이 변경되었다는 이벤트등이 있을 수 있다.
좀더 세부적으로 살펴보자. 오토메이션을 알기 위해서 다시 COM에 대해 알고 넘어가야 할 문제점들이 몇 가지 있다. 도대체 COM 개체가 무엇인가? 개체 또는 오브젝트. 일종의 추상 화로 데이터와 메서드를 포함하는 것이라고 C++ 또는 OOP에서 들어 봤을 것이다. COM 개 체 역시 마찬가지이다. 데이터는 개체에 의해 메모리에 저장된 정보이고, 메서드는 그 개체 가 서비스를 제공해주는 코드이다. 단지, COM 개체에서는 이 메서드들을 인터페이스란 놈 으로 그룹화를 지어 놓았다는 것이 특징이라면 특징일 것이다. 최소한 COM 개체는 IUnknown 인터페이스 하나는 가지고 있을 것이다. 그렇다고 이것 하나만 가지고 있는 COM 개체는 아무짝에도 쓸모가 없다. 아무런 서비스도 제공하지 않는 놈을 어디다가 써먹 겠는가? 이 놈은 아마 메모리 공간만 차지하는 식충이와 같을 거다. 여기서 잠시 깊게 생각 해보자. COM 개체는 여러 클라이언트들이 연결 될 수 있다. 그 클라이언트들은 COM 개체 의 특정 인터페이스의 메서드를 요청할 것이고 그렇게 하기 위해서는 클라이언트들이 COM 개체의 인터페이스 포인터를 알아야만 한다. 여기서 문제점이 발생한다. COM 개체와 클라 이언트가 같은 언어로 만들어졌다면 클라이언트는 COM 개체의 사용방법을 쉽게 알 것이다.
하지만, COM 이란 놈이 언어 독립적으로 만들어지지 않았는가. 결국 다른 언어에서도 접근 할 수 있는 방법을 제공해야만 했다. 알다시피, COM 인터페이스는 가상메서드테이블과 일 맥상통하는 말임을 COM을 조금 공부해본 사람이라면 누구나 알 것이다. 일반적으로 우리 는 vtable 또는 vtable이라고 한다. 그럼 인터페이스는 모두가 vtable 인터페이스인가? 그렇 지는 않다. 바로 우리가 여기서 해야 할 dispatch 인터페이스란 놈이 또 있는 것이다.(여기 서 우리는 IDispatch 인터페이스와 연관 된 놈임을 연상할 수 있다.) 왜 이 놈이 생겼을까?
그 이유가 바로 가상메서드테이블을 지원하는 않는 언어들이 있었기 때문이었다. 예를 들면 예전의 비주얼 베이직 같은 언어가 그러하다. 하지만, 요즘은 이것도 지원하는 것으로 알고 있다.(내가 비주얼 베이직을 잘 모르기 때문에 오류가 있을 수도 있다. 하지만, 마이크로소 프트에서 말하는 것이니, 아마도 맞을 것이다.) 그렇다고 이 dispatch 인터페이스가 필요 없 어진 것은 아니다. 여전히 비주얼베이직 스크립트 언어라던지 자바스크립트언어에서는 필요 로 한다.
dispatch 인터페이스는 일반적으로 디스핀터페이스(dispinterface)라고 불리기도 한다. 그럼 여기서 다시 한번 생각해보자. C++에서의 문자열과 비주얼 베이직에서의 문자열 처리 방식 은 다를 것이다. 그리고 다른 데이터 타입역시 처리 방법에서 미묘한 차이가 있을 거라 생 각한다. 그런데 이 가상메서드 테이블에 있는 메서드들의 변수 유형을 어떻게 맘대로 사용 할 수 있겠는가? 결국 이 문제를 해결하기 위해 dispinterface 란 놈을 만들었고, 이 dispinterface를 사용하는 것을 오토메이션이라고 한다. 그럼 우리는 dispinterface 에서 공통
적으로 쓰이는 매개변수를 정할 필요가 생겼다. 비주얼 베이직에서도 무리 없이 쓸 수 있게 말이다. 그래서 나온 것이 variant 라는 유형이고 이걸 사용하면 해결이 될 것이다. 이런 결 론이 나온 것이다. Variant 라는 데이터형을 잘 모르는 사람도 있을 것 같다. 비주얼 베이직 을 사용하는 사람은 대부분 아주 편리하게 사용하고 있을 거라 생각한다. 데이터 형에 신경 쓸 필요 없이 variant라고 선언하면 데이터 형은 비주얼 베이직에 의해 알아서 적절하게 데 이터의 포멧이 해석되기 때문이다. 결국 언어 때문에 생긴 거였음을 우리는 알았다.
자, 대충 이 IDispatch 인터페이스가 왜 필요한지 알아봤다.
그럼 여기서 인터페이스의 종류가 vtable 인터페이스와 dispatch 인터페이스 이 두 종류만 있는 것인가? 그렇지가 않다. 이 두 가지의 메모리 구조를 조합한 이중 인터페이스가 그것 이다. 인터페이스의 종류를 앞에서는 표준 인터페이스랑 커스텀 인터페이스로 나눴는데, 이 건 또 뭐야 하는 사람도 있을 것 같다. 이건 단지 나누는 방법의 문제가 아닐까 싶다. (한번 생각해 보던지 아니면 앞의 강좌를 참조하면 되겠다.)
이 이중인터페이스의 경우는 비주얼 베이직에서 만든 COM 개체의 경우 기본적으로 이중 인터페이스를 사용해서 메서드를 제공한다고 한다. 그럼 이중인터페이스가 나온 배경도 살 펴보자. 자동화 개체를 구현하기 위해서는 dispatch 인터페이스를 사용해야 한다. 하지만 이 방법은 C++ 과 같이 인터페이스에 직접 접근할 수 있는 언어 입장에서는 오히려 실행속도 가 늦어지는 단점을 가진다. 이유는 간단하다. 나중에 하겠지만, IDispatch 인터페이스의 Invoke 메서드를 통해 자동화를 지원하는 메서드에 접근하기 때문이다. 이것으로 메서드 호 출과정이 두 세단계는 더 늘어나기 때문이다. 그래서 마이크로 소프트에서는 C++ 같이 인 터페이스에 직접 접근이 가능한 언어를 위해서 IDispatch 인터페이스에서 상속받아 만든 인 터페이스를 같이 노출시킬 것을 권장하였다. 그러면 비주얼 베이직 스크립트 언어는 dispatch 인터페이스를 총해 자동화 개체의 메서드에 접근하고 C++ 같은 언어는 커스텀 인 터페이스로 바로 접근할 수 있게 된다.
지금까지 대충 어떻게 해서 dispatch 인터페이스가 필요하게 되었고 단점도 조금은 알아봤 다. 그럼 본격적으로 IDispatch 의 내부 메서드들를 디비보자.
IDispatch 인터페이스에는 기본적으로 4개의 메서드가 추가되어 있다.
GetTypeInfoCount, GetTypeInfo, GetIDsOfNames, Invoke 이렇게 4개이다. 당연히 이것도 IUnknow 에서 상속받았으니 QueryInterface, AddRef, Release가 포함 되어있는 것은 자명한 일일테구.
사실 이 네 개의 메서드를 구현하는 것은 생각보다 복잡하다. Invoke 메서드를 알겠지만, 인 자도 매우 복잡하다. 그래서 COM에서는 IDispatch 인터페이스의 헬퍼메서드들을 제공한다.
DispGetIDsOfNames, DispGetParam, DispInvoke, CreateStdDispatch, CreateDispTypeInfo 메 서드등등이다. 일단 여기에 대해서는 언급하지 않겠다. 왜냐하면 이부분 역시 책에 자세히 설명 되어 있고 우리가 오늘 할 IDispatch를 알아보는 것과는 직접 관련이 없다고 생각하기 때문이다.
그럼 각각의 IDispatch인터페이스의 메서드가 하는 역할은 무엇일까?
먼저 GetTypeInfoCount 메서드를 알아보자. 이 메서드는 개체에 대한 타입 정보가 있는지 알아온다. 타입정보를 제공한다면 1을 그렇지 않으면 0을 리턴하도록 한다. 그리고, GetTypeInfo 메서드에서 타입정보로의 포인터를 리턴한다. 즉, 인터페이스에 대한 타입정보 를 얻을 때 사용하는 메서드이다. 타입정보만 얻어오면 게임오버가 아닌가? 타입정보에 메 서드의 정보가 다 나와 있기 때문이다. 하지만, 실제로 중요한 메서드는 GetIDsOfNames 메 서드와 Invoke 메서드가 되겠다. GetIDsOfNames 메서드는 특정 메서드나 속성 이름에 대응 되는 DISPID라는 값을 얻어온다. 그러면 Invoke 메서드에서 해당 코드를 실행하게 할 수 있다. 여기서 메서드가 아닌 속성(Property)이란 말이 나왔다. 여기에 대해 잠시 알아보자.
COM 인터페이스는 메서드의 그룹화라고 할 수 있었다. 그리고 데이터 멤버를 설정하고 값 을 얻어오기 위해 우리는 일반적으로 Set 또는 Get으로 시작되는 메서드를 사용한다. 하지 만 비주얼 베이직에서는 이런식으로 하지 않는다. 그냥 바로 값을 넣는 방법을 사용한다.
예를 들면, m_edit.width = 100 이런식으로 될 것이다. C++ 이라면 m_edit.SetWidth(100) 라 는 메서드를 사용하겠지만 말이다.
IDL에서 이 메서드를 속성으로 취급하는 방식을 가지고 있다. IDispatch를 위해 만든 것이다.
속성을 정의 하는 IDL의 간단한 예를 보자.
Interface Iobject : IDispatch {
[propput]
HRESULT Prop ([in] VARIANT_BOOL bValue) [propget]
HRESULT Prop ([out, retval] VARIANT_BOOL *bValue);
}
대충 보면 알 듯 싶다. [in]은 Set_ 이런 함수의 역할 일 것이고 [out]은 Get_ 이런 함수의 역할을 할 것이라는 걸 충분히 짐작할 수 있다.
자. 지금까지 내가 개념위주로 설명하긴 했지만, 코드역시 조금은 포함이 되어 있었다. 그리 고 인프로세스 서버만 중점적으로 다룬 것을 눈치 채신 분들도 있을 것이다. 왜 로컬과 원 격서버를 자세히 다루지 않았을까 라고 의심하는 분들도 계시리라 생각한다. 조금은 개인적 인 생각이긴 하지만 내 생각엔 앞으로 대부분의 COM 컴포넌트는 DLL 인 인프로세스 서버 로 구현될 것 같다. COM+ 에서 자세히 보면 알게 되겠지만, 인프로세스라고 해서 원격이나 로컬에서 실행되지 못할 이유가 없는 것이다. COM+에서 알아서 해주기 때문에 이제는 어디 에 쓰일지 미리 예상하고 거기에 맞게 구현할 필요가 없다는 말이다. 잘 생각해보면 왜 이 런 생각이 나왔는지 알 수 있다. DLL로 구현하면 다 쓸 수 있다. 하지만, EXE로 만들 경우
는 분리된 프로세스에서만 실행 될 수 밖에 없을 것이 아닌가? 물론, 원론적인 COM의 이 해를 위해서는 모두 해야 할 것이다. 하지만, 대충 봐서 알겠지만, COM 자체 구현의 차이점 은 없었다는 것도 봤을 것이다. 단지 부가적인 DLL 모듈을 작성할 것인가? 아니면 실행 모 듈을 작성할 것인가의 차이었지, COM 인터페이스를 선언하고 메서드를 구현하는 것에는 차 이가 없었다는 얘기이다. 그냥 내 생각은 이렇다. 한가지만 알아도 다 되는데, 굳이 다 할 필요가 있을까 라는 의미였다. 큰 차이점이 있는 것도 아니고 말이다. (그래도 하고 싶다면 말리진 않겠다.)
마지막으로 스래딩방법이다. 먼저 이것을 하기 전에 아파트먼트라는 단어에 익숙해져야 한 다. ‘아파트먼트’ 라는 말은 우리가 일반적으로 쓰는 우리가 살고 있는 아파트라고 불리는 영 문식 표기이다. 그런데 이게 또 COM 이랑 무슨 상관인가? 난 아무리 생각해도 아파트먼트 랑 별 상관이 없는 것 같다. 다른 좋은 말들을 놔두고 왜 하필 헷갈리게 아파트먼트인가?
아무리 연관 지어서 생각하려고 해도 만만치가 않았다. 그래도 이해하려면 억지로 끼워 맞 춰서라도 이해해야 한다. 가장 황당한 부분이 아닌가 싶다.
아파트먼트는 일반적으로 STA(SingleThreaded Apartment)와 MTA(MuitiThreaded Apartment) 두 가지로 나뉜다. 그런데 요즘은 NA(neutral apartment)(TNA(threadneutral apartment)라고 도 불린다)가 추가되었다. 아마도 이 NA가 앞으로는 표준이 되지 않을까 생각해본다.
그럼 세부적으로 알아보자.
프로세스는 하나 또는 이 이상의 STA를 가질 수 있는데, 그럼 이 STA가 도대체 무엇인가?
해석하면 단일 스래드 아파트먼트이다. 잠시 우리는 여기서 아파트먼트를 하나의 공간으로 생각해보자.(사실, 공간은 아니다.) 일단, STA 에는 실행 스래드를 하나만 가질 수 있다. 하 지만, 하나의 프로세스가 여러 개의 STA를 가지는 것이 가능하기 때문에 동시에 여러 메서 드를 호출하는 것도 가능은 할 것이다. 그리고, 이 호출은 윈도우 메시지 큐를 사용하기 때 문에 자동으로 동기화 되고 디스패치된다. (여기서 주의 할 점이 있다. 인프로세스 서버의 경우 윈도우가 메시지 처리를 하기 때문에 메시지 루프를 가질 필요가 없다.) 쉽게 말하자 면, STA는 여러 개의 COM 개체를 관리할 수도 있고 하나만 관리 할 수도 있다. 하지만, 한 번에 실행은 한 놈만 실행 시킨다는 것이다. 이번엔 너의 메서드를 호출해 주도록 하지, 담 엔 너, 담엔 너 이런 식으로 말이다.
두번째인 MTA 의 경우는 대충 예감할 수 있을 것이다. 하나의 프로세스는 단 하나의 MTA 만 가질 수 있다. MTA 역시 STA와 마찬가지로 여러 개의 COM을 가질 수 있다. 대신 동시 에 여러 개의 메서드 호출을 처리할 수 있는 장점이 있다. 하지만, STA 처럼 동기화에 신경 쓸 필요가 없는 것이 아니기 때문에 동기화 개체들을 사용해서 직접 동기화를 제공해야 한 다. 대신 퍼포먼스가 뛰어나다는 장점이 있다. 아무래도 STA를 여러 개 사용할 경우 생기는 여러 개의 동시작업으로 인한 스래드 컨택스트 스위칭이 줄어들기 때문이 아닐까라고 생각 한다.
이 부분의 자세한 내용은 책을 참조하기 바란다. 책이 기술적으로 훨씬 자세하게 설명되어 있다. 내가 할 말은 이 아파트먼트를 일종의 스래드 모델로 이해하기 바란다는 거다. 이때 는 이런 방법으로 운영하면 좋을 것이다. 또는 이럴 때는 이렇게 하는 것이 퍼포먼스가 뛰 어 날것이다. 이런 것만 알면 된다. COM 컴포넌트 하나 달랑 쓰는데 MTA 쓰는 것도 무식 한 짓이고, 대용량 서버에 몇 만대의 클라이언트가 붙는데 여기서 STA를 쓰는 것도 무식한 짓이다. 대충 개념만 알고 적절하게 선택만 해주면 나머지는 COM 이 알아서 해준다.
참고로, 비주얼 베이직의 경우 STA로만 프로그래밍이 가능하다. 여기서 우리는 높은 퍼포먼 스를 위해 MTA나 NA를 써야 하는데 COM 개체 작성에서 왜 C++을 써야 하는 지 알 수 있다. 이밖에도 C++에서만 제공할 수 있는 세부적인 사항들이 많다. 이런 점들 때문에 COM 의 최고의 언어로 C++을 꼽는 이유이다.
오늘은 여기서 마치겠다. 막판에 오니깐 빨리 끝내고 싶은 맘이 굴뚝 같아 진다. 이 글을 읽는 분들께는 미안하지만, 왠지 COM+에서 새로운 맘으로 더 좋은 글을 쓰고 싶기에 여기 서는 조금의 미완성으로 남기고 싶다.
그럼 다음강좌에서 보자.
다음이 COM의 마지막이 될 듯 싶습니다. 혹시나 모자라면 더할 지는 모르겠지만, #10에서 는 지금 까지 나온 용어들과 개념을 총정리 할 생각합니다. 이정도 개념만 알면 책 보는데
는 지장 없겠지 하는 정도가 될 것 같습니다.
오늘 하루도 많이 애 쓰셨습니다. 특히나 오늘은 더 어렵죠? ^^;
그리고 잡담입니다.
점점 IT 쪽 상황이 어려워 지고 있습니다. 정확히 말하면 일반 어플리케이션으로 패키지를 만들어서는 회사 존립 자체가 어려워 지고 있습니다. 웹도 이제는 서비스 개념이 아니면 힘 들어 집니다. 옛날 홈페이지 구축해주고 돈 버는 시대는 갔습니다. 얼마 하지도 않습니다.
인건비 겨우 빠집니다. 일반 패키지 만들어도 돈 주고 사는 사람도 없습니다. 돈을 벌려면 회사를 상대로 상품을 팔아야 합니다. 개인 사용자가 얼마나 돈이 있겠습니까? 그리고 불법 복제가 몸에 벤 사람들입니다. 저 역시 마찬가지 이지만, 집에서 쓰는 제품들 중에 정품이 얼마나 될까요? 몇Copy 팔지 않더라도 비싸게 파는 것이 훨씬 개발자에겐 편하고 이득도 클 겁니다. 새로운 아이디어도 점점 찾기 힘들어 집니다. 회사 입장에서는 개발 시간이 길 어지는 프로젝트는 꺼려 할 겁니다. 일반 API로 프로그래밍을 한다는 것도 이제는 조금은 지양해야 합니다. 시간 많이 걸리죠. 노력 많이 필요하죠. 이걸 기초라고 생각하시는 분들이 많이 계십니다. 하지만 전 그렇게 생각하지 않습니다. API가 왜 기초입니까? 돌아가는 내부 구조 역시 모르는 것은 마찬가지입니다. 정말 기초는 리눅스 커널 분석하면서 새로 API를 만드는 것이 기초입니다. 어차피 이런 거 안 할 거라면 COM으로 편하게 작업하는 것이 낫 지 않을까요? 마이크로소프트도 이제는 API 가 아닌 COM 하나 던져주고 이걸로 짜면 돼 라고 말합니다. 이제 말 안 해도 제 말뜻 아시리라 생각합니다. 한번쯤 고민해보시길 권장 합니다. 커피 한잔 마시면서 또는 담배 한대 피면서 말이죠.
그럼 오늘하루도 즐겁게 ^^
email : icoddy@hotmail.com msn id : icoddy@hotmail.com
박성규
