[colinfinck]

> Only if you want to be trendchasing rather than letting backwards compatibility take care of itself...

> I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6 because it's fast and enough for what they do. Takes <250MB of disk space, and the self-contained binaries it generates will work on any version of Windows starting at Win95.

I share your view about the unmatched backwards compatibility of Win32 binaries, but I wouldn't let a 24-year old compiler like MSVC6 near any new project. We are talking about a compiler here that doesn't even support the C++98 standard, let alone all the basic features for writing safe software (stack cookies, _s APIs, smart pointers - just to name a few).

When I needed reliable self-contained binaries and backwards compatibility, I switched to VS2019's clang-cl compiler and ported their libc++. Together with winpthreads from the mingw-w64 project, this enabled me to write software using even C++20 features, but still maintain compatibility down to Windows NT 4 from 1996. If you're interested, it's all documented here: https://colinfinck.de/posts/targeting-25-years-of-windows-wi...

[account42]

That's really cool, was wondering how hard it would be to make libc++ play nice with XP - currently I still use MSVC 2017 for those builds but that won't get newer language features and I am planning to move to Clang anyway. Do you know of any effort to go even further back and support pre-NT Windows with a modern C++ compiler?