windows: usage of deprecated `std:wstring_convert` #32361

std:wstring_convert was deprecated in C++17 & is removed in C++26. Cross-compiling for Windows with GCC 15.1.0 is warning about this:

../../src/common/system.cpp: In function 'void runCommand(const std::string&)':
../../src/common/system.cpp:52:32: warning: 'template<class _Codecvt, class _Elem, class _Wide_alloc, class _Byte_alloc> class std::__cxx11::wstring_convert' is deprecated [-Wdeprecated-declarations]
   52 |     int nErr = ::_wsystem(std::wstring_convert<std::codecvt_utf8_utf16<wchar_t>,wchar_t>().from_bytes(strCommand).c_str());
      |                                ^~~~~~~~~~~~~~~
In file included from /opt/homebrew/Cellar/mingw-w64/12.0.0_3/toolchain-x86_64/x86_64-w64-mingw32/include/c++/15.1.0/locale:47,
                 from ../../src/util/string.h:13,
                 from ../../src/tinyformat.h:149,
                 from ../../src/logging.h:10,
                 from ../../src/common/system.cpp:10:
/opt/homebrew/Cellar/mingw-w64/12.0.0_3/toolchain-x86_64/x86_64-w64-mingw32/include/c++/15.1.0/bits/locale_conv.h:262:33: note: declared here
  262 |     class _GLIBCXX17_DEPRECATED wstring_convert
      |                                 ^~~~~~~~~~~~~~~

Apparently there is no direct replacement in the standard library.

i hope we can replace runCommand with use of the subprocess library soon, to unify the "launch subprocess" path.

with use of the subprocess library soon

Note that subprocess.h is also using wstring_convert: https://github.com/bitcoin/bitcoin/blob/d62c2d82e14d27307d8790fd9d921b740b784668/src/util/subprocess.h#L1071.

Note that subprocess.h is also using wstring_convert:

Ugh. Well at least it's an upstream issue for them, too, then.

So in principle modern Windows can use UTF-8 on the 8-bit APIs, removing need for any conversion, but i'm not sure starting from when, and this relies on setting a specific code page globally at startup. Edit: according to Microsoft this is since Windows Version 1903 (May 2019 Update). This requires providing a "Fusion manifest for an unpackaged Win32 app", whatever that means, if we can even do this with mingw32.

Alternatively we could borrow these (windows specific) functions from our leveldb patch:

  // Converts a Windows wide multi-byte UTF-16 string to a UTF-8 string.
  // See http://utf8everywhere.org/#windows
  std::string toUtf8(const std::wstring& wstr) {
    if (wstr.empty()) return std::string();
    int size_needed = WideCharToMultiByte(
        CP_UTF8, 0, &wstr[0], (int)wstr.size(), NULL, 0, NULL, NULL);
    std::string strTo(size_needed, 0);
    WideCharToMultiByte(CP_UTF8, 0, &wstr[0], (int)wstr.size(), &strTo[0],
                        size_needed, NULL, NULL);
    return strTo;
  }

  // Converts a UTF-8 string to a Windows UTF-16 multi-byte wide character
  // string.
  // See http://utf8everywhere.org/#windows
  std::wstring toUtf16(const std::string& str) {
    if (str.empty()) return std::wstring();
    int size_needed =
        MultiByteToWideChar(CP_UTF8, 0, &str[0], (int)str.size(), NULL, 0);
    std::wstring strTo(size_needed, 0);
    MultiByteToWideChar(CP_UTF8, 0, &str[0], (int)str.size(), &strTo[0],
                        size_needed);
    return strTo;
  }

This requires providing a "Fusion manifest for an unpackaged Win32 app", whatever that means, if we can even do this with mingw32.

I believe we can use an approach similar to the one described at https://stackoverflow.com/questions/33000158/embed-manifest-file-to-require-administrator-execution-level-with-mingw32.

Great, good to know that's possible. i guess by the time we switch to C++26 and this becomes a blocking issue, it will be fine to require a 2019 windows version, and we can simplify things by using the "ASCII" Windows APIs everywhere and provide strings as-is. This would also allow dropping the leveldb patch.

Great, good to know that's possible. i guess by the time we switch to C++26 and this becomes a blocking issue, it will be fine to require a 2019 windows version, and we can simplify things by using the "ASCII" Windows APIs everywhere and provide strings as-is. This would also allow dropping the leveldb patch.

A proof of concept is available in #32380.