Hi Tom,
Well, you could try our TeleTools controls. There are 32bit and 64bit versions. You could also just compile to x86 and not "anycpu" or 64bit. Is there a reason they need a 64bit version? 32bit works just fine and unless there is another control that is in that project that only comes in a 64bit version, or there is a particular function (math/database) that might benefit from the wider address space, a telephony app won't run any better.
TAPI changed for UNICODE and 64bit. Tapisrv runs as a service and the API is exposed in a DLL. You will find the 32bit and 64bit versions of TAPI in the SysWow64 and System32 folders as Tapi32.dll. Both have the same name. There is also Tapi3.dll (yuck) which is COM and not an upgrade to TAPI 2.2, but just a wrapper around some of the main functions and a different way to manage audio.
The code for TAPI in any bitness is somewhat agnostic. Your "SafeLoadLibrary" call will find the right TAPI32.DLL. The only TAPI functions that are 64bit are some of the structures and handles. This is irrelevant in our controls since we handle all that, but coding to the Windows API, you would have to know where every pointer is and to code accordingly. In 64bit, things like lineMessage's Params which are now a DWORD_PTR, not a DWORD. Same with the handle to your callback routine for the events. So if your code/compiler doesn't make things handle the pointer size automatically for the different builds, then you can overrun memory or just point to the wrong place in memory. For example, if the old code used DWORD or Integer instead of a pointer type or "NativeInt" for these things, then you had a little work to do. If the old code used the right type and the compiler builds for a 32bit or a 64bit by internally recognizing those types as having changed for bitness, most code would run with no changes.
The last thing is pointer math. In order to navigate into a structure to find the value of a particular parameter from its offset (or if you use the UNICODE TAPI function calls like lineOpenW instead of lineOpenA), you need to have more agnostic code that accounts for the fact that a byte is not the same as a character now and a pointer can be either 32 or 64bit.
But here is a VERY IMPORTANT CONSIDERATION: What device are you using? Many of the telephony devices did not update their TSPs (Telephony Service Providers or drivers). Since they are also DLLs and you cannot call into a 32bit process from a 64bit one or visa versa, you will not be able to use any of those devices with a 64bit program (Some PBXs, original Dialogic cards, etc). I would recommend going with VoIP if you can. We also have a SIP driver to let you to connect to PBXs and VoIP SIP Trunks. So you can bypass the TSP on SIP enabled PBX if you want and go though SIP.
Fred Decker
ExceleTel Inc.
www.exceletel.com