Windows XP support survey

Niall Douglas

6 May 2015 6 May '15

10:03 a.m.

The Boost SC suggested I ask about Microsoft Windows XP support in Boost libraries here, so I'd appreciate if library maintainers could state: 1. If they still support Microsoft Windows XP i.e. actively do not use APIs not supported by XP. And if SP3 is the only service pack supported, or if any XP is okay. 2. Whether they regularly test their libraries on a Windows XP machine to ensure their libraries work there. 3. Their personal opinion about when would be best to drop mandatory Microsoft Windows XP support. Individual library maintainers can of course choose to keep supporting it. As we all know, Microsoft Windows XP is no longer supported by Microsoft as of April 2014, however a widely available registry tweak reenables support and updates until 2019. However Visual Studio 2012 cannot run on XP, nor by default can produce binaries which execute on XP, so testing and developing for XP compatibility is going to become increasingly difficult. It may become wise to announce a date that XP support guarantees will be dropped, and any users needing XP support must remain on an older Boost version and/or make use of Boost modularity to mux their own Boost distro. One big reason for thinking about this is that the first C++ 11 mandatory Boost libraries are just around the corner, and they of course need VS2013 or even VS2015 and so therefore cannot promise Windows XP support. There are also a number of post-XP APIs the assumption of which would make some library authors very pleased. For example, I would assume any Boost.Thread v5 would use the Vista only condvar APIs as one can then skip emulating condvars with win32 semaphores which would be an enormous saving of code complexity. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Attachments:

SMime.p7s (application/x-pkcs7-signature — 6.2 KB)

Show replies by date

Andrey Semashev

6 May 6 May

10:16 a.m.

On Wed, May 6, 2015 at 1:03 PM, Niall Douglas wrote:

...

The Boost SC suggested I ask about Microsoft Windows XP support in Boost libraries here,

It seems, we're restarting this thread: http://thread.gmane.org/gmane.comp.lib.boost.devel/245008/ (tl;dr; I proposed to raise the default version to Vista in libs/winapi config headers; rejected because XP was still supported at the time).

...

so I'd appreciate if library maintainers could state:

1. If they still support Microsoft Windows XP i.e. actively do not use APIs not supported by XP. And if SP3 is the only service pack supported, or if any XP is okay.

I have compatibility code in Boost.Log and Boost.Sync. Both should work fine on Windows XP and by default are built for that target (as Windows XP is the default Windows target in WinAPI submodule).

...

2. Whether they regularly test their libraries on a Windows XP machine to ensure their libraries work there.

I don't. My libraries are only tested on Windows XP if some testers do that.

...

3. Their personal opinion about when would be best to drop mandatory Microsoft Windows XP support. Individual library maintainers can of course choose to keep supporting it.

I think it is more correct to bump the default Windows target to Vista or even 7, if there is any significant difference. Whether or not particular libraries support building for older Windows is a choice of the library maintainers. I don't think there are mandatory requirements on support for a particular Windows version (or a particular OS in general).

Beman Dawes

10:33 a.m.

On Wed, May 6, 2015 at 6:16 AM, Andrey Semashev wrote:

...

On Wed, May 6, 2015 at 1:03 PM, Niall Douglas wrote:

...
The Boost SC suggested I ask about Microsoft Windows XP support in ... 2. Whether they regularly test their libraries on a Windows XP machine to ensure their libraries work there.

I don't. My libraries are only tested on Windows XP if some testers do that.

...

...
3. Their personal opinion about when would be best to drop mandatory Microsoft Windows XP support. Individual library maintainers can of course choose to keep supporting it.

I think it is more correct to bump the default Windows target to Vista or even 7, if there is any significant difference. Whether or not particular libraries support building for older Windows is a choice of the library maintainers. I don't think there are mandatory requirements on support for a particular Windows version (or a particular OS in general).

+1 --Beman

Niall Douglas

10:34 a.m.

On 6 May 2015 at 13:16, Andrey Semashev wrote:

...

On Wed, May 6, 2015 at 1:03 PM, Niall Douglas wrote:

...
The Boost SC suggested I ask about Microsoft Windows XP support in Boost libraries here,

It seems, we're restarting this thread:

http://thread.gmane.org/gmane.comp.lib.boost.devel/245008/

(tl;dr; I proposed to raise the default version to Vista in libs/winapi config headers; rejected because XP was still supported at the time).

Yep, a valuable thread for everyone to read. However we are now one year after official XP support was stopped by Microsoft, and even if we decide this now, the next Boost release will need to announce it's the last supporting XP, and only the release after that would target the Vista API. I would therefore expect XP support to be switched off around October, six months from now. 18 months past XP termination seems reasonable to me.

...

...
3. Their personal opinion about when would be best to drop mandatory Microsoft Windows XP support. Individual library maintainers can of course choose to keep supporting it.

I think it is more correct to bump the default Windows target to Vista or even 7, if there is any significant difference. Whether or not particular libraries support building for older Windows is a choice of the library maintainers. I don't think there are mandatory requirements on support for a particular Windows version (or a particular OS in general).

I think we're talking about library authors being allowed to require _WIN32_WINNT >= 0x600 for their library to compile. Say in their config.hpp you'd error out if _WIN32_WINNT is < 0x600. Whether we actually change _WIN32_WINNT to default to 0x600 or even 0x601 I think is a separate matter. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Andrey Semashev

10:47 a.m.

On Wed, May 6, 2015 at 1:34 PM, Niall Douglas wrote:

...

On 6 May 2015 at 13:16, Andrey Semashev wrote:

...
On Wed, May 6, 2015 at 1:03 PM, Niall Douglas wrote:

...
The Boost SC suggested I ask about Microsoft Windows XP support in Boost libraries here,

It seems, we're restarting this thread:

http://thread.gmane.org/gmane.comp.lib.boost.devel/245008/

(tl;dr; I proposed to raise the default version to Vista in libs/winapi config headers; rejected because XP was still supported at the time).

Yep, a valuable thread for everyone to read. However we are now one year after official XP support was stopped by Microsoft, and even if we decide this now, the next Boost release will need to announce it's the last supporting XP, and only the release after that would target the Vista API. I would therefore expect XP support to be switched off around October, six months from now.

18 months past XP termination seems reasonable to me.

I agree.

...

...
...
3. Their personal opinion about when would be best to drop mandatory Microsoft Windows XP support. Individual library maintainers can of course choose to keep supporting it.

I think it is more correct to bump the default Windows target to Vista or even 7, if there is any significant difference. Whether or not particular libraries support building for older Windows is a choice of the library maintainers. I don't think there are mandatory requirements on support for a particular Windows version (or a particular OS in general).

I think we're talking about library authors being allowed to require _WIN32_WINNT >= 0x600 for their library to compile. Say in their config.hpp you'd error out if _WIN32_WINNT is < 0x600.

Whether we actually change _WIN32_WINNT to default to 0x600 or even 0x601 I think is a separate matter.

Formally, this was never prohibited. But I think it would be strange if some libraries didn't build with the default _WIN32_WINNT (or BOOST_USE_WINAPI_VERSION defined in libs/winapi headers, which I encourage to use as a configuration point for Boost libraries). So I think it is related.

David Stone

12:48 p.m.

Windows XP is end-of-life, but Windows Server 2003 is not yet (although that happens in a month or two), and they are essentially the same version. That being said, the next Boost release will be after Server 2003 is no longer supported. I am fine with dropping XP / 2003 support.

Olaf van der Spek

1:58 p.m.

On Wed, May 6, 2015 at 12:03 PM, Niall Douglas wrote:

...

However Visual Studio 2012 cannot run on XP, nor by default can produce binaries which execute on XP, so testing and developing for XP compatibility is going to become increasingly difficult.

As far as I know this is false. 2013 and 2015 have _xp toolsets that allow building for XP.. -- Olaf

Niall Douglas

3:19 p.m.

On 6 May 2015 at 15:58, Olaf van der Spek wrote:

...

...
However Visual Studio 2012 cannot run on XP, nor by default can produce binaries which execute on XP, so testing and developing for XP compatibility is going to become increasingly difficult.

As far as I know this is false. 2013 and 2015 have _xp toolsets that allow building for XP..

You may have missed my qualifier "nor by default". Also, the compatibility toolsets you mention target a much older STL and C++ support level. VS2015 claims it should be a 99% C++ 11 compliant implementation, so it will be the first MSVC where all C++ 11 codebases should reasonably expect to "just work", constexpr and all. That certainly can never target XP. VS2015 RTM actually also has a surprising amount of C++ 1z already in there. It's competitive with latest clang (sans relaxed constexpr and variable templates). I am quite amazed at the sudden leap forward by Microsoft actually, it shows just what they are capable of now they have started competing once again. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Stephan T. Lavavej

6:01 p.m.

[Niall Douglas]

...

Also, the compatibility toolsets you mention target a much older STL and C++ support level. VS2015 claims it should be a 99% C++ 11 compliant implementation, so it will be the first MSVC where all C++ 11 codebases should reasonably expect to "just work", constexpr and all. That certainly can never target XP.

That's incorrect. 2015's XP targeting has the same level of C++11/etc. support as Vista+ targeting. (IIRC, the separate toolset is because a different Windows SDK is required.) For example, I wrote a dedicated implementation of call_once() for XP, avoiding Vista's InitOnceExecuteOnce that is used otherwise. STL

Niall Douglas

11:01 p.m.

On 6 May 2015 at 18:01, Stephan T. Lavavej wrote:

...

That's incorrect. 2015's XP targeting has the same level of C++11/etc. support as Vista+ targeting. (IIRC, the separate toolset is because a different Windows SDK is required.)

Wow. That's really great news. VS2015 is looking like it's a quantum leap over previous releases. Thanks Stephan. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Stephan T. Lavavej

11:29 p.m.

[Niall Douglas]

...

VS2015 is looking like it's a quantum leap over previous releases.

On a related note, if there are compiler/CRT/STL/etc. bugs in 2015 RC blocking Boost, we need to know NOW. We'll treat such bugs with high priority, but if they're reported too late then we won't be able to fix them in RTM, and fixing anything in Updates is harder and takes longer to ship. STL

Niall Douglas

11:55 p.m.

On 6 May 2015 at 23:29, Stephan T. Lavavej wrote:

...

[Niall Douglas]

...
VS2015 is looking like it's a quantum leap over previous releases.

On a related note, if there are compiler/CRT/STL/etc. bugs in 2015 RC blocking Boost, we need to know NOW. We'll treat such bugs with high priority, but if they're reported too late then we won't be able to fix them in RTM, and fixing anything in Updates is harder and takes longer to ship.

You and your team already fixed all my showstoppers (template aliasing, packed parameter parsing), including in that recent VS2013 update. I am very grateful. For the list's information, Stephan and his wider team turned around those fixes in two weeks, very impressive. You've made the APIBind technique fully functional on MSVC which I hope will form the foundation of a C++11 only 100% modular Boost 2.0 (c.f. my C++ Now presentation next week + shortly to be released Handbook of C++ 11/14 Library Best Practices). The only remaining big flaws for me are the lack of two phase lookup, and that C++ 11 constexpr is pretty useless (which isn't Microsoft's fault, but C++ 14 constexpr is enough not a headache to use to bother with using). BTW are you willing to document how your STL invokes the magic Expression SFINAE support in MSVC? I understand you don't want people using internal magic compiler hooks, but I can also see that some Boost authors (I'm thinking Louis and his Boost.Hana) would be very interested. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Stephan T. Lavavej

7 May 7 May

5:42 p.m.

[Niall Douglas]

...

BTW are you willing to document how your STL invokes the magic Expression SFINAE support in MSVC?

1. Write the expressions required by is_assignable and allocator_traits. 2. Hope it works. 3. Complain to the compiler team when it explodes. The compiler will SFINAE out of some expressions for some reasons, but will horribly explode (and sometimes ICE) for other reasons. Even within is_assignable, things like access control have caused problems. Those have been fixed, but there are definitely still problems with arbitrary expressions. I had to be extremely careful while rewriting <functional> to avoid triggering Expression SFINAE, because misapplication of PMFs/PMDs was something the compiler couldn't backtrack from. We document Expression SFINAE as unsupported, to make it clear that step #3 is not available to users other than the Standard Library. Also, we have announced that Expression SFINAE *will* be implemented in the compiler in a 2015 Update, supported for production use - but not necessarily Update 1. STL

pfultz2

9:28 p.m.

...

Also, we have announced that Expression SFINAE *will* be implemented in the compiler in a 2015 Update, supported for production use - but not necessarily Update 1.

Oh, really? So we might have an update to VS2015 this year that will support Expression SFINAE? Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Windows-XP-support-survey-tp4675159p46752... Sent from the Boost - Dev mailing list archive at Nabble.com.

Stephan T. Lavavej

10:16 p.m.

[pfultz2]

...

Oh, really? So we might have an update to VS2015 this year that will support Expression SFINAE?

We cannot guarantee timing. It will be the first thing the compiler team works on after RTM. STL

Matt Calabrese

10:40 p.m.

On Thu, May 7, 2015 at 3:16 PM, Stephan T. Lavavej < stl@exchange.microsoft.com> wrote:

...

[pfultz2]

...
Oh, really? So we might have an update to VS2015 this year that will support Expression SFINAE?

We cannot guarantee timing. It will be the first thing the compiler team works on after RTM.

Awesome!!! IMO, this is one of the most important things currently missing. ... any chance there are also plans to make the preprocessor more compliant? ;) Only half-kidding here... I know that's a much more difficult problem to solve for entirely different reasons. It'd be great if there were at least some plans for it though. -- -Matt Calabrese

Niall Douglas

8 May 8 May

12:40 a.m.

On 7 May 2015 at 15:40, Matt Calabrese wrote:

...

... any chance there are also plans to make the preprocessor more compliant? ;) Only half-kidding here... I know that's a much more difficult problem to solve for entirely different reasons. It'd be great if there were at least some plans for it though.

I'd have thought replacing the preprocessor probably just about the easiest compiler mod possible. We can even do it ourselves by getting winclang to feed preprocessed output to MSVC for us! Two phase lookup, on the other hand, is likely to be one of the very hardest to support for a compiler like MSVC. I can see Concepts in MSVC before two phase lookup. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Matt Calabrese

2:27 a.m.

On Thu, May 7, 2015 at 5:40 PM, Niall Douglas wrote:

...

I'd have thought replacing the preprocessor probably just about the easiest compiler mod possible. We can even do it ourselves by getting winclang to feed preprocessed output to MSVC for us!

That's why I said "for other reasons." It'd be simple to just swap out the preprocessor with a compliant one, but that breaks tons of code including code in windows headers. Even the clang-cl effort tries to mimic funky MSVC preprocessor behavior such that it is feasible to use in a windows system. I'm pretty sure that in the past Microsoft has explicitly stated that they have absolutely no plans of ever fixing their preprocessor, but I remain hopeful that it will be fixed eventually.Unfortunately it tends to only be people like boost developers who really care, and Boost.Preprocessor bends over backwards to support MSVC anyway, so there's not enough incentive for Microsoft to do anything.

...

Two phase lookup, on the other hand, is likely to be one of the very hardest to support for a compiler like MSVC. I can see Concepts in MSVC before two phase lookup.

Oh yeah, definitely. If you're talking concepts-lite kind of concepts, that's not much more complicated than C++11 SFINAE. I wouldn't be surprised if that's one reason they actually are tackling SFINAE now. -- -Matt Calabrese

Edward Diener

2:47 a.m.

On 5/7/2015 10:27 PM, Matt Calabrese wrote:

...

On Thu, May 7, 2015 at 5:40 PM, Niall Douglas wrote:

...
I'd have thought replacing the preprocessor probably just about the easiest compiler mod possible. We can even do it ourselves by getting winclang to feed preprocessed output to MSVC for us!

That's why I said "for other reasons." It'd be simple to just swap out the preprocessor with a compliant one, but that breaks tons of code including code in windows headers. Even the clang-cl effort tries to mimic funky MSVC preprocessor behavior such that it is feasible to use in a windows system. I'm pretty sure that in the past Microsoft has explicitly stated that they have absolutely no plans of ever fixing their preprocessor, but I remain hopeful that it will be fixed eventually.Unfortunately it tends to only be people like boost developers who really care, and Boost.Preprocessor bends over backwards to support MSVC anyway, so there's not enough incentive for Microsoft to do anything.

Boost.VMD has workarounds for the non-compliant VC++ preprocessor also. I have been told that Microsoft has said once again that they will create a standard C++ preprocessor.

Stephan T. Lavavej

3:40 a.m.

[Edward Diener]

...

I have been told that Microsoft has said once again that they will create a standard C++ preprocessor.

The C99 preprocessor is on the (nearly empty) list of things we intend to implement to achieve full C++11 conformance. (With the exception of dynamic exception specifications; they are still Standard but deprecated in C++11, and basically nobody cares about them now.) STL

Edward Diener

4:45 a.m.

On 5/7/2015 11:40 PM, Stephan T. Lavavej wrote:

...

[Edward Diener]

...
I have been told that Microsoft has said once again that they will create a standard C++ preprocessor.

The C99 preprocessor is on the (nearly empty) list of things we intend to implement to achieve full C++11 conformance.

If and when you do this, would you please have some sort of predefined macro that tells preprocessor programming, including Boost.PP and Boost.VMD, that VC++ has a C++ standard conforming preprocessor.

Stephan T. Lavavej

11:06 a.m.

[Edward Diener]

...

If and when you do this, would you please have some sort of predefined macro that tells preprocessor programming, including Boost.PP and Boost.VMD, that VC++ has a C++ standard conforming preprocessor.

_MSC_FULL_VER will report this (I doubt you'll need to additionally examine _MSC_BUILD). STL

Olaf van der Spek

7 May 7 May

8:34 a.m.

On Wed, May 6, 2015 at 5:19 PM, Niall Douglas wrote:

...

On 6 May 2015 at 15:58, Olaf van der Spek wrote:

...
...
However Visual Studio 2012 cannot run on XP, nor by default can produce binaries which execute on XP, so testing and developing for XP compatibility is going to become increasingly difficult.

As far as I know this is false. 2013 and 2015 have _xp toolsets that allow building for XP..

You may have missed my qualifier "nor by default".

No I didn't. What does it mean though? A 'default' VS2013 install does have the _xp toolset and thus can build for XP if the user wants. Did you mean the _xp toolset isn't the default toolset? -- Olaf

Niall Douglas

9:56 a.m.

On 7 May 2015 at 10:34, Olaf van der Spek wrote:

...

...
...
As far as I know this is false. 2013 and 2015 have _xp toolsets that allow building for XP..

You may have missed my qualifier "nor by default".

No I didn't. What does it mean though? A 'default' VS2013 install does have the _xp toolset and thus can build for XP if the user wants.

Did you mean the _xp toolset isn't the default toolset?

I was working from deprecated knowledge where the XP compatible toolset was previously an optional download installed after Visual Studio. VS2015 has first tier support for XP, so my argument that C++ 11 mandatory Boost libraries cannot work on XP is invalid. That removes one reason to deprecate supporting XP in Boost. Incidentally, feelings on XP support seem very muted this time round, with everyone agreeing we should drop it after the next Boost release. I admit surprise on the consensus. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Olaf van der Spek

10:06 a.m.

On Thu, May 7, 2015 at 11:56 AM, Niall Douglas wrote:

...

On 7 May 2015 at 10:34, Olaf van der Spek wrote:

...
...
...
As far as I know this is false. 2013 and 2015 have _xp toolsets that allow building for XP..

You may have missed my qualifier "nor by default".

No I didn't. What does it mean though? A 'default' VS2013 install does have the _xp toolset and thus can build for XP if the user wants.

Did you mean the _xp toolset isn't the default toolset?

I was working from deprecated knowledge where the XP compatible toolset was previously an optional download installed after Visual Studio.

VS2015 has first tier support for XP, so my argument that C++ 11

So did VS2013..

...

mandatory Boost libraries cannot work on XP is invalid. That removes one reason to deprecate supporting XP in Boost.

Incidentally, feelings on XP support seem very muted this time round, with everyone agreeing we should drop it after the next Boost release. I admit surprise on the consensus.

Why wait until after the next release? -- Olaf

Niall Douglas

10:34 a.m.

On 7 May 2015 at 12:06, Olaf van der Spek wrote:

...

...
Incidentally, feelings on XP support seem very muted this time round, with everyone agreeing we should drop it after the next Boost release. I admit surprise on the consensus.

Why wait until after the next release?

1. The Windows Server based on XP hasn't EOLed yet. In July it will. 2. End users will need to be warned next release that that will be the last with XP support. There are a *lot* of end users who care deeply about XP support. It's still 15% of the PC desktop market. They should be warned about this change. In the end though, if none of the devs are testing for XP, I think we have to drop guarantees for it. That said, I'd support develop branch going Vista only from now on. Master branch should stay at XP for one more release. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Olaf van der Spek

10:48 a.m.

On Thu, May 7, 2015 at 12:34 PM, Niall Douglas wrote:

...

On 7 May 2015 at 12:06, Olaf van der Spek wrote:

...
...
Incidentally, feelings on XP support seem very muted this time round, with everyone agreeing we should drop it after the next Boost release. I admit surprise on the consensus.

Why wait until after the next release?

1. The Windows Server based on XP hasn't EOLed yet. In July it will.

Perhaps you should mention server 2003 too then..

...

2. End users will need to be warned next release that that will be the last with XP support.

End users don't care / know about Boost. Do you mean downstream developers?

...

There are a *lot* of end users who care deeply about XP support. It's still 15% of the PC desktop market. They should be warned about this change. In the end though, if none of the devs are testing for XP, I think we have to drop guarantees for it.

That said, I'd support develop branch going Vista only from now on. Master branch should stay at XP for one more release.

Won't the next release be based on the (current) develop branch? -- Olaf

Niall Douglas

11:22 a.m.

On 7 May 2015 at 12:48, Olaf van der Spek wrote:

...

...
2. End users will need to be warned next release that that will be the last with XP support.

End users don't care / know about Boost. Do you mean downstream developers?

End users for Boost are anyone who consumes Boost. That's devs/testers mostly.

...

...
There are a *lot* of end users who care deeply about XP support. It's still 15% of the PC desktop market. They should be warned about this change. In the end though, if none of the devs are testing for XP, I think we have to drop guarantees for it.

That said, I'd support develop branch going Vista only from now on. Master branch should stay at XP for one more release.

Won't the next release be based on the (current) develop branch?

Yes. But maybe setting _WIN32_WINNT to 0x600 or 0x601 will cause Boost or users of Boost to break. A period of time with that turned on so people can find problems (if any) before turning it on permanently might be wise. I would *assume* 0x601 will be problem free, but I can't say for sure. I doubt anyone currently can. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Vladimir Prus

7:31 p.m.

On 05/07/2015 12:56 PM, Niall Douglas wrote:

...

On 7 May 2015 at 10:34, Olaf van der Spek wrote:

...
...
...
As far as I know this is false. 2013 and 2015 have _xp toolsets that allow building for XP..

You may have missed my qualifier "nor by default".

No I didn't. What does it mean though? A 'default' VS2013 install does have the _xp toolset and thus can build for XP if the user wants.

Did you mean the _xp toolset isn't the default toolset?

I was working from deprecated knowledge where the XP compatible toolset was previously an optional download installed after Visual Studio.

VS2015 has first tier support for XP, so my argument that C++ 11 mandatory Boost libraries cannot work on XP is invalid. That removes one reason to deprecate supporting XP in Boost.

Incidentally, feelings on XP support seem very muted this time round, with everyone agreeing we should drop it after the next Boost release. I admit surprise on the consensus.

That might be too early. I, for one, object to artificially removing support for XP, which is what you appear to propose. It's still an OS used by people, so it's reasonable for app developers to target it, and having boost.config error out on XP will be bad. Thanks, -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com

Niall Douglas

10:46 p.m.

On 7 May 2015 at 22:31, Vladimir Prus wrote:

...

...
Incidentally, feelings on XP support seem very muted this time round, with everyone agreeing we should drop it after the next Boost release. I admit surprise on the consensus.

That might be too early. I, for one, object to artificially removing support for XP, which is what you appear to propose. It's still an OS used by people, so it's reasonable for app developers to target it, and having boost.config error out on XP will be bad.

No, I'm saying individual libraries can refuse to build on XP if they choose after support is dropped. Even if Boost.Build sets _WIN32_WINNT to 0x601 (Win7), it should be the case that binaries still generally compile and work on XP. If a library uses a Vista or later API, then the DLL or EXE would refuse to load. If not, they should work fine. What I'm suggesting is that notice is given that XP support is now down to each library maintainer's good wishes, and libraries are coming which won't support XP, and will never support XP. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Olaf van der Spek

8 May 8 May

7:27 a.m.

On Fri, May 8, 2015 at 12:46 AM, Niall Douglas wrote:

...

On 7 May 2015 at 22:31, Vladimir Prus wrote:

...
...
Incidentally, feelings on XP support seem very muted this time round, with everyone agreeing we should drop it after the next Boost release. I admit surprise on the consensus.

That might be too early. I, for one, object to artificially removing support for XP, which is what you appear to propose. It's still an OS used by people, so it's reasonable for app developers to target it, and having boost.config error out on XP will be bad.

No, I'm saying individual libraries can refuse to build on XP if they choose after support is dropped.

Even if Boost.Build sets _WIN32_WINNT to 0x601 (Win7), it should be

Why 7 and not Vista?

...

the case that binaries still generally compile and work on XP. If a library uses a Vista or later API, then the DLL or EXE would refuse to load. If not, they should work fine.

What I'm suggesting is that notice is given that XP support is now down to each library maintainer's good wishes, and libraries are coming which won't support XP, and will never support XP.

I think XP should either be properly supported or it shouldn't be supported period. -- Olaf

Rob Stewart

8:43 a.m.

On May 8, 2015 3:27:48 AM EDT, Olaf van der Spek wrote:

...

On Fri, May 8, 2015 at 12:46 AM, Niall Douglas wrote:

...
I'm saying individual libraries can refuse to build on XP if

they

...
choose after support is dropped.

Even if Boost.Build sets _WIN32_WINNT to 0x601 (Win7), it should be

Why 7 and not Vista?

Vista never had much traction. Smart users upgraded computers preloaded with Vista; I did so on a laptop. As another example, my company bypassed Vista. All its desktops run Windows 7.

...

...
the case that binaries still generally compile and work on XP. If a library uses a Vista or later API, then the DLL or EXE would refuse to load. If not, they should work fine.

What I'm suggesting is that notice is given that XP support is now down to each library maintainer's good wishes, and libraries are coming which won't support XP, and will never support XP.

I think XP should either be properly supported or it shouldn't be supported period.

XP isn't supported now since there's apparently no testing for it. The change is to be clear that the minimum supported Windows OS is 7. That doesn't mean that maintainers or Boost.Config should make changes to purposely sabotage using (parts of) Boost on XP. ___ Rob (Sent from my portable computation engine)

Olaf van der Spek

10:13 a.m.

On Fri, May 8, 2015 at 10:43 AM, Rob Stewart wrote:

...

...
Why 7 and not Vista?

...

Vista never had much traction. Smart users upgraded computers preloaded with Vista; I did so on a laptop. As another example, my company bypassed Vista. All its desktops run Windows 7.

Right, but not everyone is a smart user.. People are still running Vista although they shouldn't.

...

...
...
the case that binaries still generally compile and work on XP. If a library uses a Vista or later API, then the DLL or EXE would refuse to load. If not, they should work fine.

What I'm suggesting is that notice is given that XP support is now down to each library maintainer's good wishes, and libraries are coming which won't support XP, and will never support XP.

I think XP should either be properly supported or it shouldn't be supported period.

XP isn't supported now since there's apparently no testing for it. The change is to be clear that the minimum supported Windows OS is 7. That doesn't mean that maintainers or Boost.Config should make changes to purposely sabotage using (parts of) Boost on XP.

XP-compatible code paths are still being tested aren't they? -- Olaf

Niall Douglas

10:15 a.m.

...

...
Why 7 and not Vista?

Vista never had much traction. Smart users upgraded computers

On 8 May 2015 at 4:43, Rob Stewart wrote: preloaded

...

with Vista; I did so on a laptop. As another example, my company bypassed Vista. All its desktops run Windows 7.

Also Vista is highly unusual in that it had no corresponding Windows Server edition. There was a straight jump from an XP base (2003) to a 7 base (2008). I can see us remaining on Windows 7 support for a very long time. Which is no bad thing, Windows 7 hammers down all the nails I currently care about on Windows.

...

...
...
What I'm suggesting is that notice is given that XP support is now down to each library maintainer's good wishes, and libraries are coming which won't support XP, and will never support XP.

I think XP should either be properly supported or it shouldn't be supported period.

XP isn't supported now since there's apparently no testing for it. The change is to be clear that the minimum supported Windows OS is 7. That doesn't mean that maintainers or Boost.Config should make changes to purposely sabotage using (parts of) Boost on XP.

Exactly. If those who really care about XP support could donate some XP testing resources to Boost it would go a long way towards keeping XP support around. After all maintainers can't know if they have broken XP support unintentionally otherwise. If they don't donate those resources, it's obvious they don't actually care that much after all. Even still, there are libraries coming which can't support XP. I especially see any Boost.Thread v5 not supporting XP, not ever. That's still a while out, but the bullet should be bit sooner rather than later so notice should be given. Once Windows Server 2003 passes EOL I think it's time to give notice. It's not like older versions of Boost are going anywhere. People needing XP support can remain on an older Boost. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Stephan T. Lavavej

11:04 a.m.

[Niall Douglas]

...

Also Vista is highly unusual in that it had no corresponding Windows Server edition. There was a straight jump from an XP base (2003) to a 7 base (2008).

This is completely incorrect. Server 2008 was Vista-class, Server 2008 R2 was Win7-class. See http://en.wikipedia.org/wiki/Windows_Server_2008 : "Windows Server 2008 is built from the same code base as Windows Vista". Same deal with Server 2012 (8.0-class) and Server 2012 R2 (8.1-class). STL

Niall Douglas

12:59 p.m.

On 8 May 2015 at 11:04, Stephan T. Lavavej wrote:

...

[Niall Douglas]

...
Also Vista is highly unusual in that it had no corresponding Windows Server edition. There was a straight jump from an XP base (2003) to a 7 base (2008).

This is completely incorrect. Server 2008 was Vista-class, Server 2008 R2 was Win7-class. See http://en.wikipedia.org/wiki/Windows_Server_2008 : "Windows Server 2008 is built from the same code base as Windows Vista".

I had no idea the R2 variant was particularly different before. I had assumed also it was a free upgrade, but I am wrong on that too. Ok, I guess that means Boost should target the Vista API not Win7 then. That's a big problem for any Slim Reader Writer user as they only added the Try variant APIs in 7 :( Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Paul A. Bristow

13 May 13 May

12:28 p.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Niall Douglas Sent: 07 May 2015 23:46 To: boost@lists.boost.org Subject: Re: [boost] Windows XP support survey

No, I'm saying individual libraries can refuse to build on XP if they choose after support is dropped.

Even if Boost.Build sets _WIN32_WINNT to 0x601 (Win7), it should be the case that binaries still generally compile and work on XP. If a library uses a Vista or later API, then the DLL or EXE would refuse to load. If not, they should work fine.

What I'm suggesting is that notice is given that XP support is now down to each library maintainer's good wishes, and libraries are coming which won't support XP, and will never support XP.

FWIW, +1 for this. I suspect that the Boost libraries used by those stuck supporting XP code will not try to use any new libraries, nor get bug fixes from older libraries, because they are now fully 'mature'. If all else fails for them, they can freeze at a particular Boost version. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Andrey Semashev

7 May 7 May

10:48 p.m.

On Thursday 07 May 2015 22:31:37 Vladimir Prus wrote:

...

On 05/07/2015 12:56 PM, Niall Douglas wrote:

...
On 7 May 2015 at 10:34, Olaf van der Spek wrote:

...
...
...
As far as I know this is false. 2013 and 2015 have _xp toolsets that allow building for XP..

You may have missed my qualifier "nor by default".

No I didn't. What does it mean though? A 'default' VS2013 install does have the _xp toolset and thus can build for XP if the user wants.

Did you mean the _xp toolset isn't the default toolset?

I was working from deprecated knowledge where the XP compatible toolset was previously an optional download installed after Visual Studio.

VS2015 has first tier support for XP, so my argument that C++ 11 mandatory Boost libraries cannot work on XP is invalid. That removes one reason to deprecate supporting XP in Boost.

Incidentally, feelings on XP support seem very muted this time round, with everyone agreeing we should drop it after the next Boost release. I admit surprise on the consensus.

That might be too early. I, for one, object to artificially removing support for XP, which is what you appear to propose. It's still an OS used by people, so it's reasonable for app developers to target it, and having boost.config error out on XP will be bad.

Would it be ok if we just change the default in libs/winapi? XP would still be selectable.

Gavin Lambert

11:55 p.m.

On 7/05/2015 21:56, Niall Douglas wrote:

...

Incidentally, feelings on XP support seem very muted this time round, with everyone agreeing we should drop it after the next Boost release. I admit surprise on the consensus.

For what it's worth, as a Boost consumer I still care about Boost working on XP -- however for the application that I need to still work on XP, I'm ok with requiring that it use a specific Boost version and no later (it's already using one several versions behind the current release). I'm in favour of Boost changing its default _WIN32_WINNT setting to Vista/Win7, although *if possible* it would be nice if the application author could still choose to set it back to XP and have most of Boost still work.

Gevorg Voskanyan

10:39 p.m.

On 06.05.2015 14:03, Niall Douglas wrote:

...

[snip]

...

However Visual Studio 2012 cannot run on XP, nor by default can produce binaries which execute on XP,

Slight note on the above: that doesn't apply to all types of binaries, but only to EXE files. DLLs produced with a non-"_xp" toolset work just fine under Windows XP. In one of my projects I've put all the code in a DLL that is built regularly with the default toolset, and then I have a minimal EXE built with the _xp toolset that just forwards main()'s arguments to the DLL. That way the EXE never has to change, so there is no need to invoke the _xp toolset ever again even though the application undergoes heavy development and continues to work fine under Win XP. Gevorg

Gavin Lambert

8 May 8 May

1:39 a.m.

On 8/05/2015 10:39, Gevorg Voskanyan wrote:

...

On 06.05.2015 14:03, Niall Douglas wrote:

...
[snip]

...
However Visual Studio 2012 cannot run on XP, nor by default can produce binaries which execute on XP,

Slight note on the above: that doesn't apply to all types of binaries, but only to EXE files. DLLs produced with a non-"_xp" toolset work just fine under Windows XP. In one of my projects I've put all the code in a DLL that is built regularly with the default toolset, and then I have a minimal EXE built with the _xp toolset that just forwards main()'s arguments to the DLL. That way the EXE never has to change, so there is no need to invoke the _xp toolset ever again even though the application undergoes heavy development and continues to work fine under Win XP.

This might eventually bite you. Granted that I haven't verified this myself, but one of the reasons announced for the "_xp" vs. not-"_xp" toolsets was that the SDK team had removed XP support from the latest Platform SDK. So one of the things that _xp does is to select the older Platform SDK headers that still do support XP. Most APIs are the same between XP and Vista/7, so *most of the time* you can get away with using the wrong version, just like most of the time you can get away with running code compiled with _WIN32_WINNT=0x0601 on XP. If you happen to use one of the APIs that doesn't exist on XP, though, or (harder to track down) if you use one of the APIs that does exist on both but has had a structure size change, then you'll get code that mysteriously fails on XP by using the wrong toolset and/or wrong _WIN32_WINNT setting. The toolset also affects which version of ATL/MFC are linked to, and again since the newer versions of these do make use of non-XP-compatible APIs in some classes, if you happen to use these in your own code then you'll have problems on XP. (And since this is an implementation detail, it's not documented which classes are "safe" on XP when using the non-XP toolset.)

Gevorg Voskanyan

8:42 a.m.

On 08.05.2015 5:39, Gavin Lambert wrote:

...

This might eventually bite you.

Granted that I haven't verified this myself, but one of the reasons announced for the "_xp" vs. not-"_xp" toolsets was that the SDK team had removed XP support from the latest Platform SDK. So one of the things that _xp does is to select the older Platform SDK headers that still do support XP.

Most APIs are the same between XP and Vista/7, so *most of the time* you can get away with using the wrong version, just like most of the time you can get away with running code compiled with _WIN32_WINNT=0x0601 on XP.

If you happen to use one of the APIs that doesn't exist on XP, though, or (harder to track down) if you use one of the APIs that does exist on both but has had a structure size change, then you'll get code that mysteriously fails on XP by using the wrong toolset and/or wrong _WIN32_WINNT setting.

Good to know, thanks. No problems so far though.

...

The toolset also affects which version of ATL/MFC are linked to, and again since the newer versions of these do make use of non-XP-compatible APIs in some classes, if you happen to use these in your own code then you'll have problems on XP. (And since this is an implementation detail, it's not documented which classes are "safe" on XP when using the non-XP toolset.)

ATL/MFC isn't used by that code. Thank you, Gevorg

3469

Age (days ago)

3476

Last active (days ago)

List overview

Download

41 comments

14 participants

participants (14)

Andrey Semashev
Beman Dawes
David Stone
Edward Diener
Gavin Lambert
Gevorg Voskanyan
Matt Calabrese
Niall Douglas
Olaf van der Spek
Paul A. Bristow
pfultz2
Rob Stewart
Stephan T. Lavavej
Vladimir Prus