Sheng Jiang 蒋晟

The ADO team had to make a breaking change the ADO APIs due to compatibility problem with Microsoft Office. Now it seems to be Tapi’s turn. In the 64 bit editions of Windows 8 and Windows Server 2012, some TAPI providers would stop getting incoming calls due to implementation changes in the TAPI service (TAPISRV) that had to be done for 64 bit compatibility.

The problem is pretty obvious from the documentation, for example LINE_NEWCALL has this:

htLine = (HTAPILINE) hLineDevice;
htCall = (HTAPICALL) 0;
dwMsg = (DWORD) LINE_NEWCALL;
dwParam1 = (DWORD)(HDRVCALL) hdCall;
dwParam2 = (DWORD)(LPHTAPICALL) &htCall;
dwParam3 = (DWORD) 0;

The parameters can’t really be passed as DWORDs – on a 64 bit build, pointers are 64 bit in size, and a DWORD is 32 bit.

Fortunately this can be corrected fairly easily, just ignore what the documentation said and treat the DWORD parameters as DWORD_PTR, however for the end users they would need updates from TAPI providers to get TAPI working on their Windows 8 /Server 2012 machine.

According to TAPI MVP Andreas Marschall, the following TAPI providers are affected (If you got a provider released before 2012,  it is likely also affected)

• Avaya TAPI
• Acatel-Lucent TSP
• NEC TSP (for PBX NEC SL1100)
• Siemens HiPath TAPI 120/170 (V2 R1.66.0)