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 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.
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.
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.
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
* LCIDs for TradChinese.wxl and SimpChinese.wxl installer
translations now should be correct.
* Verified all other LCIDs against Microsoft kb
http://support.microsoft.com/kb/221435
