First try the modern Windowsy way, where we can directly query if escape sequences will be processed.
The function is available as far back as Windows 2000, but it just won't return the right flag until the Windows version is new enough.
If that fails, fall back to the Unixy way, as not all colour-supporting terminal emulators for Windows use the Win32 API to declare that capability.
The implementation isn't identical as isatty wasn't available without adding more headers, and we already have Windows.h in this file, so I might as well use the Win32 API instead of its POSIX-compatibility layer.
These warnings were always enabled, but we didn't see them due to https://gitlab.com/OpenMW/openmw/-/issues/7882.
I do not fully understand the cause of 7822 as I can't repro it in a minimal CMake project.
Some of these fixes are thought through.
Some are sensible best guesses.
Some are kind of a stab in the dark as I don't know whether there was a
possible bug the warning was telling me about that I've done nothing to
help by introducing a static_cast.
Nearly all of these warnings were about some kind of narrowing
conversion, so I'm not sure why they weren't firing with GCC and Clang,
which have -Wall -Wextra -pedantic set, which should imply -Wnarrowing,
and they can't have been affected by 7882.
There were also some warnings being triggered from Boost code.
The vast majority of library headers that do questionable things weren't
firing warnings off, but for some reason, /external:I wasn't putting
these Boost headers into external mode.
We need these warnings dealt with one way or another so we can switch
the default Windows CI from MSBuild (which doesn't do ccache) to Ninja
(which does).
I have the necessary magic for that on a branch, but the branch won't
build because of these warnings.
This means the shared memory struct is just 255 bytes longer than a few
commits ago instead of 32K.
Also introduce a function for putting path strings in the shared memory
as there was too much copied and pasted code and it was error-prone.
Also free some handles once we're done with them so they don't leak.
Well... unless we fail to get the user profile directory.
Also put freeze dumps in a more appropriately-named file.
Discussed in https://gitlab.com/OpenMW/openmw/-/issues/7455
Manual rewrite of c21695c951
As well as that, I found a bug where the crash dump path was being converted from a std::filesystem::path to a utf8-encoded std::string, then passed to the crash catcher, which converted it to a std::filesystem::path implicitly, but using the system eight-bit code page, which wouldn't usually be UTF-8. That's now fixed by passing the function that expects a path a path instead of a string.
AnyOldName3
Evil Eye
elsid
psi29a
Alexei Kotov
Andrei Kortunov
Shi Han
Cody Glassman