Kleine Korrektur für 64bit Systeme

Im großen und ganzen scheint die jetzt seit fast 3 Wochen verfügbare 64bit Version der Baustatik nur sehr wenig Ärger zu machen – eigentlich gab es bisher nur kleinere Ärgerlichkeiten, die wir korrigiert haben.

Heute bin ich auch noch so einen Fall aufmerksam geworden – in diesem Fall nicht wirklich eine Kleinigkeit, aber wohl ein Fall, der nur sehr wenige Kunden betrifft.

Damit das Problem eintritt, müssen drei Voraussetzungen erfüllt sein. Zum einen muss der eingesetzte Rechner ein 64bit Windows Rechner sein. (Nur dann wird auch mit der 64bit Version der Baustatik gearbeitet, und nur in dieser Version tritt das Problem auf.). Zweitens muss die Software per Work&Cash verwendet werden. Bei allen anderen Lizenz-Arten tritt das Problem ebenfalls nicht auf. Und schließlich darf der verwendete Timeserver kein lokal installierter sein – er muss sich statt dessen auf einem anderem Rechner im Netzwerk befinden.

In diesem Fall kann man zwar die alten Programme “einfach so” verwenden, bei der Verwendung der Baustatik erhält man aber eine Fehlermeldung, das der Timeserver “keine Zeiteinheiten” mehr übrig hat.

Wer dieses Problem mit der Baustatik hat, der kann hier (Download 2022 entfernt) eine Zwischenversion herunterladen, bei der dieses Problem behoben ist. (Zum Installieren der Zwischenversion muss zunächst die vorhandene Version manuell über die Systemsteuerung deinstalliert werden. Danach kann die Zwischenversion installiert werden.)

Wieso tritt das auf, und warum haben wir (ich) das beim Testen nicht gefunden?

Um das zu verstehen, muss man einige Dinge über die beteiligten Komponenten wissen. Die “alten” Programme laufen immer als 32bit Programme, während die Baustatik auf 32bit Windows als 32bit Programm und unter 64bit Windows als 64bit Programm läuft. (Das ist seit dem letzten Update so: Davor war die Baustatik auch immer ein 32bit Prozess.)

Der Timeserver selbst ist grundsätzlich ein 32bit Programm. (Man hätte auch keine Vorteile davon, wenn er unter 64bit Windows ein 64bit Programm wäre – der Speicherbedarf des Timeservers ist minimal.)

Die Client-seitige Konfiguration des Timeservers – also der Teil, der sich damit beschäftigt wie die Programme mit dem Timeserver kommunizieren – erfolgt also auch als 32bit Prozess. Die Konfigurationsdaten werden dabei in der Registry hinterlegt.

Nun ist es so, das 64bit Programme und 32bit Programme für einige Einstellungen in der Registry unterschiedliche Äste verwenden. (Der Grund dafür ist die Rückwärtskompatibilität für 32bit.). Das gilt auch für den TimeServer – der schreibt seine Konfigurationsdaten immer in den 32bit-Teil der Registry. Darum können die alten Programme diese Konfiguration auch lesen und funktionierten klaglos. Die 64bit Variante der Baustatik versuchte aber die Konfigurationsdaten aus dem 64bit Teil der Registry zu lesen: Nur, das da eben nichts stand.

Wenn diese Konfigurationsdaten nicht gefunden werden, dann versucht die Software grundsätzlich eine lokale Verbindung herzustellen – ganz egal, was man “eigentlich” eingestellt hat. Das tut natürlich weiter nicht weh, wenn man ohnehin eine lokale Verbindung wünscht.

Will man aber eine “entfernte” zu einem anderen Host, dann kamen diese Einstellungen bei der Software gar nicht erst an – und sie stellte eine lokale her. Die lokale Verbindung ging aber, denn einen lokalen TimeServer gibt es ja immer. Nur war – im Fall der betroffenen Kunden – dort keine Zeit eingetragen. Warum auch: Die sollte ja zentral verwaltet werden. Das Resultat war dann die eingangs genannte Fehlermeldung.

Beim testen habe ich das aus einem einfachen Grund nicht gemerkt: Ich habe mir die Sache zu einfach gemacht. Statt tatsächlich einen anderen Rechner als Remotehost zu verwenden, habe ich auf meiner lokalen Workstation den Timeserver so konfiguriert, das er auch per Netzwerk kommunizieren kann. In der Client-Konfiguration haben ich dann auch “Netzwerk” eingestellt – und die Sache funktionierte. Nur eben nicht per Netzwerk, sondern lokal – weil das der Rückfallmechanismus ist, der dann eintritt, wenn die Konfigurationsdaten nicht gefunden werden. Sah aber “richtig” aus. Sorry

Ab dem nächsten Update funktioniert das auch in der genannten Kombination richtig, bis dahin kann man die oben verlinkte Zwischenversion verwenden, in der das auch korrigiert ist.