Age | Commit message (Collapse) | Author |
|
Change-Id: I2ed1fffc0ccca34d87ffc39d009eed466b5fb937
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105063
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ibc1e7505e6a7492f4d0714c848a6d1eebcdf4a0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97589
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
... because it contains x86 binaries in addition to x64: e.g., twain32shim,
spsupp_x86.
The opposite (inclusion of x64 MSM into x86 MSI) is not possible ( see
https://stackoverflow.com/questions/58181986 ), so do it just for x64 MSI.
Change-Id: I3935fce751b1b6d04291fede6b82be25fe541582
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86667
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit a4681e8b74a59439110af42ff18cce021512056d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86680
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Without that, after initial installation, the state of the feature is
undefined, and following uninstallation can't define that it needs to
be uninstalled, unregistering SharePoint.OpenDocuments class.
Change-Id: Ib7455833fb397c332735eb4c8ab63f763b4e469b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86598
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 01fa2b022e4d5b7392b02181d9bb9bfc76272d62)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86601
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
This registers SharePoint integration libraries using regsvr.exe.
Both 32-bit and 64-bit libraries are registered; registration of
LOSPSupport.OpenDocuments is unconditional.
This introduces a new hidden MSI feature, which is disabled for
installation: gm_SharePointSupport_SubstMSO. When installed, it
registers SharePoint.OpenDocuments class in registry, thus
overriding registration of this component by MS Office, allowing
LibreOffice to serve as MS Office replacement working in IE with
SharePoint. To install the feature, either a transform is needed
setting the feature's level <= 100, or a command line:
msiexec path-to-msi ADDLOCAL=gm_SharePointSupport_SubstMSO
Change-Id: I5517bbb68dcc6db8bcb2bbc2368394ee4a62d741
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86452
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86462
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
- added EULA (sla.r) in special OS X resource fork format
- added volume icon which does not work ATM, TODO later
- new dmg background image and adjusted .DS_Store
- fixes to tolerate space in app bundle name
Change-Id: Ia855d7d677136de951c2b9b31ee8d5583475dd41
|
|
(cherry picked from commit 74d90488662c55fd5f31b203e02b228137b42076)
(cherry picked from commit ccf572e5e4a0a2fe1c3f5b9a166e2d5e4277c83a)
Change-Id: I64ea8d8722c9da252c6142a862e9363759d38ba3
|
|
(cherry picked from commit 08f328e20e85d41793413df6ed653d033b499517)
(cherry picked from commit 8988a747cb8937da96f4f2b5164b393fb988f6f5)
Change-Id: Ie62c6a98563261e3601be70ff5eff6603b625445
|
|
Change-Id: Ibde24b2045497aca4ea37845fc42c327d22d3d42
|
|
Now that there are some available, new mo files need to be added
to the installer.
Tested with Spanish on Windows to work.
Change-Id: Id70305fa5a674bc9e302aa6937a03c4573888da4
Reviewed-on: https://gerrit.libreoffice.org/84569
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit a36a3f65d19497a0f6f13780b8e2bf0068c94c18)
Reviewed-on: https://gerrit.libreoffice.org/84610
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
when the switch --disable-crashdump is set, then the
switch "CrashDumpEnable" set to "false", was only in
instdir/program/soffice.ini, but was not
in soffice.ini in msi it was always true
Change-Id: I2668c1425a776fdf5f0c4e4511c2216e8f418a5b
Reviewed-on: https://gerrit.libreoffice.org/83171
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
(cherry picked from commit 73524467b9a6a7c4e6d5173aba79d80632ef46e2)
Reviewed-on: https://gerrit.libreoffice.org/83289
|
|
Reported here: https://twitter.com/erez/status/1193838467668697089
Change-Id: I96fdb82646e6b2e49b6032766195309a97da0fba
Reviewed-on: https://gerrit.libreoffice.org/82439
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
- in soffice.ini (sofficerc) the entry "CrashDumpEnable" default is "true"
- when false then the Dump.ini and the dump-file are not written
- when the switch --disable-crashdump is set, then the
switch "CrashDumpEnable" set to "false"
- when the entry "CrashDumpEnable" is missing, in this case is the
default true, too
- the checkbox under Options-General "Send crash reports to ..."
is deactive and shows off (only view, not change the config)
- when set the environment variable "CRASH_DUMP_ENABLE" to any char
then the switch "CrashDumpEnable=false" are overrules with true
and the Dump.ini and dump-file are write
Change-Id: I34e7795640eb95d111e18b0ad46ec67b2c126b19
Reviewed-on: https://gerrit.libreoffice.org/79273
Tested-by: Jenkins
Reviewed-by: Juergen Funk (CIB) <juergen.funk_ml@cib.de>
|
|
Change-Id: Ie2b04ee443dece851d3d96afbc932aa64369c75c
Reviewed-on: https://gerrit.libreoffice.org/79084
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Change-Id: Ic95b9f887da83d0931ed54b76d23465660786a79
Reviewed-on: https://gerrit.libreoffice.org/78273
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I47d9659fc21abec652a5a440004c0c2d27ec3b53
|
|
A verb was missing for parallelism.
Change-Id: If6452e576a71b2634934f98a814d9459f4b74e78
|
|
Change-Id: I04adf5850fff872d27a8ddc344523de281448a80
Reviewed-on: https://gerrit.libreoffice.org/72895
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I29f68f16c228c46841a7a3a50bb6dfe4f703403f
Reviewed-on: https://gerrit.libreoffice.org/72212
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Regression from 7a9f6df7fb83ec23d09cb5744c2c865fa22e7143
ERROR: The following errors occurred in packaging process:
ERROR: Source for LICENSE.html not found!
ERROR: Could not copy to
/Users/gerrit/lode/bibisect/core63/workdir/installation/LibreOfficeDev/dmg/
install/en-US_inprogress/LibreOfficeDev_6.3.0.0.alpha0_MacOS_x86-64/LICENSEs/LICENSE.html No such file or directory
Change-Id: I6c51a853238b1ecea64f900c0c60e7a9bb370dc9
Reviewed-on: https://gerrit.libreoffice.org/71417
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
The Bundle_Contents_Resources_Lang dir gids (its only use) have been unused
since f0b57c30fdb5ecdd25879844159b9038399bc6de "Info.plist et al were no longer
found when creating a .dmg", and those Contents/Resources/*.lproj dirs are
created on demand now, anyway.
Change-Id: Ia3e867307c4fc31180594d507721577a21cc20b1
Reviewed-on: https://gerrit.libreoffice.org/71319
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I5e2f222449424d4a6498d8566f13aca7f07c0c51
Reviewed-on: https://gerrit.libreoffice.org/68303
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Noticed this on console:
cpp: <macro>:1 C:/BLP/core/scp2/source/calc/registryitem_calc.scp:1261 \
Bad token \text/x-ms-iqy produced by ##
See https://bugs.documentfoundation.org/show_bug.cgi?id=111344#c9
Change-Id: If6b5b4ae90c1b0fb812a5e2cd87d17fc688d21c6
Reviewed-on: https://gerrit.libreoffice.org/68885
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I414959f0f278792c5cac0c58746faa6b7773e494
Reviewed-on: https://gerrit.libreoffice.org/65593
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This allows Windows/applications to pick OOXML editors (and thus
LibreOffice) when they lookup by content type, not by extension.
Change-Id: I0daca12f735035e6fc39484b5c788af37b81b575
Reviewed-on: https://gerrit.libreoffice.org/65563
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
It passed "make check" on Linux
Change-Id: Ic8b2adeb949bfc72830667b6928147ebd053d2f0
Reviewed-on: https://gerrit.libreoffice.org/65517
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
On Windows 8.1, the one that is problematic to tell from Windows 10
(because the latter also exposes its version as 603 to the msiexec),
the registry value doesn't exist at
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
but let's play safe and also check for "#6" value just in case.
Reference:
https://stackoverflow.com/questions/31072543/reliable-way-to-get-windows-version-from-registry
Thanks to Mitchell <blazer64@gmail.com> for the idea!
Change-Id: Ic907c4d992a7cb1d12e392686c19cd6fd6da3c7c
Reviewed-on: https://gerrit.libreoffice.org/65231
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This replaces commit 53058090beede6a399e2f408f62c28a2921ff8ab. Now
not only failure to start WU service, but also other errors during
MSU installation won't break installation. E.g., running WU service
as Guest does not prevent the service from starting; but installing
updates fail, which makes previous solution incomplete.
Instead, show a warning in those rare cases when an error happens,
and continue. It will allow users to see the reason if they see
"api-ms-win-*.dll missing" message later after installation. Of
course, some small percentage of these warnings will be false, e.g.
those on Windows 10. But those false messages must be really small
minority, because only when (1) the installation fails (2) on a
system with the component already present, such a message would be
false. And it will not prevent the installation.
This will not block unattended installations, since in those cases,
MsiProcessMessage() will do nothing.
Change-Id: I3a9e681e9d6701d092bd5c18bb4b68b4f77170f3
Reviewed-on: https://gerrit.libreoffice.org/64874
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Being a GUI application on Windows (with related flag in the executable header
- see https://blogs.msdn.microsoft.com/oldnewthing/20090101-00/?p=19643/), OS
would detect the subsystem before launching the application, and won't attach
the parent console or redirected output handles from it to the application.
Also, different hacks to reattach the GUI application to the console later are
unreliable on different Windows versions, and work improperly (the output goes
to the console after the launch command has already returned, which is wrong
in batch files). This makes it extremily difficult to do CLI operations with
LibreOffice on Windows, with error codes/warnings/messages/output missing or
going to wrong consoles.
Making an executable for CUI subsystem, on the other hand, makes Windows to
allocate a console before starting it when the program is run by itself. This
makes the console window to appear on screen unconditionally, even if it's
hidden later when the program has started. This flashing is undesirable.
But we use a wrapper executable on Windows, called soffice.exe, which is what
actually launched by user, and which runs soffice.bin. This allows us to make
soffice.bin the proper console application, and thus make it capable to behave
properly in CLI scenarios, while avoid the console flashing when run from the
soffice.exe (which would suppress the console creation using DETACHED_PROCESS
creation flag to CreateProcessW).
Also creating a new wrapper for console (soffice.com) allows to use command
lines which omit explicit executable extension (no ".bin"), like this:
"C:\Program Files\LibreOffice\program\soffice" --help
which allows to continue using multiple available help resources unchanged,
since .com extension is tried prior to .exe by Windows' cmd.exe.
Change-Id: I089d0f30f860da6cfc781b4383f6598a08a4d238
Reviewed-on: https://gerrit.libreoffice.org/63572
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ic222fbe902686efe75061d1354339e37671144b8
Reviewed-on: https://gerrit.libreoffice.org/63084
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
Change-Id: Ibafa81b412036e98fa9ab047fc8e204660eae120
|
|
(cherry picked from commit 72b2299f3ec474a09e00f4966abc8c37bb972ec1)
Change-Id: I8bc06a07974f98707df39ff39d9e1a215cba9c52
Reviewed-on: https://gerrit.libreoffice.org/61156
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
There appears to be common situation that a system has *some* UCRT libraries
in System32, that were installed improperly (presumably by some applications
using simple copy).In these cases, our installer would detect the presence of
ucrtbase.dll, and not try to install UCRT on the system.
Unfortunately, it seems that oftentimes such improper UCRT installations miss
some parts of UCRT, which leads to LibreOffice failing to start with messages
like "The program can't start because api-ms-win-crt-string-l1-1-0.dll is
missing from your computer. Try reinstalling the program to fix this problem."
(the missing component varies).
This patch removes the check for UCRT presence. Installer will try to install
UCRT on applicable systems unconditionally. Since the proper outcomes in case
of already present UCRT are either WU_S_ALREADY_INSTALLED or WU_E_NOT_APPLICABLE
and both are treated as success in inst_msu action (see InstallMSU in
setup_native/source/win32/customactions/inst_msu/inst_msu.cxx), this should
only make this part more robust, and not bring new problems (yes, I know that
actually there will be new problems, as usual).
Change-Id: I22a3d357014d31a8e492ff8a15bcb477eeb79735
Reviewed-on: https://gerrit.libreoffice.org/60789
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I78b8c745b9d6e4a23fa13622188c5bd1776b0ac6
Reviewed-on: https://gerrit.libreoffice.org/59882
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
...left over from 26b40fcfc67480e75bd9959b0c5cb9db10fdf6a1 "Moving mysqlc into
connectivity as a library". (Apparently, for one, a module's Files that don't
exist are ignored, so 8ecf5e1815b5459bc0bbcdfb398d3bd53b0c2861 "Build fix, make
install: mysql-connector-ooo extension is gone" removing
gid_File_Oxt_MySQLConnector but not
gid_Module_Optional_Extensions_MySQLConnector referencing it didn't cause
trouble; and for another, an empty module is ignored, so there were no
extension-mysql-connector packages generated any more---but better clean up the
junk anyway.)
Change-Id: If598a968dfbbe9b5f16d735e8011e192cbd4178b
Reviewed-on: https://gerrit.libreoffice.org/59669
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Since
commit 26b40fcfc67480e75bd9959b0c5cb9db10fdf6a1
CommitDate: Fri Aug 24 17:19:51 2018 +0200
Moving mysqlc into connectivity as a library
Was used in #ifdef WITH_EXTENSION_MARIADBC
Change-Id: Ib95d81fbd79f253c4490dd3afdfd67962b5f1563
|
|
Change-Id: I4b36d8700ad369b58205b699e0aff5591d2f1d6a
|
|
Change-Id: Icee6f97abf9182621e43a0039b52c2f2e141fa01
|
|
For Automation clients. Provided in extensions/source/ole/servprov.cxx
for an instance of ooo.vba.word.Application.
Change-Id: I277f461bf6206f3516b14fabe8b27dc4c06018b5
Reviewed-on: https://gerrit.libreoffice.org/55052
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I46f75e969b1252a95118888507c116f44578dfbd
Reviewed-on: https://gerrit.libreoffice.org/54699
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: Ie0e8b8b7ad59ee640d6b195dfae1a7cf745056fd
Reviewed-on: https://gerrit.libreoffice.org/54543
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
in page number, chapter and outline numbering
in ~30 languages by integrating libnumbertext library.
- offapi: add linguistic2::NumberText
New NumberingType constants:
- ordinal indicators (1st, 2nd, 3rd...)
- cardinal number names (One, Two, Three...)
- ordinal number names (First, Second, Third...)
Note: these numberings are parts of OOXML, too.
Plain text files of Libnumbertext's language data
are installed in share/numbertext (similar to
share/fingerprint), allowing further customization.
Change-Id: I4034da0a40a8c926f14a3f591749a89a8d807d5a
Reviewed-on: https://gerrit.libreoffice.org/53313
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Using nested install is bad because (1) MS advises against it (though it
most possibly doesn't relate to our specific case, when we install the
vc redist exe package in UI part, so actually only a single MSI session
is active at any time); (2) because it adds some extra interactions
(user sees something "unrelated" being installed, which raises concerns;
additional admin authentication required); and (3) because it runs in
InstallUISequence, thus only installing the UCRT when doing interactive
installation (unattended installs, including GPO, need to install UCRT
separately).
This patch aims to incorporate the original UCRT MSU (Windows Update)
packages (https://support.microsoft.com/en-us/help/2999226) available as
a zip archive from
https://www.microsoft.com/en-us/download/details.aspx?id=48234
- the same as used in VC redists for VS 2015 and 2017. This obsoletes
the separate installation of the redist; since we also have the redist
as merge module in our MSI, that is enough (and removes redundancy).
The MSUs are installed using wusa.exe in a custom action (deferred,
non-impersonating).
As a small bonus, embedding MSUs instead of redist EXE allows us to
shrink the size of installer a little (~10 MB).
As deferred custom actions cannot access current installer database,
we workaround this by using initial immediate impersonating action to
extract the binaries into a temporary location. To ensure that the file
gets removed upon completion (both successful and failed), we use an
additional cleanup action.
Commit 61b1d631331551b43bc7d619be33bfbfeff7cad6 is effectively reverted.
Change-Id: I1529356fdcc67ff24b232c01ddf8bb3a31bb00bd
Reviewed-on: https://gerrit.libreoffice.org/52923
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This reverts commits 914f6385d98f8c898102c971a4d5b0eb9f075ef0 and
a6045159237419ce8fa49202c672e3895f0ab30a. A investigation required why
is the problem with them; meanwhile, they break builds.
Change-Id: I713b27dd64e8ac7beb2757c362765b60ce191f8d
Reviewed-on: https://gerrit.libreoffice.org/53078
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I7e2cc08a1312da629e4644be97ebc7ed40250702
Reviewed-on: https://gerrit.libreoffice.org/52995
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This uses VC Runtime upgrade code (checked using Upgrade table) to
find installed redist, instead of checking registry keys that change
between versions (while the runtime is still compatible, as with 2015
and 2017).
Also, it checks if UCRT is present. Now, if either VC Runtime or UCRT
is absent, we try to install the redist. This would allow to install
UCRT in scenarios when first install was attempted on a system not
suitable for UCRT (like Win7 w/o SP1, or Win8.1 w/o April 2014 update
rollup), where VC Runtime gets installed, but UCRT is still missing.
We use the ucrtbase.dll version to check that; and as the expected
version is 10.x, we take into account that Win10 lies about versions.
Change-Id: I864dfc09cf1bdc775501729fa2a27dc98295588c
Reviewed-on: https://gerrit.libreoffice.org/52794
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Apparently the MSMs have been renamed in Visual Studio 2017.3 but only
configure was adapted, not scp2.
Not sure if these MSMs are still relevant given the new
gid_File_Vcredist_Exe thing.
Change-Id: I4fe27c8298b3a2024acc62d12ce8ea67e2eca80d
|
|
supporting old Hungarian orthography optionally,
according to the official 3-year transitional
period in schools.
Change-Id: Ifbc5583c1e53bc4ac07e73a90e0dd02e159f83e6
Reviewed-on: https://gerrit.libreoffice.org/47398
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
|
|
... in InstallUISequense.
Use --with-vcredist-dir to point to a directory with vc_redist.x64.exe
and/or vc_redist.x86.exe. Use --without-vcredist-dir (or
--with-vcredist-dir=no) if you don't want to ship it as part of
installer and want to silence the configure warning.
VCRedist 2015 version 14.0.24215.1 is available at
https://www.microsoft.com/en-us/download/details.aspx?id=53840
Since VisualStudio 2015, VC redist merge module that we used before
started to work differently: it installs the UCRT only on WinXP,
but not on later OSes (Vista to 8.1) which may lack the UCRT (Win10
has it out of the box). The merge module only installs VCRuntime on
those systems, which still leaves us with "api-ms-*.dll is missing"
problem.
(https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/
gives more information on VCRedist refactoring background.)
Since commit 71d9a61302e65fe091cf70c13fa72b3df09b7e3a, we use a
workaround described at the page mentioned above 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 for one additional 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). The former is done here: this reverts commit
71d9a61302e65fe091cf70c13fa72b3df09b7e3a.
This approach 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, and unattended
installation is advanced stuff that requires prepared user. A
notice would be required in release notes and FAQ, though.
Change-Id: Ia6a16be60af8a08f41ea7c3dbd457d8f89006006
Reviewed-on: https://gerrit.libreoffice.org/46356
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
VersionNT is now always greated than 600 (only needs checking in version
checking action). ISSETUPDRIVEN and ISSCHEDULEREBOOT are specific to
InstallShield and aren't relevant to LibreOffice installer.
Change-Id: I6cb769c863e09f1568ae895a6cfbb0e5940c2486
Reviewed-on: https://gerrit.libreoffice.org/46434
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|