Windows and Mac OS X both use the path of the executable for finding other dlls, but not the path of each dll that is loaded (that could be a lot of paths). I think GNU/Linux might do the same, I don't remember off the top of my head, but you so rarely encounter this on GNU/Linux since you're almost always installing dlls in the path (/usr/lib, /usr/local/lib).
With the Mac version of readanysf~, the libraries are loaded from a statically defined path (/Library/Pd/readanysf~). So to make an easily deployable readanysf~ for Windows, this issue will have to be sorted out.
Any suggestion on how to do that Hans? Is there a way to make it so that it tightly integrates with Pd-extended?
That part of Windows linking I don't know, so the thing to do is to find whether there is a way to add to the DLL load path, then make readanysf~ do that. That's probably a single function call. Otherwise, people will need to install the DLLs into pd\bin or \Windows\system32.
.hc
I guess what I am asking, is that now that it exists for all platforms, what in your opinion is the best strategy for including it in pd-extended? Or, is it already included?
Are there any other externals that package .dll's and .so files in pd-extended? Maybe we can look at this tomorrow in LA (if I make it).