WinCE 调试某手写输入法时遇到的加载手写库失败的问题

调试某手写输入法时遇到的加载手写库失败的问题

在 WinCE6.0 下使用此手写输入法 SDK 做了一个单独的手写输入程序A(MFC Dialog 框架)。正常情况下，可以正常使用。

此 A 程序，采用 LIB 方式加载此的手写 SDK。

在运行某一带手写输入的程序 B 后，A 程序无法运行。首先怀疑 B 程序中也使用了此手写 SDK，导致加载冲突。

但仔细想想程序 B 和程序 A 应该运行在不同的进程空间，且最后确定程序 B 并未使用此手写。

进一步测试发现，如果程序 A 先运行，再程序 B 程序。虽然 B 可以正常运行，在手写输入后无法识别。

 

由于 A 程序，在 B 程序运行后根本无法运行，无法进行调试来分析问题的原因。参考再三，决定将 A 程序调用手写 SDK 的方式由静态加载修改为动态加载。

分析 A 程序，发现只调用了 4 个手写 SDK 的程序。采用 LoadLibrary() 加载 DLL 和 GetProcAddress() 加载此 4 个函数后

(1) 在不运行 B 程序时，4 个函数加载都成功，手写功能可以正常使用；

(2) 在先运行 B 程序后，发现有三个函数加载是没有问题的，其中一个函数无法加载成功，GetLastError() 得到的错误是: 87(参数不正确)。

 

在修改为动态加载后，测试过先运行 A 程序，再运行 B 程序。和以前的结果是一样的，B 程序的手写无法识别。

再次测试，将 A 程序中对手写 SDK 的初始化代码删除后，先运行 A、再运行 B 程序，B 程序一样无法手写识别。

至此，都未解决问题。

 

查看此 B 程序，发现其虽然没有使用此手输入法。但其使用的输入法与此手写输入法的 DLL 名称、DLL 中函数的名称完全是一样的。

将 A 程序使用的此手写 SDK 的动态库 DLL 改名，再次进行测试发现 A 程序和 B 程序可以完美的共存。

进行到这一步，问题已经解决，但对问题的根本原因(也就是解析)还不明白。

问题的关键在于运行 B 程序后为何 A 程序动态加载 DLL 中的函数时，那个函数会加载失败？两个独立的进程空间，为什么会冲突？