On Monday, 8 October 2012 at 17:20:03 UTC, Regan Heath wrote:
Could XChat be loading your dll using:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx
and the flag DONT_RESOLVE_DLL_REFERENCES, or similar.
To debug, I would write a debug file using *C* IO functions
from DllMain, check it loads/runs/outputs to the file from your
dummy C host application, then try again with XChat and see
what you get.
You could also alter the dummy C host application to call
LoadLibraryEx and pass DONT_RESOLVE_DLL_REFERENCES and see what
happens.
R
Upon loading the application, which is when plugins are loaded,
DLL_PROCESS_ATTACH is invoked once. Subsequently,
DLL_THREAD_ATTACH is invoked 4 times. Then after about a second,
still during startup, DLL_THREAD_DETACH is invoked twice.
DLL_PROCESS_DETACH is then invoked once when closing the
application.
XChat uses gmodule - part of glib - to load plugins. I looked at
gmodule's Windows implementation, and it uses LoadLibraryW.
Despite finding all this, I still tried modifying the dummy host
to use LoadLibraryEx out of curiosity. An access violation occurs
in some druntime exception handling code as soon as I call into
the plugin's init function.
