https://msdn.microsoft.com/en-us/library/ms679351 describes that
"it is unsafe to take an arbitrary system error code returned from an API
and use FORMAT_MESSAGE_FROM_SYSTEM without FORMAT_MESSAGE_IGNORE_INSERTS"
Previously in case when an error string would contain inserts, function
returned error, so the error message wasn't shown (at least it didn't
crash, thanks to nullptr as the function's last argument).
As the function may fail, we now pre-nullify the buffer pointer to avoid
dereferencing uninitialized pointer later (though at least for some
Windows versions, the function nullifies the pointer in case of
FORMAT_MESSAGE_ALLOCATE_BUFFER, but there's no explicit guarantee of this).
Also release of allocated buffer is changed to recommended use of
HeapFree.
The code that doesn't make use of OUString is left directly calling
FormatMessage, to avoid introducing new dependencies. Where it makes
sense, we now use WindowsErrorString from <comphelper/windowserrorstring.hxx>
Change-Id: I834c08eb6d92987e7d3d01e2c36ec55e42aea848
Reviewed-on: https://gerrit.libreoffice.org/44206
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The problem is that python modules (*.pyd) find DLLs in the wrong
places.
This is because sal_detail_initialize() calls SetDllDirectoryW(""),
which removes (sometimes?) the "current directory" from the DLL
search order, which is deliberately initialized to the "program"
dir by CreateProcess() calls in officewrapper.cxx.
Loading DLLs still works for LO's own DLLs since they are all
in the "program" directory, which is the same directory where
all the executables are, so it is searched first.
But CPython loads its modules with LOAD_WITH_ALTERED_SEARCH_PATH,
which doesn't search the directory of the executable but
the directory of the immediately loaded DLL i.e. the *.pyd file
instead, i.e. python-core-X.Y.Z/lib.
It would be possible to call SetDllDirectory(".../program")
instead but probably that would require patching python
since it needs to be done in the real exectuable, not in
the wrapper executable.
So overwrite the $PATH again (like was done in the days of
the office of the holy trinity) in the officewrapper.cxx and
genericloader.cxx to prepend "program" and get priority
over the rest of $PATH.
This still doesn't protect against C:/Windows/System32/LIBEAY32.DLL
since that has higher priority than $PATH but hopefully nobody
is *that* stupid.
This patch fixes soffice.exe, swriter.exe etc., and unopkg.exe.
The python.exe wrapper already prepends "program" to $PATH.
Change-Id: If03f07eba9a2c7fc6cf44f82f639b5d0b4c62e20
...assuming the delayLoadHook in cli_ure/source/native/native_bootstrap.cxx is
no longer necessary and loading of cppuhelper from the program dir cannot fail
regardless in whatever scenario the cli_cppuhelper library itself is loaded.
Change-Id: I13f32b327bca4cce9780864f5e57cdad3860afe5
