(Thanks to Mike Kaganski for noticing the gotcha here that a naive replacement
with
> std::wstring(const wstring& str, size_type pos)
would do something rather different than
> std::wstring(const wchar_t* s, size_type n)
does.)
Change-Id: I78837c014cdc154f276db1a11a87aaf74319a9fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159114
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
These routines can fail during MSI installation
(seen leftover program_old folders, with program folder missing).
We at least want to see the error in the MSI log file when this doesn't succeed.
This outputs error messages like:
MSI (s) (C4:5C) [10:47:54:280]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI37B4.tmp, Entrypoint: RemovePrgFolder
CustomAction RemovePrgFolder returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 10:47:54: RemovePrgFolder. Return value 3.
Change-Id: I4ce4099eeb3e0ee79eb4a2e1d3887f9810fd9669
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134160
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Do not bundle LanguageTool which is at a 10 year old version (1.7)
while upstream has a lot of new releases (now at version 5.5.x)
It is not bundled by any downstream distributions
so it makes no much sense to keep it integrated here.
Change-Id: Icd2ef151b1b8d0252ffa3db0caaba576f2783fa9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133356
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
...which defines NULL as a plain 0 integer literal instead of the GNU __null
extension, so clang-cl's -Wnull-conversion cannot kick in. These findings are
from an experimental build done with clang-cl and a modified
> --- a/clang/lib/Headers/stddef.h
> +++ b/clang/lib/Headers/stddef.h
> @@ -83,6 +83,10 @@ typedef __WCHAR_TYPE__ wchar_t;
> # if !defined(__MINGW32__) && !defined(_MSC_VER)
> # define NULL __null
> # else
> -# define NULL 0
> +# if __cplusplus >= 201103L
> +# define NULL nullptr
> +# else
> +# define NULL 0
> +# endif
> # endif
> #else
> # define NULL ((void*)0)
However, that build also ran into lots of places where 3rd-party code in
external/ and Windows system headers caused issues when NULL is nullptr (which
I worked around with various hacky patches for that build), so this is
unfortunately not something that can easily be enabled generally.
Change-Id: I10674464498a9bc63578d9e6cc32ddde23ab4f30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124419
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
There had originally been some back-and-forth among
134ae5da1c "jl154 #162868# remove
basis/presets/bundled/bundled.ini, and create always share/extensions folder",
4c333e8ac7 "jl154 #162868# removing the
package.txt from the extensions folder. Extensions folder will be created in a
different way than installing a dummy file", and
8f4cf9a16e "jl154 #162868# guarantee existence of
extensions folder" whether or not that dummy file was necessary to ensure
creation of the (otherwise potentially empty) $(LIBO_SHARE_FOLDER)/extensions/
directory. That is no longer necessary with gb_Package_add_empty_directory
(though the logic that had to be added to setup_native/Package_packinfo.mk now
is a bit unfortunate, and will need to be updated whenever the list of potential
bundled extensions changes).
(And that dummy package.txt file is apparently not used to track whether per-
user extension information needs to be updated when the contents of
$(LIBO_SHARE_FOLDER)/extensions/ changes. That is rather done by
comparing the status of the $(LIBO_SHARE_FOLDER)/extensions/ directory itself
against user/extensions/bundled/lastsynchronized in the UserInstallation, see
needToSyncRepository in desktop/source/deployment/misc/dp_misc.cxx.)
Change-Id: I5b9956c508288945f32a88afaef57ac0b63dc27f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120081
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Annoyingly the packinfo_*.txt don't support conditionals but we can
work-around that with a little duplication.
Change-Id: Id00a6831effcc63a917fc21d2cd201474fdb559d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109569
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(105): error C2660: '`anonymous-namespace'::WriteLogElem': function does not take 5 arguments
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(83): note: see declaration of '`anonymous-namespace'::WriteLogElem'
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(118): note: see reference to function template instantiation 'void `anonymous-namespace'::WriteLogElem<char,std::string>(MSIHANDLE,MSIHANDLE,std::ostringstream &,UINT,const Ch *,const std::string &)' being compiled
> with
> [
> Ch=char
> ]
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(382): note: see reference to function template instantiation 'void `anonymous-namespace'::WriteLog<char[18],std::string>(MSIHANDLE,const char (&)[18],const std::string &)' being compiled
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(105): error C2660: '`anonymous-namespace'::WriteLogElem': function does not take 6 arguments
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(83): note: see declaration of '`anonymous-namespace'::WriteLogElem'
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(118): note: see reference to function template instantiation 'void `anonymous-namespace'::WriteLogElem<char,std::string,char[6]>(MSIHANDLE,MSIHANDLE,std::ostringstream &,UINT,const Ch *,const std::string &,const char (&)[6])' being compiled
> with
> [
> Ch=char
> ]
> C:/lo/core/setup_native/source/win32/customactions/inst_msu/inst_msu.cxx(516): note: see reference to function template instantiation 'void `anonymous-namespace'::WriteLog<char[19],std::string,char[6]>(MSIHANDLE,const char (&)[19],const std::string &,const char (&)[6])' being compiled
and
> C:/lo/core/setup_native/source/win32/customactions/reg_dlls/reg_dlls.cxx(104): error C2660: '`anonymous-namespace'::WriteLogElem': function does not take 5 arguments
> C:/lo/core/setup_native/source/win32/customactions/reg_dlls/reg_dlls.cxx(82): note: see declaration of '`anonymous-namespace'::WriteLogElem'
> C:/lo/core/setup_native/source/win32/customactions/reg_dlls/reg_dlls.cxx(117): note: see reference to function template instantiation 'void `anonymous-namespace'::WriteLogElem<char,std::wstring>(MSIHANDLE,MSIHANDLE,std::ostringstream &,UINT,const Ch *,const std::wstring &)' being compiled
> with
> [
> Ch=char
> ]
> C:/lo/core/setup_native/source/win32/customactions/reg_dlls/reg_dlls.cxx(159): note: see reference to function template instantiation 'void `anonymous-namespace'::WriteLog<char[27],std::wstring>(MSIHANDLE,const char (&)[27],const std::wstring &)' being compiled
Change-Id: I7e8c121f8589ae847c9e4fd12e218408ea9e451e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108836
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
If user has a language set as user locale, and installer is shown in that
language, it's likely that that language is needed for installation.
Change-Id: I37fb959291262b772ec8e1b35c687d64e0ee76a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98612
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
* Label left-aligned (tdf#132322)
* Long build string cut at 25 chars
* Extra text such as Tinderbox info wraps now at Misc
* UI-Language shortened to just UI
* More padding between about image and text
* Splash screen uses Vegur font
* Splash with small border
* Non-TDF logos have a "Community Edition" text
Change-Id: I1ec31e22052e365f28fe91de3e083252975911c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93444
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
It used to be set both in AppSearch action (using RegLocator table),
and in MigrateInstallPath custom action. This would overwrite value
of INSTALLLOCATION taken from user, and read on the previous step,
with values taken on the next step.
Only migrating the install location in one single place - in custom
action MigrateInstallPath - makes the process controllable. Also it
allows to easily see all the various places in registry we read.
Change-Id: Ib7e04c26e71ba92c6a62a0511971bfb3bdb7db72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87867
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Since component ids change across major versions, install location
isn't kept automatically for major upgrades. Use OLDPRODUCTS property
set during FindRelatedProducts action (see Upgrade table created by
solenv/bin/modules/installer/windows/upgrade.pm). Read InstallLocation
in existing MigrateInstallPath custom action under
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\GUID, where
GUID is the value of OLDPRODUCTS.
This only reads registry hive for the current installer architecture
(32/64 bit), so that the other architecture installation path is not
taken into account when old version is of different architecture, to
avoid installing into wrong directory when e.g. upgrading from 32-bit
to 64-bit, so 64-bit program is not installed to Program Files (x86).
Change-Id: Ib9fa004818908a5706c5af040f1a5a36c03d2f36
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87844
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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>
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>
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>
Stephan Bergmann