Blog · 23. Oktober 2026
Altlasten am Leben halten: wenn der Quellstand nicht mehr vollständig ist
Nicht jede Elektronik, die wir betreuen, ist bei uns entstanden. Einiges haben wir als Altbestand übernommen: eine Servicesoftware in Visual Basic 6, Firmwarequellen im Zeichensatz Windows-1252, Platinen, von denen nur noch die Fertigungsdaten existieren. Das ist keine Ausnahme, sondern der Normalfall, sobald ein Gerät älter ist als die Werkzeuge, mit denen es gebaut wurde. Was wir dabei gelernt haben.
Erst sichten — und den Dateidaten nicht trauen
Ein Altbestand kommt selten als geordnetes Archiv, meist als Kopie eines Laufwerks. Die erste Versuchung ist, nach Datum zu sortieren. Das führt in die Irre: In einem übernommenen Bestand trug fast jede Datei dasselbe Datum — das der Kopie —, einige sogar den 1. Januar 1980. Das ist das früheste Datum, das das alte Dateisystem FAT speichern kann; es steht meist dort, wo beim Kopieren oder Packen kein gültiges Datum mehr mitkam.
Die Reihenfolge der Stände steht deshalb nicht im Dateisystem, sondern in den Dateien selbst: im Titelblock des Schaltplans, im Versionsfeld der Layoutdatei, in Änderungslisten. Auch Namen täuschen. Ein Ordner namens „REV1839" klingt nach Platinenrevision — die Zahl bezeichnete aber den Build des Layoutprogramms, mit dem gespeichert worden war. Und mehrere Dateien gleichen Namens in verschiedenen Ordnern hatten verschiedenen Inhalt: Wer beim Einsortieren den Herkunftspfad wegwirft, überschreibt unbemerkt einen Stand mit einem anderen.
Nach dem Einsortieren wird gezählt, ob alles angekommen ist. Versionsverwaltungen schließen Ausgabeordner wie „Gerber" oder „Plot" oft absichtlich aus — beim Import eines Altbestands verschwinden Dateien in Ordnern dieses Namens dann ohne jede Meldung.
Wenn der editierbare Quellstand fehlt
Von einer Platine gab es keinen Schaltplan und kein Layout zum Bearbeiten mehr, nur den Fertigungsdatensatz aus einem anderen Layoutprogramm: Gerber, Bohrdatei, Plots. Bei einer anderen lag die Layoutdatei laut Dateikopf auf einem Netzlaufwerk des früheren Entwicklungsrechners — im übergebenen Bestand ist sie nicht enthalten. In beiden Fällen ist der Fertigungsdatensatz jetzt der einzige technische Nachweis der Platine. Er wird nicht aufgeräumt, sondern gesichert, auch wenn Fertigungsdaten sonst nicht zu den Entwurfsdaten gehören. Muss die Platine je neu aufgelegt werden, beginnt die Arbeit dort.
Widersprechen sich die Unterlagen, zählt, was gefertigt wurde. Bei einer Baugruppe nannten Layout und Stückliste für dieselbe Position verschiedene Drosseln; gefertigt worden war nach der Stückliste. Solche Funde werden festgehalten und mit dem Kunden geklärt — nicht stillschweigend in eine Richtung „korrigiert".
Bei der Firmware ist die entscheidende Frage nicht, ob ein Quellcode übergeben wurde, sondern ob er vollständig ist. Das zeigt erst der eigene Build: Lässt sich der Stand bauen, und verhält sich das Ergebnis auf dem Gerät wie die Firmware, mit der heute produziert wird? Bis das belegt ist, bleibt die ausgelieferte Datei die Referenz. Fehlt der Quellcode ganz, heißt das meist: neu schreiben, gegen das dokumentierte Verhalten des laufenden Geräts — wie wir dabei vorgehen, steht auf der Seite zur Übernahme verwaister Entwicklungen und im Beitrag über fremde Firmware.
Der Zeichensatz: wenn aus einem Byte zwei werden
Ältere Firmwarequellen sind oft nicht in UTF-8 gespeichert, sondern in Windows-1252, mit Windows-Zeilenenden. Was dort als Text steht, kommt am Ende als Bytes auf dem Display an. Moderne Editoren und Werkzeuge nehmen UTF-8 an und schreiben eine Datei beim Speichern gern stillschweigend um — dann ändern sich genau diese Bytes:
| Zeichen | Windows-1252 | UTF-8 |
|---|---|---|
| ° (Grad) | B0 | C2 B0 |
| ü | FC | C3 BC |
| € | 80 | E2 82 AC |
Eine Anzeige, die die Bytes nach Windows-1252 darstellt, zeigt statt „25 °C" dann „25 °C"; Texte fester Breite verschieben sich, Menüzeilen laufen über. Ein Fehler beim Kompilieren entsteht dabei in der Regel nicht.
Unsere Regel für solche Bestände: Die Quellen bleiben im Zeichensatz, in dem sie angelegt sind — samt der Änderungsdokumentation, die neben dem Code liegt. Geändert wird byteweise, und nach jeder Änderung wird geprüft, dass sich nur die beabsichtigten Bytes geändert haben und jede Zeile noch mit dem Windows-Zeilenende schließt.
Varianten: eine Änderung, mehrere Geräte
Eine Firmware, die über mehrere Gerätevarianten gepflegt wird, steckt voller bedingter Übersetzung: Je nach Variante wird ein anderer Teil des Codes gebaut. Ändert sich etwas für eine Variante, muss belegt sein, dass die anderen nichts davon abbekommen. Wir lassen dafür den Präprozessor des Compilers den Code jeder unbeteiligten Variante auflösen und vergleichen das Ergebnis mit dem unveränderten Stand — es muss identisch sein. „0 Fehler" beim Bauen ist dabei kein Nachweis; der Nachweis ist der Vergleich.
Jede ausgelieferte Firmwaredatei trägt Variante, Version und Datum im Namen, und im Versionsverlauf steht, aus welchem Quellstand sie gebaut wurde. Ein ausgelieferter Stand wird danach nicht mehr verschoben. So lässt sich auch in Jahren noch beantworten, welcher Code auf einem Gerät läuft — die Frage, an der Altbestände sonst scheitern.
Auch die Servicesoftware gehört zum Gerät
Eine Servicesoftware in Visual Basic 6 würde heute niemand mehr so schreiben. Solange im Feld mit ihr gearbeitet wird, gehört sie aber zum Produkt — und wird gepflegt wie die Firmware, statt bei der ersten Gelegenheit neu geschrieben zu werden. Ein Neubau ist ein eigenes Projekt mit eigenem Risiko. Er lohnt sich, wenn die alte Software nicht mehr zu halten ist, nicht schon, weil sie alt ist.
Und bei Ihnen?
Ließe sich die Firmware Ihres ältesten Geräts, das noch gefertigt wird, heute aus dem Quellstand bauen — und wer würde das prüfen? Schreiben Sie uns — uns interessiert, welches Stück bei Ihnen zuerst gefehlt hat.
Transparenzhinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und vor der Veröffentlichung fachlich geprüft.