DLL Search Algorithm Flawed

[Michael_D_]

We have upgraded from IPP 5.1 to 6.02. We also want to be compatible with Windows Vista or Windows 7. This means system32 is "off limits" as an install location for the IPP DLLs. We also don't like the PATH environment solution, since anyone can change the PATH and break the DLL search algorithm. Why doesn't the "waterfall" procedure look in the current directory? This would solve our run-time problem of missing DLLs. Please advise.

[noemata]

Quoting - pvonkaenel

Fair enough. I cannot come up with an example of when this "fix" might interfere with another linking model. I just get nervous when a low-level change is introduced that has the potential to cause unexpected side effects - I've introduced very elegant "fixes" to standard behavior in the past which ended up biting me later on and at the expense of very difficult debugging (and failing to remember I'd implemented the elegant "fix").

Out of curiosity, what did your management have against the static linking solution?

Peter

We had no trouble getting IPP to behave the way we needed it to for our own app. We implemented a custom installer and our own DLL loader and were still able to stick with implicit DLL linkage. The options Peter and others have outlined should cover any use case scenario.

If you absolutely need to stay clear of ANY potential issues, you could always build a custom version of anIPP based DLLthat exposes one API used to initialize a function pointer table. That way you could author as youdo now and use some header magic before building your production release to link with your private copy of IPP. Take a look at how "GLEW" works for OpenGL.

[elhefe38]

Quoting - matthieu.darbois

I really don't think that, when loading "dummyPathippi-x.x.dll", trying to load "dummyPathippioptimizedversion-x.x.dll" should be considered a non-standard behaviour. It may be non-standard behaviour for WINDOWS but should be standard for IPP. We have several ActiveX which use IPP and don't work with the dynamic link model. It's simply not acceptable.
You state ahead that : "The proposed IPP changemay help some people work around this issue, but it may also cause other developers new problems which are even more difficult to understand because the behavior is non-standard.". I do not agree with you, it will surely help developers to know that the optimized module loaded is the one which resides in the same path as the dispatch DLL. If you have for example IPP 6.0 in your path and, along with your activeX, IPP 6.0 Update 2, you might wonder why ippiTrueDistanceTransform fails with large images..

By "standard", I guess Peter meant "following Windows' rules for dll loading". And yes, what you describe is, following this terminology, totally "non-standard" :)
As for the rest, I do agree with you (mostly), except that changing a known (well...) behavior into a different one *might* be a pain when it comes to problem identification.
Still, static linking would be (in your case) a much more elegant and reliable solution (and in my own experience not increasing too much the size of the dlls, if you substract all the optimized ipp dlls you have to redistibute along with your product)
Regards

[noemata]

Quoting - elhefe38

By "standard", I guess Peter meant "following Windows' rules for dll loading". And yes, what you describe is, following this terminology, totally "non-standard" :)
As for the rest, I do agree with you (mostly), except that changing a known (well...) behavior into a different one *might* be a pain when it comes to problem identification.
Still, static linking would be (in your case) a much more elegant and reliable solution (and in my own experience not increasing too much the size of the dlls, if you substract all the optimized ipp dlls you have to redistibute along with your product)
Regards

Here's an explanation of "side-by-side",and a couple otherways of resolving these sorts of issues:

http://msdn.microsoft.com/en-us/library/ms811694.aspx

Look up "DLL hell" for complete examples of how to solve your install issues.

You should always have a private copy the DLLs your application relies on. It is the safest way of ensuring the correct behaviour of your app. Relying on how a system's path variable may be set is one way to induce premature hair loss. Updating the path variable in your installer requires esoteric installer operations that are error prone.

It's far simpler to install your application in a manner that eliminates any dependencies. That way, anything else in the system's path won't matter; your app will be immunized against it.

[matthieu_darbois]

This issue (#545821) is resolved in IPP 6.1. ActiveX can now be loaded when linked against IPPs DLL without having IPP in the path.

[Michael_D_]

Quoting - matthieu.darbois

This issue (#545821) is resolved in IPP 6.1. ActiveX can now be loaded when linked against IPPs DLL without having IPP in the path.

I have also verified this problem to be fixed in our latest build when using IPP 6.1. We no longer have to trash the system32 area with DLLs. Matthieu, Thanks for you diligence and support in this matter.