Mit meinem vorherigen Blogeintrag Windows 8 ist Gift für Legacy Code kam auf Twitter eine Diskussion zu Stande, wieso denn unsere Anwendung derart hohe Berechtigungen benötigt und dass der Code doch inzwischen längst neu geschrieben worden sein sollte. Außerdem wurde eingeworfen, was Legacy Code direkt mit der UAC zu tun hätte.
Gemäß der englischen Wikipedia Ausgabe beschreibt Legacy Code unter anderem eine nicht länger 
unterstützte Technologie. Demzufolge ist Windows XP, als das am weitesten verbreiteten Betriebssystem nach Windows 7 ein Legacy System. Zunächst einmal hat Legacy Code nichts direkt mit der Benutzerkontensteuerung zu tun. Allerdings ist es so, dass Legacy Code in der Regel recht alt ist, weshalb er konsequenterweise eben auch nicht mehr weiterentwickelt wird. Code, welcher z.B. vor .NET entstand, würde ich in jedem Fall als Legacy bezeichnen. Selbst .NET 1.0 und 1.1 würden vermutlich die meisten von uns hier einordnen. Nun ist klar, dass vor beispielsweise 10 Jahren die Coding Conventions noch völlig andere waren. Programmkonfigurationen standen in INI-Dateien im lokalen Ausführungsverzeichnis oder die Registry musste für das ein oder andere Szenario herhalten. Demzufolge ist es vorwiegend Legacy Code, der mit der UAC Probleme macht. Das heißt nicht, dass nicht auch neuer Code nicht Schwächen aufweist, jedoch betrifft es vornehmlich alte Module.
Ich schätze, dass mindestens 80% der Anwendungen (z.B. die ERP-Systeme) noch entsprechende Module verwenden. Und das ist eine sehr konservative Schätzung! Holger Schwichtenberg schrieb zu Windows 7, dass noch kein Bestandteil auf .NET basiert. SAP hat nach dem, was ich von Consultants höre, noch teilweise Programmzeilen aus den 70er Jahren. Wie ich aus eigener Erfahrung weiß, ist selbst heute noch für die Datenübertragung im EDI Umfeld primär OFTP v1 im Einsatz, d.h. die Kommunikation zwischen Firmen geht mit einer überwältigenden Mehrheit über ISDN. Das zeigt, dass alte Technologien allgegenwärtig sind. Wer sich damit bisher noch nicht hat rumschlagen müssen, gehört zu den wenigen Glücklichen.
Wie gesagt: Nur, weil alte Software im Einsatz ist, heißt dies nicht, dass deshalb automatisch höhere Berechtigungen notwendig sind, doch leider ist das oft der Fall. Nun könnte man noch erörtern, wie es denn sein kann, dass die Codestrukturen noch nicht aktualisiert wurden. Das spielt für mich allerdings kaum eine Rolle, da wir einfach vor diesem Problem stehen.
Aber um der Sache Genüge zu tun: Projekte werden immer noch (nichts von wegen agil) in großen Firmen auf Jahrzehnte geplant, wenn man nach HP geht, läuft deren Strategie sogar auf 75 Jahre (geradezu lächerlich!). Darüber hinaus kann eine IT sich nicht einfach einmal 3-5 (oder länger) Jahre Zeit nehmen und allen alten Code migrieren. Wenn sie das täte, würde die Fachabteilung / Geschäftsleitung vermutlich den Verantwortlichen direkt vor die Tür setzen. Selbst wenn dem nicht so wäre, so käme man der Konkurrenz nicht mehr hinterher und könnte das Produkt gänzlich einstellen.
Frage an die Leser: Wer kam denn bisher gar nicht in die Berührung mit Legacy Code?
Mit Tag(s) versehen: LegacyCode, Win8
Uli Armbruster 
Unsere Anwendung existiert auch schon ziemlich lange – aber spätestens mit Win7 mussten wir feststellen, dass es keine gute Idee ist, eine INI Datei direkt ins Programmverzeichnis zu legen. Damit gab es damals schon Probleme.
Schlagen jetzt mit Windows 8 die Probleme erst auf, dann liegt es nicht an Windows 8, sondern an dem Versäumnis die App von Zeit zu Zeit zu warten, bzw. mal wieder auf den neuesten Stand zu bringen. So etwas rächt sich natürlich irgendwann.
LikeLike
Wir reden hier nicht von einer kleinen App, sondern von einem großen ERP-System… Wenn dem so einfach wäre allen Code auszutauschen, würde Microsoft nicht noch WinForms unterstützen müssen…Auch VB6 lässt sich mit Win8 noch installieren…Dann müsste man schon ganz konsequent sein und sagen: Hey, alles Alte raus! Denn gerade bei Legacy Codes sind Buffer Overflows vermutlich nicht schwer zu provozieren…
LikeLike
Aber es geht ja auch nicht darum WinForm rauszuwerfen und auf Metro umzustellen. So wie ich es verstanden habe, geht es mehr um Konfigurationsdetails. Also wo liegt die INI Dateien, und was steht in der Registry. Selbst bei einem großen ERP System, können da nicht all zu viele Klassen betroffen sein.
LikeLike
Sorry, da habe ich mich vielleicht missverständlich ausgedrückt: Ini-Files sind nur ein Beispiel wie früher gearbeitet wurde und was jetzt Probleme macht. Da haben wir noch ganz andere Szenarien…zum Beispiel das Speichern temporärer Dateien, wo man das nicht mehr darf. Oder das Lesen/Schreiben in der Registry, oder, oder…
LikeLike
Hoi Uli
Ich muss mich jetzt hier meinen Vorrednern anschliessen und mal die Facts auf den Tisch legen. Windows 7 wurde im Oktober 2009 offiziell gelaunched. Bereits Vorher gab es einige Informationen über UAC und Alphas bis RTMS wo man das Ganze ausprobieren konnte. D.h. was du hier propagierst ist reine Symptombekämpfung. Und Fakt ist: Ihr habt’s verschlafen! Punkt. Da hilft es nicht das Tool dafür verantwortlich zu machen. Deine Risikoanalyse muss das Aufzeigen und entsprechend in den Releasezyklus deiner Software miteinbeziehen. D.h. spätestens heute hättest du dieses Problem nicht mehr wenn ihr eure Hausaufgaben gemacht hättet. Ich arbeite auch in Projekten mit mehreren 100’000 Zeilen Code und selbst dort kriegt man die Probleme in den Griff. Oft sind es einfache Mittel wie Basepfade umlegen oder simple Helper einführen die längerfristig das Problem an der Wurzel packen.
Gruss Dani
LikeLike
Abgesehen davon war das nicht erst mit Windows 7 so, sondern galt schon unter Vista.
Wer das bis heute – immerhin drei Generationen von Windows – nicht umgestellt hat, sorry, der hat irgendwo gepennt, und bekommt jetzt dafür die Quittung.
Insofern habe ich da auch wenig Verständnis für, wenn man jetzt mit dem Finger auf Microsoft zeigt und sich beschwert, Legacy-Zeugs würde ja nicht mehr richtig unterstützt, das neue Konzept wäre realitätsfern, blablabla …
Nein, ist es eben nicht. Das ist vollkommen richtig. Das, WAS falsch ist, ist, seine Anwendung heute noch so laufen lassen zu wollen wie vor 10 Jahren auf XP.
Und insofern: +1 bezüglich dessen, was Dani geschrieben hat.
LikeLike
Also wir haben nichts umgestellt und verwenden stur WindowsXP weiter. Insgesamt würde ich davon ausgehen das, wenn überhaupt, Web-Entwickler von dem Legacy Code Problem weniger betroffen sind. Desktop Entwickler im Microsoft Umfeld reagieren wohl deshalb so gereizt weil dieses Problem ca. 12 Jahre lang(gerechnet ab Win95) nicht wirklich exisitierte. Die Mentalität ist so das Microsoft das gefälligst zu lösen hat, gerade weil Abwärtskompatibilität ja mal eines DER Markenzeichen von Microsoft war(Als Steve Ballmer noch nicht Alleinherrscher war). Ich verstehe beide Seiten und kritisiere an Microsoft lediglich das man sich manchmal schwer tut ‚offensiv‘ zu kommunizieren was jetzt eben so nicht mehr geht und das frühzeitig und nicht nur für Konferenzbesucher.
(Ich hätte mir gewünscht das man z.B. FxCop soweit aufbohrt auch Legacy Code zu erkennen)
LikeLike
@Daniel/Golo: Es ist leider finanziell nicht machbar, dass 10-15 Jahre alter Code in 3 Jahren derartig geändert wird, dass alle früheren Ansätze, die heute Probleme machen, gelöst werden. Lassen wir Vista außen vor, weil es in Firmen im Prinzip gar nicht eingesetzt wurde, so hatte man seit Win7 genau 3 Jahre Zeit! Anhand der Zahlen, wie hoch die Quote von WinXP noch in Firmen ist (nachdem win7 erst dieses Jahr WinXP im Endkundenmarkt überholen konnte!), kann man leicht ableiten, dass eben die Mehrheit der Firmen hier Probleme hat. Außerdem würde mich interessieren, an welchem 15-Jahre alten Projekt ihr mitentwickelt, bei dem dieses Problem bereits gelöst ist?
LikeLike
Wieso sollte man Vista außen vor lassen? Auch wenn es von Kunden vielleicht nicht genutzt wurde, so ändert das nichts daran, dass man als Entwickler wusste, was auf einen zukommen würde … dann halt ein paar Jahre später mit dem Nachfolger von Vista.
Und wenn das Geld nicht da ist (wobei es ja in der Regel eher am Wollen als am Geld hängt …), dann darf man sich eben nicht beschweren, wenn eines Tages was nicht mehr geht.
Unsere Branche ist nun mal davon geprägt, dass sich Dinge relativ zügig ändern. Wenn man diesen Wandel nicht mitgehen kann oder will, ist das okay – sofern man dann nicht erwartet, dass sich der Rest der Welt nach einem richtet.
LikeLike
Da kommen wir zu dem Punkt das Entwickler sich oft erst dann praktisch mit etwas beschäftigen wenn zum ersten Mal der Fall auf dem Tisch liegt. (Hier und da was lesen ist nochmal was anderes) Wenn der Kunde an Vista vorbei geht dann geht der Entwickler an Vista vorbei. Ja unsere Branche mag vom stetigen Wandel geprägt sein aber Kunden haben dafür nicht immer Verständniss, oftmals verstehen Kunden die Rolle des IT-Dienstleisters als Puffer für diese Probleme und irgendwo haben sie gelesen das .NET doch überall läuft… Für mich liegt die Warheit in der Mitte. In der Mehrheit der Fälle verursacht Legacy Code vor allem Secrity Issues. Sieht einer von euch noch eine Issue Kategorie die genau so stark vertreten ist?
LikeLike
PS: Zu dem bereits 15 Jahre alten Projekt erzähle ich Dir gerne OT was.
PPS: Dass man hier nur kommentieren kann, wenn man sich anmeldet, nervt …
LikeLike
Um noch auf die Frage aus dem ersten Teil zu kommen: Wie hieß das Analyse Tool von MS, um seine Anwendungen bzgl. der UAC Verstöße zu analysieren?
LikeLike
[…] UAC oder keine UAC – Das ist hier die Frage […]
LikeLike