This is only possible for now because x86 uses the D3DCompiler_43.dll
and x64 uses the D3DCompiler_47.dll.
If we need both to use the same version, we'll need a more complex
directory structure.
But let's tackle that then.
Setting Mumble's priority class higher than the games
is a bad behavior which can cause inconsistency for
input timing in games such as Team Fortress 2.
The g15helper tool links against a static library
provided by Logitech. It is only available for
32-bit x86.
Use our new toolchain mechanism to enable g15helper
to be enabled for x64 builds.
The Win32 ExitProcess() API takes an UINT, and we
used to pass negative values to it.
Obviously, those negative values can be represented
just fine in an unsigned integer, but for the sake
of following the API and to avoid future confusion
this commit changes the error constants used by
the overlay helper program to be non-negative.
The old parsing was error-prone and hard to read.
We introduce the GetCommandLineArgs() function that returns
he program's arguments as a vector of strings.
Using this function makes the code that processes the arguments
much simpler and easier to understand.
Many of our slots determine which variables to use depending
on the sender of the signal. However, they weren't very careful
about any possible invalid states.
This change makes sure we fail if we're in invalid state.
Normally, Mumble itself will terminate the helper processes.
But if Mumble crashes, or is manually killed by the user, it
will not be able to terminate the helper processes itself.
In order to fix this, we create a way for the helpers to know
when their parent process has terminated.
This is implemented by creating an inheritable process handle
in Mumble, and passing its value to the helpers.
The helpers then WaitForSingleObject() on the parent handle, and
exits with status code 0 if it the WaitForSingleObject() call
returns successfully.
This adds hidden config options for disabling arch-specific
overlay helpers.
This is useful for people that only want the overlay for a
specific architecture, and also for debugging and troubleshooting
arch-specific overlay problems.
We need this in case there's a bug in one of the overlay helpers.
Without this, we would restart a crashed helper immediately. If this
bug is triggered every time the helper is run, we'd get into an infinite
restart loop, potentially making the host computer unresponsive.
OverlayPrivateWin used to only listen for process
termination. Technically, this should work just fine.
This change makes OverlayPrivateWin listen for process
errors as well, by subscribing to the error() signal
of the QProcess of each of our helpers.
The idea is that this could provide us helpful error
messages when troubleshooting issues where overlay
helpers are exiting untimely.
When Qt terminates a QProcess via the terminate()
method, it sends a WM_CLOSE message.
However, the overlay helper did not know of WM_CLOSE,
so it would quietly ignore it.
This commit teaches the overlay helper to exit on
WM_CLOSE.
This change adds a function, canRun64BitPrograms() to OverlayWinPrivate.
If the program is built for x64, the function unconditionally
returns true.
If the program is built for x86, the function uses a call to the
runtime-resolved kernel32!IsWow64Process to determine whether or
not the system is x64 capable.
This functionality is needed to avoid spawning the x64 helper in
case the system cannot support it. Doing so without care, like we
did previously, could be fatal because Mumble immediately restarts
the helper process if it terminates. This would presumably make the
host computer unusable.
Vtable offsetes is almost all that we store in the shared memory,
and they vary by architecture.
So, don't share the memory between arches. Instead, crate
arch-specific shared memory regions.
This splits fx11 into an x86 variant and an x64 variant.
This creates effects11_x86.lib and effects11_x64.lib, instead
of the single effects11.lib we had previously.
The minhook build is also tweaked. However, since minhook
is only used on x86_64, it is only built for x86_64.
Consequently, the library is still called minhook.lib.
The overlay itself is split into mumble_ol.dll and mumble_ol.exe
for x86, and mumble_ol_x64.dll and mumble_ol_x64.exe for x86_64.
These CONFIG options allow a .pro file to select which toolchain
its target should be built with.
To force a target to always be built for x86 (in both x86 and
x86_64 build environments), set CONFIG+=force-x86-toolchain.
The same thing is possible with force-x86_64-toolchain.
This also changes the log message to be equivalent to the one used
by the transmit-switcher toolbar item.
This makes the strings more consistent. This should make both users
and translators happy.
The new 'no_include_pwd' CONFIG option introduced by
d855b67d10 showed us this bug.
Before that commit, OS X *did* include PWD in the INCLUDEPATH
by default. Because of that, the equivalent of '../speex-build'
was *already* in the INCLUDEPATH, because 'speex-build' is the
PWD of the .pro file.
Now that we explicitly require the PWD not to be included, our
own inclusion of 'speex-build' must be spelled correctly to work.
This commit fixes that.
This commit fixes an issue caused by a new behavior in Qt 5.4.1 that
causes
PWD to be included in the default INCLUDEPATH on Windows with the nmake/VS
generators.
This new behavior was implemented in the following Qt commit:
qtbase/a90bb5b89a - centralize/unify/sanitize INCLUDEPATH "enrichment")
a90bb5b89a
This is a problem because our codecs in 3rdparty use two distinct
config.h files: one for Win32, and one for everything else.
The Win32 variant lives in the Win32 subdirectory of the build root.
The build root is the directory that will be added automatically by
the new Qt behavior. Typically, the build root has a build suffix,
for example 'speex-build'.
The regular config.h - the one for everything else but Win32 - lives
in the buildroot itself.
This new Qt behavior caused the wrong config.h file to be included
on Windows. Since the build root is now in the INCLUDEPATH,
the config.h file that lives in the build root now takes precedence
over the one in the Win32 directory.
To restore the old behavior for the codec builds, we use Qt config
option called 'no_include_pwd'. That explicitly tells qmake to not
include the PWD in the INCLUDEPATH. This restores the previous
behavior on Windows.
The 'no_include_pwd' config option has been around in Qt for a while.
It was not introduced with the aforementioned change to Qt, so it
doesn't break backwards compatibility for us.
...and gate it behind the hidden 'shortuct/linux/evdev/enable'
config option.
We don't actively want people to use evdev unless
they really have to (as it requires people to change the
permissions of their keyboard device node to be quite wide-open
to be useful).
Our evdev code has also caused problems for users of
Yubikeys and other gadgets that identify themselves as
keyboards. Those problems should be a thing of the past
with this commit.
Fixes#1145
Some configurations of Qt 5.X explicitly disable deprecated
parts of the API, such as 'QSsl::TlsV1'. To allow Mumble to build
on those configurations, we have to use 'QSsl::TlsV1_0' instead,
like we did in the prior to 71e522f4c4.
This commit also fixes an issue where QSsl::SecureProtocols was only
selected on the base 5.4.0 release, and not subsequent patch releases.
We upstreamed a patch for adding the self-explanatory
QSsl::TlsV1_0OrLater, QSsl::TlsV1_1OrLater and QSsl::TlsV1_2OrLater
enums to QSsl.
Before this, we had a patch in our Qt 5.4 build (on Windows), that
changed the meaning of QSsl::TlsV1_0 to mean "TLSv1.0 or later".
However, that approach wouldn't work in the real world (some setups
require very specific TLS versions), so it was dropped in favour of
the TlsV1_0OrLater and friends.
Since our patch is in Qt 5.5, it means that we now can use
QSsl::TlsV1_0OrLater in the Mumble tree (ifdef'd to QT_VERSION
>= 0x050500), and not break anything for distros.
For Qt 5.4, we can rely on QSsl::SecureProtocols, because Qt 5.4
deprecated SSLv3. Thus, in Qt 5.4, QSsl::SecureProtocols means the
same thing as TlsV1_0OrLater means in Qt 5.5.
Why do we need TlsV1_0OrLater and friends if we have
QSsl::SecureProtocols? Because we don't have a guarantee that
QSsl::SecureProtocols will keep having TLSv1.0 as its minimum
version. The current Mumble protocol requires TLS 1.0.
If something comes up in the future that makes us abandon TLSv1.0,
we'll still handshake it. Rejection can happen at the Mumble protocol
level instead, providing a better user experience.
This removes the date and time macro to attempt to get us to
reproducible builds. While I do like the date and time included, it
doesn't really add that much value to our users.
