Windows 3.1 used a monolithic communications driver, COMM.DRV, that provided an API for Windows-based applications to interact with communications devices and the code that served as the communications port driver. This approach made it necessary to completely replace the Windows communications driver if new functionality was required by a hardware device.
Windows 95 provides a more flexible communications architecture by separating communications operations into three primary areas: Win32 communications APIs and TAPI, the universal modem driver, and communications port drivers.
VCOMM is a new communications device driver that provides the protected-mode services that allow 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 the new Plug and Play services in Windows 95 to assist with configuration and installation of communications devices.
The following figure shows the relationship between the VCOMM communications driver and the port drivers that communicate with hardware devices.
The flow path for a Win16-based application is also illustrated in the previous figure 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 list describes the primary areas that make up the architecture.
Win32 communications APIs and TAPI.
The Win32 communications APIs in Windows 95 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 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 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 mini-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 driver. Port drivers provide a layered approach to device communications. For example, Windows 95 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, 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 95. All communications services provided with Windows 95 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 phone 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 in a cooperative manner. 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. The following figure shows the relationship between the front-end TAPI and the back-end SPI.
