Re: [boost] Raising minimum target Windows version

On 10/8/23 20:53, Vinnie Falco wrote:

On Sun, Oct 8, 2023 at 10:42 AM Andrey Semashev via Boost mailto:boost@lists.boost.org> wrote:

If you have any further comments or you think Windows 7 needs to be supported, please let me know.

Nothing actionable from me, but I am curious to know what the impact of dropping Windows 7 will be. For example, by what percentage will the library shrink? How much time is saved on CI? I would imagine that dropping Windows 7 doesn't give as much benefit as, say, dropping C++03. Of course that would depend on the library. WinAPI might in particular get a big savings. I'm just curious if there are metrics. 

Boost.WinAPI probably won't change at all as it defines the same APIs either way. I didn't plan to raise the minimum in Boost.WinAPI anyway, as other libraries might need it. Raising the minimum in Boost.WinAPI would only make some compilers unsupported and unable to compile it, but not reduce its code base. My main motivation for going beyond Windows 7 is Boost.Atomic, which needs WaitOnAddress family of functions to implement waiting/notifying operations. Without it, users have to link with the pre-built Boost.Atomic library that does runtime detection of WaitOnAddress and falls back to the lock-based implementation if those are not available. It's not a lot of code, but I'd like to remove it, and make Boost.Atomic less dependent on the library. There might be some savings in Boost.Filesystem, but I suspect it won't be much because filesystem API is a complete and utter mess on Windows, and even the APIs that are formally supported on Windows 10 are not guaranteed to work, depending on the actual filesystem. So Boost.Filesystem will probably need to retain multiple different code paths that it has now. Dropping XP will make a notable difference though. Boost.Log is mostly upgrading as a result of the former two. There will be benefits from dropping XP, but not that much, if any, from dropping 7.