General Architecture of TAPI 2.0
A version of this page is also available for
4/8/2010
The following illustration shows the general architecture of TAPI 2.0 for Windows Embedded CE.
.gif "Aa921181.4d1f1274-1403-41f7-b11a-afd82b31af09(en-us,MSDN.10).gif")
In the TAPI 2.0 architecture that is implemented in Windows Embedded CE, the Tapi.dll library file gets loaded in the Device.exe protected server library (PSL). Tapi.dll exports the TAPI set of functions that are supported in Windows Embedded CE. An application first links to the Coredll.dll file. When an application calls a TAPI function, Coredll.dll thunks the call to Tapi.dll in the process context of Device.exe. TAPI service provider DLLs are loaded by TAPI and executed also in the process context of Device.exe.
When an application that is based on Windows Embedded CE calls a TAPI function, the Tapi.dll library file validates and arranges function parameters, and then forwards them to the appropriate service provider. A service provider can provide different levels of the TSPI: basic, supplementary, or extended. For example, a simple service provider might provide basic telephony service, such as support for outbound calls, through a Hayes-compatible modem, while a custom service provider that has been written by a third-party vendor might provide a full range of inbound and outbound call management.
Underneath the TSPI layer, the service provider can use any system functions or other parts of the system that are necessary to work with kernel-mode services that are designed by OEMs, as well as standard devices, such as serial and parallel ports, to control external locally attached devices. The service provider also can access network services (such as Windows Sockets) for client/server telephony.