views:

200

answers:

4

Hey, I need to use a 3rd party dll in our main app. When I staticly link to the provided DLL it works ok and I can the DLLs exported functions. But we don't want our main app dependend on this dll on startup so I tried to dynamicly load the DLL when I need it :

DLLHandle := LoadLibrary('3rdparty.dll');
ret := GetLastError();
if DLLHandle = 0 then
begin
  err := SysErrorMessage(ret);
  Writeln(err);
end //...

but did doesnt work : The LoadLibrary function returns 0 and the LastErrorcode is 3221225616. Because I don't know what I'm doing wrong I tried the same (on the same pc) coded in c and it works : but what doesn't it work with delphi ? : I call the same LoadLibrary function on the same dll!

When I monitor with ProcMon I see that the 3rdparty dll gets loaded and that also the dependand dlls of the 3rdparty dll gets loaded. : So windows certainly finds the DLL. But somewhere it the loading process it fails : When I try to load the DLL with LoadLibraryEX with DONT_RESOLVE_DLL_REFERENCES or LOAD_LIBRARY_AS_DATAFILE it also works (but I can't offcourse call the needed functions...)

I'm out of ideas : hope you guys can help me further...

thx in adv. Kristof

+5  A: 

3221225616 = STATUS_FLOAT_INVALID_OPERATION. My wild guess is that the FPU CW is different in your Delphi and C apps, and that your DLL's initialization is sensitive to this.

Craig Stuntz
+7  A: 

Does this work?

var
  SavedCW: word;

...

SavedCW := Get8087CW;
Set8087CW(SavedCW or $7);
DLLHandle := LoadLibrary('3rdparty.dll');
Set8087CW(SavedCW);
if DLLHandle = 0 then
begin
  ret := GetLastError();  
  err := SysErrorMessage(ret);
  Writeln(err);
end //...

Some discussion:

The error code, 3221225616, seems, when asking Google, to be the result of an invalid floating point operation. Now, this seems very technical; indeed, what does loading a library have to do with floating point computations? The floating point control word (CW) is a bitfield where the bits specify how the processor should handle floating-point errors; it is actually rather common that unexpected floating point errors can be dealt with by changing one of these bits to 1 (which by the way is the default state). For an other example, see this question of mine, in which I get a totally unexpected division by zero error, which is dealt with by setting the "div by zero" bit of the control word to 1.

Andreas Rejbrand
Thanks for the help but unfortuneatly it doesnt help. I keep getting result = 0 and errorcode=3221225616All ideas are welcome ...
I now changed $4 (binary 100) to $7 (binary 111). Does this help? (I suspect that the LSB is the troublesome one; if this is the case, it might suffice to do $1 (binary 001).)
Andreas Rejbrand
Yeah then it works thank you : I also tried with 5 and then it also works : I'm very gratefull for both your quick answers but I also want to understand whats going on :Can you explain it a bit to me or point me in the right direction where I can read about it ?Many thanks Kristof
Read my link and Danny's; that should help you understand.
Craig Stuntz
Kristof: The floating point control word bits control (among other things) how the FPU handles various kinds of floating point errors - division by zero, overflow, underflow, etc. The FPU can either ignore the error or raise a hardware exception. Most C/C++ RTLs disable FP exceptions. Delphi apps set the control word to enable certain FP exceptions. You can disable FP exceptions all you want, but think carefully about the consequences of ignoring errors that essentially indicate you have bad data running around in your app.
dthorpe
thx for all your info :What I find most peculiar is that when I staticly link it just worked : Does this meaan the fp cw is different when the app is still loading ?
For bacground info: I blogged about a similar issue a while ago, dissecting the 8087 control word flags: http://wiert.wordpress.com/2009/05/06/delphi-michael-justin-had-strange-floating-point-results-when-his-8087-fpu-control-word-got-hosed/
Jeroen Pluimers
When the app loads, the DLLs get loaded very soon in the process, most likely before the Delphi RTL sets the 8087 control word to the value it likes best. The DLLs probably expect the 8087 control word to be the operating system default.
Jeroen Pluimers
+5  A: 

Possibly related: http://discuss.joelonsoftware.com/default.asp?joel.3.88583.15

Try using SafeLoadLibrary() in the Delphi RTL instead of the Win32 LoadLibrary. This function preserves the FP control word before calling LoadLibrary, and sets it back to what Delphi wants after the LoadLibrary returns.

dthorpe
A: 

I think that you should report to 3rdparty.dll's developers about a bug in their DLL.

Alexander