The machinery needed to support the "manual" plugin as a DLL
file on Windows is very complex.
This is because we build Mumble itself as mumble_app.dll and link
our dependencies statically. And also because of various changes
made in Qt 5.
The manual plugin uses Qt. When Mumble linked dynamically against
Qt4Gui.dll, etc. - everything worked fine. The manual plugin simply
linked against the same DLLs.
With the move to mumble_app.dll, we also moved to statically link
against Qt for mumble_app.dll.
To accommodate the manual plugin, we implemented various hacks to
export the Qt symbols from mumble_app.dll that were necessary for
loading the manual plugin.
And that worked for a while.
However, right now, with Qt 5.6, the plugin is broken. And I get
a lot of weird crashes when interacting with the manual plugin.
Most of it boils down to the fact that both manual.dll and mumble_app.dll
have copies of statically initialized data, like QArrayData::shared_null.
Sharing objects between mumble_app.dll and manual.dll in this scenario is
impossible, because using the object in one module will cause one set of
statically initialized data to be used, while use in the other will cause
the other data to be accessed. This is especially bad for things that use
reference counting, because it'll get out of sync.
So, to get rid of this mess, we're moving the manual plugin into Mumble
itself. Functionally, it doesn't change anything. The manual plugin could
not be auto-updated because it depended on a specific Qt and Mumble
version. Mostly because it depended on the correct set of Qt symbols to be
exported from mumble_app.dll.
The plugin now works correctly, and we can safely remove a lot of the
hacks that were required to load the manual plugin in its earlier
incarnation.
The only downside is that we can't test the manual plugin in PAHelper.
But that wasn't really the case before either, because the plugin
practically depended on Mumble to run.
a179f5d249