Is there some issue between the vgmstream plugin and Winamp 5.61? by TheUltimateKoopa at 7:55 PM EDT on March 26, 2011
For some reason, the vgmstream plugin doesn't appear in the list of input plugins, even though I have in_vgmstream.dll in the plugins folder. I have Winamp 5.61 which was released March 17th, and er whatever the latest vgmstream version was, released around March 23rd or something.
I seem to remember that, upon updating, winamp can mess with the extra .dll files that vgmstream needs. try redownloading the extra .dll files listed in the vgmstream readme file and replacing your existing ones.
Winamp's rebaser process corrupts various 3rd party plugins during an update for no reason. It shouldn't be touching the files at all yet they insist on it being required.
You need to either replace the extra dll files or the in_vgmstream.dll file.
It is likely an issue with how I build the dlls that makes it susceptible to this problem. dr0 tried to explain it to me but I never quite got the hang of it. vgmstream doesn't look anywhere for the dlls, it relies on the runtime linker to pull them in, so they have to be in the main directory. Actually dynamically looking for and loading them would be a good step, but one that we have not yet taken.
maybe the installer shouldn't run the re-basing tool on all of the dlls it finds in the root Winamp and plug-ins folder but not doing it on all of the potentially loaded dlls by the Winamp process (and via loaded plug-ins) defeats the point of re-basing the dlls and the proven increase in loading time it generates. that is why it touches any dlls it finds and bar a handful of people, it works as intended for the vast majority of those people using the versions with it installed - more people complained about crashes from Chipamp (due to the older SNESamp version shipped) with the 5.6 release than have ever mentioned this dll re-basing issue.
if using the MSVC compilers, it's simple to have the supporting dlls handled via delay-loading which basically adds in LoadLibrary(..) + GetProcAddress(..) stubs on the dlls it's been set on. no idea about other compilers or why the OSes function used doesn't like the supporting dll which fails.
either way, when i looked, there isn't a way to auto-detect dlls which aren't going to like being re-based from what i was able to find and no one is keen on hard-coding an exclusion list into the NSIS plug-in used.
so the simple option (as mentioned before) if it's not viable to change how vgmstream loads the dlls is to set the supporting dlls to read-only so the OS function cannot change the dlls.