[English]Kleine Meldung zum Thema C++ Runtime-Bibliotheken und deren Verteilung als Redistribution-Pakete mit allen Problemen einer Side-by-side-Installation mit unterschiedlichen Versionen. Microsoft hat bei der Visual C ++ 2019 Redistributable auf Kritik reagiert und verwendet die gleichen Dateien wie für VC++ 2015/2017.
Anzeige
Worum geht es?
Die meisten Programme benötigen Laufzeitbibliotheken, um ausgeführt zu werden. Bei Visual C++ ist das die Redistributables (Runtime-Bibliotheken), die mit der jeweiligen Anwendung mit installiert werden. Werden VC++Runtime-Bibliotheken durch Sicherheitsupdates aktualisiert, installiert Windows diese in den meisten Fällen Side-by-Side.
Warum die Laufzeitbibliotheken Side-by-Side installiert werden, habe ich im Blog-Beitrag Windows 7/8.1/10: Fehler Side-by-Side-Konfiguration ungültig in anderem Zusammenhang erläutert.
In kurz: Laufzeitbibliotheken werden zentral gespeichert, damit die Anwendungen nicht jedes Mal die gleichen DLLs separat in Programmordner installieren müssen. Man kann durch gemeinsame Nutzung der Bibliotheken Speicherplatz sparen.
Das Problem: Verwenden zwei Anwendungen unterschiedliche Versionen einer Laufzeitbibliothek, käme es zu Konflikten, wenn die zuletzt installierte Anwendung einfach die bereits vorhandenen Runtime-Dateien überschreiben würde. Dann kommt es bei der Installation der Anwendung zu einem Konflikt, der früher als "DLL hell" bekannt war.
Um dieses dieses Problem elegant zu umgehen, wurden die Side by Side-Konfiguration im Ordner WinSxS (Windows component store) eingeführt. Bei der Installation einer Anwendung werden die Laufzeitbibliotheken, DLLs, und ggf. andere Ressourcen, in einem eigenen Unterordner des Ordners WinSxS gespeichert. Dadurch behindern sich nicht mehrere Dateien gleichzeitig. Weitere Insides finden sich im genannten Blog-Beitrag.
Anzeige
In der Praxis führt das aber zu vielfältigen Problemen – u.a. das unsichere, längst gepatchte Versionen, über Software und Updates auf einem Rechner landen. Ich hatte dies, mit Hilfe von Blog-Leser Karl, in einer Artikelreihe Das Problem mit C++ Redists & 3rd Party Sicherheitspatches – Teil 1 angesprochen. Wir hatten das auch an Microsoft herangetragen.
Runtime für VC++ 2019 mit V2015/2017
Das scheint am Ende des Tages Früchte getragen zu haben. Blog-Leser Karl hat mich gestern auf Twitter über eine Änderung informiertaufgeklärt, die Microsoft mit der Runtime für VC++ 2019 einführt.
All that care to manage C++ redists MS has released C++ 2019 which will include and replace 2015 and 2017.
Great work as this finally ends the side by side installation of outdated redists by software. All in one Runtimes isn't yet updated.@ComputerBase
Fyi @etguenni— al Qamar (Karl) (@tweet_alqamar) 20. Juni 2019
Wer sich mit der Verwaltung der VC ++ Redistributables kümmern muss, bekommt jetzt Entlastung (falls Microsoft seinen Job richtig macht – muss man abwarten). In der neu erscheinenden Laufzeitumgebung für C++ 2019 ist, laut dem obigen Tweet, auch die Redistributable von VC++ 2015 und von VC++ 2017 enthalten. Microsoft hat dazu Ende Mai 2019 diesen KB-Artikel veröffentlicht. Zitat aus dem Beitrag:
Hinweis Visual C++ 2015, 2017 und 2019 haben alle die gleichen weitervertreibbaren Dateien.
Das Installieren der Visual C++ 2019 Redistributable wirkt sich beispielsweise auf Programme aus, die mit Visual C++ 2015 und 2017 erstellt wurden. Die Installation der Visual C++ 2015 Redistributable ersetzt jedoch nicht die neueren Versionen der von Visual C++ 2017 und 2019 Redistributables installierten Dateien.
Dies unterscheidet sich von allen früheren Visual C++-Versionen, da sie jeweils ihre eigenen Runtime-Dateien hatten, die nicht mit anderen Versionen geteilt wurden.
Damit muss man sich nicht mehr um diese beiden letztgenannten Fassungen kümmern. Bei den Runtime-Bibliotheken von VC ++ 2013 oder früher ändert sich aber nichts. In einer persönlichen Mail informierte Karl mich über folgendes:
Die Neuerung gibt es übrigens schon seit C++ 2017 (14.10 / 14.16) die zum ersten Mal in der Geschichte die C++ 2015 (14.0) ersetzt.
In der Praxis gab es damit jedoch Probleme mit einigen Programmen die mit 2015 kompiliert worden sind. Es gab jedoch nochmal ein Update für die 2017 Runtimes und nun die 2019 (14.21) ich werde die demnächst bei dem Kunden mit den Problemen ausrollen und schauen ob es dann weniger Probleme gibt. Es war für mich ein Novum, dass es mit neueren Runtimes überhaupt „Stress" gibt. Wahrscheinlich schlechter Code.
Gerade bei 2013 oder älter kommt es durch Applikationen oder Spiele (Steam) immer wieder zu ersetzten Runtimes.
Das Problem wird sich aber wohl mit der Zeit erledigen wenn man nur neue Applikationen nutzt. 2005 sind wohl schon out of support und 2008 glaube ich. Was nicht heißt das ich diese dann nicht mehr installieren würde
Es ist allemal besser die letzten aktuellen Runtimes zu installieren, als gar keine was dann für noch ältere Installationen sorgt – je nachdem wie die ihre Installerprüfung programmiert haben – also gleich oder neuer: belassen / älter: side by side installieren
Zudem weist Karl darauf hin, dass es seit C++ 2008 keine Updates mehr für C++ über Windows Update / WSUS gibt. Er schreibt auch:
Windows Update für Business patcht ohnehin nur Windows Komponenten. C++ wäre also 3rd Party-Software. Bis heute werden über die Microsoft Downloadseiten und Windows Update veraltete C++ 2005, 2008 und 2012 redists verteilt. Jedenfalls ältere als die in my.visualstudio.com erhältlichen bzw. über Patrick Kuhnke AIO runtimes erhältlichen. Ich denke es will sich darum auch keiner mehr kümmern und man lässt es so aussterben.
Karl hat auf Twitter dann noch ein paar Screenshots gepostet, wie ein gesäubertes System ausschauen sollte.
This is how it should look like in with a cleaned / secure environment (AIO Runtime 2.4.8 C++ & C++ 2019) AIO will remove insecure C++ redists as Windows Update still won't update them correctly. some of the updates here are outdated, too.https://t.co/BIIBbV8RsV pic.twitter.com/G39J2RzmQ3
— al Qamar (Karl) (@tweet_alqamar) 20. Juni 2019
Das Kürzel AIO steht für All in One Runtime, die von Patrick Kuhnke gepflegt wird. Das hatte ich im Blog-Beitrag Das Problem mit C++ Redists & 3rd Party Sicherheitspatches – Teil 3 mit Unterstützung von Karl schon mal thematisiert.
Ähnliche Artikel:
Windows 7/8.1/10: Fehler Side-by-Side-Konfiguration ungültig
Citrix Workspace-App ab V1904 ohne VC++ Runtime
Das Problem mit C++ Redists & 3rd Party Sicherheitspatches – Teil 1
Das Problem mit C++ Redists & 3rd Party Sicherheitspatches – Teil 2
Das Problem mit C++ Redists & 3rd Party Sicherheitspatches – Teil 3
Sicherheit: Microsoft Visual C++ Runtime kommt mit alten Wix-Installern und Schwachstellen
Anzeige
Dann hoffen wir mal, dass Installer aelterer Programme, die meinen, ein VC++ Redist mitliefern zu muessen, nicht an der fehlgeschlagenen Redist-Installation scheitern, weil eine spaetere Version bereits installiert ist.
Das Chaos geht mir auch auf die Nerven. Schlimm genug das die Aufsplittung in x86 und x64 existiert, so gibt es noch Minimal und Additional Runtimes. Die 2019 VC++ runtimes nutze ich schon seit Monaten.
Sieht sauber bei mir so aus: https://abload.de/img/runtimesfcj0p.png
Jetzt der eigentlich Aufreger: Warum lässt MS verdammicht nochmal zu, dass wenn bereits AKTUELLE runtimes installiert sind, jedes dahergelaufene Programm nochmals alte Versionen dieser installieren darf? Wenn ich je Probleme hatte, dann weil mir irgendein Installer eine alte Version untergejubelt hatte.
Das Problem ruehrt ja nicht daher, dass es fuer verschiedene Versionen der Entwicklungsumgebungen verschiedene Runtimes gibt.
Problematisch wird es erst, wenn Anwendungen eine VC++ Runtime mitbringen, die aus der selben Hauptversion stammen und ggf. eine aeltere Version aktualisieren (was andere Anwendungen nicht moegen koennten) bzw. bei denen die Installation scheitert, weil die im Installer enthaltene Runtime aelter ist und die Installation verweigert.
–> total gaga ist hierbei, das VC++ 2015, 2017 und 2019 alle derselben Hauptversion angehoeren, macht die Fehlersuche nicht unbedingt einfacher.
Und nebenbei werden Updates fuer die C++ Runtimes noch ueber Windows-Update verteilt.
Und: die VC++ Runtimes lassen sich (mit etwas Trickserei) auch per MSI/Softwareverteilung installieren – auch das kollidiert mit den per Windows Update verteilten Aktualisierungen.
Hallo Mitstreiter, danke für euer Feedback.
Wenn man die 2019 installiert wird diese nicht mehr durch 2015 oder 2017 ersetzt.
Getestet u.a. mit Citrix Workspace welches 2017 nutzt.
Ab der vorherigen Version hat Citrix, u. a. auch auf mein und anderer betreiben die C++ Installation separiert. Zuvor gab es immer wieder Probleme bei automatischer Silent Installation, mal fehlen Redists dann oder sie lagen in Programmverzeichnissen wo sie nicht hingehörten und dann fehlte z.B. das Self Service Plugin.
Die Installation der Redists für C++ 2013 oder neuer via GPO Softwarezuweisung ist möglich, aber umständlicher zu Pflegen als mit AIO. Insb. lassen sich solche Verteilungen nur mit mühe aus der Registry entfernen, da sie auch noch unter HKLM Group Policies Appmgt Metadaten anlegen.
Das "Problem" ist das minimal und additional Quatsch sind. Diese wurden in der Vergangenheit auch nicht benötigt.
Nur die Aufsplittung nach Jahreszahl und Architektur ist sinnvoll.
Ob jetzt ein embedded system einem library von 5 MB oder 20 MB hat sollte im Zeitalter von SSDs mit mehreren 100GB keine Rolle spielen. Storage ist kein limitierender Faktor mehr.
Windows 10 hat jetzt eigene VC++ Libs. Liegen aber in anderen Ordnern.
Diese gelten nur für Store Apps (appx, MSIX etc).
Ich les immer nur Patrick Kuhne, schreib doch das Du Sereby meinst ;) – Ich hatte Ihm übrigens geschrieben, das seine letzten AIO-Runtimefiles – eine doppelte .dll haben, und alle bis auf eine x86 Versionen sind, aber im 64Bit folder(System32) landen, statt im 32Bit-Syswow64… – Da mich das bissle irretiert hat, hab ich bei msfn noch nen Thread gemacht, über die Frage wo solche dll´s hingehören, und ob ich SYSWOW64 als Environment-Variable "adden" sollte… – meld dir (warst doch auch so nen nlite Foren Hase…)
https://msfn.org/board/topic/180722-path-environment-x86-x64-vs-32bit-file/
Es ist noch nicht vorbei. Microsoft schafft es auch mit C++ 2015-2019 einen Bock zu schießen. Hardcode Version Check bei eigenem Setup für Exchange 2016 / 2019
https://docs.microsoft.com/en-us/answers/questions/167684/exchange-2016-exchange-2019-wrong-recommendations.html