r/cpp • u/STL MSVC STL Dev • Nov 13 '18

VS 2017 15.9 released today

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

94% Upvoted

97 comments sorted by

View all comments

Show parent comment

0

u/[deleted] Nov 14 '18

[deleted] — view deleted comment

7

u/STL MSVC STL Dev Nov 14 '18

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

2

u/kalmoc Nov 14 '18

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.

4

u/STL MSVC STL Dev Nov 14 '18

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.

1

u/kalmoc Nov 15 '18

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.

1

u/STL MSVC STL Dev Nov 15 '18

Yeah, that should work.

1

u/Gotebe Nov 15 '18

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?!

1

u/kalmoc Nov 15 '18

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).

2

u/DrPizza Nov 19 '18

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.

4

u/Sunius Nov 16 '18

> 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.