A Quick MFC and WTL Comparison

As I write this, I had just completed a little utility for my wife that would help keep her dial-up network connected. We use ISDN to dial into her medical school, which places the majority of her lectures online. The problem she has with this is the remote server disconnects her while she's working through her lectures. It apparently monitors idle network activity, and after a very short inactive period logs the student off. This can be more than a mere irritation, especially when she's preparing for an exam.

So being the gregarious and loving spouse, I challenged myself to write in five minutes a little MFC application to solve this problem. The good news is I met the challenge, at least initially. As for the bad news, well...as with most projects, this utility grew a little, and soon I had spent an entire evening embellishing it! (To many, myself included, this isn't truly bad news as I had fun doing so!) But my wife is delighted and has since passed copies to her fellow students. I believe this is a good thing, especially if one of them elects to enter geriatrics--I may need their services some day!

What does this have to do with the Windows Template Library (WTL) and the Microsoft Foundation Classes (MFC)? The key lies in the phrase "passed copies" in my previous paragraph. For my wife to be able to pass copies of my MFC-based application to her friends, I had to statically compile the MFC libraries. Initially, I did so with debug-level code, and I was amazed to find my tiny application grew to over 2MB in size! Ouch! Even a release-level version consumed over 200K of disk space.

I then wondered how large would a similar application be if I implemented the same functionality in WTL. I can hardly write COM code without ATL, so why not take a deeper look into WTL for traditional Windows client code? Here is what I found, given the scenario I've outlined. Since WTL is not as commonly used as MFC, I'll also give you a brief tour through the WTL version of my utility application.

Chances are you haven't worked with WTL. There isn't space available in this article for me to adequately describe WTL in detail, but I can point you in a couple of directions for help. First, I've included WTL with the sample application's download to make it easier for you to find and use it. Second, there are several good online sources for WTL information, including source code, descriptions, tutorials, and other handy stuff. Here is a list of several URLs you should visit if you're interested in WTL:

• www.sellsbrothers.com/tools (Chris Sells is a WTL aficionado)
• www.develop.com/dm/dev_resources.asp (two excellent "Inside WTL"-style white papers)
• www.idevresource.com/com/library/articles/wtlarch.asp (WTL architecture from Richard Grimes)
• www.codeproject.com/wtl (source code examples)

Unfortunately, Microsoft considers WTL an unsupported project, so there is a significant lack of documentation coming from Redmond on the subject. But if you're looking for lean and mean Windows code but don't want to dip all the way down to the raw Windows API for everything, WTL is most likely a good alternative. The best news is that WTL consists of several header files (and an AppWizard), so you're free to modify the source code should you need to do so.

WTL and MFC, The Experiment

I wanted to compare apples to apples, and since I had implemented the utility in MFC first, I copied as much of that existing code to the WTL project as I could. The application itself consists of a dialog-based utility that wraps CreateProcess(). To keep the remote system from sensing inactivity, I "ping" a remote site at regular intervals. I could have written the ping functionality myself, using icmp.dll, but to meet my five-minute challenge, I decided to simply simulate this command line at the DOS prompt:

If you're not familiar with ping, it's a utility that prompts the remote host for status information. The ping program reads the returning network packets and determines if the remote host is available, and if it is, how long was the roundtrip latency. The term ping stands for packet internet groper.

Any system with network capability will have ping.exe loaded, so barring catastrophic conditions, CreateProcess() should be able to locate ping.exe, run it, and generate enough spurious network traffic to keep the remote host happy for awhile. Of course I selected a well-known Internet URL to ping (well known to me, anyway).

When handling WM_INITDIALOG, both versions of the Pinger utility start the timer and issue an initial round of pings. After the initial pings are made, the timer is configured to issue the WM_TIMER message after the user-selectable period has expired. To keep things a bit simpler, I elected to single-thread the application, in which case various buttons are disabled while the ping process is in progress.

The only quantitative result I was interested in determining was to compare compiled executable file sizes. This application is not computationally intensive, so I didn't consider runtime latencies to be a critical piece of information. Even so, there are several qualitative conclusions we can draw from the file sizes, which I address in the next section.

The resulting file sizes for pinger.exe are shown in Table 1. Note the MFC versions include statically linked MFC and C runtime libraries (for easy distribution). These files were built using Visual Studio, Version 6, Service Pack 4 running under Windows 2000 Server. The WTL versions do not require any additional WTL support libraries.

For each case, the WTL executable image is roughly 4 times smaller than the MFC image (3.79 times smaller for release, 4.83 times smaller for debug). Granted, this isn't statistically accurate, so we can't draw generalized results for each and every possible WTL and MFC application. However, it does underscore the fact that WTL, like ATL, can be used for creating Windows executables with very small footprints very quickly.

I should note that you could make the MFC executables smaller yet if you used the MFC libraries dynamically. However, this masks the true size of your application. The MFC DLLs are 908 and 972 KB in size (respectively) for debug and release on my system. You are then also responsible for supplying the DLLs to your user base, and as anyone who has written installation programs and installed MFC DLLs knows, this is more than a little challenging to do correctly. It is dangerous to assume the MFC DLLs will be in place for you if you don't install them yourself. The unfortunate part of this is you can very easily damage a user's computer by installing incorrect MFC DLLs, such as those found in the initial release of Visual Studio, Version 6.0.

WTL precludes all of this, and if you keep the ATL_MIN_CRT directive in place as you compile, you won't even need the C Runtime Library. In that case you also won't need to distribute msvcrt.dll, although in many practical cases you can avoid distributing this DLL. It has not changed much over the years (although professional installations do install it as a matter of course if it is required).

So if WTL is so wonderful, why isn't everyone using it? Laying the argument for thin clients aside, part of the answer lies in the fact WTL was only recently introduced. In fact, the first place it became available to the developer community was with the Platform SDK for Windows 2000 (not part of the standard Platform SDK). It came as part of a code sample...very little fanfare for such an evolutionary companion to ATL 3.0. But it's also true Visual Studio supports MFC application development to a greater degree. While there is some ATL support present in Visual Studio, most MFC developers are quite familiar with ClassWizard even though there is a rough equivalent for ATL (and WTL).

MFC also has evolved to the point it supports a great many desirable features, such as MAPI, support for the other Windows logo requirements, sockets, documents (if you like and/or use that pattern), and compound document files. WTL has its share of cool features, but MFC is the clear feature champ. Both environments support framed main window architectures (frame window with separate view window), SDI and MDI applications, split windows, dialog-based applications, and various COM-based classes for COM support.

If you had asked me two years ago which development tool I'd use to create full-featured client-side applications, I would have told you I'd use MFC. However, even given the loss of some of the features provided by MFC, today I'd use WTL to create professional client applications. Not having to install the MFC DLLs on a user's system is a benefit that far outweighs the MFC feature loss, at least in my opinion.

To help introduce you to the WTL, I'll briefly describe the WTL version of my ping utility. I created the WTL Pinger version using the WTL AppWizard, which you'll find included with the WTL files included with the source code download. Like the MFC application AppWizard, you can select from an assortment of application styles, as you see from Figure 1.

I selected a dialog-based application, which led to the second AppWizard page you see in Figure 2.

With the files initially created, I created the utility's user interface, which I've shown in Figure 3.

The WTL AppWizard creates fewer files than the MFC AppWizard, and in this particular case, I made modifications to maindlg.h, resource.h, and pinger.rc. I left the remaining WTL source files unchanged.

As far as the resource file pinger.rc was concerned, I removed the extraneous strings from the string table, updated the version information, removed the (unnecessary) accelerator table, and modified the dialog box to match the MFC version's user interface. I naturally made corresponding changes to resource.h. These items should not be present in a dialog-based application, which I believe to be a bug in the AppWizard.

The bulk of the work is shown in Listing 1, where you see the contents of maindlg.h.

// maindlg.h : interface of the CMainDlg class

m_CRateSpin.Attach(GetDlgItem(IDC_RATESPIN));

m_CRateSpin.SetRange(20,60);

m_CRateSpin.SetPos(30);

m_CRateSpin.Invalidate();

// Start the timer...first pass is a 1 second delay

// before first ping. :)

m_iTimerID = SetTimer(1,1000);

// Check for problems

if ( m_iTimerID == -1 ) {

   // Couldn't get a timer, so ask to continue...user

   // will have to ping at will using "Ping Now" button.

   TCHAR szErrMsg[MAX_PATH];

   if( ::LoadString(_Module.GetResourceInstance(),IDS_E_NOTIMER,szErrMsg,MAX_PATH ) > 0) {

      // Error string loaded, so display error message

      int iResponse = MessageBox(szErrMsg,"Error!",MB_YESNO|MB_ICONERROR);

      if ( iResponse == IDNO ) EndDialog(-1);

   } // if

   return 0;

The helper methods DoPing() and CreatePing() were relatively unchanged between the MFC and the WTL versions. The minor changes I did have to make involved the message box code to display error conditions and the formulation of the command line string. I didn't use the WTL CString class so I could avoid the C Runtime Library (since I could). Note you could use the STL string class in its place if you still wanted smart string support.