So Solfege was presumably getting handed an outdated version of the dll to run, instead of the version installed in its bin folder. A typical DLL hell issue.
It's been years since I last recall fighting with DLL hell. So I guess that while .Net doesn't completely solve DLL hell, it has certainly mitigated the problem.
I first tried looking for the dll in c:\windows\system32. But there was no copy of zlib1 there.
I thought that the wrong DLL version might be somewhere on the environment PATH. So I then wrote the following Powershell script to search for the dll:
$paths = ($env:path -split ';' | % { $_ -replace '%SystemRoot%','c:\windows' } ) Get-ChildItem -path $paths -filter 'zlib1.dll'
This script showed that one of the Roxio folders is in the path and contains a zlib1 dll from 2010. So I removed Roxio from the environment path. But still I got that error message.
[If I'd thought to first check what order Windows looks for dll's in, I could have saved myself the trouble. It looks like the PATH variable is the last place searched.]
So where could the culprit be?
I then opened up the Process Explorer utility from the brilliant SysInternals suite. One of my most-used features in Process Explorer is the "Find handle or dll" menu item (CTRL + F). This showed that zlib1.dll was in c:\windows\SysWOW64...
That version of zlib1.dll was ancient - last modified in 2007. So I backed it up and copied a much newer version across.
And now GNU Solfege is working again!
No comments:
Post a Comment