Raising minimum target Windows version
Hi, I'm considering raising minimum target Windows version for my libraries to at least Windows 7. This means dropping workarounds for missing WinAPI functions that are present (but, for a very long time now, untested) for Windows XP. This specifically pertains to Boost.Atomic, Boost.Filesystem and Boost.Log. I'm also tempted to raise the requirement to Windows 8 to have access to WaitOnAddress & co., but I'm hesitant since Windows 7 might still be wide spread (perhaps, not on desktop but embedded). The current plan is to announce this in the release notes for the upcoming 1.84 release and drop the support in 1.85. This will mean the dependent libraries and tools will similarly drop support for older Windows versions. Additionally, I'm proposing to raise the default target Windows version in Boost.WinAPI to Windows 10, provided that the Windows SDK that is detected in compile time supports it. This means that by default many Boost libraries that rely on Boost.WinAPI for WinAPI definitions will target Windows 10. Which, in particular, means the prebuilt binaries we distribute will require Windows 10, unless libraries take explicit measures to stay compatible with older versions. I have no fixed time frame for the proposed Boost.WinAPI change, but it could be done as soon as in 1.84, since this doesn't remove anything, just changing the default. Comments? Objections? Counter-proposals? I'm especially interested in comments regarding Windows 7 as the new baseline - am I being too conservative? Thanks.
On Tue, Oct 3, 2023 at 4:29 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
I'm considering raising minimum target Windows version for my libraries to at least Windows 7
Go higher. Windows 7 has 3.34% market share left. And its not like those users will be left out, they can stay on 1.83.0. Thanks
Am 04.10.2023 um 02:11 schrieb Vinnie Falco via Boost:
On Tue, Oct 3, 2023 at 4:29 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
I'm considering raising minimum target Windows version for my libraries to at least Windows 7
Go higher. Windows 7 has 3.34% market share left. And its not like those users will be left out, they can stay on 1.83.0.
Seconded. Last time we delivered a WinXP app to our industrial customers was 15 years ago. Since then they *all* migrated to Win7 which is our targeted version for at least 10 years. These days, *none* of our customers is on Win7 anymore, Win10 is their minimum requirement, even asking for Win11 support. Dani
On 04.10.23 02:11, Vinnie Falco via Boost wrote:
On Tue, Oct 3, 2023 at 4:29 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
I'm considering raising minimum target Windows version for my libraries to at least Windows 7
Go higher. Windows 7 has 3.34% market share left. And its not like those users will be left out, they can stay on 1.83.0.
That's not how it works in the land of downloadable closed-source software. I can't exactly download the latest game from Steam and modify it to use an earlier version of Boost. -- Rainer Deyke (rainerd@eldwood.com)
On 04.10.23 01:28, Andrey Semashev via Boost wrote:
Comments? Objections? Counter-proposals? I'm especially interested in comments regarding Windows 7 as the new baseline - am I being too conservative?
I'm still trying to support Windows XP in my own software, but I admit that I'm losing that battle and may have to switch to Windows 7 in the not too distant future. I'm not planning on going beyond Windows 7, as Windows 7 looks like the last sane version of Windows. -- Rainer Deyke (rainerd@eldwood.com)
Andrey Semashev wrote:
Hi,
I'm considering raising minimum target Windows version for my libraries to at least Windows 7. This means dropping workarounds for missing WinAPI functions that are present (but, for a very long time now, untested) for Windows XP. ... Comments? Objections? Counter-proposals? I'm especially interested in comments regarding Windows 7 as the new baseline - am I being too conservative?
FWIW, people are still using Boost in $current_year to target Windows XP. Yes, this surprised me as well. https://github.com/boostorg/system/issues/113 https://github.com/boostorg/system/issues/111 https://github.com/boostorg/system/issues/110 Note that 113 is specifically about building Filesystem.
Yes, 113 is from me. We still need to support some machines which run on it. I hope they get soon upgraded to a new os. The application gets updated. About all 4 to 8 boost versions the used boost from the application gets updated. Just keep in touch with the current libraries. It is still a pita to support XP nowadays... 04.10.2023 10:45:48 Peter Dimov via Boost <boost@lists.boost.org>:
Andrey Semashev wrote:
Hi,
I'm considering raising minimum target Windows version for my libraries to at least Windows 7. This means dropping workarounds for missing WinAPI functions that are present (but, for a very long time now, untested) for Windows XP. ... Comments? Objections? Counter-proposals? I'm especially interested in comments regarding Windows 7 as the new baseline - am I being too conservative?
FWIW, people are still using Boost in $current_year to target Windows XP. Yes, this surprised me as well.
https://github.com/boostorg/system/issues/113 https://github.com/boostorg/system/issues/111 https://github.com/boostorg/system/issues/110
Note that 113 is specifically about building Filesystem.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 10/4/23 02:28, Andrey Semashev wrote:
Hi,
I'm considering raising minimum target Windows version for my libraries to at least Windows 7. This means dropping workarounds for missing WinAPI functions that are present (but, for a very long time now, untested) for Windows XP.
This specifically pertains to Boost.Atomic, Boost.Filesystem and Boost.Log.
I'm also tempted to raise the requirement to Windows 8 to have access to WaitOnAddress & co., but I'm hesitant since Windows 7 might still be wide spread (perhaps, not on desktop but embedded).
The current plan is to announce this in the release notes for the upcoming 1.84 release and drop the support in 1.85. This will mean the dependent libraries and tools will similarly drop support for older Windows versions.
Additionally, I'm proposing to raise the default target Windows version in Boost.WinAPI to Windows 10, provided that the Windows SDK that is detected in compile time supports it. This means that by default many Boost libraries that rely on Boost.WinAPI for WinAPI definitions will target Windows 10. Which, in particular, means the prebuilt binaries we distribute will require Windows 10, unless libraries take explicit measures to stay compatible with older versions.
I have no fixed time frame for the proposed Boost.WinAPI change, but it could be done as soon as in 1.84, since this doesn't remove anything, just changing the default.
Comments? Objections? Counter-proposals? I'm especially interested in comments regarding Windows 7 as the new baseline - am I being too conservative?
Thanks everyone for the feedback. Given that there were no objections to increasing the default target Windows version in Boost.WinAPI, I have increased the default to Windows 10. On compilers that don't support Windows 10 the latest supported version is the default. This change will be part of 1.84. Regarding my libraries, I think I will still deprecate support for Windows XP in 1.84 but will make the deprecation period longer, until 1.87 (about a year after 1.84). This should give users time to upgrade their projects. Regarding the new minimum, I think it will be Windows 10. The feedback I received (including privately) indicates most people don't think supporting Windows 7 is worthwhile, and Windows 8/8.1 seems to be even less popular, so Windows 10 it is. If you have any further comments or you think Windows 7 needs to be supported, please let me know.
On Sun, Oct 8, 2023 at 10:42 AM Andrey Semashev via Boost < 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. Thanks
On 10/8/23 20:53, Vinnie Falco wrote:
On Sun, Oct 8, 2023 at 10:42 AM Andrey Semashev via Boost <boost@lists.boost.org <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.
participants (6)
-
Andrey Semashev -
Daniela Engert -
Georg Gast -
Peter Dimov -
Rainer Deyke -
Vinnie Falco