In a computer using a Microsoft Windows® operating system, application programs (like Web browsers or E-Mail packages) ask for TCP/IP services by calling for them over a standardized Application Programming Interface (API) to a dynamically-linked library (.dll) known as a WINdowsSOCKet (winsock).
By constructing software in layers and agreeing on standard interfaces between those layers, different people can develop and offer specialized capabilities without having to re-invent their own version of everything that went before. Any Windows application program can get graphical user interface (GUI) functions familiar to many users by simply calling functions from a Windows API. Windows' GUI functions, in turn, pass-on operating system services (like opening files on a disk) which they get from DOS.
The de facto standard way of providing bytes of data to/from a TCP/IP connection on the Internet was developed for the Berkeley Unix operating system. It creates buffers in RAM that hold the bytes for a particular application program in what is known as a socket. This software layer sits between Unix application programs (some of which use the X-Windows GUI - no relation to Microsoft) that use the data from/to the sockets, and a TCP/IP stack that handles the Internet interface.
A variation on this theme of sockets was created to interface between Windows application programs (like Netscape Navigator®, Eudora®, etc.) and TCP/IP stacks that could run under DOS/Windows. Unsurprisingly, it is called the Windows Sockets (WinSock) API.
As long as Netscape's programmers (for example) adhere to this standard, they can get the TCP/IP services they need to download web pages from the Internet with function calls to this API. As long as people writing TCP/IP stack software (like Trumpet Software, for instance) provide a DLL called winsock.dll which contains those function calls and interfaces to their stack (tcpman.exe, in Trumpet's case) for TCP/IP services, their software can be used by anyone who wants to use Netscape, Eudora, etc. over a SLIP or PPP modem connection to the Internet.
NOTE: NetCom has a proprietary TCP/IP stack with an API that Netcruiser® can call, but which is not completely compatible with all of the WinSock API functions that other application programs might call.
Trumpet WinSock has become a shareware de facto standard, but there are (more expensive) commercial TCP/IP stacks for the DOS/Windows environment. The DOS7/Win4 operating system (Windows 95®) has its own TCP/IP stack with a winsock.dll that will provide WinSock API functions to both 16- and 32-bit application programs. It accommodates enhanced GUI calls for compatible application programs, but doesn't have the flexibility in tuning parameters for speed that Trumpet WinSock does. (For example, you can't set TCP MSS independent of IP MTU.) Trumpet has recently made available a 32-bit version of its winsock as beta (evaluation) software, which is obviously not as bug-free as a full-blown product.
NOTE: With any winsock, the packets of 8-bit octets in TCP/IP downloads get squeezed through a bit-serial com port after being speed-limited by your modem (if you have well-tuned TCP/IP settings). Hence, all winsocks are one-bit devices on the end that does the down-loading from your modem. The 16-bit winsock vs 32-bit winsock argument pertains to what kind of application programs you want attached to the other end of the winsock to use the data, not how fast you can get the data from the Internet.
Any winsock.dll has to be loaded into RAM (thus making its API functions available) by the communications program to which it is uniquely bound. No other winsock.dll can be substituted. If the program can't find its particular winsock.dll, or finds a "foreign" winsock.dll for another program, the Windows error message Undefined Dynalink will appear. The solution to this problem is to never allow more than one winsock.dll to be on the PATH defined in your autoexec.bat file (or its de-facto extensions like the windows\system directory).
NOTE: The WinSock API functions presented to TCP/IP-using application programs, and the serial (com) port interface of the dialer, are both standardized. The division of the rest of the internal software functions between the winsock.dll library and the dialer program that loads it varies between vendors, as do the procedure calls for those functions in the library. As a result, each winsock.dll can only be used with the matching dialer program with which it was developed (and into which its import library was linked).
Trumpet WinSock's TCPMan(ager) program must be on your PATH if you expect any WinSock application program (like a web browser, or E-Mail, etc.) to be able to load the winsock "on demand." Keeping its winsock.dll in that directory, and renaming any other winsock.dll in the windows\system directory to something else (like winsock.000) is necessary in that case to prevent such conflicts.
NOTE: If you start your applications from TCPMan's LOGIN.CMD script, you don't need to keep TCPMan on the PATH, since the correct winsock.dll is loaded into RAM before the application is started. A rapid-redialing Trumpet script that does this, as well as automatically adapting for multiple access providers, is downloadable from the CONTENTS page.
On start-up, any winsock-using application program first establishes that it can get a socket from the winsock - the set of buffers in RAM established by winsock.dll, where incoming and outgoing bytes from/to your Internet connection are held for that application program's exclusive use. If it can't, it will issue a WSAError message that a socket is not available.
The winsock will expect that, on exit, any winsock-using program will inform it that the program is finished with the socket (by invoking the winsock's WSACleanup routine), and winsock can de-allocate the system resources it obtained from Windows for that socket. If the program crashes, it won't go through such a clean shut-down, and winsock will complain with the error message <program name> Failed to Call WSACleanup.
Leaving Windows with unclear ideas as to who is using which particular part of memory is not a good idea. If another program tries to use the resources, even though your application is no longer using them, Windows' Virtual Memory Manager may think one program is trying to use another's memory space. It will then warn of a General Protection Fault at the memory location in question. To make these system resources available for use by other programs you will have to exit and re-start Windows, to re-initialize the VMM's list of allocated memory space.
This FAQ is available as a Windows Help® file for off-line viewing
Copyright© 1995 by Albert P. Belle Isle