An error occurred while loading the handwritten library when debugging a handwritten input method by wince.

When debugging a handwritten input method, the problem of loading the handwritten library failed. In wince6.0, the handwritten Input Method SDK made a separate handwritten input. Program A (MFC dialog framework ). Under normal circumstances, it can be used normally. This a program uses lib to load this handwritten SDK. Program a cannot run after program B is input manually in a certain area. First, I suspect that this handwritten SDK is also used in program B, resulting in loading conflicts. But think about how program B and program a should run in different process spaces, and finally confirm that program B does not use this handwriting. Further tests show that if program a runs first, then program B. Although B can run normally, it cannot be identified after handwriting input. Because program a cannot run after program B runs, it cannot be debugged to analyze the cause of the problem. For reference, I decided to change the method for calling the handwritten SDK of program a from static loading to dynamic loading. After analyzing program a, we found that only four handwritten SDK programs were called. Use loadlibrary () to load the DLL and getprocaddress (). After loading the four functions (1) when the program B is not running, the four functions are loaded successfully, and the handwriting function can be used normally; (2) After running program B, it is found that there are no problems in loading three functions. One of the functions cannot be loaded successfully. The getlasterror () error is: 87 (the parameter is incorrect ). After being modified to dynamic loading, the test first runs program a and then program B. The result is the same as the previous one. the handwriting of program B cannot be recognized. Test again to initialize the handwritten SDK in program. Code After the deletion, run a and program B first. Program B cannot be recognized by handwriting. At this point, the problem has not been resolved. Check the program B and find that it does not use the input method. However, the input method used is the same as the DLL name of the handwritten input method and the name of the function in the DLL. Rename the dynamic library DLL of the handwritten SDK used by program A. test again to find that program a and program B can coexist perfectly. At this step, the problem has been solved, but the root cause of the problem (that is, the analysis) is still unclear. The key to the problem is, after running program B, why does program a fail to load the function in DLL dynamically? Why are two independent process spaces in conflict?