I just solved a puzzling issue that Frenkys posted in the ARDrone forum. And this was my first real visit to Dependency Hell.
The ARDroneDLL library did not work in Windows XP. So I installed a Windows XP SP3 as a virtual machine to find out about this problem. Visual Studio now gave me a DLLNotFoundException telling me that ARDroneDLL.dll could not be found. Since this was not true (it cleary is in the right folder), I started up Dependency Walker.
As a first thing, I saw that MSJAVA.dll was missing. But what the hell is MSJAVA.dll (Java Virtual Machine by Microsoft) doing in this project?? It turns out that it was a transitive dependency from some other library that was a transitive dependency of another library, and so on. So I installed this crappy VM. Now, the dependency was not missing anymore. But the problem stayed the same.
The next library that caused a problem was MPR.dll. As it turns out, “some versions of SHLWAPI.DLL (like the one on Windows XP) have a delay-load dependency”, so this is not a real problem, but rather a warning. The native Windows libraries can deal with this issue quite well, so there is nothing wrong with the library.
Now I got to the most interesting library. Kernel32.dll did had some errors. All the methods dealing with condition variables turned out not to be present. Very interesting. Searching for that issue, I found out that condition variables are not supported in Windows XP and below. So this DLL changed significantly.
So now, I could finally get to the root cause of the problem. Condition variables are used in the drone library. But the SDK developers had already thought about a fallback solution. You can deactivate using condition variables by commenting a definition line in one of the header files. A full rebuild later, I could see that the exception no longer occured.
I really hope that in the future, there will be exception messages that tell me what’s wrong when loading a library instead of obfuscating me. Please do me that favour.