Appendix D: What You Need Appendix D: What You NeedThis is a hypertext version of Appendix D in the text Windows Sockets Network Programming, by Bob Quinn and Dave Shute.
This appendix summarizes what you need to create a WinSock application and maintain a test environment. We tell you what files you need, where to get them, or how to create them yourself. We consider the mechanics of application creation and execution. We describe how to switch between different WinSock implementations, and we mention the use of languages other than C.
The most essential file of all is a copy of the Windows Sockets version 1.1 specification itself (dated 20 January 1993). This is the definitive reference for WinSock by Martin Hall, Mark Towfiq, Geoff Arnold, David Treadwell, and Henry Sanders. The original work is in Microsoft Word version 2.0 format (winsock.doc), although it is also available in straight text (winsock.txt), postscript (winsock.ps), Windows help (winsock.hlp), and hypertext markup language (winsock.htm) formats.
The essential file for WinSock development is the winsock.h header file. This contains all the structure definitions, macro definitions, and function prototypes for the WinSock API. You need to #include this file in your WinSock source code files.
In most cases you'll also need a winsock.lib import library file for the 16-bit WinSock API, or wsock32.lib for the 32-bit WinSock API. You can link with either library in order to load the WinSock dynamic link library--winsock.dll or wsock32.dll, respectively--at run time.
Of course, you'll also need a winsock.dll in order to run your 16-bit WinSock applications (or wsock32.dll for 32-bit applications). And these dynamic link libraries require a properly installed TCP/IP protocol stack and a network interface (Ethernet, SLIP, PPP, etc.).
Section A.2.1 (Appendix A) of the version 1.1 WinSock specification lists a number of other header files and indicates that any WinSock development kit must provide them. However, there is no need for them. The other header files are listed for backward compatibility with Berkeley source code. They are superfluous for a number of reasons: Their essential contents are already included in the WinSock.h file; you need to make some changes to most Berkeley Sockets source code to port them to WinSock anyway; and it's easy enough to #ifdef out the files if they are unavailable.
The Windows Sockets specification (winsock.doc) and standard winsock.h and 16-bit winsock.lib files are available at many FTP sites on the Internet, including
ftp://sunsite.unc.edu/pub/micro/pc-stuff/ms-windows/winsock
ftp://ftp.stardust.com/pub/winsock/version1/dev
If you already have a winsock.dll file, you can create your own copy of the 16-bit import library (winsock.lib) with the implib.exe utility that ships with Microsoft C, and Borland C. Just type
implib winsock.lib winsock.dll
Many TCP/IP stack vendors can provide a winsock.dll, including the shareware Trumpet WinSock version available from Peter Tattam. It's important to remember that you must have a winsock.dll from the same vendor that provided your TCP/IP stack.
The 32-bit wsock32.dll ships with Windows NT and Windows 95 and runs over the Microsoft TCP/IP stack. These 32-bit environments also have a winsock.dll file that acts as a "thunk-layer" to allow 16-bit WinSock applications to run over the 32-bit wsock32.dll. Conversely, Microsoft's Win32s installs a 32-bit wsock32.dll thunk layer in 16-bit Windows environments (Windows version 3.1 and Windows for Workgroups 3.11) over any vendor's WinSock DLL currently in use. We describe this architecture in Chapter 15, "Platforms."
The 32-bit wsock32.lib Microsoft ships with Microsoft Visual C++ version 2.0 (there's also a non-standard version of winsock.h that contains Microsoft's own extensions).
You do not need to do anything special to compile WinSock source code. The only important consideration is that you #include the winsock.h file in any source module that uses WinSock functions, macros, or structures.
Most applications link implicitly with a WinSock DLL (winsock.dll or wsock32.dll) at run time. Implicit linking is easy, since no extra code is needed. Implicit linking occurs automatically if you link with either the winsock.lib or wsock32.lib import libraries when you create your executable. The disadvantage is that your application will not run at all if the Windows subsystem cannot find the WinSock DLL at run time.
Not being able to run the application when the winsock.dll file is unavailable is okay for most WinSock applications, since you can't do much without a WinSock DLL anyway. However, there are times when you'd like your application to run whether or not the winsock.dll file is available. For example, your application may not require network access to be useful, or perhaps you want to provide your own explanation to your application user about the missing winsock.dll file.
To allow your application to run without a winsock.dll file available, you need to link with the winsock.dll explicitly. To do this, you use the Win API function LoadLibrary(), followed by GetProcAddress(), to initialize a pointer to each function your application uses. You also want to check for the existence of the DLL before you call LoadLibrary() since Windows automatically displays a message box indicating the DLL cannot be found if LoadLibrary() fails. The following code example shows how to do this:
#includeAlso, don't forget to call FreeLibrary(hWinSockDLL) after you call WSACleanup() to free the instance resource and unload the DLL from memory.. . . int (PASCAL FAR * lpfn_recv)(SOCKET, char FAR *, int, int); int (PASCAL FAR * lpfn_send)(SOCKET, char FAR *, int, int); int (PASCAL FAR * lpfn_WSAStartup)(WORD, LPWSADATA); int (PASCAL FAR * lpfn_WSACleanup)(void); int (PASCAL FAR * lpfn_WSAGetLastError)(void); OFSTRUCT stFile; HFILE hFile; HINSTANCE hWinSockDLL = 0; . . . #ifdef WIN32 /* Load 32-bit WinSock DLL */ hFile = OpenFile("wsock32.dll", (OFSTRUCT FAR*)&stFile,OF_EXIST); if (hFile != HFILE_ERROR) hWinSockDLL = LoadLibrary ("wsock32.dll"); #else /* Load 16-bit WinSock DLL */ hFile = OpenFile("winsock.dll", (OFSTRUCT FAR*)&stFile,OF_EXIST); if (hFile != HFILE_ERROR) hWinSockDLL = LoadLibrary ("winsock.dll"); #endif if (hWinsockDLL >= 32) { (FARPROC)lpfn_recv = GetProcAddress (hWinsockDLL,"recv"); (FARPROC)lpfn_send = GetProcAddress (hWinsockDLL,"send"); (FARPROC)lpfn_WSAStartup = GetProcAddress(hWinSockDLL,"WSAStartup"); (FARPROC)lpfn_WSACleanup = GetProcAddress(hWinSockDLL,"WSACleanup"); (FARPROC)lpfn_WSAGetLastError = GetProcAddress(hWinsockDLL,"WSAGetLastError"); /* Check for any null pointers in case GetProcAddress failed */ if (!lpfn_recv | !lpfn_send | !lpfn_WSAStartup | !lpfn_WSACleanup | !lpfn_WSAGetLastError) { FreeLibrary (hWinSockDLL); hWinSockDLL = 0; } } if (!hWinSockDLL) { MessageBox (hwnd, "Unable to load winsock.dll","Error"); }
One of the limitations of WinSock version 1.1 is that you can only have one active winsock.dll on your system at a time. This would be fine if all WinSock implementations were created equal, but as we have described, they are not. Part of the process of WinSock application development involves testing an application over different WinSock implementations. As a result, it is not unusual for an application developer to need to switch between various vendors' WinSocks and TCP/IP protocol stacks. This is tricky but not too difficult.
A significant variety of WinSock and TCP/IP stack architectures are available for Windows, and each one has its own requirements when you want to switch between them. There are differences in the network interface drivers they use, in whether they have a terminate and stay resident (TSR) portion that must be loaded before running Windows, or load as a virtual device drivers (VxD) when Windows loads.
It's not difficult to create a batch file for each protocol stack you have, which will allow you to switch quickly to that stack for testing. In the best case, it's simply a matter of exiting from Windows and running the batch file. In the worst case, you'll need to execute the batch file and reboot the PC before you run Windows again.
To create a batch file for a vendor's stack, do the following:
Here are the types of changes you can expect most WinSock protocol stack installation applications make to these configuration files:
autoexec.bat: It will have changes to the path, and possibly a terminate-and-stay-resident (TSR) program load that may be related to the network driver in use. If the stack uses an NDIS driver, it runs netbind.
config.sys: It will have device drivers, including protman.dos if the stack uses an NDIS driver.
system.ini: It will have virtual device drivers lines added (file names with .386 extensions).
The WinSock specification was originally designed with the C programming language in mind, so its constructs are very C-centric. However, since the API is provided in a dynamic link library, it is possible to access WinSock from any language capable of utilizing a DLL. This includes most languages, including PASCAL, C++, and even Visual Basic.
The WinSock programming community has produced a number of public domain and shareware files available at many Internet sites that address the needs of other languages. This includes a Pascal-compatible version of the winsock.h file, Visual Basic versions of the winsock.h file, Visual Basic Custom Controls for WinSock and C++ WinSock class libraries. Numerous commercial products are also available, many of which implement application protocols and provide high-level APIs to simplify application development. The main reason to purchase a commercial development kit is to get support as you develop applications.
For up-to-date links to many network sites that contain this type of WinSock programming information, you can refer to http://www.sockets.com.