On Thu, Nov 7, 2024 at 6:21 PM Thiago Macieira wrote:
>
> It's usually too late too. If you've loaded an ABI-incompatible plugin into
> memory, you're already in dangerous territory. This plugin may have load-time
> initialisation content that will cause crashes or data corruption.
>
> You need to determine whether the plugin should be loaded before it's loaded.
> That's metadata information that cannot be obtained from C++ and cannot be
> created by C++ alone.


I'm currently working on a wxWidgets project to load pretty much any
kind of GUI plugin into it (e.g. ActiveX control, DotNet plugin):

    https://forums.wxwidgets.org/viewtopic.php?f=1&t=51469

In cases where the plugin itself is written in wxWidgets, here's how I
ensure that the main program is linked with the same wxWidgets library
as the plugin:

    - The main program asks the plugin for the address of the function
wxUninitialise, and compares it with the address of its own
wxUninitialise

Sort of like this:

        if ( &::wxUninitialise != Plugin_GetAddrOfUninit() )
        {
            // cannot load plugin -- two different versions
        }


> QPluginLoader does something like this. The QPlugin side of it creates a
> special section in your binary with some metadata that tells the loader some
> things about the ABI (for us, what matters are simply the Qt versions). But
> the QLibrary/QPluginLoader side has a parser that can find this metadata and
> decide for itself whether to attempt to load or not. We also have a few
> techniques that would cause a plugin that is incompatible to fail to load in
> the first place.


I'm focusing at the moment on loading Qt plugins into a wxWidgets program:

    https://forum.qt.io/topic/159495/gui-program-accepts-various-kinds-of-gui-plugin

I get the Qt plugin to render the widgets into a pixel array, and then
the wxWidgets main program draws the pixels on a panel on screen. Now
just need to figure out how I'm going to forward the mouse and
keyboard.