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 中的函数时,那个函数会加载失败?两个独立的进程空间,为什么会冲突?
原文地址:https://www.cnblogs.com/91program/p/5206237.html