前言
也许，你是一个顽固的SDK簇拥者；
也许，你对MFC抱着无比排斥的态度，甚至像我一样对它几乎一无所知；
也许，你符合上面两条，而且正在寻求着一种出路；
也许，你找到了一条出路——WTL，但是仍然为它的技术支持、它的上下兼容性感到担忧；
也许，你还有着更多的也许；
也许，这时候你看到了李马的这篇文章。
世界上的故事，往往就是由各种“也许”交织而成的。
我的转型
历史告诉我，在向别人推荐一样东西的时候，首先应该告诉别人你从中获益了多少，如是才能够使这一切更加具有说服力。比如我告诉你，我自从用了ATL之后，腰不酸了、腿不疼了、走路也有劲儿了，那么你没准儿就会对ATL产生些许的好感。是的，在《前言》的这一节里，我将以我自身的Win32 GUI程序设计经历来向你不遗余力地推荐ATL——因为我的这一系列连载就是以它为主题的。
2000年，我开始用Visual Basic学写Win32下（严格地说，当时的Windows 95并不能算是纯粹的Win32系统，它只是一个16/32位Windows的杂种）的程序。到了2001年，我开始厌倦它的运行库与运行效率，于是转投了Delphi。也许是Borland的粉丝不好做，也许是我厌倦了PASCAL的严谨，又也许是那种“真正的程序员用VC”的幼稚思想在作怪——总之，我又投向了VC。
一方面是我忒抠门儿，不舍得花钱买好书；另一方面，中国的MFC书籍琳琅满目鱼龙混杂而使我无法提起学习的兴致——反正不知道什么时候开始，我就开始强烈抵触MFC这个本无过错的Framework，而仅仅凭着杂志报纸上寥寥的几篇SDK文章和全英文的MSDN 6.0开始了我艰难的学习长征。所幸，这一路上虽然磕磕绊绊，但最终我还是到达了属于我的陕北。如果您于此期间曾经在网上或其它媒体上看到过我的Win32技术文章，就应该会发现这其中我极少涉猎MFC的任何内容——我不否认我对它存在着狭隘的偏见，虽然我在2005年完成的毕业设计是用MFC编写的。
SDK终究不是一个让人舒适的归宿，我想SDK的粉丝们都应该有着深深的体会。哪怕是你的代码增加到1000行，你都会觉得维护这些东西的难度非常之大——臃肿、堆砌、全局、耦合、复用性差——有太多丑陋的词语都可以用在这上面。是的，我的确说过我不喜欢MFC，但是我也同样不能否认用MFC编写的程序结构清楚、分流明晰——当然，如果你不是深入到MFC内部去看的话。举个例子来说，我所编写的进程查看器July的2.11版本就是用SDK编写的（这个版本是开源的），才1000行出头的代码就已经使得我难以驾驭它们了，以致于后来我不止一次地想重写之——我想过用MFC，甚至Delphi的VCL。不过，运行库的限制和庞大的EXE体积还是使我放弃了这些想法。
如果说MFC和VCL是生长在深宫名门的大家闺秀，那么WTL就可以算是一位浪迹天涯的绝色歌女。我在2004年的时候，曾与它不经意地邂逅。精良的设计、轻巧的EXE、无与伦比的效率——如果不是它的兼容性存在问题的话（如果不修改的话，WTL 7.1连它自己附带的某几个sample都无法通过编译），我几乎就要拜倒在它的石榴裙下了。
于是我继续迷茫，这种迷茫一直持续到了2005年我毕业之后。2005年8月的时候，为了研究不借助MFC调用ActiveX控件的技术，我接触了WTL的发端——为开发COM组件而设计的ATL。时至今日我似乎已经无法回忆起当时的景况，只记得一个月之后，用ATL重写的July v2.20就诞生了。
比起大家闺秀和绝色歌女，ATL则更像是一位温柔贤惠的朴实女子。
对症下药
说归说，ATL终究不是万灵之药。它是否适合你，且看你是否已经存在以下病症（当然，我也为你列出了其它可选药物）：
看重程序独立性，不喜欢程序运行库。显然，.net和Visual Basic都不适合你。除ATL外，你还可以选择VCL、MFC（静态链接），当然还有WTL。
看重程序效率。Visual Basic绝对不适合你。由于VCL与MFC内部会为窗口控件维护对象链，所以可能也不适合你。在这一方面，ATL和WTL会是不错的选择。
看重EXE的大小。没的说，VCL和静态链接的MFC不能列入你的选择，ATL和WTL仍是最佳选择。当然，如果你不计较Windows自己捆绑的MFC运行库的话，MFC动态链接也可以。
你不得不在没有MFC的Windows环境下编写代码。有这样的环境吗？也许你要问。是的，Smartphone 2003正是这样一个环境。ATL是你最佳的选择，当然你还可以选择.net Compact Framework。
此外，你需要做好准备迎接以下这些使用了ATL以后可能带来的并发症：
向导支持较少。可以说，VC的IDE就是完全为MFC程序设计准备的。它为ATL的支持甚少，似乎只有几个窗口消息处理器可以用。所以，有很多的消息映射可能需要你自己手工完成。
技术支持有限。毕竟ATL是为COM组件开发准备的，所以关于用ATL进行GUI开发的资料非常少，除了MSDN上的说明和网上寥寥的几篇文章之外，似乎就很难找到了。
最后，我为你列出ATL较之WTL更优秀的几点：
代码兼容性强。比如VC6.0写出的代码在大多数情况下（我暂未遇到少数情况）都可以不经修改地在VS2003下编译运行。
消息分流简单。我是前说过，VC对ATL的向导支持是很有限的。这样一来，WTL丰富的消息分流反而成了累赘。如果你用WTL写过程序，相信你会有相同的感觉——手工编写那批多种多样消息处理函数并不是一件轻松的事情。
当然，我本人对WTL并没有偏见，但WTL的不为官方所支持也是它自身不争的一个事实。相信还有很多人对WTL的官方化望眼欲穿，然而他们还是迟迟不能如愿。如果WTL真有那么一天（我也认为肯定会有那么一天），关于代码兼容性、向导支持、技术支持的这些问题都将不会是问题。
关于本系列连载
《ATL的GUI程序设计》这一系列的文章是李马为ATL/WTL之间的矛盾而做出的一个折中，也是李马在2006年为大家献上的一份礼物，希望大家能够喜欢，也希望它们能够成为大家迈入WTL之门的引领者。
阅读本系列文章有两个先决条件：第一，你需要了解C++的模板技术，因为ATL的技术基础就是建构于模板之上的；第二，你需要了解Win32 SDK程序设计，这方面的经典教材是Charles Petzold的《Programming Windows》（中译《Windows程序设计》），有关这方面的基础知识我在本系列文章中不再进行任何解释。
本系列文章将会介绍如何使用ATL进行Win32的GUI程序设计方法，包括ATL的GUI基础使用方法、高级主题以及对ATL的扩展。此外，本系列文章还会对ATL/WTL的某些关键实现技术进行解说，这些内容的理解与否并不影响使用ATL进行GUI程序设计，你可以根据个人情况来选择阅读。
本系列文章中所有附带的源代码都是在Visual C++ 6.0 sp4和Visual Studio 2003.net上编译通过的，但主要环境仍然基于VC6.0之上，VS2003则只供验证之用。
就这样了！我谨用一句呼应开头的话来结束这段稍嫌冗长的开场白：
——也许，认识ATL之后，以前的“也许”将不再是“也许”……
李马 2006年1月10日于京师海淀
