-
Hi All,
Actually my dll is the only one accessing the comport. There is no problem getting data and returning data to the different application loading my dll.
Example
I got 2 application both loading my dll concurrently. Let them be APP1 and APP2 where APP1 is the first application loading the DLL.
2 functions in my DLL. DLL_Ftn1, DLL_Ftn2
DLL_Ftn1 just computed some end result based on input parameters and return the result.
My DLL_Ftn2 actually gets data from from calling Application and sends over to comport. note that the dll is the only one accessing the com port.
APP1 and APP2 could call DLL_Ftn1 with different input arguments and also get the different computed result succesfully. This shows that there is no problem for the dll to dispatch data to the APP1 and APP2 although they both make calls to the same DLL_Ftn1.
I think that's because the DLL has got seperate data space for APP1 and APP2.
Problem lies here. When APP1 make calls to DLL_Ftn2, it works well. But when APP2 makes calls to DLL_Ftn2, it doesn't work. Although Dll generally has different data space, some data could be shared => APP1 and APP2 could both update a certain variable in the dll.
Although the dll is the only one accessing the com port, seems like the dll loaded by APP2 is not able to send the data out.
Is it really not achievable using purely a dll?
Learner
-
I think you are really confusing yourself with the way you understand DLLs. Your DLL does not access the serial port! It does not have it's own processing space. It is loaded into the other application's processing space and all it does is provide code for App1 and App2 to access the serial port (the same way as MFC DLL provides your applicaitons with high level routines).
-
I see that dll is able to share data between different processes using #pragma data_seg, that's why I thought its able to have its data space.
Hmm.. I guess you're right. Looks like using Dll for this function is really no way out.
Thks for your time and effort. :))
Regards
Leaner
