Then maybe use some dummy plugin to debug the issue, like stub plugin (which is open source?).
You might have misunderstood my most recent comments above, but I did actually test this with the stub. The stub does nothing more than register itself with the engine's plugin API. All of the functions are no-ops. But when built with Visual Studio 2017, using the "v141_xp" toolchain, the AGS engine fails to initialize the stub with the exact same error message.
Ok, so if I understand you correctly, AGS3 games using any kind of plugins will no longer run under Windows XP. Is that correct? Given that XP is fifteen years old by now, I'm actually ok with telling people to do an upgrade, since we now know what's causing it. Thank you both for looking into this issue.
I don't think it's "any kind of plugins", but I think it must have something to do with the VC++ runtime
and the way the AGS engine is loading the plugins. My suspicion is that the engine is somehow expecting the plugin to have the same VC++ runtime libraries as it uses itself. I don't know if this is a limitation of the engine or the way it invokes the plugin functions, but it has always been my understanding that external libraries
should be allowed to link against a different C++ runtime, so long as that linked runtime is available (which is the case, due to static linkage).
I don't suppose it would help to build the plugin against the same VC++ runtime as the AGS main executable?
I will have to reinstall VS2008 to test this, but I will see what I can find out. (P.S. As an aside, I noted above that I had mucked some things up with the configuration settings of the stub when renaming the project (namely, when using the stub for "disjoint" builds, which I forgot to test). The stub should be able to build against VS2008, and I will upload relevant binaries and source once I'm sure that everything is working there properly.)