The bug was introduced in 13cbf72877.
It was only reported last year and because of a side effect: consistent lag for the entire application.
That's something that should be dealt with independently.
When performing a debug build, the "deadlock plugin" will be included
in the build, which uses the thread functionality of the std. However,
during compiling there would be an error about a symbol in thread.hpp
not being found (_beginthreadex). As it turns out, this was due to us
having a header file called Process.h, which would shadow the windows-
specific header file defining the mentioned symbol.
Therefore, in this commit we rename the Process base class to
AbstractProcess and rename the files accordingly, fixing that error.
See also: https://stackoverflow.com/q/27230258
Instead of excluding all plugins but the link one on OSes other than
Windows and Linux, the new approach allows for a more granular control
by introducing a list of plugins that is supported on the different
platforms.
This replaces the globbing approach which means that new plugins have
now to be included in this list explicitly.
The advantage of this is that this allows for a much greater flexibility
for handling plugins on different OS.
Furthermore the plugin's own directory is no longer added to the
include-path by default. If a plugin wishes to do this, it should do so
explicitly. This should help make the plugins easier to move around in
the future.
This commit introduces a new plugin framework into the codebase of the
Mumble client. Note that "plugin" here really refers to a (more or less)
general purpose plugin and is therefore not to be confused with the
previously available positional data plugins (only responsible for
fetching positional data from a running game and passing that to
Mumble).
The plugin interface is written in C, removing the compiler-dependence
the old "plugins" had. Instead plugins can now be written in an
arbitrary language as long as that language is capable of being compiled
into a shared library and also being capable of being C-compatible.
As already indicated a plugin is essentially a shared library that
provides certain functions that allow Mumble to interface with it.
Inside Mumble the so-called PluginManager is responsible for managing
the plugins and relaying events to the respective callbacks. Plugins
themselves can also interact with Mumble on their own initiative by
using the provided API functions.
Fixes#2455Fixes#2148Fixes#1594Fixes#2051Fixes#3742Fixes#4575Fixes#4751
Apparently the first commit (59ae429972)
did not include all files.
Furthermore the used script tended to produce funny results in certain
cases. This has been fixed and as a result thereof a few more changes
were made in this second run.
The code was retrieving the wrong offset (GetLocalClient).
As a result, peek() always returned 0 and the player ID was always 1.
The plugin appeared to be working fine because the player ID is always 1 when playing locally.
Previously, only module() was present: it retrieved the base address of the specified module.
It worked fine, but it iterated through the process' modules every time it was called.
This commit replaces it with modules(), which returns an std::unordered_map containing all modules.
The map uses the module name as key and Module as value.
Aside from the performance improvement, the new code also provides info for each module region:
- Start address.
- Size.
- Whether it's readable, writable and/or executable.
5df2bb2c0b explains how we gain access to the game's interfaces.
Once we have access to the interfaces, we retrieve the address of the variables' we're interested in by reading the assembly of one or more functions accessing them.
The process for each function is documented in the code.
