对 Windows TSF 的一些想法

在 windows-rs 里暴露出了几个有意思的 GUID :

• GUID_TFCAT_TIPCAP_LOCALSERVER
• GUID_TFCAT_TIPCAP_TSF3

windows-rs 是 winmd 生成的，虽然最近才发现它们已经在 win32 metadata 的源里躺了很长时间了，但之前就从几个地方对这些东西有所了解。

先说说 LocalServer ：这里的 LocalServer 指的就是 COM 的 LocalServer 了，一个以 exe 方式运行的 COM server 。与之相对的就是现在各类 TSF TIP 实现常用的方法 InProcServer ，即作为 DLL 加载进目标进程中。目前只有微软的输入法实现了 LocalServer 的运行模式，因为 TSF 的文档里根本就没说这件事。 TSF 文档水平实在很烂，还不更新，也没什么资料，基本靠自己瞎猜和看别人怎么写。

用 LocalServer 有几个好处，首先不被加载进别的进程有一定的安全性，同时也不会因为输入法的故障而使应用程序出问题。微软在 Win8 时的文档里，想规定 TIP 不能和本地的其他程序进行通信，只能用 web 的方式去进行一些网络通信，比如实现云输入法的功能。但这样本地词库、皮肤等各种自定义功能不也就废了么？所以微软虽然文档上装了个大B，但实际上口子放得很大：常见的通信方式是在 TIP 和输入法后端间架一条 Named Pipe ，但由于 Pipe 只是方便单向的请求，所以像 mozc 还会让 TIP 创建一个不显示的窗口，通过窗口的信息来实现双向的通信。如果换用 LocalServer ，就完全没有这样的问题，反正我已经跟目标程序毫无关系了，你还管我干嘛吗？

这样说来，是不是 GUID_TFCAT_TIPCAP_COMLESS 也没有意义了呢？既然没有 DLL 加载进目标程序，系统的 TSF 框架来和我通信，加不加载 COM 也不会影响到目标程序，该 obsolete 了。

再说说 TSF3 ： Edge 的某个设计文档里提了一嘴这个内容，另一方面，通过对 ChsIME.exe 的符号进行观察，可以发现它用了很多 ITsf* 的 COM 对象，而不是 ITf* 开头的对象，难道等 TSF3 出来的时候又要重写一遍输入法？具体改动了什么就不好说了，对 COM 的逆向一窍不通，只能简简单单看函数的名字和一些简单的函数在干啥，来猜一猜。

另一件值得提的是， mozc#819 指出微软的输入法现在只通过异步的方式处理 EditSession ，是不是新版的 TSF3 里会对异步支持比较好呢？不过 TSF3 还是要向下兼容 TSF 的，那么面对那些头疼的 TSF Aware App ，是不是又多了一层类似 Cicero 的东西要处理？真的好想看一下微软输入法的源码啊。