> > A bit more important: would it make sense to include the hook *in the > > QEMU executable itself*, rather than in the DLL? If it works, it would > > be much preferrable. You still would have to add the .lib file to the > > compilation, but win32_linker.c could simply be placed in os-win32.c > > with fewer changes to meson.build and the makefiles.
> My initial trials of this didn't work. But having read the docs again, I'm > going to have another go at it now... Here is a diagram of what's going on. /---dynamic load------v qemu libplugin.dll ^---delay load--------/ First, qemu dynamically loads the plugin, which does no linking. It finds the function qemu_plugin_install, and invokes it. As soon as libplugin.dll calls any qemu_plugin_* function, the delay loader steps in and searches for qemu.exe. It fails to find it, and the delay failure helper steps in and returns the right reference to the top level executable. Everything gets linked OK. Windows will look for __pfnDliFailureHook2 in the module doing the delay loading, which in this case is the plugin DLL. So, the __pfnDliFailureHook2 function pointer needs to be in the plugin DLL. We could have qemu set the value of that pointer before it calls install, but I can't find the way to expose a function pointer in such a way that `g_module_symbol` can find it. Possibly we could pass in a pointer to it in qemu_plugin_install or a new qemu_plugin_set_linker_fn, but that is getting back to the sort of shenanigans we're trying to avoid, and which previous attempts at windows plugins were based on. so: maybe, but I'm not sure it would be any tidier. Greg. -- Follow Rapita Systems on LinkedIn<https://www.linkedin.com/company/rapita-systems?utm_source=rs_email_sig>