1.3.0 has been released. master now represents the current state of
development towards the next feature release 1.4.0.
Bugfixes for 1.3 will happen in the 1.3.x branch.
Compared to earlier version bumps we bump a lot more files because of
we produce more artifacts; overlay process, dll and exe split, etc.
This should have happened right after the 1.3.x branch was split off.
We used to use DIST for referencing extra files that should be included
in our tarballs created by 'make dist'.
However, we've since migrated away relying on 'make dist' in release.pl.
Instead, we include everything, and have a list of items to exclude, such
as IETF RFC drafts distributed in 3rdparty/speex-src that do not adhere to
the Debian Free Software Guidelines.
Use correct types for handling pointer size/memory addresses.
Make use of boost optional as GetFnOffsetInModules return type. The
unsigned return type does not allow for negative error values anymore,
which we did not make use of anyway, and optional is more explicit.
Replaces workaround/error detection from the commits
114495e59fa3e7958f16Fixes#1924
It is better to be explicit and API correct, even if the resulting
types ended up to be the same through typedefs or the implementation
reinterpret-casting to a memory address pointer.
As provided by Remadan in mumble-voip/mumble#3029.
LaunchPad is Daybreak Games's own launcher, used for games such as
PlanetSide 2 (Standalone) and others.
This was originally implemented in
2f07778a0e.
This change was a mistake. We use the WH_CBT hook to inject our DLL into
potential targets. That means that every mouse/keyboard event will trigger
an attempt to load our overlay DLL, if it isn't already loaded.
That, combined with the new ability for the overlay to decline being
injected caused problems for processes that are blacklisted by Mumble:
Every mouse/keyboard event would attempt to load the DLL, go through the
exclusion checks (query the process tree, query the registry, find out
that the process is blacklisted, unload the DLL...).
We can't have that, so let's just revert this.
This is useful for cases like GTA V.
Its launcher is available via Steam, or via Rockstar Social Club/Retail.
Before this change (if it wasn't already in the blacklist), the GTA V
Launcher, when launched through Steam, would show the overlay.
Now, since we treat it as a launcher, it'll be implicitly blacklisted.
This commit adds an 'excludecheck' module to the Windows overlay DLL that
implements the exclusion logic for the Mumble overlay.
It implements the new launcher filter mode, as well as the traditional
whitelist and blacklist-based approaches.
The rules for the launcher filter mode are:
- Is the process blacklisted? Don't allow the overlay.
- Is the process whitelisted? Allow the overlay.
- Does the process's executable live in a whitelisted path? Allow the
overlay.
- Is one of the process's ancestors in the launcher whitelist? Allow the overlay.
- Otherwise, disallow overlaw.
These simple rules, along with some sane defaults allow much finer-grained
control over the overlay -- and it allows us to ship a default profile
where we practically only inject into games.
This is a small code-cleanup commit that moves the
procname parsing to a separate function. This makes
the code clearer, and we're able to properly document it.
Returning FALSE From DllMain when fdwReason is DLL_PROCESS_ATTACH
means you're declining to be loaded.
This allows us to be fully unloaded from program that we've decided
(via exclusion rules) we don't want to be in.
This change is a small refactoring in the overlay DLL.
We rename bBlacklisted to bEnableOverlay, because the
bEnableOverlay naming is clearer in a world where we
have the launcher filter exclusion mode.
This new module exposes the GetProcessAncestorChain() function.
This function is going to be used by the new exclusion check module
to implement the launcher filter.
This commit changes various pri and pro files to always prepend
the global build output directory (which can be either 'release'
or 'debug', depending on the current build configuration).
Otherwise, if a library that we build ourselves, such as -lspeex in
CONFIG+=bundled-speex, is also available in one of the other lib dirs,
we can't be sure that the one in our build output directory will be used.
This is a problem on FreeBSD, where we add /usr/local/lib
to the QMAKE_LIBDIR in compiler.pri. That directory might contain
its own -lspeex.
With this change, we now prefer libraries in our build output directory
to system libraries.
This allows the overlay to build with the Windows SDK version
of fxc.exe.
This removes the need for people developing locally to install
the legacy DirectX SDK.
Before:
warning C4312: 'reinterpret_cast': conversion from 'unsigned long' to 'HANDLE' of greater size
Also, please note the comment in src/mumble/Overlay_win.cpp regarding the
32-bit masking:
https://msdn.microsoft.com/en-us/library/aa384203.aspx says:
> When sharing a handle between 32-bit and 64-bit applications, only
> the lower 32 bits are significant [...]
We might as well...
This is short-term fix until we figure out where to go with
the overlay launcher filter, path filter, etc.
Fixesmumble-voip/mumble#1117
It seems that in EVE Online, if we update our overlay texture but do not
draw to the screen, the texture mapping is never freed, until we begin
drawing again.
I do not know enough D3D11 to know why.
Instead, this commit works around the issue by introducing a fully legal
optimization to the blit() method:
If the rect of active overlay elements is empty (that is, the screen is
empty), do not perform a blit at all.
The change also introduces an extra call to blit upon receiving
OVERLAY_MSG_ACTIVE. That message is the message that signals that
the rect of active elements has changed.
We need to blit here to ensure we redraw correctly once the rect
of active overlay elements changes.
Fixesmumble-voip/mumble#1123
The interplay between Mumble/Steam/Uplay overlays seems
to have been fixed by one of the parties (not us!).
Far Cry 4 now runs with the Mumble overlay.
Fixesmumble-voip/mumble#1514
