Stl: What was the problem with run-time libraries as SxS (Side-by-side) assemblies?

[AlexGuteniev]

I'm old enough to recall when run-time libraries were SxS assemblies, and so there could be incompatible changes.

As I see, currently preservation of ABI between releases is used, and apparently the ABI was locked at the level of the first release after SxS.

So what was so bad about SxS that even fixed ABI throughout multiple releases is better?

[StephanTLavavej]

WinSxS (aka "Fusion") was considered more complicated to build and deploy, but after searching my email archives, I don't have good specific examples of "X used to be hard and it's easier now" (partly because I'm not a DLL/installer expert, mostly because issues weren't described in clear detail AFAICT).

It certainly took a lot of effort between VS 2008 and VS 2010 to stop using WinSxS and switch to our current model. However, this was unrelated to ABI stability. We've handled ABI breaks by renaming DLLs, and we intentionally broke ABI between all of VS 2008 (msvcp90.dll, last release with WinSxS), VS 2010 (msvcp100.dll), VS 2012 (msvcp110.dll), VS 2013 (msvcp120.dll), and VS 2015 (msvcp140.dll). Since then, the VS 2015/2017/2019 release series have been binary compatible (which is why the STL's DLL is still named msvcp140.dll).

@msalehmsft might know more. (According to my vague memories, he wasn't directly involved with the work to remove WinSxS, but he might have more detailed memories of that era than I do.)

[AlexGuteniev]

Ok, I thought you remember.
Asked just out of curiosity.
I thought WinSxS was supposed to solve what you call "printer driver problem".

[gmileka]

I used to work on the C++ libraries back in VS 8, 9, and 10... so I'll try to reconstruct my memories :)

The cost comes from sxs requiring a different signing process, a different packaging msi/wix pipeline, and a system to maintain the manifests and the redirection policies in a such a way that it is usable (one incorrect version, and things stop working).

If an organization is actually making full use of the tight coupling of sxs, there are a lot of dev scenarios that break down - ranging from most devs not understanding how to resolve sxs dependencies, to not knowing how to build and deploy, and finaly false positives where bits are compatible, but versioning doesn't allow it - and your exes stop working altogether.
This becomes very painful when we add different branches to the mix... This also translates to consumers of the library should the producers expose so many versions/redirection policies to them.

For VC++, we ended-up using sxs, but still renaming the assemblies between major versions and always redirecting to the latest. This is equivalent to just renaming the dll and replacing older versions of the dll with a new dll with the same name.
Note that such redirection disallowed any application from using older versions of the dlls even though it could exist sxs.
This was acceptable because the promise of VS at the time was to not break binary compatibility for a given major release during its servicing life time. So, unless a bin-compat bug escapes a servicing update, the customer should not have been affected.

One might ask, "why did VC++ deploy such global policies which points to the latest?" This kind of defeats the point of sxs... True, and the motivation was to make sure there is a way to patch security updates. Leaving vulnerable Microsoft dlls in use on the system is not an option.

Now, evaluating the cost of producing/maintaining sxs assemblies vs. (what's left of) the benefits, became hard to justify for VC++. So we made the decision to revert to renaming the dlls with each major version.

I've left the C++ libraries team since 2012, so I am not up to date with how things are done now.

[StephanTLavavej]

Thanks for the definitive answer, @gmileka!

[MahmoudGSaleh]

Thanks @gmileka for all the details and the context 👍