BOOL WINAPI DisableThreadLibraryCalls(
  __in  HMODULE hModule
);

Disables the DLL_THREAD_ATTACH and DLL_THREAD_DETACH notifications for the specified dynamic-link library (DLL). This can reduce the size of the working set for some applications.

禁用指定的DLL的DLL_THREAD_ATTACH和DLL_THREAD_DETACH通知，这样可以减小某些程序的工作集大小。

Remarks:

The DisableThreadLibraryCalls function lets a DLL disable the DLL_THREAD_ATTACH and DLL_THREAD_DETACH notification calls. This can be a useful optimization for multithreaded applications that have many DLLs, frequently create and delete threads, and whose DLLs do not need these thread-level notifications of attachment/detachment. A remote procedure call (RPC) server application is an example of such an application. In these sorts of applications, DLL initialization routines often remain in memory to service DLL_THREAD_ATTACH and DLL_THREAD_DETACH notifications. By disabling the notifications, the DLL initialization code is not paged in because a thread is created or deleted, thus reducing the size of the application's working code set. To implement the optimization, modify a DLL's DLL_PROCESS_ATTACH code to call DisableThreadLibraryCalls.

该函数禁用一个DLL的DLL_THREAD_ATTACH和DLL_THREAD_DETACH通知。这对于那些经常创建和删除线程的调用很多 DLL的多线程程序是一个很有用的选项。如果这些DLL并不需要这些线程级的attachment/detachment通知。远程过程调用服务程序就是 一个例子。在这些程序里，DLL的初始化代码经常留在物理内存里，以相应DLL_THREAD_ATTACH和DLL_THREAD_DETACH通知。 通过禁用这些通知，DLL的初始化代码不会由于线程的创建和删除被换页至物理内存，这样就可以减小工作代码集的大小。要实现这个选项，可以在响应 DLL_PROCESS_ATTACH通知的时候调用DisableThreadLibraryCalls

这个隐隐的痛处，就是在GUI编程领域。

现有的大部分成熟GUI框架和工具库，其定型时间都在90年代早期，不管是因为什么原因，总之我们根本看不到template技术在这些环境中的任何重要运用。无论是专有MFC和OWL，还是开源的wxWindow和Mozilla, 以至于是专有还是开源都说不清楚的Qt，它们在其他方面有着诸多不同，偏偏倒是在对待模板技术上空前一致：严格限制在底层的数据结构领域内，抵制模板技术流入GUI主体结构。最过分的wxWindow和Mozilla，在代码编写规范里严厉禁止使用1990年之后发展出来的任何C++特性，模板、异常、多继承、STL等等，均在黑名单上。诸位有兴趣，不妨去看看，那与其说是一份C++代码编写规范，倒不如说是对C++现代特性在GUI领域应用的一份不公正的判决书。

难道模板技术真的在GUI领域无用武之地吗？

WTL给出了一个响亮的回答。

WTL是微软 ATL开发组成员Nenad Stefanovic先生在ATL Windowing机制上发展起来的一整套GUI框架，运用template技术组织和创建GUI对象，构筑了精致的面向对象框架（没错，在这里 object oriented与template达成了精致的融合）。虽然没有获得微软的官方支持，虽然其使用者人数很少，但是确实是“用过的都说好”，有位微软 MVP人士甚至说，这是微软有史以来推出的最优秀的一个framework。真是一个有趣的讽刺，最好的东西居然不被官方支持。有关于WTL的流言不少，比如这东西原本是微软内部专用，只是因为不小心才被泄漏出来等等，这更加剧它的神秘色彩。相信大家对它一定有不少问题。我们特别邀请到了WTL之父 Nenad Stefanovic先生，进行了一次网上的访谈，希望能帮助大家了解WTL的真面目。

【C++ View】：我想，可能我们的读者中有很多人对您还不是很熟悉，您能不能在此给我们简单介绍一下您自己呢？我们将非常乐意听到您的自述。还有，您能不能也对我们讲述一下您对于中国以及中国人民的基本看法呢？

【Nenad】：好的。我现在在Microsoft工作，是它里面的一个软件开发人员。你们杂志的读者中可能有人知道，我就是Windows Template Library （WTL）的创作者。我来自于前南斯拉夫，在那我完成了我的学业并开始了我作为软件开发人员的工作生涯。现在，我在美国居住的时间已经超过了10年了。
中国的文化以及传统给我留下了极为深刻的印象，我对此十分感兴趣。我想，作为一个国家以及民族，中国已经处于一个伟大并且不断在成长中的位置上。作为一个从前南斯拉夫来的人，我早就了解到关于中国的很多事情。在与来自中国的人民的接触过程中，我还了解到了你们日常生活的一些状况。我还想了解更多（有关中国的事情），希望有一天我可以到中国来游览。

【C++ View】：您是什么时候开始想起要开发WTL呢？为什么？您在开发它时的最初目的是什么？您又是如何地看待它未来的发展呢？

【Nenad】：WTL是我在从事ATL （Active Template Library）开发工作时的产物。那时我们正在扩展ATL，使之得以支持ActiveX control，而我负责的就是其中对于窗口机制部分的支持。这时，我就开始想，是不是可以把同样的技术应用到更为广泛的窗口机制中，以获得更丰富的UI 控制、组件、以至于应用程序呢？于是，作为ATL的一部分，WTL被开发出来了。它将ATL进行了扩展，以使得它可以支持各种类型的与UI相关的组件或者应用程序。然而，它并没有随着ATL一同集成在Visual Studio中被发布，于是我就决定将它作为一个单独的ATL扩展库发布出去。
我认为WTL将一直是那些在Windows下开发应用程序以及组件的开发者的一个很好的选择。我并不认为在以后，我们会对WTL有一个大的改动（或者增添），因为WTL的一个设计宗旨就是“遵循Win32 UI的API及其设计”。现在如此，将来还是会如此下去。

【C++ View】：我第一次接触WTL是在2000年7月。在那时，我就想：“没有官方的支持，没有文档，也没有商业吹捧，它最多只能够存活6个月。”但现在 15个月过去了，它反而流传得更为广泛，更加的生机勃勃。许多C++程序员，尤其是一些我们所认知的“专家”以及“大师”，都在使用WTL。我当然知道这主要是因为WTL的出色，但我想，能够在没有官方的力量牵涉的情况下吸引如此多的注意，WTL一定还有更出色的东西，请问您是如何看待WTL的成功呢？它成功的原因又是什么？

【Nenad】：我认为WTL成功的最主要原因就是，它确实而且及时地满足了开发者的需求。越来越多的开发人员开始使用ATL，当他们需要更多的UI支持时，他们很自然的就会开始使用WTL。从其他的开发团队所提供支持来看，WTL看起来似乎要比其他的项目更加开放。许许多多人为WTL做了大量工作，如：创建示例代码，撰写文档等。WTL之所以能够被广为接受并获得如此大的成功，来自于这些开发团队的支持绝对是一个重要的因素。

【C++ View】：请问您对于MFC是怎么看的？您喜欢它吗？如果不，为什么呢？还有，最让人迷惑不解的就是Managed C++了，它是不是C++呢？MC++的提倡者是不是真的认为会有一些C++的用户转而去学习它呢？您的看法又是如何呢？

【Nenad】：我认为MFC是一个了不起的框架库。请不要忘了，在MFC被设计出来初期，那时的C++编译器还具有很多的限制，并且那时主要的平台还只是16位的Windows。不幸的是，由于MFC被设计成为一个框架，使得我们很难利用新编译器中那些更好的C++特性来改进它，也很难将Windows中的很多新特性添加到MFC中。我不喜欢MFC的地方是它高度依赖DLL的特性——因为它将导致许多兼容性方面的问题；还有就是MFC的整个框架设计——它在应用程序的设计中限定了太多东西。
Managed C++是C++的一个扩展，它允许C++程序得以使用受管（managed）代码。我们需要了解的一个很重要的特性就是，我们可以使用MC++来编译已有的C++代码而无需对它们进行任何改动。MC++允许开发者同时使用他们所熟悉的非受管代码以及受管代码来开发同一个模块。这就提供了一个非常好的途径，使已有的代码与新的受管代码相互作用，并也可使得我们创建一个项目，同时使用受管的和传统的C++代码。

【C++ View】：在过去的15年中（甚至更长的一段时间内），C以及C++构成了几乎所有Microsoft技术的基础（如：OS，COM等）。我们这些 C++用户花费了大量的时间来熟悉并掌握它们（C以及C++），因为我们相信我们所付出的一定会有回报（?）。但现在的风向好像有了很大的改变。.NET 出现了，世界似乎就要充斥CLR （Common Language Runtime，公共语言运行库）以及／或JVM （Java Virtual Machine，Java虚拟机）。现在C++已经出现了退潮的迹象。那么，请问您对于C++（不是MC++）在Microsoft技术中的前景如何看待？它是否会由此消亡？还是就此沦落为一门边缘语言？

【Nenad】：是的，世界也已经发生了变化。对于网络服务以及连接这样的新型应用程序的开发已经浮上了水面。我认为那些新的编程语言（如Java，C#，以及VB.NET）都是针对以下两个主要的问题而开发出来的——简化软件的开发过程以及对于Internet应用程序开发提供更好的的支持。简化软件的开发过程使得更多的开发者可以写出更多更好的应用程序并减少完成开发项目所需要的时间。而支持Internet的开发，对于这个 Internet越来越深入到我们的日常生活中的时代来说，毫无疑问是一件非常重要的事情。
我认为C++会继续作为一门重要的编程语言发挥作用，尤其是对那些独立软件开发商和那些系统级开发来说更是如此。从另一方面来说，我相信.NET将会在不久以后成为另外一个非常重要的开发平台。对于未来来说，.NET拥有成为主流编程平台的潜力，但我们必须认识到，这样的过渡阶段肯定要持续一段时间。

【C++ View】：我们的读者中有很多是初学者，在他们学习完（标准）C++后，他们希望能够找到一条道路，掌握到足够多的Microsoft的技术使自己成为经验丰富的、熟练的程序员。您能不能给我们指出这样的一条道路来呢？我们是不是应该学习Win32 API编程？学习MFC是否是值得的？WTL/ATL/STL算得上是一个可靠的解决方案吗？又或是我们应该直接学习C#？如果您能够给我们一些建议，相信会有很多的人为此而感激您的。

【Nenad】：我认为这主要取决于他们的计划以及雄心。你所做的越多，在长时间竞争中你就越占据优势。不过你也要注意保持与实际问题的平衡。我建议那些决心以后只做Internet相关开发的人可以直接去学习C#或者VB.NET，同时学习.NET平台。而那些更多地了解Windows 平台以及它所提供的服务方面知识的人，当然就必须需要更多地了解有关Win32 API以及那些支持Windows编程的库相关的知识。

【C++ View】：在我刚开始学习WTL后不久，有一位热心人给我发了份邮件。他写道：“如果你不是一个好的ATL程序员的话，你就不可能成为一个好的WTL程序员；如果你不会COM编程的话，你就不可能成为一个好的ATL程序员；但一旦你决定开始学习COM，你就迈出了踏向地狱的第一步。”COM是不是真的那么难学？我们应该如何地来学习WTL呢？我们是不是应该按照这样的顺序学下来呢，API->COM->ATL->WTL？还有，COM 将会变得如何？他是不是还能够保持Microsoft的核心技术这一头衔，抑或是被.NET给替换掉然后就此消失？

【Nenad】：我不认为使用和理解WTL就一定要掌握COM。相比于COM来说，Win32 UI的知识对于理解WTL显得更为重要。但毫无疑问的是，ATL的相关知识是必不可少的。由于ATL主要任务就是支持COM，所以，有COM的知识只是会更好一些而已，但它们并不是必需的。
我也不认为COM是一个噩梦，但毫无疑问的是，想要成为一个COM专家，要学的东西实在是太多了。但请记住一件事情，很多使用COM或者WTL的人并不都是COM方面的专家。要想使用它们，人们所需了解的只是一些COM的基本原理就够了，其他的相关的知识则可以在需要时再去学习。

【C++ View】：请问您对于泛型程序设计是如何看待的？它到底是OOP的一个补充呢，还是完全不同于OOP的另外一个程序设计范型呢？我们是否可以将GP以及 OOP一同联合使用？我想，在设计和实作出WTL的艰苦过程中，对于OOP以及GP之间的关系，您一定有了自己的看法，您能不能给我们说一下呢？

【Nenad】：GP和OOP非常不同，这主要是由于GP从不显式地表达出设计元素之间的关联来。然而，它们也可以被非常高效地组合运用。
WTL 中使用了一种GP连同OOP的设计。我在其中大量使用了模板来实作出传统的OOP中的类。我很乐意指出的是，WTL中并没有使用一种“纯”设计，它也没有遵循任何的设计指导方针或者设计规格。可是，我还是认为WTL使用到了C++语言中的最主要的精髓处——对于一个特定的问题使用一种最适合它的适当典范。

【C++ View】：最近，著名的C++元老级大师Stanley Lippman加入了Microsoft并成为其VC.NET开发小组中的一员。请问您对于此事是如何看待的？您认为Microsoft试图向公众传播一种什么样的信息呢？这是否也意味着Microsoft希望VC.NET成为一个完全标准化的C++编译器，并继续保持C++的核心系统语言地位呢？

【Nenad】：我认为这显示了Microsoft对于促进C++编译器以及语言继续发展的决心，并为此找到了最佳人选来获取帮助。我确信VC.NET将会继续是开发应用程序的强有力工具，并且它同时还将包含有.NET开发能力。目前我们正在进行兼容C++标准方面的工作，不久我们就会看到成效。

【C++ View】：我现在正在学习WTL以及ATL，既然您是WTL的作者，同时又是ATL开发小组中的一员，您能不能给我一些建议呢？

【Nenad】：对于WTL和ATL来说，有好几个编程方面的领域是十分重要的：大体上的C++语言知识，了解模板，COM（对ATL而言），以及Windows UI编程（对WTL而言）。在这些领域有着坚实的基础对于WTL以及ATL开发人员来说有着很大的好处，同时对于理解这两个的源代码也能够起到帮助作用。
我同样也很乐意去鼓励大家多写程序。这也是学习如何使用一个程序库，或者一门编程语言，或者一个操作系统的一个最好的方法。在写程序的过程中经常会出现一些书本上没有提及但又必须被解决的问题。在开始学习时读一些东西是很有用的，而写程序则是向纵深发展的最佳方式。

【C++ View】：有人说，我们现在已经处于后PC时代的门口，未来将会是一个嵌入系统的世界，嵌入式的智能设备将会无所不在，并且对比PC来说，嵌入系统的产业将会是一个更大的市场。您是否相信这些呢？您是否认为WTL以及其他的一些C++模板库对于嵌入式开发也适用呢？它们是否适合Internet开发？

【Nenad】：是的，我认为我们现今所使用的各种设备中的大部分在以后都将会演变成为一些小的，具有专门用途的计算机。但这并不意味着 PC的数目以及重要性将会由此降低，只不过是表明还有着许多其他的设备需要被加强以使得我们可以对其进行编程并且连接。由于必须需要有软件的支持，而软件又需要有人来写，这些新的设备将会给软件开发人员带来极大的机遇。
有许多的C++函数库都可用于嵌入系统的开发，WTL也将会在那些 Windows用户界面较为重要的开发中（例如，在Pocket PC平台上面开发）占有一席之地。对于嵌入式开发来说，良好的弹性，微小的内存耗用永远都会是很重要的特性，而模板库在这方面占据了一个非常好的地位。

【C++ View】：在过去的7年（甚至更长的一段时间）内，COM都是Microsoft中的核心技术。现在我们可以预见到，在下一个十年间，这个核心将会变为.NET。我的问题就是，COM有什么过错？COM将何去何从？它是否会逐渐消失呢，还是会被其他的一些技术给替代？COM和.NET之间的关系是什么样的情况？.NET是否是基于COM之上呢？现在学习COM是不是还值得？

【Nenad】：或许你不应该问COM有什么过错，而是应该把.NET看成COM的进化。.NET扩展了COM最初的目的——创建可重用的二进制程序组件——并向其中添加了很多重要的特性：丰富的元数据，了不起的运行库，内建的安全机制，版本机制等。对于现今的软件开发来说，所有的这些新的特性都非常重要，所以.NET能够广泛地支持它们，是一件很伟大的产品。Microsoft同时也提供了在.NET和COM之间进行互操作的能力，这使得以前所开发出来的COM组件在.NET环境中同样也能够得到使用。
我仍然认为学习COM是一个很好的主意——它甚至对于那些希望学习.NET的人们来说也是一个很好的开端，学习COM同时也有助于我们更深入地理解 .NET本身的设计和实现。

【C++ View】：我猜想您肯定是一个C++爱好者。现在这门语言面对着许多的挑战。作为反击措施，Stroustrup博士提议开发许多有用的库，并引导 C++程序员把C++当作一门高级语言来使用。现在我们已经可以得到好几个极好的现代的C++库，除去ATL、WTL以及STL之外，还有Boost库、 MTL、ACE/TAO、DTL等。一切都显示着C++社区正在酝酿着一次变革。请问您觉得这场变革能否成功？为什么？您的那些Microsoft中的 VC.NET开发小组中的同事对于此态度是怎样的？

【Nenad】：C++是一门伟大的语言，即便遇到了新的挑战，它仍然将是非常重要的。程序库对于语言本身是极好的补充，它们为开发者提供了一些十分有用的可重用代码。存在如此众多的、了不起C++程序库，这件事情本身就表明了C++社区的庞大和强大。我认为这场变革已经成功了，并且会一直成功下去。你们可以放心，VC.NET开发组是不会对这些已有的程序库熟视无睹的，我预期他们会不断地加强对于这些库的支持。

【C++ View】：最后一个问题。既然许多人并不了解WTL，作为WTL之父，您现在有机会在这里做一个演讲，请简短地介绍一下WTL。

WTL是一个基于模板的、专为开发用户界面的程序库。它扩展了ATL，并提供了一些类用来实现应用程序的用户界面、组件和控件。它提供了各种类来支持各种各样的用户界面元素：顶级窗口、MDI、标准控件和通用控件、通用的对话框、属性表以及属性页、GDI对象、UI更新、可卷动的窗口、分割窗口、命令条等等……
WTL的实现使用了和ATL一样的模板架构，所以对于ATL开发者显得很自然。同时它并没有改变或者是隐藏那些 Windows相关结构，那些Windows程序员在使用WTL时也不会感到很吃惊。WTL的一个主要设计原则就是避免在没有引用到其他WTL类时，出现不必要的内部依赖。这意味着我们的程序将只包含有我们实际上所使用的代码，除此之外再无其他的东西。加上了模板的使用后，这样做得到的结果就是一些非常小的，不依赖于运行库的程序。
WTL专注于用面向对象的方法来编写Windows的用户界面程序，同时保持代码的尺寸很小。同时，它也为开发者提供了一个很好的基础，可以写新的类来扩展WTL。
最后，我在编写WTL时就希望开发者能够喜欢在开发中使用它。我同样也希望您能够使用它并喜欢上它。