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

#endif // !defined(AFX_MAINDLG_H__DC16127C_44F9_4BCF_BDAB_52E20D803699__INCLUDED_)

// IDM_ABOUTBOX must be in the system command range.

_ASSERTE((IDM_ABOUTBOX & 0xFFF0) == IDM_ABOUTBOX);

_ASSERTE(IDM_ABOUTBOX < 0xF000);

CMenu SysMenu = GetSystemMenu(FALSE);

if(::IsMenu(SysMenu))

{

   TCHAR szAboutMenu[256];

   if(::LoadString(_Module.GetResourceInstance(), IDS_ABOUTBOX, szAboutMenu, 255) > 0)

   {

      SysMenu.AppendMenu(MF_SEPARATOR);

      SysMenu.AppendMenu(MF_STRING, IDM_ABOUTBOX, szAboutMenu);

   }

}

// Subclass and initialize the controls

m_CURL.Attach(GetDlgItem(IDC_URLTXT));

m_CURL.SetLimitText(MAX_PATH);

m_CURL.SetWindowText("www.endurasoft.com");

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

{

   UINT uCmdType = (UINT)wParam;

   if((uCmdType & 0xFFF0) == IDM_ABOUTBOX)

   {

       CAboutDlg dlg;

       dlg.DoModal();

   }

   else

      bHandled = FALSE;

   return 0;

LRESULT OnPingNow(WORD /*wNotifyCode*/, WORD wID, HWND /*hWndCtl*/, BOOL& /*bHandled*/)

{

   // Do the ping

   DoPing();

   return 0;

{

   // Check status of suspend checkbox, and if not

   // suspended, ping

   if ( IsDlgButtonChecked(IDC_SUSPEND) == BST_UNCHECKED ) DoPing();

   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.

[Back] [Home]