This section describes the following topics:
Windows 98 separates communications operations into three primary areas: Win32 communications APIs and the Telephony API (TAPI), the universal modem driver, and communications port drivers. Figure 29.28 shows the communications architecture.
Figure 29.28 Serial Communications architecture
VCOMM is a communications device driver that provides protected-mode services allowing Windows-based applications and drivers to use ports and modems. To conserve system resources, communications drivers are loaded into memory only when in use by applications. Also, VCOMM uses Plug and Play services in Windows 98 to assist with configuration and installation of communications devices.
Figure 29.28 also illustrates the flow path for a Win16-based application to show how compatibility is maintained when hardware or software vendors replace the Windows 3.1 Comm.drv driver. The vendor-specific communications driver, however, communicates directly with the I/O port, rather than through VCOMM.
The following paragraphs describe the primary areas that make up the architecture.
Win32 communications APIs and TAPI.
The Win32 communications APIs in Windows 98 provide an interface for using modems and communications devices in a device-independent fashion. Applications call the Win32 communications APIs to configure modems and perform data I/O through them. Through the Windows Telephony API (TAPI), applications can control modems or other telephony devices.
Universal modem driver.
The universal modem driver (Unimodem) is a layer that provides services for data and fax modems and for voice so that users and application developers will not have to learn or maintain difficult modem AT commands to dial, answer, and configure modems. Rather, Unimodem does these tasks automatically by using miniport drivers written by modem hardware vendors.
Unimodem is both a VCOMM device driver and a TAPI service provider. Other service providers (for example, those supporting other devices, such as an ISDN adapter, a telephone on a PBX system, or an AT-command modem) can also be used with TAPI.
Port drivers.
Port drivers are specifically responsible for communicating with I/O ports, which are accessed through the VCOMM device driver. Port drivers provide a layered approach to device communications. For example, Windows 98 provides a port driver to communicate with serial communications and parallel ports, and other vendors can provide port drivers to communicate with their own hardware adapters, such as multiport communications adapters. With the port driver model in Windows 95 and Windows 98, it is not necessary for vendors to replace the communications subsystem as they did in Windows 3.1.
Windows Telephony API.
TAPI-aware communications applications no longer need to provide their own modem support list because interaction with a modem is now centralized by Windows 98. All communications services provided with Windows 98 use these services.
TAPI provides a standard way for communications applications to control telephony functions for data, fax, and voice calls. TAPI manages all signaling between a computer and a telephone network, including basic functions such as dialing, answering, and hanging up a call. It also includes supplementary functions, such as hold, transfer, conference, and call park found in PBX, ISDN, and other telephone systems. TAPI also provides access to features specific to certain service providers, with built-in extensibility to accommodate future telephony features and networks as they become available.
TAPI services arbitrate requests from communications applications to share communications ports and devices cooperatively. Win32-based applications can use TAPI functionality to make outgoing calls while others are waiting for incoming calls. Of course, only one call can be performed at a time, but users no longer have to close applications that are using the same communications port.
TAPI consists of two interfaces: an API that developers use to write applications and the service provider interface (SPI) that applications use to establish the connection to the specific telephone network. This model resembles the computer industry model for printers, in that printer manufacturers provide printer drivers for Windows-based applications. Figure 29.29 shows the relationship between the front-end TAPI and the back-end SPI.
Figure 29.29 Telephony API and service provider interface
Windows 98 includes several new components in its Dial-Up Networking architecture. This section gives an overview of the new architecture and then breaks it down into the following areas:
For more conceptual information about Dial-Up Networking and PPTP, see Chapter 19, "Remote Networking and Mobile Computing."
This section describes many of the components included in the Dial-Up Networking architecture, which is shown in Figure 29.30.
Figure 29.30 Dial-Up Networking architecture
Following are descriptions of the major user-mode components in this architecture.
Rnaui.dll.
An Explorer extension that implements the Dial-Up Networking folder and invokes Rnaapp.exe to dial.
Rasapi32.dll.
The main Windows 98 RAS API DLL. It supports the Phonebook APIs.
Smmscript.dll.
Implements the session manager modules (SMMs), which enable new dial-up protocol implementations to be rolled under the RAS API and the user interface.
Rnanp.dll.
A Windows 98 network provider DLL.
Directcc.exe.
The Direct Cable Connect alternative user interface for connecting computers directly, using a serial or parallel cable. The first time it is run, it creates modem entries that are hidden from the Modems option in Control Panel but appear in the System option.
Following are descriptions of the major kernel-mode components in this architecture.
Pppmac.vxd.
Implements the core RAS protocols: PPP, SLIP, Asynchronous NetBEUI, and NetWare Connect.
Ndiswan.vxd.
Supports network driver interface specification wide area network (NDISWAN) miniport drivers. It is installed as a protocol and appears in the Network option in Control Panel as a protocol. Each adapter that is installed is bound to the NDISWAN protocol, and NDISWAN miniports bind only to the NDISWAN protocol.
Figure 29.31 shows how the components of Dial-Up Networking work together when Dial-Up Networking is setting up a call over a modem or ISDN device.
Figure 29.31 Call control for modems and Integrated Services Digital Network devices
To set up a connection over a modem, a user first starts a Dial-Up Networking connection. The Dial-Up Networking engine looks for information about the telephone call in the Phonebook and then queries TAPI for the available TAPI devices. Next, it places a call on the device specified in the Phonebook entry. TAPI translates the device to the correct TAPI service provider (TSP) (in this case, the Unimodem TSP). The Unimodem TSP translates the Dial-Up Networking command to specific modem commands, and then sends the modem commands to Unimodem.vxd. Unimodem.vxd sends them to VCOMM, which sends them out a serial or parallel port to a modem.
The process is similar for an ISDN card. However, TAPI uses the WAN TSP rather than the Unimodem TSP. The WAN TSP passes the commands through NDISWAN and to the ISDN driver’s TSP, and the ISDN driver’s TSP translates the commands.
Figure 29.32 shows an example of what happens after a call has been set up and data is being transferred. This example shows data transfer over a modem.
Figure 29.32 Data transfer for modems
In this example, data is sent through the Windows Sockets DLL. The TCP/IP stack then encapsulates the data in TCP and Internet Protocol (IP) and then sends it to Pppmac.vxd (the component that implements the RAS protocols). Finally, Pppmac.vxd encapsulates the packet in a PPP frame and sends it to VCOMM.
Virtual private networking (VPN) is a secure method for creating an on-demand connection between two computers in different locations. The virtual private network consists of the two computers (one computer at each end of the connection) and a route, or tunnel, over the public or private network. Virtual private networking is implemented in Windows 98 using the Point-to-Point Tunneling Protocol (PPTP).
This section describes the Windows 98 architecture that supports virtual private networking.
For more detailed information about virtual private networking, see Chapter 19, "Remote Networking and Mobile Computing."
Figure 29.33 shows call control for a PPTP connection over a modem. Contrast this diagram with Figure 29.31, which showed call control for an ordinary Dial-Up Networking connection. In Figure 29.31, the call request passes through the Unimodem TSP. In Figure 29.33, it passes through the WAN TSP instead.
Figure 29.33 Call control for a Point-to-Point Tunneling Protocol tunnel over a modem
Figure 29.34 shows PPTP data transfer.
Figure 29.34 Data transfer for a Point-to-Point Tunneling Protocol tunnel over a modem
In this example, data is transferred using Client for Microsoft Networks and sent out over a modem. It could also be transferred using Client for NetWare Networks and sent out over an Ethernet connection or an ISDN device.
The data is sent by Vredir and encapsulated in IP. As with a normal data transfer, it is sent to Pppmac.vxd. In a normal data transfer, however, the data would have been sent through the Pppmac.vxd VCOMM interface to VCOMM. Here, it is rerouted instead through the Pppmac.vxd NDISWAN interface.
From there, it travels to Netpptp.sys, the component that handles the PPTP connection. Netpptp.sys transfers the PPP data to the TCP/IP stack, where it is encapsulated in GRE (defined in RFCs 1701 and 1702.).
It is next sent back through NDIS to Pppmac.vxd, which encapsulates it in PPP and sends it through VCOMM to the serial port and, finally, to the modem.
Figure 29.35 shows the encapsulated packet that is finally sent to the modem.
Figure 29.35 Internet Protocol datagram containing encrypted Point-to-Point Protocol packet