Thomas Woelfers Baustatik Blog

Baustatik-Software und was sonst des Weges kommt

Ärgerlicher Fehler im Setup von Baustatik

Folgendes ist passiert: Seit Version 1.17 trägt das Installationsprogramm der Baustatik in der Windows-Registry einen Pfad ein. Dabei handelt es sich um den Pfad, unter dem die Software im System installiert wurde. Der Grund dafür ist der, das separate Lizenz-Installer die Installation finden können und die Lizenz-Datei an die richtige Stelle kopieren können.

Dieser Pfad wird im gleichen Ast der Registry gespeichert, in dem auch die älteren Programme diese Information ablegen. Blöderweise wird dieser Ast beim deinstallieren der Software ebenfalls vom Rechner entfernt. Dummerweise wird dabei gleich der ganze Ast mit entfernt und nicht nur der eine Eintrag. Das hat nur eine dumme Nebenwirkung: Die "alten" Programm laufen danach nicht mehr, bzw. können nicht mehr gestartet werden.

Auch das wäre noch weiter kein Beinbruch - es passiert ja nicht so besonders oft, das die Baustatik deinstalliert wird. Sollte man meinen - nur ist das leider nicht so: Jedesmal wenn ein Update der Baustatik installiert wird, entfernt das Installationsprogramm zunächst die bereits installierte Version.

Mit anderen Worten: Durch das installieren eines Updates für die Baustatik können die "alten" Programme nicht mehr gestartet werden. Sorry - Mea Culpa.

Glücklicherweise ist zumindest die Lösung des Problems einfach: Es reicht aus, einmal von der Installations-CD die "Programme" zu installieren: Das trägt die Pfade wieder ein, und die Programme laufen dann auch wieder.

Das Problem ist leider erst heute ans Licht gekommen: Diesen Registry-Eintrag gibt es erst seit Version 1.17, und damit trat das Problem dann beim installieren aufs Update mit der Version 1.18 zum ersten Mal auf. Jeder, der von 1.17 auf 1.18 wechselt muss also danach außerdem einmal das Setup-Programm für die "alten" Programme laufen lassen.

Außerdem ist der Fehler natürlich auch in allen 1.18 Setups drin, die gestern oder heute Vormittag runtergeladen wurden. (Die zur Zeit auf dem Server liegende Version hat das Problem nicht mehr.). Wehr also gestern oder heute eine 1.18er Version runtergeladen hat, der bekommt das gleiche Problem dann beim installieren des nächsten Updates....

Kann mich nur entschuldigen....

Neue Updates verfügbar

Ab sofort gibt es ein Update für die Baustatik. Details zum Update finden sich wie immer im Update-Protokoll, die wichtigsten Neuerungen sind aber:

Liniengelenke
Ab dieser Version können Liniengelenke als Verbindung zwischen zwei Faltwerkselementen definiert werden. Liniengelenke können definiert werden, wenn ein Faltwerkselement keine Biegemonente an einer Kante aufnehmen oder weitergeben soll. Ein wenig Hintergrund dazu gibt es hier: Wirkungsweise von Liniengelenken in Baustatik.

Dokumentation
Abgesehen davon, das die Dokumentation noch ein wenig an Umfang zugenommen hat, kann man sie nun (auch teilweise) ausdrucken. Dazu klappt man den Teil der Dokumentation auf, den man ausdrucken will, und markiert ihn dann mit den Optionsmarken im Inhaltsverzeichnis. (Das gilt für die Dokumentation, die als Online-Hilfe im Programm eingebaut ist - nicht für die, die im Internet zur Verfügung steht.) Danach drückt man entweder auf den "Vorschau" oder auf den "Drucken" Schaltknopf in der Werkzeugleiste der Hilfe. Ich rate davon ab, die Hilfe komplett auszudrucken: Vollständig ausgedruckt umfasst das Ding dann etwa 1400 Seiten.

Neu in der Dokumentation ist nun auch ein kleines Tutorial, das den Einstieg ins Programm etwas vereinfachen soll.

Export des Ausdrucks
Wie bisher kann der Ausdruck nach Word, Excel und in HTML exportiert werden. Zusätzlich gibt es nun auch die Möglichkeit, den Ausdruck in den Statikeditor BauText zu exportieren. (Diese Funktion ist zur Zeit noch ein wenig rudimentär und wird wohl im Zuge der Zeit noch ein bisschen "aufgepeppt" werden.)

Import aus AutoCAD
Der Befehl "Importieren" im Datei-Menü tut nun tatsächlich etwas sinnvolles: Man kann AutoCAD DWG-Dateien importieren. Die importierten Daten werden in der Graphik als Hilfslinien und -punkte angezeigt. Auf die Punkte kann gerastet werden. Im "Bearbeiten" Menü gibt es einen Befehl, mit dem die importierten Daten entfernt werden können. Anders als bei den "älteren" Programm bleiben die Daten im Dokument erhalten, bis sie gelöscht werden. D.h., die Daten werden auch mit abgespeichert und liegen dann beim nächsten Programmstart direkt wieder vor.

Ärgerlicher Fehler in Navigationspunkten

Die Navigationspunkte in der Baustatik sind der primäre Mechanismus um Graphiken auszudrucken. Im Navigationspunkt wird unter anderem auch abgelegt, welches Ergebnis angezeigt wurde, und wie die einzelnen Objekte anzuzeigen sind. Stellt man zum Beispiel eine "andere" Farbe für Stäbe ein, legt dann einen Navigationspunkt an, setzt die Farbe zurück und macht einen Ausdruck vom Navigationspunkt (indem man ihn in der Ausgabesteuerung für den Ausdruck aktiviert) - dann wird der Stab in der Farbe gedruckt die er hatte, als der Navigationspunkt angelegt wurde.

Das gleiche gilt auch für Beschriftungen: So kann man zum Beispiel Navigationspunkte mit Stabbeschriftungen und solche ohne Stabbeschriftungen anlegen.

Zumindest in der Theorie. In der Praxis war das leider anders: Die Sache mit den gemerkten Einstellungen klappte zwar für Knoten, Faltwerkselemente und eigentlich auch alle anderen Objekte - nur nicht für Stäbe. :-(

Ab dem nächsten Update ist das aber korrigiert.

Wie man in Vista nach mehreren Dateierweiterungen gleichzeitig sucht

Wenn man in Vista nach einem bestimmten Dateityp suchen will - zum Beispiel nach allen Dateien vom Typ ".doc", dann kann man im Suchfeld einfach *.doc eingeben. Was aber, wenn man sowohl nach .doc als auch nach .xls Dateien suchen möchte.

Eingentlich ist das einfach - die Suche kennt nämlich Logische Operatoren, und einer davon ist OR. Man gibt also im Suchfeld "*.doc OR *.xls" ein - und bekommt dann eine Liste aller Word- und Excel-Dateien.

Alle Elemente ausdrucken

In der Ausgabesteuerung bei Faltwerks-Dokumenten von Baustatik kann man den numerischen Ausdruck auf bestimmte Elemente beschränken. Dazu klickt man zunächst im Baum der Inhalte auf den Ast, den man einschränken will (z.B.: Ergebnisse: linear -> Einzellager). Daraufhin erscheinen die zu diesem Ast eingestellten Eigenschaften im unteren Bereich des Dialoges. Ein Teil dieser Eigenschaften ist immer in der Kategorie "Einschränkungen" zusammengefasst. Dort befindet sich immer die Optione "Alle Elemente ausdrucken". Von Haus aus steht diese Option auf "Ja" - es werden also (z.B.) alle Einzellager mit ausgedruckt.

Stellt man die Option auf "Nein", dann kann man unter "Ausgewählte Elemente" eine Liste derjenigen Elemente angeben, die man ausdrucken möchte. Zur Zeit muss man dabei die Namen der Elemente durch ein Semikolon (;) voneinander trennen, wobei vor und hinter dem Semikolon ein Leerzeichen zulässig ist. Es geht also zum Beispiel "4;5" oder auch "4; 5" oder auch "4 ; 5" etc.

Ein Leerzeichen als Trenner für die Elemente ist nicht möglich - und dafür gibt es einen Grund: Die Objekte selbst können ja Leerzeichen im Namen enthalten. So muss ein Stab ja nicht unbedingt "S1" benannt sein, er kann auch "Binder links" heißen. Darum: Keine Leerzeichen als Trennsymbole.

Ab der nächsten Version kann man aber zusätzlich zum Semikolon auch ein Komma verwenden.

Die unntigen Zeilenumbrüche wurden entfernt

Mir ist völlig schleierhaft warum es das tut, und wiese Outlook glaubt, es sei eine gute Idee: Auf jeden Fall stellt Outlook 2007 bei Textmails einen kleinen blauen Balken oberhalb der Mail dar. Darin steht der Text: "Die unnötigen Zeilenumbrüche wurden entfernt."

Nahezu immer handelt es sich bei diesen "unnötigen" Zeilenumbrüche um solche, die der Versender der Mail mit voller Absicht im Text untergebracht hat, um einen der wenigen in Textmails möglichen Formatierungseffekte zu erzielen. Genau: Einen Zielenumbruch. Und es ist dann auch nicht besonders überraschend, das eMails, bei denen die "unnötigen" Zeilenumbrüche entfernt wurden, nicht besonders gut lesbar sind.

Man kann dann zwar auf den blauen Balken klicken und Outlook bietet dann auch an, die Zeilenumbrüche wieder einzufügen - aber lästig ist das schon. Man kann diese Funktion aber auch ganz abschalten, und zwar unter Extras -> Optionen -> Einstellungen -> E-Mail-Optionen -> Zusätzliche Zeilenumbrüche in nur-Text-Nachrichten entfernen.

Automatische Builds mit Visual Studio und Source Safe

Warum überhaupt automatische Builds? Kurze Antwort: Weil man sonst nicht weiss, ob man sein Projekt überhaupt bauen kann. Der Grund dafür ist der, das das Visual Studio einige "magische" Dinge tut die dazu führen können, das man ein Projekt bauen kann, obwohl - wenn alles "ordnungsgemäß" ablaufen würde - der Build fehlschlagen müsste.

Ich habe dafür ein paar Beispiel, die in unserer aktuelle Solution tatsächlich aufgetreten sind. Die Solution umfasst zur Zeit 65 Projekte. 2 davon sind Setup-Projekte, die anderen sind C# sowie Native und Manged C++ Projekte. Ein Projekt enthält überhaupt keine Code, sondern ausschliesslich Dokumentation in Form von HTML, CSS, JavaScript und Bitmaps.

Problemfälle die aufgetreten sind:

  • Ein (C#) Projekt konnte (innerhalb von VS) gebaut werden, obwohl es einen Typ benutzte der aus einer Assembly stammte, die nicht referenziert wurde. (Der Build auf der Kommandozeile schlug fehl.)
  • Ein (Managed C++) Projekt konnte gebaut werden, obwohl im Code ein Typ aus einer nicht referenzierten Assembly verwendet wurde. (Der Build auf der Kommandozeile schlug fehl.)
  • Einige C++ Projekte konntn gebaut werden, obwohl die Projekt-Abhängigkeiten (und damit die Build-Reihenfolge) nicht korrekt war.

Der eigentliche Grund warum wir regelmäßige "nächtliche" Builds auf einem Buildserver durchführen wollten war aber ein anderer: Wir haben einen mitlerweile recht großen Satz an Testcases, bei denen es aufgrund des Umfangs langsam aber sicher unhandlich wird, sie interaktiv durchlaufen zu lassen. Statt dessen werden dieses Testläufe nun einfach automatisch nachts durchgeführt - schlägt ein Test fehl, werden die Entwickler per eMail informiert. Praktische Sache.

Nun sollte man annehmen, das automatische Builds eine einfach Sache sein sollten - schließlich ist das Projektsystem seit Visual Studio 2005 ja auf MSBuild aufgebaut: Zumindest hiess es das immer. In der Theorie sollte es also reichen

MSBuild NameDerSolution

einzugeben, und MSBuild sollte dann genau das gleiche Produzieren, was auch innerhalb der IDE stattfindet. Nun - das ist leider nicht so, wie ich feststellen musste. Doch eins nach dem anderen: Das erste Problem war nämlich, das vor jedem Build zunächst einmal ein aktueller Satz an Quellcode-Dateien aus dem Revision Control System besorgt werden muss. Wir verwenden als RCS Visual Source Safe (*1), und also machte ich mich auf die Suche in der zugehörigen Dokumentation.

Die ist, um es höflich zu sagen, etwas mager. Um per Kommandozeile ein Get-Latest-Version zu machen, muss man folgendes tun:

  • Die Environment-Variable "ssuser" auf einen gültigen Source Safe Usernamen setzen.
  • Die Environment-Variable "sspwd" auf das zugehörige Passwort setzen.
  • Die Environment-Variable "SSDIR" auf das Source-Safe Verzeichnis der Solution setzen.
  • Per "cd" in das Verzeichnis wechseln, in das Source Safe die lokale Kopie des Codes platzieren soll. (Es gibt eine Option mit der man dieses Verzeichnis angeben kann, die habe ich aber nicht ans laufen gebracht.)
  • Dann per "ss" Kommando die neueste Version holen: ss get $/PfadZurSolutionInderSSDatenbank -R
  • Dann bekommt man das Problem, das Source Safe als erstes einen Prompt ausgibt und fragt, ob das aktelle Verzeichnis das permanente Default-Verzeichnis für die Solution werden soll. Mit dieser Frage hatte ich zwei Probleme: 1) Ich verstehe sie nicht und 2) Für ein automatisches Build ist sie hinderlich. Nun gibt es eine Option "-Y", mit der man angeblich alle interaktiven Prompts abschalten kann - aber leider weiss ich nicht, ob die Antwort auf die Frage dann "Ja" oder "Nein" lautet - und außerdem habe ich die Option ausprobiert: Die Frage wurde aber trotzdem nicht unterdrückt. Daher Rückgriff auf MS-DOS Zeiten:
  • Anlegen einer Datei "N.dat", die ausschließlich den Buchstaben N enthält und abändern des SS-Aufrufs auf:
  • ss $/PfadZumProjekt -R <n.dat

Damit hat man zumindest schon mal den aktuellen Quellcode. Nun gehts ans bauen. Nichts einfacher als das, dachte ich:

msbuild NameDerSolution.sln /t:Rebuild /p:Configuration=Release

In der Theorie ist das auch richtig - aber in der Praxis ging das bei mir nicht.

  • msbuild kann keine Setup-Projekte bauen
  • msbuild kann auch keine C++ Projekte bauen, und delegiert die Arbeit dazu an ein anderes Tool. Das übersetzt dann in der Theorie auch richtig - nur leider klappte das auch nicht.

Unabhängig von den fehlenden Setup-Projekten (damit könnte ich leben), habe ich zwei Probleme gefunden:

1) Wenn man in einem Managed C++ Projekt eine Referenz auf ein anderes Projekt mit Managed Code hat, dann wird das von MSBuild völlig ignoriert. Die Referenz müsste eigentlich in die Compiler-Option "/FU PfadZurAssemblyDerReferenz" umgesetzt werden. Das passiert aber nicht. Resultat: Der Compiler kennt die aus der referenz stammenden Typen (und Namespaces) nicht, und der Build schlägt fehl. Das kann man allerdings umgehen, indem man nicht das Projekt referenziert, sondern die Assembly per "#using <Pfad zur Assembly>" einbettet: Nicht schön, funktioniert aber.

2) Ich hatte einen Fall (den ich auch immer wieder reproduzieren kann, aber leider nur mit genau diesem Projekt), bei dem im Build auf der Kommandozeile eines C# Projektes eine gesetzte Referenz ebenfalls einfach ignoriert wurde. Warum das in diesem Fall passierte konnte ich nicht herausfinden, und einen Workaround dafür habe ich auch nicht. (In allen anderen Fällen funktionierte das ja auch, nur in einem einzelnen Fall eben nicht. Das ist aber genauso gut, als wenn es nie gehen würde: Der Build schlägt fehl.)

Also kam MSBuild leider nicht in Frage. Netterweise gibt es aber eine Alternative: Visual Studio hat auch einen Kommandozeilen-Modus, mit dem man Builds durchführen kann. Der Aufruf dazu geht wie folgt:

devenv PfadZumSolutionFile.sln /Rebuild "Debug" /out PfadZuEinemLogFile.log

Ruft man das aber so auf, dann passiert folgendes: C++ Build schlagen fehl. Grund: Include- und Lib-Dateien werden nicht gefunden. In der Theorie ist es so, das man über die VC++ Projektoptionen in der IDE die richtigen Pfade für Header und Libraries einstellt, und das die Kommandozeilen-Variante dann diese Einstellungen verwendet. Für Header hat das bei mir auch geklappt, für Libraries aber nicht.

Workaround: Vor dem Aufruf von "devenv" die Environment-Variablen "INCLUDE" und "LIB" mit den Pfaden zun den Headern und Libraries setzen, und "devenv" dann mit der zusätzlichen Option "/UseEnv" aufrufen.

--

(*1) Mir ist bewusst das Source Safe keinen besonders guten Ruf geniesst, und ich bin auch mit einigen Dingen darin eher unzufrieden. Unabhängig davon kann ich aber die Meldungen über "verlorerne" Daten, die immer wieder gern angebracht werden, absolut nicht bestätigen.

Wieso es Leute gibt, die Botnets betreiben

Ich hatte gestern eine interessante Diskussion zum Thema Botnets. Ein "Botnet" ist ein Netzwerk von Computern, bei denen die Computer zum Netz gehören, ohne das die Eigentümer etwas davon wissen: Der Computer wird irgendwie infiziert (falsche Mail angeklickt, falsches Programm gestartet... da gibt es viele Möglichkeiten) und befindet sich nach der Infektion eigentlich unter der Controlle des Botnets bzw. dessen Betreibers - und nicht mehr unter der seines Eigentümers.

Wenn der Botnet-Betreiber die Ressource der Zombies (so nennt man die Rechner unter fremder Kontrolle) nun nicht besonders aggressiv ausnutzt, wird der eigentliche Eigentümer nie bemerken, das sein Rechner von Fremden benutzt wird.

Das "Storm" Botnet allein wird auf eine Größe zwischen einer und fünfzig Millionen PCs geschätzt - und Storm ist nicht das einzige Botnet. Die interessante Frage ist aber natürlich  - wie verdienen die Betreiber damit eigentlich Geld, denn darum gehts ihnen ja schließlich.

Offensichtlich kann man Botnets für DDoS Attacken und zum Spam-versenden benutzen, allerdings ist es ja nun so, das bei einer Erpressung per DDoS das gleiche Problem gilt wie bei alle Erpressungen: Die Geldübergabe ist halt schwierig.

Ich glaube das einen zentrale Einkommensquelle für solche Leute was ganz anderes, viel unauffälligers ist. Und zwar ein vorgehen, bei dem der größte Beteiligte [in diesem Fall Google, die Sache betrifft aber auch jeden anderen, der Pay-Per-Click Werbung verteilt] (abgesehen von den Bösen) Geld verdient (und damit kein wirklich großes Interesse hat was dagegen zu unternehmen) und die Geschädigten gar nicht mitbekommen, das Sie geschädigt werden. Obendrein wird der Betrug auch noch durch völlig unbeteiligte durchgeführt und sieht ohne näheres Hinsehen auch gar nicht wie Betrug aus.

Und so geht das ganze: Der Botnet-Betreiber installiert auf seinen Zombies einen kleinen Web-Proxy. Jede Anfrage vom Browser muss durch diesen Proxy, wird davon aber nicht weiter belastet: Der unschuldige Surfer bemerkt nichts. Klickt der Surfer aber auf eine Google AdSense Werbung, dann fängt der Proxy den Request auf, und änder die Publisher-ID, die sich darin befindet: Statt der Id des Webseitenbetreibers trägt er einfach seine eigene ein, und lässt dem Request ansonsten freien Lauf.

Bei Google geht der Request dann ein: Da freut sich Google, weil die dafür schließlich Geld bekommen. Den Anteil den der Webseitenbetreiber bekommen würde bekommt aber der Botnet-Betreiber - ganz legal gutgeschrieben von Google. Der Seitenbetreiber ist also der Dumme - merkt das aber nicht: Er sieht vielleicht eine etwas schlechtere "Klickrate" - nur kann das viele Gründe haben.

Wie gesagt: Um die Sache zu verdeutlichen haben ich Google genannt - klappen tut das aber mit praktisch jeder Pay-Per-Klick Werbung im Internet. (Google hat mit dieser Werbeform in 2006 etwa 10 Milliarden Dollar Umsatz gemacht.)

Mal angenommen "Storm" hätte nur 10 Millionen Rechner, und vor jedem sitzt ein Surfer, der nur einmal pro Tag auf eine Werbebotschaft klickt. Das wären dann 10 Mio Klicks am Tag. Ein Klick auf eine AdSense Werbung bringt (je nach beworbenem Wort) zwischen 5 Cent und 50 Euro. Mal angenommen, es sind nur 10 Cent - dann verdienen die Betreiber von Storm immer noch locker 1 Mio Euro pro Tag. Jeden Tag. Ohne das dies jemand bemerkt, und ohne das Google besonders großes Interesse daran hätte, irgendwas dagegen zu unternehmen.

Visual Studio 2008 ab sofort verfügbar

Mit einem MSDN Abo kann man das ganze seit gestern Abend runterladen. Es gibt eine ganze Menge Neuerungen und Veränderungen - das hier sind die meiner Ansicht nach wichtigsten:

  • VS 2008 kann parallel zu VS 2005 installiert werden
  • Visual Studio Tools for Office ist nun integriert
  • Unit Testing jetzt auch in der "Professional" Edition (Danke !)
  • Quellcode zum .NET Framework (dazu gibts Source Server, die aber gerade erst angeworfen werden: Wie man tatsächlich in den Quellcode zum .NET Framework stept soll nächste Woche veröffentlicht werden.)
  • LINQ, Anonymous Types, Lambda Expressions, Extension Methods, Automatic Properties (in C# und VB)
  • Der HTML/CSS Designer ist nun der gleiche wie in Expression Web.
  • AJAX fest integriert
  • Javascript deutlich besser integriert: Mit Intellisense und Debugger-Support

Das Download der Pro-Edition hat etwa 3.3 GB, das Download für die MSDN Library etwa 2 GB. Wer außerdem noch SourceSafe Support will, der braucht das Update CTP von Source Safe und sollte außerdem diesen KB Artikel lesen, denn es braucht einen manuellen Installationsschritt, der im KB Artikel erklärt wird. (Die fertige Version vom neuen Source Safe wird dieses Problem nicht haben.)

Achja: Die kostenlosen Express Versionen gibts auch wieder. VS Express Developer Center

Fußgängerbereich mit Google ausloten

Joel zeigt auf den WalkScore. Dabei handelt es sich um einen Webdienst, mit dem man überprüfen kann, welche Dinge leicht von einer bestimmten Adresse aus zu bewerkstelligen sind. Eigentlich eine ganz nette Idee für jeden, der gerade eine neue Wohnung sucht. Die Daten dafür stammen von Google - und sind leider nicht sehr verlässlich. Um nicht zu sagen: Entweder die grundlegenden Daten, oder aber die Auswertung davon ist völliger Schwachsinn.

Nur als Beispiel mal mit der Anschrift von unserem Münchner Büro - mitten in der Maxvorstadt in München: Es gibt praktisch nichts, was man hier per Pedes nicht machen kann. Das Resultat von WalkScore sieht aber anders aus - und das auch noch auf Basis falscher Daten: Massmannstr, Munich, Bavaria

  • Das Hotel Flora ist kein Grocery Store, ebensowenig wie die anderen Hotels (Es gibt aber sehr wohl einige in der Nähe)
  • Die Restaurants (außer 'Hans Schneider') gibt es tatsächlich, auch wenn einige davon nicht mehr existieren. Es fehlen aber jede Menge.
  • Die "Coffee Shops" sind, nun ja: "Alexander Ziegler", "Antiquitäten Lüttme" und "Angelika Brahmer". Eher nicht.
  • Die Bars: Es fehlen viele, und der Subway Store ist eben ein Subway, aber keine Bar.
  • Die Kinos: Naja, das war wohl überhaupt nichts.
  • Die Schulen: Bessere Treffer als bei den Kinos, aber auch eher falsch. Es gibt aber in der Tat einige "richtige" Schulen in der Nähe.

Etc., etc.: Im Nachhinein habe ich den Eindruck das die fehlenden Daten ein Problem von Google sind, und die fehlerhafte Interpretation ein Problem von Walk Score - aber zusammengenommen machen sie die Sache doch extrem unzuverlässig.

Kann ich wirklich nicht empfehlen.