For Windows SDK 8.1 HRESULT_FROM_WIN32 is defined as an inline
function without the constexpr, which is required for case statement
inside a switch.
Change-Id: Ibb195ef900926d87ff04f82a6d73112b8858f633
Reviewed-on: https://gerrit.libreoffice.org/75111
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Things break without OpenSymbol font. On the other hand, if you
install just the fonts, but not anything else, you can happily use
the fonts in other applications. So just invert the dependency.
Change-Id: I4c2dbff59699365cba67d3b1c6ade5ec7c2462bf
Reviewed-on: https://gerrit.libreoffice.org/71898
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
It seems that wusa.exe would fail with error code 0x80080005
if launched too soon after WU service was sent a stop control
(which was added in tdf#123832).
Change-Id: I470a8a8e933e8a0cd6208c095ed63c1761b3b434
Reviewed-on: https://gerrit.libreoffice.org/71045
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
We don't need the dynamic load complexity for these now with baseline
Windows version being Windows 7 SP1. Stuff used only for compatibility
with older versions was dumped.
Change-Id: I810f271796cfd875cfa18a3081c9ad444fe57b3e
Reviewed-on: https://gerrit.libreoffice.org/70321
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The code is using expicit (mostly W) Windows API, and is independent
from the macro. Removing it here allows to catch places where some
UNICODE-dependent macro is used unintentionally.
Change-Id: I5dff40aecfc3c3dc7fc4cf7271a995a675943a45
Reviewed-on: https://gerrit.libreoffice.org/70237
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
V575 The potential null pointer is passed into 'foo' function
Add asserts to those cases that are related to OOM cases. There's
nothing to be done if the assertions fail anyway.
Change-Id: I92ac95d44f512aa1948b1552b0e1f6da695a9f92
Reviewed-on: https://gerrit.libreoffice.org/70008
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reportedly under some circumstances execution of wusa.exe may hang
for very long time (available logs show more than 90 min). LO MSI
installer waits for wusa.exe indefinitely in its deferred inst_msu
custom action; during this wait, one can't abort the installation.
There is an evidence [1] that stopping WU service prior to wusa
launch might prevent this hang.
The patch does two things:
1. It stops running WU service prior to wusa launch.
2. It adds a check for user input by executing MsiProcessMessage
twice a second, and checking its return value, to allow early
return in case user cancels the installation.
This is a blind shot, since I cannot reproduce the problem myself.
[1] https://superuser.com/questions/1044528/
Change-Id: I8bf4ce52b3e9d98a4f90af3abcc49ac63b6a0e40
Reviewed-on: https://gerrit.libreoffice.org/69487
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
This replaces commit 53058090be. 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>
Since commit 1882827320, an attempt to
install UCRT will be performed regardless there is an evidence that it's
present on the system, to workaround some cases where the existing UCRT
is broken (tdf#115405, tdf#119910).
But that made other errors to emerge: on systems where users disable WU
service using some exotic ways, installer is unable to enable the
service, and fails. [1][2] Examples of such hard-disables are using
`sc delete` [3] and associating WU service with a guest account. Many
such cases are reported for Windows 10, where installation of the UCRT
is not required.
So the solution (imperfect, but possibly the best possible here) is to
allow installer to continue in case of failure enabling the service.
This will automatically eliminate all problems related to Win10; and
also for cases where users are advanced enough (the majority of such
hard-disable cases should be those), it might be enough to add a
relevant FAQ entry.
[1] https://ask.libreoffice.org/en/question/172227/cannot-install-631/
[2] https://ask.libreoffice.org/en/question/175571/installation-failed-unknown-error-win10x64/
[3] https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/sc-delete
Change-Id: Ie85016eb6f0667f39412a3089fe1b1855cb1fc73
Reviewed-on: https://gerrit.libreoffice.org/64825
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
...that had been removed with 28b4f4aeaf "Get rid
of Windows .def files in setup_native, use __declspec(dllexport)". Looks like
for 32-bit builds, the .def file EXPORTS are still needed to avoid __stdcall's
_...@NN symbol decoration (and for 64-bit builds __stdcall is effectively
ignored, so the removed .def files didn't make a difference there).
This is only a partial revert of 28b4f4aeaf, the
addition of __declspec(dllexport) for the benefit of loplguin:external should
still be fine.
Change-Id: I76a1a3f4671824367bab495afeba291c0340108d
Reviewed-on: https://gerrit.libreoffice.org/61047
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Including:
* expanding STDAPI to its definition (as per
<https://msdn.microsoft.com/library/ms686631(vs.85).aspx> "STDAPI"), to add
__declspec(dllexport) into its middle, in
extensions/source/activex/so_activex.cxx; as discussed in the comments at
<https://gerrit.libreoffice.org/#/c/60691/> "Get rid of Windows .def files in
setup_native, use __declspec(dllexport)", having a function both listed in a
.def file EXPORTS and marking it dllexport is OK, and the latter helps the
heuristics of loplugin:external; however, the relevant functions in
extensions/source/activex/so_activex.cxx probably don't even need to be
exported in the first place?
* follow-up loplugin:salcall in sal/osl/w32/file-impl.hxx
Change-Id: Ida6e17eba19cfa3d7e5c72dda57409005c0a0191
Reviewed-on: https://gerrit.libreoffice.org/60938
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
For one, replacing the dated .def files with equivalent functionality should be
a good move all by itself. And for another, it paves the way for using
loplugin:external with clang-cl on Windows, which uses the heuristic of not
warning about functions that are explicitly marked as __declspec(dllexport).
Change-Id: I6efd50a8c5ce2a166ca0dd4e5f472118f3f9a071
Reviewed-on: https://gerrit.libreoffice.org/60691
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...left over from 26b40fcfc6 "Moving mysqlc into
connectivity as a library". (Apparently, for one, a module's Files that don't
exist are ignored, so 8ecf5e1815 "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>
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 61b1d63133 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>
Some scripts in which it was used have been removed
(commit e1082e4536) and
the more reliable 'fakeroot' is now in use at all
other places where libgetuid.so was previously used
(s. tdf#115554).
Change-Id: I638e96e5c8d671e3b145b79f33de718fe34ea514
Reviewed-on: https://gerrit.libreoffice.org/49837
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
These scripts were never shipped to end users (the corresponding
install_linux.sh was only added to the instset in LO times,
see 117b3242db) but were used
by QA and developers to install multiple Solaris builds
as non-root using getuid.so.
But the "archive" installation set can be used for the
same purpopse and doesn't require a custom script.
Change-Id: I665277bef7c5ddd58e798f5f1b1c6a97a0f3cfc5
Automatic rewrite (of loplugin:cstylecast and loplugin:unnecessaryparen) after
cab0427cad "Enable loplugin:cstylecast for some
more cases" and a409d32e7f "More
loplugin:cstylecast"
Change-Id: Ib3355159dd08333e1b7a8d091caf2069cdcc7862
Reviewed-on: https://gerrit.libreoffice.org/48317
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Since we dropped support of Vista and below in master toward 6.0,
those checks are needless. Removing the code that only worked in
older versions, and streamlining the resulting code.
Also, use kernel32.dll version for Windows version, instead of
deprecated GetVersionEx, and inconvenient VersionHelpers. Since both
GetVersion(Ex) and VersionHelpers (based on VerifyVersionInfo) are
subject to manifest-based behavior since Windows 8.1, this move will
hopefully result in more reliable OS version detection.
Change-Id: I3edd8fc1843e64b6a65bd3a126be6a085511f13c
Reviewed-on: https://gerrit.libreoffice.org/42905
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
...to avoid -Werror,-Wunused-command-line-argument in case some ASan build
setting passes in such flags
Change-Id: Ia613a10e3564a23715019ee0c7c755cdcbf7a47c
nd101