开发问题
WTL 最终产品
使用WTL建立的程序很小的，AppWizard生成的默认SDI程序编译后的exe文件大小只有64k， 去掉多余的功能，编译只有24k大小。一个真实的商业级程序应该
不会超过250k，并且这些文件经过压缩后将会再减少2/3的体积，可以在Internet上快速下载。
在Buid完成后，如果你没有使用CRT和其他的DirectX之类的库，那么WTL工程编译后的exe或dll就是你唯一需要发送给最终用户的文件。
WTL程序没有额外的依赖。文件少，出现问题的几率就少。
CRT
C-Runtime library上Win32 API之上的一组C函数，通常被称作CRT。CRT的源代码是VC++的一部分（在src目录），如果你仔细看一下的话，就会发现这些CRT的函数是用ANSI C实现的，一些直接调用了APIs，一些通过调用中间函数间接调用了APIs。CRT大部分是来自ANSI C标准库的一些函数（printf，strok等），但是也有一些Win32平台相关的函数（比如（beginthreadex在做了一些CRT初始化后调用了CreateThread API）
如果你的程序只使用ANSI C标准库，你的代码就是可移植的。有许多百万行代码级的工程在经过不到2％的更改后就可以在Windows和UNIX上顺利通过编译和正常运行。CRT确实在某些领域提供了Win32所没有的功能，比如string形式的浮点数、C++异常和为全局变量调用构造/析构函数。
如果你使用ATL和WTL进行编程，你的代码绝对不可能移植到UNIX/LINUX之上，这样有个问题就产生了，我到底有必要连接到CRT吗？CRT在很大程度上是Win32 APIs的重复，所以大部分情况下，大案是“No”。离开了C++异常处理和全局变量的构造/析构函数，也可以生存，而使用了CRT，你的程序体积将增大，并有了额外的外部依赖(MSVCRT.dll)而这个库有多个版本，这也可能成为麻烦的根源。
WTL AppWizard生成的工程的设置使得CRT在debug build是可用（为了调用ATLASSERT），而在release build时并不包含进来（预处理指令中的_ATL_MIN_CRT宏）。如果你没有注意到这个细节，可能会对“使用了CRT的WTL工程怎么也无法在release模式下编译通过”的问题束手无策。注意：CRT在Release模式下默认是不被包含的。
错误处理
在WTL程序中要使用C++异常处理，就必须依赖CRT（当然，如果你愿意可以使用）。另外对API可以使用GetLastError和ATLASSERT
WTL名称空间（namespace）
新的ISO C++标准引入了名称空间的概念，WTL为了避免和其他类库产生名称冲突，它的每一个头文件都是以下面的代码开始：
namespace WTL
{
并以：
}; //namespace WTL
结束
……
……
模板/类/方法名
WTL的命名管理沿用MFC的，由于它们两个都是基于Win32 API的，所以这么做是有意义的。并且多数的WTL程序员是来自MFC程序员。
WTL的类名是这样的，CEdit，CStatic和CDC。窗口消息的处理程序名称为OnInitDialog and OnOK。数据交换使用DDX，方法名为DoDataExchange。
WTL和MFC不同的地方是，在有些地方，WTL明智地遵循了Win32的名称，比如Win32的UpDown控件在WTL中为CUpDownCtrlT，而在MFC中为CSpinButtonCtrl。
Windows的版本
WTL全面支持Win2000和WinMe（以及Windows XP——译者）中的新UI特性，但也可以用于旧版本的Windows，这个可以通过#define一个WINVER来实现。