In Windows Vista, TSF added the ability to run in locations where it had previously been disabled. For example, TSF is now available on secure desktops, in full screen (DirectX) applications, and in MTA threads. However, text services have to be aware of these new environments, and must tell TSF that it is aware of these environments.
A text service that wishes to run in one of these new environments (e.g., UI-less mode, secure mode, or console mode) must implement ITfTextInputProcessorEx instead of ITfTextInputProcessor:
TSF will CoCreateInstance() this interface.
Next, text services that implement ITfTextInputProcessorEx must also register under one or more of the appropriate categories: GUID_TFCAT_TIPCAP_COMLESS, GUID_TFCAT_TIPCAP_SECUREMODE, GUID_TFCAT_TIPCAP_UIELEMENTENABLED, or GUID_TFCAT_TIPCAP_WOW16.
What do these categories mean?
Text service will be launched on the secure desktop.
Text service implements ITfUIElement, and draws its UI accordingly.
Text service can operate without COM. See below.
Text service can work with Win16 applications. All text services in this category are assumed to be in the GUID_TFCAT_TIPCAP_COMLESS category as well.
Previous versions of the TSF Manager had a number of application compatibility problems with COM threading models, particularly with applications that were not TSF-aware. In Vista, the TSF Manager can create text services without using COM (by loading the DLL directly and calling DllGetClassFactory). However, there are obvious restrictions on text services - namely, that the service itself cannot use COM, either. If a text service follows these restrictions, it can register under the GUID_TFCAT_TIPCAP_COMLESS category, and be active in more applications.
COM-less text services can still create COM objects, but they cannot use CoCreateInstance(). Instead, COM objects can be allocated off the heap, or ATL-based text services can use CComObject<T>::CreateInstance().