BUG: Cannot locate the procedure entry point FreeAddrInfoW when you run an application on Windows Server 2003 or on Windows XP

When you run a Unicode-enabled application that uses the FreeAddrInfo Windows Sockets function, or that uses helper classes such as ATL::CSocketAddr on a computer that is running Microsoft Windows Server 2003 or Microsoft Windows XP, you may receive the following error message:

The ws2_32.dll library does not export the FreeAddrInfoW symbol that you must have to use the Unicode version of the FreeAddrInfo function.

To resolve this problem, follow these steps:

1. Copy the Atlsocket.h file to any directory that you want to use. This file is located in the following directory:
   Program Files\Microsoft Visual Studio .NET 2003\Vc7\atlmfc\include
2. Add the following block of code to the copy of the Atlsocket.h file that you created in step 1.

   //Atlsocket.h
   #pragma comment(lib, "ws2_32.lib")
   #pragma comment(lib, "mswsock.lib")
   //Start of Addition
   #if _WIN32_WINNT < 0x0502
     #define ADDRINFOT addrinfo
     #define GetAddrInfo getaddrinfo
     #define FreeAddrInfo freeaddrinfo
   #endif
   //End of Addition namespace ATL

3. Start Microsoft Visual C++.
4. On the Tools menu, click Options. In the left pane of the Options dialog box, expand Projects, and then click VC++ Directories.
   
   Note If you are using Visual C++ Express Edition, expand Projects and Solutions in the left pane of the Options dialog box, and then click VC++ Directories.
5. Under Show directories for, click Include files. Then, add the directory where the modified version of the Atlsocket.h file is located to the top of the list.
6. Rebuild you application

Microsoft has confirmed that this is a bug in the Microsoft products that are listed in the "Applies to" section.

Steps to reproduce the problem

1. Start Microsoft Visual Studio .NET 2003.
2. On the File menu, point to New, and then click Project.
3. Click Visual C++ Projects under Project Types. Then, click Win32 Console Project under Templates.
4. In the Name box, type Sample, and then click OK.
5. In the Win32 Application Wizard dialog box, click to select the ATL and the Add Support for check boxes under Application Settings, and then click Finish.
6. In the Sample.cpp file, replace the existing default code with the following code.

   #include "stdafx.h"
   #include <atlsocket.h>
   
   void _tmain()
   {
   	CSocketAddr aSocketAddr;
   }

7. In Solution Explorer, right-click the project node, and then click Properties.
8. In the project Property Pages dialog box, click General under Configuration Properties in the left pane. In the right pane, set the Character Set property to Use Unicode Character Set. Click OK.
9. On the Build menu, click Build Solution to build the application. You may notice that no compilation errors or linking errors occur during the build process.
10. On the Debug menu, click Start Without Debugging. You may notice that you receive the error message that is described in the "Symptoms" section.

In Windows Server 2003 and in Windows XP, new Windows Sockets functions are added to the Windows Socket API. GetAddrInfo and FreeAddrInfo are the two new Windows Sockets functions that are added for dealing with both Internet Protocol version 6 (IPv6) and Internet Protocol version 4 (IPv4) addresses. The Active Template Library (ATL) 7.1 CSocketAddr class uses these new Windows Socket functions to provide support for IPv6. Other ATL and Microsoft Foundation Classes (MFC) classes also use the CSocketAddr class to provide IPv6 support. For example, the CAsyncSocket class and the CSMTPConnection class use the CSocketAddr class.

Note The CAsyncSocket class is an MFC class. The CSMTPConnection class is an ATL class.

The problem that is described in the "Symptoms" section occurs in any Unicode-enabled application that uses the FreeAddrInfo Windows Socket function on a computer that is running Windows Server 2003 or Windows XP. Because the ATL CSocketAddr class uses the FreeAddrInfo function, the same problem also occurs in ATL 7.1. Any class in ATL 7.1 and MFC 7.1 that uses the CSocketAddr class to enable IPv6 support reflects this behavior. For example, the CAsyncSocket class and the CSMTPConnection class use the CSocketAddr class.

ATL server classes such as CAtlHttpClient and CSoapSocketClientT use the ZEvtSyncSocket class, and display the same error. This behavior occurs because the ZEvtSyncSocket internal class uses the CSocketAddr class in its implementation.

Note The CAtlHttpClient class provides HTTP client support. The CSoapSocketClientT class provides XML Web services client support.

For more information about changes that have been made to ATL, visit the following Microsoft Developer Network (MSDN) Web site:For more information about new Windows Socket functions that have been added to the Windows Socket API, visit the following MSDN Web site: