Dear all,
I would be happy to get some help regarding the folowing linking problem between a commercial program and a LV DLL produced from a very simple VI.
I give you the facts:
1) The commercial program (pippo.exe) make use of its own ini file (pippo.ini). Of course that file is managed by the program in a manner that I don't even want to know: it's its conf file.
2) pippo.exe has its own plu in mechanism which works using DLL exporting a certain interface.
3) I have developed an interfacing DLL (pippo-lv.dll) whose only purpose is to call the function SUMFUNCTION() built from a VI (sumfunction.vi) and embedded in a shared library (sumfunction.dll) (actually a sum of two doubles).
4) Note that the LV builder output also a sumfunction.ini file. I suppose it is a config file for the dll, I understand that it may be useful for complex applications, but it is totally useless in this example and probably in my application.
However, here is the problem: when pippo.exe loads the plug-in, pippo-lv.dll, (this happens at run time when the user of the program performs certain actions), and the loader loads the sumfunction.dll and in chain all the dynamic link libraries from which it depends, the file pippo.ini get corrupted! As the program reads the file after the dlls are loaded, it starts to behave badly because it can't manage the corruption of its configuration file (pippo.ini). The presence or not of the sumfunction.ini file beside sumfunction.dll does not change the effect. The only way to avoid the corruption is to place sumfunction.dll somewhere the system can't find it, which of course stops the load of the entire plug-in.
The original ini file is the folowing:
<path>
<string>
<three lines of numbers>
The corrupted file becomes:
[LVFFRT]
<path>
<string>
<three lines of numbers>
It seems to me that the lvffrt.dll library tries to write where it shouldn't. Please note that the entire mechanism works perfectly if a make the calls to the plug-in from a test program.
Any one has an idea of how this could be solved? I can't change the logic of the commrcial program of course and I have not seen options to prevent the tampering of the NI RTE dlls with the configuration file of the original program that makes use of them. Is there a way to stop this behaviour? This problem prevents me to deploy my plug-in for the program using LV.
System configuration:
Windows 7 enterprise SP1 32-bit
LabView 2010 with Professional Develomet System v10.0.1 (32-bit)
Eclipse-MinGW to build C/C++ layers and test program
Sincerely,
Anton
