[Libreoffice-bugs] [Bug 122134] LibreOffice instlaller msi attempting to install KB2999226 on windows 10 machine.

Sun Dec 16 10:58:54 UTC 2018

https://bugs.documentfoundation.org/show_bug.cgi?id=122134

--- Comment #2 from Mike Kaganski <mikekaganski at hotmail.com> ---
Short version: this is the direct result of
https://git.libreoffice.org/core/+/1882827320ed760de82211cf690b686f8d34ff74.

TLDR version:

Yes, since the commit above, the installation of KB2999226 is attempted on all
supported Windows platforms, unconditionally. The reason for this follows.

First, the discussion of dependency on the KB (i.e., on UCRT) is given in bug
108580 comment 60. There, it's explained why do we now embed the KB installer
in the MSI in the first place.

When we did that, we discovered that the awkward decision of MS to only provide
UCRT for Vista+ as MSU has made many other applications to look for ways to
install it, just as we struggle with that. And many of those do that wrong.
They install UCRT improperly, so that it allows them to run; but for
LibreOffice, the wrong installation is enough to detect it, but insufficient to
operate. We discovered that at least Avast antivirus does that, so we have a
number of reports when LibreOffice failed to run after installation on system
with Avast preinstalled: see bug 119910.

So the solution was to remove the check for the presence of UCRT. Now we simply
try installing the UCRT MSU unconditionally. What does it mean? It means that
we depend upon Windows Installer service (because MSU is Windows Installer
package); and we check the return value of the installation. If we get that the
update is not applicable for the system, we just continue. But errors make the
installer to fail; and disabling the Windows Update generates one such error.

Actually, our installer knows how to temporarily enable a disabled Windows
Update service, *if it was disabled in a usual way* (its startup type set to
"Disabled" in Service Manager). But we don't provide a solution for any
advanced technique to disable the service (which users sometimes have to do
because of other MS interesting decisions about their update policy, which is
outside of this discussion).

Well - but the update is not required on Windows 10; so why just not skip it
based on the Windows version?

You won't believe, but the problem here is just one of the ~recent decisions
Microsoft has made about WinAPI; and that decision is IMO one of the most
idiotic ones ever made. It's about getting Windows version information; [1] now
the WinAPI dedicated to obtaining Windows version (GetVersion) is deprecated,
and - what's most important - returns lies! It doesn't tell you that you are
running on Windows 10, unless you explicitly include a manifest in your
application that it supports Win10. The reasoning behind the change was no less
idiotic: because *some* developers made mistakes checking versions improperly,
now all developers (including those who do it properly) should suffer.

Well - we do include such manifest into LibreOffice executables. Isn't that
enough? Unfortunately, no. When installing the application, the executable
running is not one of LibreOffice executables; it's Windows Installer component
named msiexec.exe (a part of Windows OS) that is running and performing all the
checks and actions recorded in MSI. And guess what? Believe it or not, but the
msiexec.exe in Windows 10 does *not* include a manifest about its compatibility
with Windows 10! The Windows component responsible for installation of packages
does not contain what is required to get the accurate Windows version
information! It only declares compatibility with Windows 8.1 in the manifest,
so you get Windows 8.1 when you check the version in the installer!

When MS had introduced the change in version API, it had published a workaround
on its GetVersion documentation page. The workaround consisted of getting
version of a system file (kernel32.dll) instead. And initially, it worked. But
then, in some Windows 10 update, they decided that they made life of developers
too easy, and had made another step in the direction of hiding version
information from us. And that last step (I don't know if and where it was
published) was the most astonishing in its consequences. They altered the API
for getting file versions (at least in Windows Installer) to also not return
version numbers greater than Windows version specified in their msiexec.exe.
What does it mean in reality? Well - it means that if your application depends
upon a file with version like 12.X, you will *never* get the correct version in
your MSI check, because msiexec.exe will report version 6.3 (the internal
version of Windows 8.1) for that file! No matter what that file was. No matter
if the file versioning is independent of OS versioning.

And now, if you check for UCRT DLL version on Windows 10, you will get 8.3,
although it had never had that version! The very first release of the library
had version 10.X already. I simply don't see a reliable way to detect that we
run on Windows 10 from installer, to conditionally avoid some steps (installing
the KB in this case).

Does that mean that there's nothing to be done here?
No. First, in
https://git.libreoffice.org/core/+/46a5440daea1d65bd4e2f3b2793098bea9f8c907, I
had changed the MSU installation process to not fail on errors related to
inability to start the service - see bug 121987. So, in the next LO version
installer, some such cases will not lead to the problem. But not all: if the
service is not disabled, but run with reduced permissions, which results in
failed installation - contrary t failed service startup - the installation will
still fail. Additionally, if the service was disabled on a Win7 with UCRT
absent, the solution will lead to that "Cannot run LibreOffice,
api-ms-win-crt-runtime-l1-1-0.dll is missing" error later when attempting to
run LO.
Thus, I am working on another patch - https://gerrit.libreoffice.org/64874 -
which will never fail installing the MSU, but will emit a warning about that
instead. That will at least prepare users that something *might* go wrong
later, but will not prevent them from completing the installation.

And that last solution will still emit those warnings on Windows 10 (where it
shouldn't in theory), because of that difficulty to get the OS version I
discussed above. If someone has an idea how to solve the version problem, I'd
be most thankful!

If you are still with me at tgis point, all I can say is thank you for reading
this!

[1]
https://docs.microsoft.com/en-us/windows/desktop/w8cookbook/operating-system-version-changes-in-windows-8-1

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20181216/e42aab88/attachment.html>