Before the release of .NET and Windows Forms (and the announcement of Windows Presentation Framework), with the release of these newer frameworks for writing Windows applications, Microsoft didn’t give WTL a great deal of development time and eventually released it as an open-source project in 2004. This article looks at the newer WTL releases since the open-source release, and examines where WTL fits in the C++ programmer’s toolkit.
The Microsoft Foundation Class (MFC) library was Microsoft’s most successful attempt at providing a C++ library that relieved developers from the tedium of manually writing all the boiler-plate code of a Windows application. MFC and the C++ language grew up together, and backwards-compatibility requirements meant that, by the time MFC reached version 6 in 1998, it was beginning to show its age.
The newer Active Template Library (ATL), which was targeted at COM component creation, had a more flexible and appealing style of programming that seemed just as applicable to Windows programming as it did to COM. Template-based libraries, combined with the Standard C++ library, also offered an application framework that was much lighter than MFC, which had become fairly bloated with features added version after version.
Microsoft answered the need for a template-based Windows library with the Windows Template Library (WTL), which was an extension to ATL. WTL shipped as part of the Platform SDK in an undocumented and unsupported form. Despite its humble beginnings and the lack of Microsoft support (probably due to the upcoming Windows Forms functionality in the .NET Framework), WTL gained a solid support base and has refused to go away. In fact, many C++ developers believed it had the potential to become a mainstream framework for C++ Windows development.
With the release of these newer frameworks for writing Windows applications, Microsoft decided in 2004 to open-source WTL rather than simply kill it. The project now sits on SourceForge. WTL is available under the Common Public License 1.0, a permissive license that allows commercial development. Where warranted, however, an organization should ensure that the license is suitable before embarking on development projects involving WTL.
The current release of WTL is 8.0, a minor upgrade of WTL 7.5 that provides optimized IDE support for Visual Studio 2005. The full list of IDE, ATL, and Platform SDK compatibilities is listed in the ReadMe file that accompanies the WTL distribution. One of the more exciting points to note is that WTL 8.0 supports embedded development on Windows CE devices in addition to providing support for 32- and 64-bit development.
In addition to the SourceForge site, an unofficial WTL Documentation site offers a zipped compiled HTML help file that documents WTL 7.5. The documentation is largely based on comments in the WTL source files, but may provide a more convenient form of documentation for some developers.
WTL Hello World
The WTL release includes a script file to register the WTL application wizards with Visual Studio. After running these scripts, a WTL/ATL Application Wizard will be available in the Visual C++ project types, as shown in Figure 1.
Figure 1: WTL Application Wizard
Apart from the lack of documentation, the development experience with WTL is on a par with other C++ libraries. The Application Wizard offers a wide range of application types (see Figure 2) and UI features (see Figure 3).
Figure 2: WTL Application Types
Figure 3: WTL User Interface Features
For those familiar with MFC and the UI classes in ATL, WTL code will look very similar. As with MFC, WTL uses macro message maps to route Windows messages to the code that responds to the messages. It also has many of the same standard source files, such as stdafx and mainfrm.
In contrast to MFC, WTL does not support the full View-Doc-Application pattern. As is typical with template-based libraries, a lot of the functionality is contained in header files. A simple WTL application will have only two source files: stdafx.cpp and a source file that contains the application’s entry point.
WLT uses the same mix-in style of programming as ATL, which makes sense given their common heritage and shared classes. Mix-in programming adds a base class to provide a certain set of functionality. The CMainFrame class generated by the WTL wizard is a good example of mix-in programming at work. It has four base classes:
CFrameWindowImpl is a WTL class (derived from the ATL class CWindowImplBaseT) that provides support for the creation and management of frame windows and associated items such as toolbars. CUpdateUI is a WTL class for managing update UI maps, with CMessageFilter and CIdleHandler acting as interfaces for various UI methods.
One area where new WTL developers may struggle is porting the samples to Visual C++ 2005. In the absence of documentation, the WTL samples are a great resource for exploring the functionality offered by WTL. WTL 8 ships with the samples still in the Visual C++ 6 format, and when a number of these are updated to Visual C++ 2005, the following linker errors may occur:
CVTRES : fatal error CVT1100: duplicate resource. type:MANIFEST, name:1, language:0x0409
LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
The simplest solution to this problem is to turn off incremental linking, as shown in Figure 4.
Figure 4: Getting the WTL Samples to Compile
A Fine Work in Progress
For developers familiar with MFC looking for a more modern and lighter-weight framework free from large DLL dependencies, WTL may prove to be the solution they seek. As an open-source, community project, developers can add and modify features as required, and the continuing development and release cycle of WTL give every indication that it will be a project that will continue to attract developers to maintain and add to its code base.
About the Author
Nick Wienholt is an independent Windows and .NET consultant based in Sydney, Australia. He is the author of Maximizing .NET Performance from Apress, and specializes in system-level software architecture and development with a particular focus on performance, security, interoperability, and debugging. Nick can be reached at NickW@dotnetperformance.com.