WTL과 MFC, Win32를 비교하는 문서를 찾아보려고 인터넷을 검색했지만 한방에 정리해 놓고 있는 문서를 찾지 못했습니다. 해서 검색을 통해 찾아낸 몇가지 문서에 나와 있는 내용을 발췌/정리해 봤습니다.

위의 실행파일 크기 비교는 어떤 코드로 실험했느냐에 따라 구체적인 측정 수치는 매우 달라질 것이지만 대략의 우열을 Win32 > WTL >> MFC 으로 정리할 수 있을 것입니다. (MFC의 경우 두 문서 모두 static link로 빌드한 수치입니다.)

WTL for MFC Programmers, Part I - ATL GUI Classes에서는 WTL을 MFC와 비교해 장단점을 다음과 같이 적고 있습니다.

WTL은 마이크로소프트가 만든 MFC를 대체할 만한 우수한 라이브러리임에도 불구하고 공식지원을 하지 않는 것은 여기에 적혀있는데로 .Net을 밀기 위한 MS의 마케팅 전략이 아닐까 싶습니다. 이 때문에 WTL을 사용이 확산되지 않고 있다고 생각됩니다.

아무튼, WTL은 template 라이브러리로서 Win32의 장점인 경량(light-weight) 프로그램을 제작할 수 있고 MFC와 같이 풍부한 라이브러리를 제공(사실 MFC 만큼은 안되지만…)하므로서 생산성을 향상할 수 있습니다. 이 정도되면 WTL 안 쓸 이유 없을 것 같네요.

몇 개월간 윈도우 프로그램을 작성하는데 Win32 API만을 고집해서 사용해 봤습니다.

WTL/ATL, MFC등의 라이브러리를 사용하지 않고 Win32 만을 고집해서 사용했던 이유는

• 빠른 실행 성능을 갖는 데스크탑 어플리케이션을 작성하고
• 작은 바이너리 사이즈와 mfc*.dll등에 의존적이지 않은 어플리케이션을 작성하고
• WTL/ATL에 친숙해지기 위해 시간을 투자하기가 싫었고
• 라이브러리에서 커버하지 못하는 정밀한 제어를 위해서는 결국에는 어쩔 수 없이 Win32를 사용해야 한다고 생각했고
• 윈도우 프로그래밍과 시스템에 대한 이해를 보다 견고히 하고자 했기 때문이었습니다.

몇 개월간의 코딩작업 후 내린 결론은 이렇습니다.

Win32 API를 적당히 클래스로 래핑하고 유틸리티 클래스를 만드는 등, 많은 시간을 투입했던 작업들은 결국 MFC나 WTL/ATL이 만들어 놓은 것들을 다시 만드는 것에 불과했습니다. 물론 결과물의 퀄리티는 이들 라이브러리의 퀄리티를 넘어서기는 커녕 그에 훨씬 못 미치는 것이었습니다.

몇 개월간의 뻘짓 끝에 그동안 미뤄 두었던 WTL을 적극적으로 사용해 보겠다고 마음 먹었습니다.

비록 가상 PC 지만 난생 처음 제 PC에 리눅스를 설치했습니다.

리눅스 설치가 저의 컴퓨터 생활에 어떤 변화를 줄 수 있을지 기대가 됩니다.

STL 은 유니코드를 제대로 지원하지 않습니다. 그 대단한 STL의 옥의 티(엄청난 티)가 아닐 수 없습니다.

여기(Upgrading an STL-based application to use Unicode.) STL을 사용하는 어플리케이션에서 Unicode 를 지원하도록 업그래이드 하는 방법을 적어 놓았습니다. 보면 느끼시겠지만 참으로 구질한 일입니다.

사실 생각해보면 SBCS 언어권의 사람들이 Unicode 관심이나 있겠습니까… 자기네 프로그램 팔아볼 목적이 아니면… (문서의 작성자 이름을 보니 역시나 일본인이군요.)

Plug-in Architecture Framework for Beginners

플러그인이란 주 프로그램(host application)을 수정하지 않고도 주 프로그램의 기능을 수정하거나 추가기능을 제공하는 프로그램입니다. 많은 수의 소프트웨어들이 플러그인을 만들어 추가할 수 있도록 만들어져 있습니다. MS 오피스와 이클립스는 그 대표적인 예 중 하나입니다.

위 문서에서는 실제 프로페셔널 어플리케이션에 곧바로 적용해 사용하기에는 많은 부분이 부족하고 flat DLL을 사용하는 초보적인 수준이지만 플러그인 프래임웍을 어떻게 제공할 것인지 고민하는 개발자에게는 기초적인 아이디어를 얻을 수 있는 좋은 시작점이 될 것입니다.