| Age | Commit message (Collapse) | Author |
|---|
|
installer.
|
|
Mumble anymore.
The only user was Effects11, which is gone.
The removal of the two DLLs shaves off ~6MB from the default
Mumble installation on Windows.
Goodbye.
|
|
|
|
|
|
This is to aid in making the installer WiX project
a bit more maintainable and readable.
If we need the old non-static installer, we always
have the history in Git.
|
|
Attempt to fix #1757
|
|
In theory, the installer should already do this, but if we
aren't caferful with our component GUID'ing (or so the docs say),
it can break.
This method will force the uninstallation to happen before
installation.
This should fix the issue where stale files from old versions
are left behind.
|
|
This commit updates the Mumble installer to install all binaries except
mumble.exe into a "versioned root".
For example, a typical Mumble installation would look something like this
(rooted the install target, typically "C:\Program Files (x86)\Mumble"):
/mumble.exe
/Versions/1.3.0/mumble_app.dll
/Versions/1.3.0/mumble_ol.dll
/Versions/1.3.0/mumble_ol_x64.dll
/Versions/1.3.0/mumble_ol_helper.exe
/Versions/1.3.0/mumble_ol_helper_x64.exe
/Versions/1.3.0/mumble-g15-helper.exe
/Versions/1.3.0/[various runtime DLLs, D3DCompiler, MSVCRT, etc.]
This also changes the installer to disable use of the Windows restart
manager.
The Windows restart manager does not work too well when the Mumble
overlay is in use. In this case, the restart manager will prompt users
to restart all applications that the overlay is injected into.
Users see this as a big list of programs that they must close to
upgrade Mumble.
This can be very scary for anyone that does not know about the
inner workings of the Mumble overlay, and are new to Mumble.
It is an instant red flag for people, and they will associate
Mumble with malware, or be afraid that it will actually touch
anything in those programs and make them unusable in some fashion.
The combination of disabling the restart manager and the new
versioned directory hierarchy removes nearly all of the cases
where a user sees a "file in use" dialog when running the Mumble
installer.
The overlay DLLs will not trigger the "files in use" dialog anymore,
because upgrading to a newer version of Mumble will cause the new
overlay DLLs to be installed in a distinct directory.
The removal of the old overlay files will also not trigger the
"files in use" dialog. Their removal will simply be scheduled
on the next restart of the computer.
This commit also includes a forceful termination of "mumble.exe"
when performing an upgrade of the Mumble installation. This is done
because the removal of the restart manager functionality in the
installer unfortunately also removes the ability to have the restart
manager quit Mumble on upgrade.
With the implementation of the versioned directory hierarchy, there
is a problem with the placement of some of our dependencies, at least
when Mumble and Murmur are installed at the same time.
The "murmur.exe" executable expects dbghelp.dll, msvcr120.dll and
msvcp120.dll to be next to "murmur.exe". However, with this new
directory hierarchy for the client, those DLLs live in the versioned
root instead.
To remedy this, we include two copies of these dependencies. If Murmur
is not chosen during installation, only Mumble's copies are installed
in the versioned root. If Murmur is selected, the DLLs will also be
installed next to murmur.exe.
|
|
|
|
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
|
|
|
|
|
|
Possibly fixing "Error applying transforms." when trying to start the installer in Finnish Windows
|
|
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.
|
|
This change adds the mumble_ol_x64.dll overlay DLL to
the installer, along with mumble_ol_x64.exe, the new
x64 overlay helper.
|
|
|
|
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.
|
|
|
|
|
|
|
|
This reverts commits e7282052993602ae5e0a1d3a8485c17adbf89d50
and 1749ef46dfc4c9ead4e41766ba9cace786f4fa35 .
|
|
The current install removes the installed products after upgrading
to the new one. With x86<->x64 transitions into the same directory
this can lead to the installer removing files just installed.
Work around that by uninstalling first and then doing the upgrade
install.
|
|
Previous setups used a different upgrade code for x64
installs meaning existing x86 installs wouldn't be replaced.
As we don't actually want to support having x64 and x86
versions installed alongside each other this patch makes
the x64 install use the same upgrade code as x86. Also it
makes the setup detect and upgrade x64 installs which used
the old upgrade code allowing smooth future updates for
existing users of these snapshots.
|
|
|
|
|
|
Instead of directly triggering uninstall (/x) this calls install (/i)
which will allow the user to modify, repair or actually uninstall the
application.
|
|
Created sub-features for desktop shortcuts. Will require
new translations.
Fixes #1282
|
|
|
|
|
|
|
|
|
|
|
|
|
|
installer.
Previously, the bzip2.dll was always taken from the Ice directory.
This is because we previously used ZeroC's binary Ice releases, which
included a bzip2.dll that we could use.
|
|
installer.
The actual assignment was missing an "env." prefix.
|
|
InstallerVersion requirements for VC12 redist to MergeModuleDir setting.
This change effectively reverts commit 0e447428ba8380581297e3e619967a09dda036ed.
|
|
MumbleNoMergeModule is set.
This commit updates the old RedistDirVC10 files to point to their new version 12 copies,
now that we build with MSVS2013.
It also implements an easy way to opt-out of using merge modules for the VCRT
redistributable DLLs.
With this change, if the environment variable MumbleNoMergeModule is set,
the installer build will automatically embed the VCRedist DLL files as
regular files into the final .MSI.
To avoid this behavior, one can set MumbleNoEmbedVCRedist=1. So, to build
a Mumble installer with no VCRT merge modules *and* no embedded VCRT DLLs,
one would set *both*
MumbleNoMergeModules=1
MumbleNoEmbedVCRedist=1
|
|
VCRedist.
|
|
Without this, we'd be bundling the wrong CRT for MSVS 2013.
|
|
|
|
build env.
|
|
|
|
Does not include context or identity information.
|
|
|
|
|
|
shortcuts not getting removed properly on update.
|
|
are enable. Otherwise fallback to current buildserver defaults.
|
|
* In accordance with Microsoft best practices, see http://msdn.microsoft.com/library/windows/desktop/aa511447.aspx
|
|
|
|
|
