对 Windows TSF 的一些想法

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

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 的东西要处理?真的好想看一下微软输入法的源码啊。