Problems with calling al dll inside a dll called by LabVIEW

[chrisger]

hi there

i got a 3party DLL (let's call it DLL A) written in C++ (no sourcecode available). Because i can't call this dll directly from LabVIEW (it exports a class) i created another dll as a wrapper (let's call that DLL B) with a single function "void function_B(void)". For debbuging "function_B" writes the results calculated by functions from DLL A (some doubles) to a textfile.

Now the problem:

when calling function_B from a C++ - Programm i wrote by myself all works fine. the doubles in the debug-file have the correct values.
when calling function_B from a LabVIEW - Programm all the data in the debug-file is rubbish!

Once again: function_B has no parameters (void function_B(void)). all calculations and file-IO takes place in function_B! The C++ - Programm and the LabVIEW - Propram just calls function_B.

anyone got some ideas?

thanks and best regards
chris

[becktho]

Hi chris

If I read your problem-description, paths come up in my mind. Check all the path settings - these may always cause problems.
In addition to that it may be helpful, if you could post the dll's so that we can have a look at this behaviour.

Thomas

[chrisger]

hello Thomas,

there's only one copy of both DLLs A and B on my system, so i'm sure that i call exactly the same function_B from LabVIEW and the C++ - Programm.

I'm sorry, but i'm not allowed to post the 3Party - Dll. The Function_B looks similar to

void Function_B(void){

DLLAObject myDLLAObject; // new object of the class exported by DLL A
ofstream myfile; // the debug-file

myfile.open("c:\\debug.txt");
myDLLAObject.Init();

for(int i = 1000; i < 4000; i+=100){
dblData = myDLLAObject(double(i));
myfile << dblData << endl;
}
myfile.close();
}

You see, the code is really not that interesting!

best regards
chris

[becktho]

Hi Chris

Yes this code is very simple.

But I still think there must be some kind of linking-problem (from DLL B to DLL A). I could imagine, that all these things are correct if you run a simple c++ program whether in the IDE or the exe, and that these settings may be incorrect if you use it with LV.

I know this sounds strange, but as I said - the code in DLL B is very simple and I just could imagine that there might be problems in calling DLL A.

Maybe you could do DLL B in C.Net and use the built in .Net functions.

Thomas

[chrisger]

hello thomas,

thanks for your answer.

i just got a new COM - Version of the 3Party DLL A which i can call directly from LabVIEW via automation. When i call the object from VC++ or VB all is fine. But when i call it from LV i got EXACTLY the same data rubish as described in my first post, but this time without a layer of code between LabVIEW and DLL A! So the problem is definitely part of DLL A. I'll give the DLL back to the supplier.

thanks & best regards
chris

[becktho]

Hi Chris

I see. This is the problem using IDEs as VC++ or similar. All the settings and paths are correct and if you use a single dll "standalone" in anohter project, it may not work anymore.

But anyway - I hope you'll get a working version of the DLL ;).

Thomas

[rolfk]

I can think of two reasons.

- C (well Cpp here) runtime intialization

This would be a nasty one to track down.

- Floating point unit state preservation

LabVIEW in order to maintain a coherent state of the floating point unit for its own internal use (think all the mathematical operations etc) has to make sure that no external code is trashing the FP registers from its own expected state. So most likely LabVIEW is saving the FP registers state before each single call to an external code to be restored after the external code returns. If this external code assumes its own consisitent FP registers set between multiple calls to its function it will get inconsistent floating point arithmetic results. This would be really a bug of the external code, since a library can't expect the floating point registers to stay coherent between different calls to its own functions.

Other things LabVIEW does around external code: exception interception which might interfere with a particular C++ exception implementation in an external library somehow. Not every C++ compiler uses the same exception handling. Windows uses SEH but that is supposedly protected by a Borland patent, so gcc for instance uses a different mechanisme through registers.

Rolf Kalbermatter

Message Edited by rolfk on 06-07-2005 03:42 AM

[chrisger]

hello rolf,

thanks for your answer. I wonder that the rubbish data is always EXACTLY the same, no matter if i call DLL A via DLL B or directly with COM automation, so i rather think it has something to do with runtime libraries inside DLL A. i checked the dependencies of DLL A, and there are lots of MFC - libraries linked to the DLL.

anyway, i made it a opp (other peoples proplem) and sent the DLL back to the supplier.

best regards and thanks
chris

[becktho]

And there we are - in the little lovely MS-World.

Use VC++ and MFC and you have no problem - but beware of splitting these things up and leaving this little lovely world...

This is so annoying >:(.

Message Edited by becktho on 06-07-2005 01:39 PM

[rolfk]

---

@becktho wrote:
And there we are - in the little lovely MS-World.

Use VC++ and MFC and you have no problem - but beware of splitting these things up and leaving this little lovely world...

This is so annoying >:(.

Message Edited by becktho on 06-07-2005 01:39 PM

---

Programming self contained libraries using MFC is IMHO a sure way to make them absolutely inoperable. C runtimes can already be difficult enough at times but adding MFC to this is simply a misdeed which should be severaly punished in a dungeon or something like this. If someone wants to make his application depend on MFC that would be his business but to make DLLs to be called from different environments depend on MFC is just a deadly sin.

Rolf Kalbermatter