Hi all, I'm a user of this library AND developing under Windows. After the library went supposedly stale I did a huge effort in the last 2 weeks to bring it into shape: - Implement CI: Appveyor (MSVC 2017/2019), Github actions (Linux, MSVC, MinGW) - Fix/Update & Test standalone version (requires C++11 though) - Incorporate the whole reviewfixes branch and fix ALL remaining issues from the reviewnotes but Boost.Build integration (no clue of Jamfiles, sorry) - CMake based build with support for submodules (add_subdirectory), installation and proper CMake targets (find_package(nowide) just works) - Merge all my previously opened PRs and work through open issues fixing more or less serious bugs (wrong return values, wrong behaviour on corner conditions, formatting, line-ends, pointer confusion, warnings) It can be found at https://github.com/Flamefire/nowide. It also has proper Github release integration ("Boost" and standalone version) with an extra asset for the (updated) docu: https://github.com/Flamefire/nowide/releases I'm currently tackling the hardest part: The StdIO based filebuf which turned out way harder than I though. I went over every single function and checked it against the standard to avoid excessive flushes and make sure it behaves as mandated. In the process I enhanced the test cases greatly. In tests with MSVC I see big improvements on read/write bandwidth which were complained about. They now match the std::fstream performance *on average*, meaning they are sometimes even faster (for small IO on my PC). However it is not done yet, as MinGW shows failures so I got to double-check that I didn't miss anything. So from my POV the library is/will be ready for inclusion into the next Boost release (not the currently prepared one). Some points though: - I'd need someone familiar with Jamfiles to check/fix them, especially with the Jamfiles based CMake install - Maintenance could be done by CMT, I could "lead" that though for a bit of time. To ease that I added as much as possible to CI, including a clang-format test (helps wasting review time about style discussion) - The library scope should stay narrow, i.e. as-is. Feature requests should be carefully considered, IMO it is pretty much complete. Again: Ease of maintenance is key. - Maintaining/Testing the standalone version should be continued, as should be the CMake-based build. The library scope is narrow already, and being able to use it standalone or as a submodule seems to be valuable. - Require C++11 (not sure if this is acceptable, as the review didn't point that out) - Allows reduced dependencies (cstdint, scoped_ptr, static_assert) - Standalone does already (dummy-headers redirect to std headers which could be removed then) - "Fuzzy" detection of `*::filesystem::path` to be not only compatible to boost::filesystem for also to C++17 On the importance of this library: - It has already been included into linux distros: https://bugzilla.redhat.com/show_bug.cgi?id=1502584 - Boost.Beast (as written) does not support UTF-8 against it advertising it, it could use Boost.Nowide - UTF8 codepages recently introduced IMO don't solve the problem: Unless the standard codepage is UTF8, you'll never get UTF8 arguments to `main` (unless I missed something) Regards, Alex