Under TAPI version 2.0, a telephony service provider consists of, at a minimum, a 32-bit DLL that executes in user mode in the TAPISRV process. This DLL can create threads and synchronization objects within the TAPISRV context. If the service provider implements any user interface elements, it must also export user interface DLL functions (prefixed by TUISPI); these can be included in a single DLL along with the TSPI functions.
Because they are running within the context of a Win32 process, service providers can be re-entered in the same or different functions from separate threads. The service provider must be designed with proper synchronization mechanisms on global data and resources. For performance reasons, implementors are discouraged from requiring a single master mutex on the entire service provider, although such a mechanism can be advantageous during an interim period while porting 16-bit service provider code; TAPI provides this mutex if requested by the service provider during TSPI_providerInit. TAPI is also so that it does not call a telephony service provider function on the same thread the telephony service provider used to call the LINEEVENT, PHONEEVENT, or ASYNC_COMPLETION callbacks in TAPI. However, it is possible for the service provider to be entered on other threads while it is executing in a TAPI callback function.
Service providers using TAPI version 2.0 must support at least TSPI version 2.0, including all data structure members. TAPI will not adapt older service providers to work with newer applications.
In accordance with the Win32 standard, all TSPI functions are imported by TAPI by name, rather than by ordinal, as was the practice in previous 16-bit implementations. The performance differential, which was significant in 16-bit Windows, is very slight in Win32 and no longer justifies the relative complexity, confusion, and risk of error that is possible in requiring service providers to export TSPI functions by ordinal.
Except as noted in TSPI Functions, all strings passed into or returned by service provider functions must be in Unicode.
TAPI no longer uses the telephon.ini file for storage of telephony parameters. Service providers, like all Win32 services, must use the registry for storage of persistent private data. This data is not placed in TAPI's section of the registry, the format of which is not guaranteed to be maintained in future versions. Service providers should create their own branch under the Software key. Service providers should not directly access their registry parameters from within the context of an application (for example, directly from a TUISPI function), but should instead pass requests back to the main service provider DLL in the TAPISRV context for synchronization and processing.