A DOS TSR program is one that loads into memory upon execution of a DOS command and then returns the DOS prompt, letting the user go on to use the computer for other tasks. The TSR program remains in memory and is active, responding to user commands or other events, such as network traffic, until the user either unloads the program from memory or reboots the computer.
A Windows DLL runs only while Windows is active. A DLL module loads into memory and runs when an application, such as a remote login program, needs the services the DLL provides. The software module is "dynamically loaded" as needed. When the application no longer needs the services of the DLL, the DLL is unloaded automatically by Windows and no longer functions.
Windows provides for the ability to load and lock DLL modules into memory, even when no application requires the services offered by the DLL. These locked modules often load in fixed low memory, consuming system resources.
A third software device, called a VxD, is worth mentioning here. A virtual device driver, or VxD, runs only while Windows is active. A VxD is always active once it begins running. A VxD allows a networking kernel built for a single-tasking operating system such as DOS to interact correctly with the multiple active tasks possible under Windows by managing data exchanges between the kernel and Windows.
The basic elements needed for TCP/IP networking on a PC are network interface hardware, a network interface driver, a TCP/IP transport stack, and a network application. The machine must have the necessary hardware to connect to the network wire, commonly called a network interface card, and a software program to allow data to pass between that hardware and programs running on the PC, called a device driver. This network device driver must load and remain in memory for as long as the user (or a program running on the PC) wants access to the network. The basic TCP/IP transport program (or stack) communicates with the network hardware driver and also whatever applications the user needs, such as remote login (TELNET) or file transfer (FTP).
It is possible to build TCP/IP programs which load both the transport stack and the application into memory like any DOS program. When the user terminates the application, both the transport and the user application unloads from memory, like any DOS program.
However, most DOS-based TCP/IP implementations load the transport stack into memory as a TSR. The PC can thus respond to network events at any time, as well as provide the service needed to let the user run network applications, like remote login.
With the widespread deployment of Microsoft Windows 3.0 and then 3.1, TCP/IP was integrated into the Windows environment. The combination of both Windows and DOS operating environments on the PC presented two primary options for implementing TCP/IP services. The transport stack could be loaded into memory as a TSR before Windows was started, or the transport stack could be loaded into memory by Windows, using the DLL mechanism (or as a VxD which has been technically difficult due to a lack of development tools).
Note also that in the configuration showing the transport stack resident in DOS, there is a DLL available to the Windows-resident applications which manages communications between the TSR and the Windows applications.
The differences in performance between these two configurations lie mainly in memory usage and modes of operation. Depending on the level of network activity, there may also be a major performance degradation with a Windows DLL driver.
Today's network hardware and drivers operate in real mode. Real mode is DOS single-tasking execution, in which only one megabyte of memory is available and no other operations take place simultaneously. Windows uses protected mode as its native mode of operation, which lets Windows swap programs in and out of memory, giving the user the ability to run multiple applications that would not otherwise fit into the memory capability of the PC.
Hardware devices, such as network interface cards, alert software drivers and programs of some event by issuing interrupts. It is then up to the software application to process whatever data is presented by the hardware. This mechanism works in reverse when the software application needs to send data out on the network.
Because the network drivers today only run in real mode, and is expected to address a protocol stack's buffers at interrupt time, a Windows driver protocol stack must provide a stub DOS TSR or driver to act as an address translation mechanism between a protected mode Windows stack and a real mode driver.
This is usually accomplished through a protected mode to real mode call using DPMI (DOS Protected Mode Interface). The Windows stack must then leave a significant portion of itself locked in unmoveable Windows memory to handle the reverse situation, a network interrupt to the DOS stub that generates a real mode to protected mode DPMI call into the DLL protocol stack.
Note also that the DOS TSR kernel acts as a filter in passing packets to Windows; only packets destined for this workstation and active applications on this workstation make the real to protected mode transition. In the Windows DLL architecture, all broadcast packets and all unicast packets aimed at the workstation must make the real to protected mode transition. Any packets sent to the workstation for the purpose of network testing (such as PING) or network management (such as SNMP) must also make the transition. This can cause significant degradation of Windows response time on a busy network.
By locating the TCP stack within DOS rather than Windows, the network communications stack is free to operate outside the constraints of Windows. This method allows network communication without constraining Windows (though utilizing low DOS memory that Windows cannot then use for DOS box applications) until the stack is ready to exchange data with an application. The TCP/IP stack can respond to such network events as PING without significantly disturbing Windows applications. PING is often used by network administrators to determine the responsiveness of the various hosts on a given network. Some network monitoring and management software uses PING at standard intervals to refresh a network map. There may also be some speed advantage, as the PC's CPU is not constantly switching between real mode and protected mode. Windows native operating mode is protected mode; each switch to DOS real mode affects Windows performance.
It is important to note that an application can stop the operation of other Windows utilities or programs while that application runs. Networking software, to be effective and reliable, must have access to network events at all times. Due to the contending nature of Windows 386 Enhanced Mode having two schedulers, a preemptive one for virtual DOS machines and a non-preemptive one for Windows applications, a Windows- based protocol stack must walk a fine line between these two schedulers. This has to be carefully done to assure that it receives the timer interrupt by which it performs its protocol housekeeping and retransmit functions on a consistent and timely basis without being locked out by other computer-bound Windows applications. At the same time, the Windows protocol stack must be cautious not to monopolize the Windows scheduler and degrade the performance of other Windows applications.
A DOS TSR by definition occupies memory space. Most often, that space is within the DOS 640K operational limit (a limit which has long hampered DOS program operations). By loading a TSR within the DOS 640K space, the room left to execute user applications is necessarily reduced by the size of the TSR. Load enough TSRs and no other DOS program can execute. Windows itself occupies some DOS operating space. It is possible to prevent Windows from starting by leaving too little room in DOS memory.
This has often been a primary criticism of DOS TSR networking stacks. They take up too much memory in DOS. While Windows can address up to 16 megabytes of memory (one reason for protected mode operation), Windows swaps code in and out of memory. This lets the user work with more than one application at a time, even though the active applications together would require more memory than the computer offers. Windows DLL-based implementations of TCP/IP lock the transport into low memory, taking up resources just as a TSR implementation might.
The problem of memory resource management in DOS has been addressed by the use of memory managers. A DOS-based PC equipped with a memory manager can use 16 megabytes or more of memory, far larger than the original DOS 640K limitation. Windows uses such a memory manager to address memory greater than one megabyte. The processing chips make this possible by offering protected mode operation, in which programs can be loaded in the memory area above the one megabyte boundary.
PC/TCP offers the ability to load the largest portion of the stack into expanded memory, consuming very little DOS memory space. An expanded memory manager (EMM) provides a 64K "window" or page frame into which are swapped 64K blocks of extended memory, making much greater memory available to DOS applications. The user gains the benefit of a DOS-based TSR without paying the price of reduced DOS memory.
Within any organization, particularly large organizations with many people, PCs and networks, there is likely to be a mixture of environments present. Some machines may run Windows 3.0, some Windows 3.1 and some still only DOS. There are important differences in the operating behavior of the two Windows releases, and of course DOS is substantially different from both Windows releases. Using a TSR for network transport, an organization can standardize across all environments, reducing the number of versions to support and thereby simplifying the maintenance effort. The networking module is a known quantity in all cases.