COM and ActiveX support has been added to SQLWindows/Team Developer in two fundamentally different ways: 1.5 and 2.0. Starting from 2.0, SQLWindows/Team Developer started also supporting COM servers, and the entire COM implementation was changed by adding new outline item types. However, Gupta's developers made a conceptual mistake at the time and confused interfaces with classes. For this reason, SQLWindows/Team Developer code that exposes COM servers has the implementation in the Interface item instead than the CoClass item.
Also, SQLWindows/Team Developer COM client support only works for the IDispatch interface (automation objects) and cannot support the faster and more direct dual interfaces. Basically, Team Developer can only call automation objects via the IDispatch interface. Another problem is that when COM support was added, Team Developer's error reporting system was not adapted. As a result, COM client methods are called using a more low level approach where the method call (or property setter/getter) always return the error code instead of the return value.
For these reasons, Ice Porter generates the same wrappers as the original SAL code, but the calls are dispatched through a real COM interface declared directly in the code. Also, when porting COM servers, Ice Porter fixes the interface mistake and moves the code implementation to the CoClass, with the added advantage of generating real COM dual interfaces.
After the conversion, COM code (both client and server) is much faster, robust and reliable than the original SAL code.