I downloaded zlib and compiled the library as both Windows 32-bit and Windows 64-bit dll. I now have zlibwapi.dll
and zlibwapi64.dll
.
The d
Another good tool for examining Dll dependencies is Dependency walker (depends). It looks at the file in a static way so a little easier than using process monitor.
http://www.dependencywalker.com/
It is a fairly basic "file not found" kind of error, unfortunately it doesn't tell you explicitly what DLL it couldn't find. You already know about the issue with dependent DLLs. Note that you can avoid the irksome dependency on msvcr90.dll by compiling the code with /MT
You'll need to debug the problem and that requires getting insight in where it is looking for DLLs. One good tool is SysInternals' ProcMon utility, it shows you exactly where your program is looking for files. You should see it probing for the DLL, searching through the directories of the PATH and failing to find the file.
Unfortunately ProcMon is a bit chatty and has a habit of drowning you in the data. A more dedicated tool is GFlags.exe, a tool available from the Debugging Tools for Windows package. These days included with the Windows SDK. Stored in c:\program files (x86)\debugging tools for windows\gflags.exe after you installed it. You can turn on the "Show loader snaps" option. On later Windows versions, that tells the Windows loader to generate debugging messages when it is searching for DLLs. They'll appear in the Output window when you enable unmanaged debugging.
Try ProcMon first, much easier to get going.
And of course consider pure managed solutions so you are not fighting these kind of install problems. Good ones are DotNetZip and SharpZipLib, take their first google hit.