[boost] Raising minimum target Windows version
Andrey Semashev via Boost
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Vinnie Falco via Boost
bo...@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
Daniela Engert via Boost
> On Tue, Oct 3, 2023 at 4:29 PM Andrey Semashev via Boost <
> bo...@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
Rainer Deyke via Boost
> On Tue, Oct 3, 2023 at 4:29 PM Andrey Semashev via Boost <
> bo...@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 (rai...@eldwood.com)
Rainer Deyke via Boost
> Comments? Objections? Counter-proposals? I'm especially interested in
> comments regarding Windows 7 as the new baseline - am I being too
> conservative?
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 (rai...@eldwood.com)
Peter Dimov via Boost
> 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 regarding Windows 7 as the new baseline - am I being too
> conservative?
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.
Georg Gast via Boost
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 <bo...@lists.boost.org>:
Andrey Semashev via Boost
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.
Vinnie Falco via Boost
bo...@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
Andrey Semashev via Boost
> On Sun, Oct 8, 2023 at 10:42 AM Andrey Semashev via Boost
> <bo...@lists.boost.org <mailto:bo...@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.
Vinnie Falco via Boost
bo...@lists.boost.org> wrote:
> ...
Thank you very much for the additional insights, I didn't realize the
extent of it.
Regards