| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Using a four-segment version (major.minor.patch.build) is causing issues
on Windows, because it tends to ignore the fourth version number in most
cases. This can cause upgrades to fail and/or multiple entries being
created in the installed applications list.
For this reason, this commit changes the version format to be
major.minor.build.
Fixes #4921
|
|
Apparently the first commit (59ae429972c16c377135bcccfee646b7df446933)
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.
|
|
This was done by running scripts/updateLicenseHeaders.py and then
manually editing the LICENSE file.
|
|
The build number can be specified through the new "BUILD_NUMBER" variable.
This change is very important on Windows, for two reasons:
- It allows to easily identify binaries simply by looking at their version.
More specifically, we can guess what build they're part of.
- Right now snapshots can not be updated without uninstalling first, because the version is the same (i.e. 1.4.0).
By increasing the 4th digit of the version for every build we can solve the issue.
This commit also takes care of renaming a few variables so that they're consistent and also clearer.
For example, "version" is now "RELEASE_ID".
|
|
Installation paths can now be fine-tuned by setting the respective
MUMBLE_INSTALLATION_* variables when invoking cmake.
Additionally some components that only had install rules for a certain
OS are now installed on all OSes as these components should be needed
there as well.
|
|
|
|
Instead of having to change the version number and the build year in all
those files manually, we let cmake do the work by replacing the
respective values in templates.
|
|
This commit removes all qmake-related build-files from the system. We
have now migrated to cmake and are no longer maintaining qmake anyways
and therefore there is no reason to keep it.
Removing it also clearly states to any potential user/programmer that
this project is no longer intended to be compiled with qmake.
Given that the .pri files no longer exist, the mumble-version.py script
had to be adapted to read the version from the CMakeLists.txt file
instead.
Furthermore a few of the submodules support cmake natively and therefore
we no longer need the src/buid-directory approach in order to build
them. The respective build dirs have been removed and the src-dirs have
been renamed.
|
|
|
|
GCC and Clang provide the "-m32" and "-m64" options, which tell the compiler to build as 32 bit and 64 bit, respectively.
Unfortunately MSVC doesn't provide similar options, thus this commit converts "overlay" from a subdirectory to a project.
If the build is 32 bit, the project is processed a single time and compiles a 32 bit library.
If the build is 64 bit, the project is processed two times and compiles a 64 bit and a 32 bit library.
|
|
|
|
|
|
This changes all occurances of NULL in the overlay source
dir to nullptr. Additionally explicit comparisons with NULL were
removed.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Consistently use single space before assignment operator.
|
|
|
|
|
|
silence MSVC2015 warning.
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 [...]
|
|
|
|
|
|
Developers'.
Updates mumble-voip/mumble#1513
|
|
Right now, we do not get PDB files for our overlay DLLs because
the overlay DLL PDB files share their name with the overlay helper
PDB files.
To avoid this madness, we rename the overlay helpers as follows:
mumble_ol.exe -> mumble_ol_helper.exe
mumble_ol_x64.exe -> mumble_ol_helper_x64.exe
|
|
GetCommandLineArgs().
|
|
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.
|
|
|
|
Now that the helper takes more than one argument, the
old name is not descriptive enough.
|
|
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 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.
|
|
This changes Mumble on Windows to run a helper process,
mumble_ol.exe, instead of loading mumble_ol.dll itself.
Prior to this change, Mumble would load mumble_ol.dll and
call PrepareD3D9() and PrepareDXGI() to set up the overlay.
Then, if the overlay was enabled, it would call InstallHooks()
to enable automatic injection of the overlay into new processes.
Similarly, it would call RemoveHooks() to disable automatic
overlay injection when the overlay was disabled in Mmuble.
With this change, Mumble instead runs a helper process called
mumble_ol.exe. This process sets up the overlay (equivalent
to calling PrepareD3D9(), PrepareDXGI() and calling InstallHooks()).
While running, it'll automatically inject the overlay into new
processes, just like Mumble itself did previously. On normal exit,
the helper process calls RemoveHooks() to ensure automatic overlay
injection is disabled.
To enable the overlay, Mumble starts the helper process.
To disable the overlay, Mumble terminates the helper process.
If the helper process dies when it is supposed to be running,
Mumble restarts it to ensure that overlay injection keeps
working as intended.
This change is the first part of enabling both an x86 and an x64
overlay to be active in Mumble at the same time. Since we cannot
load a 32-bit DLL into a 64-bit process (or vice versa), we need
a helper process for each architecture to reach our goal.
Note however that this commit in itself does not make it possible
for Mumble to run both an x86 and an x64 overlay at the same time.
This will come later.
|
