Neue IDE mit altem Compiler
Bei mir läuft immer noch Visual Studio 2013. Ein Umstieg auf Visual Studio 2015 kam damals nicht in Frage. Mit dem ersten Update wurden zwar die Spaltenbreite im Quellcodeverwaltungs-Explorer bei HiDPI-Auflösungen angepasst, andere HiDPI-Probleme (z.B. die Größe Kleine der Aktionsschalter beim Zusammenführen) existieren allerdings immer noch. Der größte Nachteil war für mich aber die aus 40 Mini-Dlls bestehende neue Universal CRT, die mittlerweile auch als optionales Update für Windows 7 und 8 über Windows Update verteilt wird. Nach dem GWX-Trojaner kann ich aber jeden verstehen, der nur die wichtigen Updates installiert und alle optionalen Updates links liegen lässt. Irgendetwas in mir sträubt sich dagegen, diese 40 Dlls bei der Installation pauschal in das SpeedCommander-Programmverzeichnis zu kopieren.
Mit dem Release von Visual Studio 2017 vor vier Wochen habe ich mich einmal wieder etwas intensiver mit dem Thema IDE und Compiler beschäftigt. Microsoft wirbt ja damit, dass die Performance von IDE und Compiler/Linker bedeutend zugelegt hat. Beim Öffnen meines SpeedCommander-Arbeitsbereichs mit 40 Projekten konnte ich aber keinen großen Unterschied feststellen. Das Erstellen von SpeedCommander samt den abhängigen Projekten dauert mit dem Compiler/Linker von VS 2013 ca. 2:10 Minuten, mit dem VS 2017-Toolset dagegen 2:30 Minuten. Das hat mich dann doch etwas überrascht. Man kann zwar auch weiter das alte VS 2013-Toolset verwenden (wenn beide Versionen nebeneinander installiert werden), allerdings wird dann im Projektmappen-Explorer bei jedem Projekt der Zusatz (Visual Studio 2013) angefügt. Bei den ganzen Zusätzen gehen die Projektnamen völlig unter und sind nur noch schwer herauszulesen.
Das brachte mich auf die Idee, dem VS 2017 einfach mal das VS 2013-Toolset als sein eigenes VS 2017-Toolset unterzujubeln. Die Projekte werden also auf das neue Toolset umgestellt, was den Zusatz (Visual Studio 2013) im Projektmappen-Explorer entfernt. Zudem werden die VC-Verzeichnisse atlmfc, bin, crt, include und lib aus VS 2013 nach VS 2017 übertragen. Das neue Layout des VC-Ordners in VS 2017 erfordert zwar einige Anpassungen, am Ende kann man aber den alten Compiler für VS 2017-Projekte verwenden. Das einzige, was wirklich stört, ist eine öfters ausgegebene D9002-Warnmeldung des VC 2013-Compilers über eine nicht unterstützte Kommandozeilenoption. Das lässt sich auch nicht abstellen.
Also machte ich den gleichen Test noch einmal mit einem frisch installierten Visual Studio 2015. Die wichtigsten IDE-Neuerungen im Vergleich zu VS 2013 passierten größtenteils in VS 2015, in VS 2017 kam nicht mehr viel dazu. Die fünf Verzeichnisse aus VS 2013 konnte ich 1:1 nach VS 2015 übernehmen. Die Projekte wurden ohne Fehler und Warnhinweise kompiliert und anschließend gegen die alte VC 2013-Laufzeit gelinkt. Das Starten und Debuggen des kompilierten Programms verlief ebenfalls ohne Schwierigkeiten. Anschließend habe ich noch die verschiedenen alten vcvarsxxxx.bat-Dateien des VS 2013-Toolsets durch die Pendants von VS 2015 ersetzt, damit man die Projekte auch per Kommandozeile kompilieren kann.
Das ist für mich nun die perfekte Kombination. Das Entwicklerherz erfreut sich an den Neuerungen von Visual Studio 2015, während die kompilierten Programme weiter die alte Laufzeit mit zwei Dlls verwenden und nicht die Universal CRT mit 40 Mini-Dlls voraussetzen. Zudem hat Visual Studio 2015 vermutlich alle Feature-Updates hinter sich. Zusammen mit dem alten Compiler ist das eine gute Basis für die nächsten Jahre.
muss sagen ich finde das immer sehr interessant die Einblicke und auch wenn ich nur Anfänger bin bastel ich ab und an auch selbst trotzdem rum auch wenn ich beruflich die Richtung gewechselt habe.