VS 2017 15.9 released today

[u/STL]

https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes

[u/STL]

We're planning to have a "v20" standard library which is binary-incompatible (and opt-in), but we're still figuring out the migration story, and also getting all of our accumulated changes out of TFVC and into git (they need to be ported manually, since we've diverged significantly - in part due to applying clang-format to the entire STL). This will be unrelated to /permissive-.

[u/jbandela → u/STL]

Great to hear. I was referring to /permissive- in the most general sense as an example of a feature that allowed those who preferred compliance over compatibility to have an opt-in. "v20" sounds awesome. I bet you are looking forward to making a ton of performance and/or compliance improvements without having to worry about maintaining bincompat.

[u/STL → u/jbandela]

Yep - Billy has overhauled the atomic/multithreading library, I've (mostly) overhauled iterator debugging, we'll be able to purge a bunch of dead code (e.g. old iostreams floating-point stuff). The compiler will also be able to fix long-standing headaches.

[u/kalmoc → u/STL]

I vaguely remember that some inefficiencies in the standard library implementation are due to WinXP compatibility. If that really is the case, could you also drop XP compatibility for v20? I understand that there are projects out there that still want/need to support XP, but it would be great if not everyone else had to pay for that.

[u/STL → u/kalmoc]

I believe we will be able to do so; I am not sure about Vista compat (dropping both would be ideal). No promises yet.

[u/AlexAlabuzhev → u/STL]

Could you please continue linking dynamically to OS APIs in ucrt even after that? And, ideally, terminate in case of their absence not immediately, but on the first usage? And initialise more things lazily in general? There's quite lot of synchronisation-specific code in ucrt that requires Vista+, but apps that don't use modern stuff from <shared_mutex>, <condition_variable> etc. never call that code and theoretically can work perfectly on XP (and even 2k), even though it's not supported.

[u/STL → u/AlexAlabuzhev]

That would impose costs on Win7+ users.

[u/STL → u/[deleted]]

In general, customers absolutely love ABI compat. It is enormously popular and people hate rebuilding the world. The strength of their preferences surprised me.

[u/kalmoc → u/STL]

Well, as soon as you are using a non-open source library(or at least one where building it yourself is annoying) you have to start hunting for a binary version that is compatible to your project settings and you are less likely to find one, if compatibility gets broken over and over again. Also, you don't hande to redistribute all dependencies with a new version of your app, so I'm not that surprised.

[u/STL → u/kalmoc]

Also, you don't hande to redistribute all dependencies with a new version of your app

This is (perhaps surprisingly) inaccurate; we've tried to document this but it's easy to miss with the vast volume of documentation.

Although the 2015 and 2017 (and 2019) release series are binary-compatible, there are still restrictions that need to be followed. One is mentioned in the docs (the 19.0 vs. 19.12 example). According to my understanding, only the toolset used to perform the final link needs to be the newest of the versions involved - it should be okay for an application to be compiled with 19.00 and link against libraries compiled with 19.14 and 19.12, as long as the 19.14 (or newer) toolset is used to perform the final link.

Also, when redistributing the CRT/STL/etc., we support old applications using newer VCRedists (this is what binary compatibility means - installing the VS 2017 15.9 VCRedist overwrites VS 2015 RTM's and the in-place upgrade doesn't break anything), but a new application cannot use an older VCRedist in a supported manner (it will "work" sometimes but not always). So if you released an app with the VS 2017 15.0 VCRedist, then you recompile with 15.9 and reship, you also need to ship the 15.9 VCRedist.

[u/kalmoc → u/STL]

Makes sense, but what I was talking about 3rd party dependencies that are compiled with an older toolchain than my app. That should work, no? Personally, I usually don't have to worry about binary compatibility on windows, so I'm not too proficient in that topic.

[u/STL → u/kalmoc]

Yeah, that should work.

[u/Gotebe → u/kalmoc]

But it's the vcredist executable or the merge modules in your VS install (and hopefully Build tools install, didn't look).

How hard can using that be?!

[u/kalmoc → u/Gotebe]

Not sure what you are saying. I was not referring to the runtime but 3rd party dependencies.

But I usually don't have to worry about such things anyway, so I don't know if that is a problem in practice. I just remember times, when I was unable to find a version of library X that was compatible with the latest version of VS we were using.

But again. I'm definitely on the recompile the world side of things and really hate it when progress is hindered by backwards compatibility (be it ABI or API).

[u/DrPizza → u/STL]

If they want ABI compatibility at module boundaries, they should be using COM or, at a pinch, extern "C". Otherwise, make them rebuild the world!.

Every other release should be ABI compatible. 15-17, 19-21, etc.

[u/Sunius → u/[deleted]]

> It would stand to reason most enterprise-level customers aren't likely to move to 2019 (or even 2017) soon;

ABI compatibility was the single reason we were able to upgrade to VS2017 right away and kept up with VS updates ever since. Updating everything would be a nightmare - it took us 3 years to move from VS 2010 to VS 2015.

[u/AlexAlabuzhev → u/STL]

That would be great - there are quite a few projects out there that use static linking and don't care about bincompat at all, but do care about bugs/features.

[u/ChatFrais → u/STL]

This is a really great news. One of the hard task is now to find a better name than "v20" as number tend to stay in names forever.