Nach der Veröffentlichung von SpeedCommander 14.50 im Februar dieses Jahres berichteten mir einige Anwender, dass das Installationsprogramm kurz vor dem Ende abstürzte und die Installation nicht richtig abgeschlossen wurde. Die Dateien wurden zwar kopiert, allerdings fehlten die Startmenü-Einträge und die einzelnen Anwendungen stürzten beim Aufruf ebenfalls ab. Betroffen waren nur XP-Anwender. Ich konnte das Problem aber nicht nachstellen, weder in einer VM noch auf diversen XP-Rechnern.

Ein Zusammenhang mit der Umstellung des Compilers von Visual Studio  2010 auf 2012 war naheliegend. Der finalen Version von Visual Studio 2012 fehlte zuerst die Unterstützung für XP. Nach einem Aufschrei der Entwickler wurde diese allerdings mit dem Update 1 wieder reaktiviert. Vielleicht war im Compiler ja durch diesen Umstand noch ein Fehler enthalten, der nur auf ganz wenigen Rechnern auftrat.

Da ich das Problem nicht nachstellen konnte, habe ich das Installationsprogramm mit MessageBox-Aufrufen zugepflastert und einer der betroffenen Anwender teilte mir dann immer mit, wie der letzte angezeigte Text lautete. So konnte ich mich Stück für Stück zur Absturzstelle tasten. Nun wusste ich zwar, wo der Absturz erfolgte. Aber nicht, warum.

Am Montag erhielt ich eine E-Mail von einem anderen betroffenen Anwender. Dieser hatte einen AMD-K6 in die Hände bekommen und damit ein paar Versuche angestellt. SpeedCommander ließ sich auf einem frischen XP nicht installieren, auch nicht auf einem Windows 7. Das brachte mich auf die Idee, meinen alten und schon längst in den Ruhestand verabschiedeten Dual Pentium III zu reaktivieren. Und siehe da, die Installationsprobleme traten hier auch auf.

Eine Erklärung dafür fand ich dann auf dieser Seite. Visual Studio 2012 erstellt nun standardmäßig Programme, die den SSE2-Befehlssatz verwenden. Wenn dies nicht gezielt durch den Kommandozeilenparameter /arch:IA32  deaktiviert wird, dann läuft das erstellte Programm nur noch auf Prozessoren mit SSE2-Befehlssatz. Neben dem Pentium III gehören auch Athlon XP/Duron/Sempron für den Sockel A zu den damit ausgeschlossenen Prozessoren.

Die Entscheidung von Microsoft, mit Visual Studio 2012 den Schalter für die Erstellung von SSE2-Code standardmäßig zu aktivieren, kann ich nicht nachvollziehen. Das kann auch nichts mit der temporär entfernten Unterstützung für Windows XP zu tun haben, denn selbst Windows 7 lässt sich noch auch Prozessoren ohne SSE2 installieren und verwenden. Man kann als Entwickler in Zukunft wohl nicht mehr darauf vertrauen, dass mit den gleichen Optionen erstellte Programme auch weiterhin auf allen vorher unterstützten Systemen laufen, wenn man den Compiler aktualisiert.

Ähnliches gilt übrigens auch für mit Visual Studio 2012 erstellte 64-bit Anwendungen. Unter Windows 8 beziehen sich Speicheradressen nun auf den gesamten 64-bit Adressraum. Allerdings gilt das nicht nur für die Anwendung selbst, sondern auch gleich für alle geladenen Dlls. Bei SpeedCommander schließt das sämtliche geladene Shellerweiterungen mit ein. Einige davon sind aber nicht darauf vorbereitet, dass die Adresszeiger plötzlich etwas größer als 2 GB sein können und stürzen dann bei Zeigeroperationen ab. Die Verwendung des gesamten Adressraums lässt sich durch den Linkerparameter /HIGHENTROPYVA:NO deaktivieren.

Für SpeedCommander 14 wird es in nächster Zeit noch ein kleines Update geben, das die Installation auf Prozessoren ohne SSE2-Unterstützung wieder ermöglicht. Bei SpeedCommander 15 kommt dies mit dem nächsten Update.

Zeitgleich mit Windows 8.1 hat Microsoft auch die finale Version von Visual Studio 2013 zum Download freigegeben.

Ich werde mir die neue Umgebung sicher mal in einer virtuellen Maschine anschauen. Zum produktiven Einsatz wird es aber nicht reichen. Weitaus interessanter sind da der neue Compiler und die MFC. Ich bin guter Hoffnung, dass sich beide wieder ohne großen Aufwand in Visual Studio 2008 integrieren lassen.