Softwarewartung

Software altert nicht. Was einmal programmiert wurde, kann bis zum Ende der Ewigkeit so bleiben, wie es mal war, als es “fertig” genannt wurde. Das kann vielleicht sogar bewiesen werden, zumindest wenn die Mathematik hinter den Git-Hash-Werten die Unveränderlichkeit zutreffend beweist. Und was ist mit Bugs?

Software altert nicht. Also können Bugs im Grunde nicht existieren, oder das was “fertig” schien war leider doch nicht so ganz fertig. Aus diesem Grunde (und weil wir alle nur Menschen sind) muss Software leider doch gelegentlich angefasst und angepasst werden. Manchmal möchten besagte Menschen auch nachträglich noch etwas daran ändern, vielleicht weil sie sich erst während der Benutzung darüber klar geworden sind, dass die vorherige Planung – wie überraschend! – eben doch nicht alle Eventualitäten einbeziehen konnte. Das ist dann natürlich kein Bug, sondern mehr ein neues Requirement oder ein Feature Request, wie auch immer man das nennen mag. Soweit ist das sicher bekannt.

Software-Wartung

Ein kurzer Exkurs in die Begrifflichkeit sei uns gestattet. Es gibt nämlich durchaus Stimmen, die von dem Begriff “Wartung” im Zusammenhang mit Software Abstand nehmen. Die “Wartung” eines technischen Gerätes umfasst nämlich eine etwas andere Tätigkeit, als wir dies für Software erwarten dürfen. Wikipedia sagt dazu:

Nach einer ggf. erforderlichen Sicherung des Wartungspersonals durch Wartungssicherungen umfasst eine Wartung z. B. Nachstellen, Schmieren, Konservieren, Nachfüllen, Ergänzen oder Ersetzen von Betriebsstoffen oder Verbrauchsmitteln (z. B. Kraftstoff, Schmierstoff oder Wasser) und planmäßiges Austauschen von Verschleißteilen (z. B. Filter oder Dichtungen), wenn deren noch zu erwartende Lebensdauer offensichtlich oder gemäß Herstellerangabe kürzer ist als das nächste Wartungs-Intervall.

Das alles ist für Software wohl nicht erforderlich, denn Software altert nicht, und es gibt auch keinen digitalen Verschleiß, der mit dem mechanischen Abrieb vergleichbar wäre.

Es gibt aber einen wesentlichen Unterschied: Im industriellen Bereich ändert sich (ohne Wartung) das Verhalten der Maschine durch Verschleiß, während das Umfeld weitgehend gleich bleibt. Im Software-Bereich ist es genau umgekehrt.

Wie auch immer wir es nun nennen, eines wiederum haben beide Systeme gemeinsam: Es werden gelegentlich Arbeiten am Objekt (Maschine oder Software) durchzuführen sein, um die weitere Funktion zu gewährleisten.

Umwelteinflüsse

Es gibt also einen Aspekt, den man nicht übersehen sollte: Die Welt um die Software herum ändert sich. So wie wir aktuell vor der Frage stehen, ob der Klimawandel uns zu einer Anpassung unserer Lebensgewohnheiten drängt, so muss auch unsere Software gelegentlich an die veränderten “Umweltbedingungen” angepasst werden. Ich verwende dieses Wort absichtlich, auch wenn natürlich klar sein sollte, dass mehr oder weniger viel Regen oder Sonnenschein kaum eine Auswirkung auf unsere Software haben dürfte. Im englischen wird das, was in der deutschen Windows-Lokalisierung “Systemumgebung” heißt, übrigens tatsächlich “environment” genannt!

Dennoch gibt es doch auch für Software genügend Gründe, nicht mehr zu funktionieren. Ebenso wie wir Menschen also unter Umständen unsere Lebensgewohnheiten im Zuge einer globalen Erwärmung ändern müssen, so muss auch die Software geändert werden, wenn in ihrem Öko- oder auch Betriebssystem eine gravierende Änderung erfolgt.

Häretiker

Fairerweise muss gesagt werden, dass einige Leute nicht an den Klimawandel glauben. Sie mögen Recht haben damit, oder auch nicht. Doch diese Leute wären sicher überrascht, wenn es entgegen ihrer Ansicht dann doch passiert, und sie hätten vielleicht gut daran getan, sich rechtzeitig mit der Thematik auseinanderzusetzen. “Ich glaube, Gefahren lauern nur auf jene, die nicht auf das Leben reagieren.” (Gorbatschow, 1989)

Ebenso wie im Leben ist es auch für den Softwareentwickler durchaus angebracht, sich ein paar Gedanken über mögliche Veränderungen der “Umwelt” zu machen, sei es die digitale oder die analoge. Denn der Glaube an die Unveränderlichkeit der Umgebung hat uns Entwickler schon das eine oder andere mal in die Irre geführt. Glaube allein reicht also nicht. Be prepared!

Der Software-Prepper

Wenn man nicht weiß, was passieren wird, ist es schwer, rechtzeitige Maßnahmen zu planen und zu ergreifen. Aber ein paar Dinge kann man – zumindest im Fall der Software – sicher berücksichtigen. Wie so oft hilft dabei der Blick in die Vergangenheit, denn nur selten passiert etwas absolut Neues.

Natura non facit saltu̅s – die Natur macht keine Sprünge (ja, “Sprünge”, denn “saltus” ist U-Deklination, langes “u”, Akkusativ Plural). Was wir gemeinhin mit “analoger Technik” gleichsetzen, ist zumindest für die Quantenmechanik bereits widerlegt. Auch die Software hält sich leider nicht immer an diesen abendländischen Grundsatz, was jeder bemerken wird, wenn er mit einem digitalen Musikkanal im Autoradio durch einen Tunnel fährt. Eine Zeit lang läuft die Musik weiter, dann bricht sie abrupt ab.

So gibt es leider auch bei Windows-Updates gelegentlich Überraschungen, eine davon habe ich in dem gleichnamigen Artikel bereits für Windows 10 beschrieben. Eine weitere Überraschung ist das mögliche Update auf ein 64-Bit-Office.

Der Katastrophenfall

In der Vergangenheit gab es schon mal so eine Umstellung, wenn ich mich richtig erinnere ging es um die Umstellung von 16 auf 32 Bit (oder war’s 8 auf 16?). Damals wurde in der Windows-API eine Reihe neuer Funktionen eingeführt. Diese unterschieden sich von den Vorgängern durch ein angehängtes “A” im Namen. Dadurch konnten die alten Funktionen bedenkenlos weiter verwendet werden. Wollte man jedoch die neuen verwenden, musste eine Überarbeitung der Deklarationen und teilweise auch Parameter-Typen vorgenommen werden.

Nunmehr gibt es seit einigen Jahren zwar ein 64-bittiges Office, aber genutzt wurde es nur selten. Selbst Microsoft empfahl in der Vergangenheit, im Zweifel lieber das 32-Bit-Office zu installieren, auch auf einem 64-Bit-Windows. Irgendwann, so scheint es, wurde jedoch diese Empfehlung klammheimlich fallengelassen, jedoch keineswegs durch die neue ersetzt, künftig bitte auf 64 Bit zu setzen.

Es kam, wie es kommen musste. Bei einem Kunden wurde schlagartig und unternehmensweit Microsoft Office 365 in der 64-Bit-Variante ausgerollt. Die Entwickler vorab zu informieren hielt man offenbar nicht für notwendig. Ebenso schlagartig, das heißt von heute auf morgen, funktionierten einige Applikationen nicht mehr. Zum Teil war das auf eine entsprechende Warnung von VBA zurückzuführen, aber auch darauf, dass das MSFlexGrid im VBA-Umfeld leider nicht mehr ladbar war. Ein guter Grund übrigens, auf ActiveX/OCX-Unterstützung so weit wie möglich zu verzichten. Aber das ist ja auch keine neue Erkenntnis.

Ja, man hätte es ahnen können. Ja, man hätte sich vorbereiten können. Und nein, ich habe das nicht gemacht. Damit es euch nicht ebenfalls passiert, dachte ich, ich erwähne das mal.

Die Lösung

Im Grundsatz geht es darum, alle API-Deklarationen (VBA: “declare function”) für die zukünftige Verwendung eines 64-Bit-Offices fit zu machen, ohne dadurch die Lauffähigkeit unter 32 Bit zu beeinträchtigen. Die Declare-Anweisung beschreibt (“deklariert”), woher eine externe Funktion aufzurufen ist, und wie dies genau zu geschehen hat.

Im Prinzip gleicht diese Anweisung unserer VBA-eigenen “Function”-Deklaration. Der Unterschied ist allerdings, dass wir hier nicht mehr frei in der Wahl der Parameter-Typen sind, sondern dass diese genau der Vorgabe entsprechen müssen. Denn die tatsächliche Funktion wird nicht in unserer VBA-Umgebung ausprogrammiert (“definiert”), sondern in einer DLL, die natürlich vorhanden sein muss.

Diese Code-Änderungen können bereits ab Office 2010 gemacht werden, da seit damals die Version 7 von VBA eingeführt wurde. Dadurch haben wir Zeit, die Änderungen durchzuführen und zu testen – wenn wir es rechtzeitig angehen.

Dies geschieht, indem Long-Datentypen in ihre größere Variante abgeändert werden – aber keineswegs immer. Es kommt nämlich auf die Verwendung dieser Variablen an! Eine normale Integer- oder Long-Variable bleibt nämlich auch unter 64 Bit das, was sie war: Eine 2-Byte- oder 4-Byte-Ganzzahl. Unter 32 Bit wurde jedoch “Long” auch für “Zeiger” verwendet, und da müssen wir etwas aufpassen.

Zeiger (engl. “pointer”) sind im Grunde auch nur lange Ganzzahlen, aber sie werden als Adressen von Speicherstellen interpretiert. Und diese sind unter 64 Bit nun mal etwas länger als zuvor unter 32 Bit. Daher muss auch die Variable “länger” werden, um den größeren Wert aufnehmen zu können. Das ist vergleichbar mit der Umstellung der deutschen Postleitzahlen vor vielen Jahren. Wer damals eine Software hatte, die aus Ersparnisgründen nur die bis dahin gültigen 4 Stellen für die alte Postleitzahl bereitgestellt hatte, musste diesen Speicherplatz nun um eine Stelle erweitern.

Würde man nun eine 8-Byte-Ganzzahl auf einen Speicherplatz schreiben, der nur für eine 4-Byte-Ganzzahl gedacht ist, dann würde die zweite Hälfte dieser langen Zahl an eine Stelle geschrieben, die bereits für eine andere Variable reserviert ist. Dass das ein hübsches Durcheinander geben wird, können wir uns sicher vorstellen.

VBA7 hat dafür das Schlüsselwort “PtrSafe” bereitgestellt. Unterstützt von dem neuen Datentyp “LongPtr” können wir dies verwenden, um unser 32-Bit-VBA bereits jetzt fit zu machen für das spätere Update auf 64 Bit. Das Problem rund um das MSFlexGrid ist damit leider nicht zu lösen.

Dies war nur ein kurzer Abriss zu der Thematik, dass die Antwort nicht immer 42, sondern manchmal auch 64 lautet :-) Mein Kollege Philipp Stiefel hat einen hervorragenden längeren Artikel dazu geschrieben, den ihr auf seiner Website codekabinett.com lesen könnt.

 

⁕ = Affiliate-Links

 

Ähnliche Artikel:

Schreibe einen Kommentar

Deine Email-Adresse wird nicht veröffentlicht.

2 × 2 =