Hi!
Some time ago, we had a ESC decision [1] to use a workaround for bug
108580 [2] about problem with VCRedist, which stopped to install
essential part of libraries on Windows Vista and above (currently
affected are Win7, Win8, and Win8.1), which was done in
71d9a61302e65fe091cf70c13fa72b3df09b7e3a [3], and "for 6.0 do something
clever".
Here is the proposal [4] that pretends to be clever :)
The following is essentially a copy-paste from the patch commit message:
Since commit 71d9a61302e65fe091cf70c13fa72b3df09b7e3a, we use a
workaround described at [5] as "App-local deployment of the Universal
CRT". We just copy all UCRT DLLs to LibreOffice/program. This has a
drawback though, that our UCRT is not updated by Windows Update, so
users would rely on LibreOffice updates in case of some vulnerabilities
in UCRT (and they could even not realize they have that problem).
MS recommends to install UCRT using EXEs they provide from their site.
The EXEs install both VCRuntimes and UCRTs, along with required patches,
for all Windows versions (Windows XP through Windows 10, where they only
install VCRuntimes); the installed libraries are managed by system's
update mechanism. But those EXEs cannot be used in MSI custom actions
inside InstallExecuteSequence, because they use MSI themselves.
So this patch integrates the vc_redist.xXX.exe into MSI binary table,
and uses custom action to run the EXE after ExecuteAction in
InstallUISequence. This will show the user a VCRedist install window
after the main LibreOffice installation finishes; no user interaction is
required (except one more UAC request), and errors are ignored.
Since this installation takes care of both VCRuntime and UCRT, we can
ultimately drop both the app-local workaround, and vcredist merge module
(so VCRuntime would also be updated by system).
This has its drawback: if one wants to use unattended installation
(without UI; one example is deployment using ActiveDirectory GPO), then
InstallUISequence is not run, and so VCRedist isn't installed. In this
case, one should install VCRedist separately. Supposedly this should not
be huge problem, because this is the case for many existing applications
that need separate VCRedist deployment in these scenarios.
Please share your opinions. Is this change viable?
The patch itself IMO needs some polish: I suppose that we should remove
redundant workaround (and possibly even merge module bits) if we accept
it. But it is in working state, so testing is possible.
[1]
https://lists.freedesktop.org/archives/libreoffice-qa/2017-November/010300.html
[2] https://bugs.documentfoundation.org/show_bug.cgi?id=108580
[3]
https://cgit.freedesktop.org/libreoffice/core/commit/?id=71d9a61302e65fe091cf70c13fa72b3df09b7e3a
[4] https://gerrit.libreoffice.org/46356
[5]
https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/
--
Best regards,
Mike Kaganski
Context
- tdf#108580: integrate vc_redist.exe into Windows installer · Mike Kaganski
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.