Thomas Wölfers Baustatik-Blog

Thomas Wölfers Baustatik Blog

Channel 9 hat ein Demo von WinFS


Wer sich unter dem neuen Filesystem nichts so recht vorstellen kann, der sollte sich das Video ansehen. Der Film dauert etwa eine Stunde und im Laufe dieser Zeit gibt es eine ganze Reihe an Demos, die die Möglichkeiten von WinFS aufzeigen. Klick: WinFS-Demo


Kostenlose Software für Schubbemessung


Auf unserer Mailing-Liste war Anfang des Jahres ein paarmal nach so etwas gefragt worden: Ein kleines, übersichtliches Programm, das bei der Schubbemessung im Fall der neuen DIN 1045-01 hilft. Das gibt es nun bald. Das beste daran: Das Programm ist für alle Kunden die einen Supportvertrag oder einen Work&Cash Vertrag haben kostenlos. Für Work&Cash Nutzer bedeutet das: Läuft das Programm, wird trotzdem keine Zeit berechnet. Bei den kostenlosen Studentenversionen ist das Programm natürlich auch dabei. Mehr zur Schubbemessungs-Software steht bei meinem Bruder.

Verfügbar wird das ganze vermutlich am Dienstag.


.Net: Übersetzen für 64 Bit mit Visual Studio


Wenn man ein Managed-Code Projekt hat das auf einer 32bit Windows-Platform läuft, und man möchte das nach 64bit Windows portieren, dann ist die Sache verhältnismässig einfach: Man muss nämlich gar nichts tun.

Von Haus aus generiert Visual Studio ohnehin keinen nativen Code, der wird erst beim laden der Assemblies, also zur Laufzeit des Programms erzeugt. Das geht völlig transparent, ohne das man gesonders tätig werden muss. Hat man also eine .Net Anwendung die unter 32bit Windows läuft, muss man das Ding einfach nur auf den 64bit Windows Rechner kopieren. Startet man die Kopie, hat man automatisch eine 64bit Anwendung.

Zumindest in der Theorie, denn in der Praxis muss man dann doch noch tätig werden. Und zwar dann, wenn man auch Unmanaged Code verwendet. Von den 'unmanaged' Libraries braucht man nämlich 'echte' 64bit Varianten - und das gilt sowohl für eigenen Code, als auch für Libraries von anderen. Dazu zählt auch sowas wie DirectX etc. pp..

Hat man nun den Fall, das man eine Library (noch) nicht in einer 64bit Variante vorliegen hat, und übersetzt man seine Solution auf einem 64bit System, dann gibt es Probleme: Beim Debuggen wird das Programm gestartet und der 64bit Code erzeugt - doch der ruft dann irgendwann Code auf der nur in einer 32bit Variante vorliegt - und es gibt eine Exception.

Es bleibt einem also nichts anderes übrig als sich darum zu kümmern, das eben kein 64bit sondern 32bit Code generiert wird. Der offensichtliche Weg ist dabei der, in den Projekten der Solution die Build-Option von 'AnyCPU' auf 'x86' umzustellen. Das ist allerdings sehr ärgerlich, vor allem wenn man viele Projekte hat und später einmal eine 64bit Version bauen will.

Es geht aber auch anders: Man braucht nämlich nur das Projekt, das das 'Startprogramm' erzeugt umzustellen: Wenn der ladende Prozess ein 32bit Prozess ist, dann wird auch 32bit Code generiert wenn man sich auf einer 64bit Platform befindet. 


Wieso das Update dieses mal so lange gedauert hat


Vor etwa einer Woche hatte uns zunächst ein Anwender auf einen Fehler in der Bemessung von XPLA hingewiesen. Sowas ist natürlich ärgerlich, aber nicht zu verhindern: Wie jedes Produkt hat auch ein Softwareprodukt Fehler, und die hohe Geschwindigkeit mit der Neuerungen und ganz allgemein neue Versionen zur Verfügung gestellt werden – kombiniert mit der Komplexität der Produkte – führt einfach dazu, das Fehler eben hin- und wieder vorkommen, ohne das wir diese vor der Veröffentlichung bemerken. Wie gesagt: Ärgerlich – und wir versuchen für die kommende Softwaregeneration Mechanismen einzurichten, um das zumindest zu minimieren.

 

Das hilft natürlich heute nicht weiter, ist aber im Normalfall auch kein wirklich großes Problem: Tritt ein Fehlerfall ein, stellen wir eigentlich fast immer innerhalb kürzester Zeit ein Update über unsere Download-Site zur Verfügung. Das kann man einen Tag oder zwei, manchmal auch ein Wochenende dauern – aber eigentlich nicht wesentlich länger.

 

Was im Fehlerfall passiert ist stark vom Fehler abhängig, denn meist handelt es sich ja um eher kosmetische Probleme: Ein Programm stürzt in irgend einem obskuren Kontext ab, oder aber ein Button tut vielleicht nicht das, was er soll.

 

Manchmal gibt’s größere Probleme, und so war es auch beim angesprochenem Problem. Sobald wir das erkennen, sperren wir als erstes den Download-Bereich unserer Website. Das soll verhindern, das weitere Kopien der Software die den Fehler enthalten verteilt bzw. heruntergeladen werden. Wenn der Fehler behoben ist stellen wie eine neue Version des Programms zum Download zur Verfügung, öffnen den Download-Bereich, und versenden einen eMail an alle Teilnehmer der entsprechenden Mailing-Liste. Damit bekommt jedermann sofort Bescheid das es ein Problem gab, und das es dafür auch eine Lösung gibt.

 

Diesmal war das anders: Wir haben zwar die Download-Seite gesperrt, das Update hat aber über eine Woche auf sich warten lassen. Für die vom Fehler betroffenen war das schon ganz schön ärgerlich. Für uns war es das aber auch, denn eigentlich war der Fehler kurz nachdem er uns bekannt gemacht worden war auch schon behoben. Dummerweise konnten wir aber das Update nicht verfügbar machen. Was war geschehen?

 

Um das zu erklären, muss ich ein bisschen ausholen. Die öffentliche IT-Infrastruktur von D.I.E. befindet sich im großen und ganzen im Münchner Büro. Dort steht ein Server-Rack mit den zugehörigen Rechnern: Webserver, Mailserver, der Rechner für die Work&Cash Konten, etc. etc.

 

Nachdem die Updates von dort verteilt werden, werden auch die Setups in München produziert. Das passiert auf einer virtuellen Maschine, die aus Sicherheitsgründen weitestgehend vom normalen Netzwerk abgekoppelt ist. Im Klartext: Diese virtuelle Maschine befindet sich auf einer separaten, externen USB-Festplatte ohne jegliche Verbindung zur Außenwelt.

 

Ist das Setup in dieser virtuellen Maschine produziert, wird die zugehörige Datei auf den Webserver transportiert von wo aus Sie das Ding abholen können.

 

Momentan gibts nur eine Person die Zugriff auf die beiden beteiligten Systeme hat – und das bin ich.

 

Dieser Zugriff ist obendrein auf  physische Anwesenheit beschränkt: Ich muss mich also tatsächlich direkt vor der Maschine befinden, mich an der zugehörigen Tastatur mit dem passenden Sicherheitskontext anmelden – und nur dann kann ich das Setup zum einen produzieren, und zum anderen auf den Download-Server transportieren.

 

Das Problem: Die USB-Platte und der Webserver befanden sich in München – ich war hingegen in unserer Oberhausener Hauptstellen.

 

Dumme Sache - und der Grund dafür, warum es das Update erst heute gegeben hat.

 

Was tun wir nun dagegen, das so was nicht wieder vorkommt?

 

Momentan ist das noch nicht in jedem Detail klar – denn letztlich wollen wir auch in Zukunft die Sicherheit unserer Downloads nicht gefährden. Trotzdem werden wir auf jeden Fall in paar neue Wege beschreiten, um in Zukunft besser auf derartige Probleme reagieren zu können.

 

Zum einen werden wird eine Möglichkeit schaffen, sowohl die virtuelle Maschine als auch den Webserver selbst anders erreichbar zu machen. Das wird vermutlich darauf hinauslaufen, das der Server mit passenden Maßnahmen über eine VPN erreichbar sein wird, und das das erzeugen von Setups mit einer virtuellen Maschine auf diesem Webserver oder einem zugeordneten Rechner möglich wird.

 

Es ist noch nicht ganz klar, wie lange das dauern wird – letztlich läuft der Umbau dieser Infrastruktur eher neben der normalen Arbeit – aber das sollte nicht länger als ein paar Wochen dauern: Sobald es da Fortschritt gibt, werde ich im Blog aber natürlich darüber berichten.

 

 

 

 


Updates: Xpla und andere


Ab sofort ist der Download-Bereich für die Statiksoftware auf www.die.de wieder verfügbar und es gibt auch neue Updates. Hauptsächlich geht es dabei um das Programm XPLA für die FEM Plattenberechnung. Alle Details finden sich wie immer im Update-Log des Download-Bereiches und im Blog meines Bruders.


Berechnungsergebnisse: Viele Bitmaps in der TreeView


Ich hatte vor ein paar Tagen ein kleines Klassendiagramm gezeigt, das eine Untermenge der vom Faltwerksprogramm berechneten Ergebnisse darstellt. Wenn man die verwendeten Normen (wir unterstützen momentan 13 oder 14) mal auf die DIN 1045-1 und die 18800-90 einschränkt, und dann nur Berechnungen nach Theorie 1. Ordnung betrachtet, und obendrein nur die Ergebnisse für Balken und Knoten (nicht aber für räumliche Tragwerkselemente, eingebettete Unterzüge, etc.etc.) betrachtet, dann sind das immer noch knapp 700 unterschiedliche Ergebnistypen.

Klingt erschreckend, sieht aber dann im Programm ganz harmlos aus:

results.png

Für den Programmierer gibts dann aber eine ärgerliche Sache: Diese 700 Ergebnisse haben (fast) alle ein eigenes Icon in der Baumansicht - und das erzeugt ein Problem.

Ab hier wirds wohl nur noch Programmierer interessieren...

Das Problem: Die Bitmaps liegen alle einzeln vor, da sie auch an anderen Stellen im Programm verwendet werden. Die Dinger werden also mit treeView.ImageList.Add( img, Color.Teal) zur ImageList hinzugefügt. Die liefert dann einen Index, und der wird als ImageIndex für die TreeNodes verwendet.

Dummerweise ist das bei 700 Bitmaps relativ lahm: Auf meinem Rechner dauert das fast 5 Sekunden - und in der Zeit gibts keinerlei optisches Feedback. Noch ärgerlicher: Die komplette Berechnung die vorher stattgefunden hat dauert deutlich weniger lange... Der Anwender wartet also nicht auf die eigentlichen Daten, sondern nur auf die schöne Optik.

Es gibt aber eine einfache Möglichkeit den Aufbau der TreeView ganz erheblich zu beschleunigen, wenn man viele Bitmaps in der ImageList benötigt: Dazu muss man zunächst ein Array aus Bitmaps in der benötigten Größe für alle Bitmaps erzeugen, und dieses Bitmap stellt man dann mit AddRange() in die ImageList. Natürlich braucht es dann eine manuelle Verwaltung der Indizes - aber das lohnt sicht, denn der zeitliche Aufwand geht von 5 Sekunden fast auf 0 zurück.