Im FEM Plattenprogramm XPLA kann man die Grundrissdaten entweder selbst mit den graphischen Werkzeugen eingeben, oder man importiert diese Daten aus einer DXF-Datei.

Beim Import von DXF-Daten gibt es aber ein Problem: Solche Daten stammen meist aus Zeichnungen und liegen daher gerne in merkwürdigen Koordinatensystemen, sind falsch skaliert - oder sind mit übereinander gezeichneten Linien überfüllt. Als Resultat erhält man dann nach dem Import jede Menge Linien die sich schneiden und überlappen, und noch mehr Punkte die 'fast' auf solchen Linien liegen - aber eben nur 'fast'.

Am Bildschirm kann man das leider überhaupt nicht sehen - zumindest nicht, wenn man keine sehr starke Vergrößerung wählt. Klickt man die importierten Linien und Punkte dann einfach an, so bekommt man ein statisches System in dem logischerweise die gleichen - oder stark verwandte - Fehler vorliegen. Das rächt sich etwas später, wenn man versucht ein FEM Netz zu generieren: Der Generator bemängelt dann nämlich das System und erzeugt eben kein Netz.

Hier gibt es nur zwei Mögliche Auswege: Entweder man stellt sicher, das die eingelesenen DXF-Dateien sinnvoll sind (das ist oft nur schwer möglich) - oder aber, man erzeugt den Grundriss nur Schritt für Schritt - und stellt nach jedem Schritt sicher, das sich das FEM-Netz noch erzeugen lässt. Ist das nämlich nicht der Fall, so untersucht man seinen Grundriss besser auf 'merkwürdige' Stellen.

So nett das alles ist mit dem Managed Code - letzten Endes gibt es noch jede Menge unmanaged Code der gewartet und verwendet werden will. In Fall unseres aktuellen Projektes - das eigentlich ein managed Code Projekt ist - gibt es zum Beispiel einige Megabyte an nativem Win32 C++ Code. Dabei handelt es sich um Libraries die Ihren Dienst tun, und bei denen es schlicht keinen Sinn macht, sie zur CLR zur portieren.

Das bedeutet auch, das man sich eben auch weiterhin mit Speicherlecks in normalen Win32 Code auseinandersetzen muss. Dazu gibt es den extrem hilfreichen Debug-Heap und im Fall von MFC Code die zugehörigen Wrapper wie zum Beispiel das CMemoryState Objekt. Mit einem CMemoryState kann man zum Beispiel die momentan allozierten Objekte anzeigen lassen, oder man kann eine Statistik der Allokationen erhalten. ( Um die seit einem gegebenen Zeitpunkt allozierten Speicherbereiche zu finden, muss man zunächst einen Checkpoint() durchführen, und vom zugehörigen Objekt dann DumpAllObjectsSince() aufrufen.)

Dabei zeigt einem die CRT dann neben den Allocationen (wenn möglich mit Dateiname und Zeilennummer) auch eine 'Allocation Number' an. Dabei handelt es sich um die Nummer der Allocation im laufenden Programm. Diese Nummern sind ganz interessant - das Problem ist aber: Wie findet man nun heraus, welcher Vorgang eine gegebene Allokation ausgelöst hat.

Das geht am einfachsten mit _CrtSetBreakAlloc(). Man übergibt der Funktion die Nummer der Allocation aus dem Dump - und startet den Debugger. Der bleibt dann bei dieser Allokation stehen - und man kann einfach per Call-Stack herausfinden, was den Vorgang ausgelöst hat.

Unser Mailserver (mail.die.de) ist ja schon bereits seit geraumer Zeit mit SPF ausgestattet. Sinn der Sache: Vermeidung von Spam. Ab sofort läuft ein Update der Server-Software, die auch mit Hashcash und Domain Keys klarkommt. Den aktiven Support dafür kann ich momentan gerade leider nicht anwerfen: Spätestens im Mai wird es aber soweit sein - Werkzeuge gegen Spam kann man ja gar nicht genug haben.

Es gibt verschiedene Produkte die versprechen, man könne damit Blogs innerhalb von Outlook lesen. Eins davon habe ich mir übers Wochenende angesehen: intraVNews.

Grad habe ichs wieder runtergeworfen: Die Darstellung der Blog-Inhalte war alles andere als brauchbar und absolut nicht mit Sharpreader oder RSSBandit zu vergleichen. Funktionen wie 'alles als gelesen markieren' oder 'jetzt updaten' gingen überhaupt nicht. Auch wenn es nett war die Feeds in Outlook zu haben - das ganze war insgesamt im Vergleich zu Sharpreader einfach viel zu schlecht.

Wenn ich das nächste mal die Ruhe dazu habe, schaue ich mir NewsGator an. Von IntraVNews kann ich jedenfalls nur abraten.

Kaum programmiert man ein paar Jahre mit managed Code, schon hat man sich an die immer brav verfügbare BCL gewöhnt. Da bin ich dann heute beim testen auf einem fremden Rechner prompt drüber gestolpert: Mein Programm wollte erst gar nicht starten.

Nach einiger Zeit kamen dann die Erinnerungen an 'früher'.... da war doch mal was mit Abhängigkeiten von DLLs... und dann ging dankbarerweise ein Licht auf: Wenn man im Projekt auch nativen Code mit VC++ hat das muss man natürlich auch die entsprechende RTL installieren. Ist auch noch MFC/ATL drin, dann braucht es das natürlich auch. Dito was die Redist von DirectX angeht - und so weiter und so fort.

In der Theorie also ein schönes 'Xcopy deployment' - in der Praxis ist das Projekt mitlerweile einfach zu umfangreich, als das man tatsächlich nur ein paar Dateien kopieren kann.

Bei der Gelegenheit, weil man es gerne vergisst: Das SDK (auch der Teil, der bei VS Dabei ist) enthält ein Prima Tool namens 'Depends'. Damit kann man ganz wunderbar herausfinden, von welchen DLLs eine DLL abhängig ist. 

Ich hoffe das die diversen Serverprobleme (im Downloadbereich, mit den Zeitkonten, der Webseite und zwischenzeitlich auch mit dem Mailserver) nun endlich beendet sind. Zumindest die von hier aus sieht es so aus, als würde alles wieder klaglos gehen. Wie angekündigt erfolgen die Downloads ab sofort nur noch per HTTP - wer die Programme bisher mit dem Browser heruntergeladen hat, sollte dabei keine Veränderung bemerken. Wer bisher einen reinen FTP-Client verwendet hat: Sorry - bitte auf Downloads per Browser umsteigen.

Seit heute Morgen ist es nicht mehr möglich Dateien aus dem Download-Bereich auf www.die.de herunterzuladen. Das ist das Resultat eines Problems mit dem wir schon seit einigen Tagen kämpfen: Teilweise ging die Webseite nicht, teilweise funktionierten die Zeitkonten nicht... und das ganze dann auch immer wieder von vorne.

Mitlerweile ist klar, das das ganze tatsächlich an einer defekten Netzwerkkarte lag. :-(

Die Site ist nun so umgebaut, das Sie zumindest an die Inhalte der Webseiten gelangen und auch auf Ihre Zeitkonten wieder zugreifen können - ich hoffe, das das nun auch verlässlich der Fall bleiben wird. (Immerhin: Das ist die erste größere Störung in 24 Monaten - ärgerlich, die lange störungslose Zeit nun so unterbrechen zu müssen.)

Aber: Der Download unserer Statikprogramme ist momentan NICHT möglich. Ich hoffe das aber auch übers Wochenende noch in den Griff zu bekommen. Grund für die Verzögerung: Im Rahmen des Umbaus war es notwendig auch die Art und Weise des Downloads zu verändern. In Zukunft werden die Downloads NICHT mehr über das FTP-Protokoll, sondern über HTTP erfolgen. Dazu müssen aber ein paar Skripte auf dem Server verändert werden - und das ist, womit ich mich momentan beschäftige.

Hin und wieder geht bei uns eine Anfrage ein, ob unsere Programme auch unter Linux eingesetzt werden können. Dazu ist zu sagen, das wir keine Linux-Versionen unserer Software anbieten - alle Programme sind Programme für Windows ab Version 95.

Trotzdem gibt es unter Linux Möglichlichkeiten, unsere Programme zu nutzen - der von der Linux Gemeinschaft am stärksten propagierte Weg zum Betrieb von Windows-Programmen ist dabei der Windows Emulator Wine. Den habe ich mir heute aus anderen Gründen einmal angesehen. Und ich kann behaupten - die Programme laufen. Hier im Bild zu sehen unter SuSE 9.1.

Das Installationsprogramm läuft problemlos, und auch der Programmstart ist möglich: Zwar gibt es keine Icons im 'Start' Menü oder ähnliches, und man muss auch ein wenig nach dem 'richtigen' Weg suchen, um die Dinger überhaupt ans laufen zu bekommen - aber dann gehts.

Größtenteils. Stellt sich die Frage, ob das was geht, reicht.

Man kann Dateien problemlos laden, die Optionen einstellen, die Berechnung durchführen und Ergebnisse anzeigen. Auch die verschiedenen Darstellungsarten, Dialoge und Objektmenüs funktionieren. Allerdings: Alles nicht sehr schnell, und alles nicht sehr schön. Grund: Es scheint doch einige gewaltige Probleme bei der Darstellung der verschiedenen Windows-Kontrollelemente zu geben. Die 'gehen' zwar - aber teilweise erst nachdem sie _sehr_ oft am Bildschirm ausgegeben, übermalt, und wieder ausgegeben werden. Hinerher sieht auch alles nicht so aus, wie es aussehen soll - sondern nur 'fast'. Der optische Eindruck - und darauf verwenden wir schon eine Menge Zeit - geht doch recht stark verloren. Gleiches gilt für die Arbeitsgeschwindigkeit. Vom angenehm interaktiven arbeiten, wie Sie das unter Windows von den Programmen gewohnt sind, kann man eigentlich nicht mehr sprechen. Nicht immer, aber oft.

Damit könnte man ja noch leben: Ich kenne ein paar Konkurrenzprodukte die von deren Anwendern gern als 'benutzerfreundlich' tituliert werden, aber ein (mich) ebenso erschreckendes Verhalten an den Tag legen, was Performance im allgemeinen und Bildschirmupdates im besonderen angeht.

Weniger schön ist, das das 'Drucken' unter Wine irgendwie nicht so richtig funktioniert - zumindest habe ich es nicht geschafft, irgendwas zu produzieren was auch nur ansatzweise wie ein Ausdruck ansieht. Das scheint aber unter Wine ein lang bekanntes Problem zu sein: Ich habe mich da wohl nicht zu blöd angestellt, es geht eben einfach noch (?) nicht richtig.

Wer aber nicht drucken will, der hat damit natürlich kein Problem. Er oder Sie wird aber sehr wohl ein anderes Problem haben: Es gibt doch sehr oft Abstürze. Beim testen ist mir das alle Nasen lang passiert, etwa einmal alle 10 Minuten im Verlaufe von 2 Stunden: So beim aufrufen der Hilfe, beim öffnen einer Dialogbox, und auch beim anklicken einer Platte in der Explorer-Ansicht. Wenn das passiert, dann landet man im Wine-Debugger, und das sieht dann so aus:

Das finde ich dann wirklich nicht mehr so doll: Förderlich für die Arbeit als Bauingenieur ist sowas sicher nicht. Zumindest nicht, wenn es einfach zu oft passiert.

Nicht das man mich hier falsch versteht: Ich finde die Arbeit, die das Wine Team (und die Unterstützung) geleistet hat, bis über alle Massen erstaunlich. Unglaublich eigentlich, das da überhaupt irgendwas funktioniert - und das es so gut funktioniert ist noch weitaus erstaunlicher. Nur - gut genug funktioniert die Sache eben einfach nicht, zumindest nicht, wenn man unsere Statikprogramme einsetzen möchte. (Auch wenn das jetzt ein bisschen gemein klingt: Mit Notepad und MineSweeper hatte ich keine Probleme. Nur braucht man die eben selten, um eine statische Berechnung durchzuführen.)

Wer aber einen Linux-Desktop sein eigen nennt, darauf auf keinen Fall verzichten will, und trotzdem unsere Statikprogramme einsetzen möchte - dem empfehle ich den Einsatz der VMWare Workstation unter Linux. Darin kann man ganz normal ein Windows installieren (ähnlich wie im Virtual PC von dem ich unter anderen hier berichtet habe), und darin dann unsere Programme betreiben.

Wer hingegen schlicht und ergreifend kein Windows mehr will, auch nicht im VMWare, der kann auf Linux Programme für Bauingenieure zurückgreifen. Ich muss gestehen das ich da nicht sonderlich viele Angebote kenne, aber Sofistik bietet offenbar ein Produkt Namen Statikkette an, und Abel hat eine Linux-Version angekündigt (unten auf der verlinkten Seite).

Meine grundlegende Empfehlung jedoch ist weiterhin: Verwenden Sie Windows XP mit dem Service Pack2 - und natürlich unsere Statik-Programme. Ich bin da aber auch ein klein wenig subjektiv :-)

Beim Faltwerksprogramm wird sich die Navigation im Raum deutlich vereinfachen - und im Vergleich zu bisher bestehenden Programmen wie dem Rahmenprogramm auch deutlich verbessern. Was genau passiert ist aber besser zu demonstrieren, als im Text zu beschreiben. Daher hier der erste Versuch, das ganze per Video und Ton vorzuführen.

Ich bitte um Verständniss: Das ist mein erstes Video, dementsprechend gibts ein paar Versprecher, und auch die Bildqualität könnte ein bisschen besser sein. So sieht man zum Beispiel in der Hidden-Line Ansicht den Verlauf der Körpers nicht so gut, wie das im Programm tatsächlich der Fall ist - bzw. sein wird. Wenn das Video ankommt, werde ich in Zukunft versuchen sowas häufiger zu machen...

Das Video liegt im WMV-Format vor und kann mit dem aktuellen Windows Media-Player abgespielt werden. Eine aktuelle Version davon erhalten Sie kostenlos hier.

Link zum Video (Dauer ca. 2 Minuten)

(Es ist übrigens hilfreich, wenn Sie auch den Ton zum Video hören können :-) )

Nach meinem dafürhalten deutlich besser strukturierte Ergebnisse als Google lieferte ein Beta-Engine von Microsoft Research: Search Result Clustering. Allerdings kommen die Resultate auch ein wenig langsamer - man muss warten bis sich beide Frames aufgebaut haben, um den Nutzen zu nutzen. (Tipp: Suchen Sie mal nach 'Apple' - im Result-Map gibt es dann Links die sortiert sind: Teils zur Computerfirma, und Teils zu den grünen Dingern zum essen.)

Wenn Sie eine eMail an einen Empfänger bei die.de senden, dann kann es sein das die Mail nicht zugestellt wird. Statt dessen erhalten Sie eine Fehlermeldung aus der hervorgeht, das Ihre Mail als 'Spam' abgewiesen wurde. Nun sind Sie aber kein Spammer, und Ihre Mail enthält auch keine unerwünschte Reklame: Warum also geht die Mail nicht durch?

Leider ist es so, das doch eine ganze Menge an Leuten im Internet Spam versenden. Viele tun das sogar ohne es zu wissen - weil sich zum Beispiel ein Trojaner unbemerkt auf dem eigenen Rechner eingenistet hat, und weil Spammer dann den Rechner ohne Wissen des Besitzers als Spam-Quelle verwenden. Das ist allerdings im Normalfall nicht die Ursache das Problem, es ist nur wichtig zu wissen das es nun einmal viele Spamquellen gibt.

Um nun die Menge an Spam einzugrenzen (ich habe hier ein paar Statistiken dazu gepostet) gibt es verschiedene Arten von Filtern. Unser Mailserver, mail.die.de, verwendet praktisch alle die es gibt. Eine dieser Filtermöglichkeiten besteht in der Verwendung von Spammer-Datenbanken. Dabei handelt es sich um Datenbanken die im Internet zur Verfügung stehen, und in denen bekannte Spammer (bzw. deren Rechner) aufgelistet sind. Geht eine Mail bei einem Mailserver ein, dann kann dieser auf eine solche Datenbank zurückgreifen und überprüfen, ob die eingehende Mail über einen Server gelaufen ist, der in der Datenbank aufgeführt wird.

Ist das der Fall, dann ist die Change relativ hoch, das es sich bei der eingehenden Mail um Spam handelt. Das ist auch genau der Fall, bei dem Sie die oben genannten Fehlermeldung (oder eine ähnliche) erhalten.

Was dabei passiert ist das folgende: Sie selbst betreiben eben keinen Mailserver, sondern Sie verwenden einen Mailserver Ihres ISP. Diesen Mailserver verwenden aber auch noch andere Leute - nämlich die anderen Kunden des ISP. Stellt der ISP nun nicht sicher, das seine Kunden keine Spam versenden - dann wird der Mailserver über lang oder kurz als bekannte Spam-Quelle in der Datenbank eingetragen. Resultat: Alle Kunden des ISP haben ein Problem - auch die, die gar keine Spammer sind - denn Mailserver die die Spammer-Datenbank benutzen, nehmen keine eMails mehr von diesen Kunden an.

Was können Sie in diesem Fall tun?

Das kommt in erster Linie auf Ihre ISP an: Sie sollten sich auf jeden Fall mit dem ISP kurzschliessen und sich über das Problem beschweren: Wenn die Fehlermeldung die Sie erhalten haben eine Information darüber enthält, welche Datenbank den Rechner bemängelt hat, dann sollte Sie Ihrem ISP diese Information mitgeben. Ansonsten wird Ihr ISP zumindest die eMail-Adresse benötigen, an die Sie die Mail versenden wollten.

Der ISP kann sich dann seinerseits darum kümmern zunächst die eigenen Probleme zu beseitigen. Dazu gehört zum Beispiel das Kündigen von Verträgen mit Spammern, oder aber auch die Kooperation mit Kunden deren Rechner von Trojanern befallen sind um sicherzustellen, das diese Rechner in Zukunft keine Spam mehr versenden. Ist das geklärt, kann der ISP bei der Datenbank beantragen wieder aus der Liste der bekannten Spammer entfernt zu werden: Sowas geht meist automatisiert uns sollte nicht länger als ein paar Stunden - meist eher 30 Minuten - dauern.

Danach hat der ISP ein Problem weniger, und Sie sind wieder in der Lage Mails zu versenden.

Es gibt mit Sicherheit jede Menge und drei Tools zum brennen von CDs, und vermutlich sind einige davon sogar sehr gut. Nachdem ich aber nur alle paar Monate mal eine CD brenne benutze ich im Normalfall einfach den bei XP eingebauten Mechanismus: Leere CD einlegen, Dateien aus dem Explorer ins passende Fenster ziehen - fertig. Das mag nicht der 'optimale' Weg sein, aber ich kann mir das zum einen merken, und zum anderen finde ich das auch eingängig und einfach.

Allerdings kann XP eines nicht (zumindest glaube ich das das so ist) - und zwar Images, die man bereits als .ISO CD hat, auf einen Rohling zu brennen. Auch dafür gibt es vermutlich supertoole Werkzeuge, aber das mache ich noch seltener als das 'normale' brennen von CDs.

Soweit ich mich erinnere heute zum zweiten Mal insgesamt. Und darum habe ich da auch kein besonderes Werkzeug für, sondern versuche die Software zu verwenden, die bei meinem Brenner dabei war: Sonic RecordNow DX.

Und das macht die Sache zum Kampf. Wer das gleiche Problem auch einmal hat: So gehts.

1. Man startet Sonic und klickt alle merkwürdigen Wizards und sonstige angeblich Hilfreiche Dialoge weg.
2. Danach hat man nur das Sonic-Fenster vor sich, und das hat oben eine Werkzeugleiste.
3. Da klickt man auf 'Abbild'.
4. Das öffnet im Arbeitsbereich eine Art Formular. Das hat unten ein Textfeld mit der Beschreibung: 'Datenträger-Abbilddatei'. Da muss man den Pfad zum ISO-Image angeben. Dazu klickt man am besten NICHT auf 'Datei hinzufügen', denn das führt nur dazu das das Programm anfängt alle lokalen Laufwerke zu durchsuchen - und das dauert einfach viel zu lange. Normalerweise weiss man ja schliesslich, wo sich die Datei befindet.
5. Statt dessen öffnet man einen Explorer und zieht die Datei dann per Maus in das Textfeld. Das führt dazu, das der Pfad im Textfeld richtig eingetragen wird.
6. Dann klickt man auf den roten Button, der so aussieht, als würde er das Brennen abbrechen. (Von wegen 'rot' und so...
7. Das wiederum startet dann den Brennvorgang.

Userinterfaces from hell: Ich frage mich wirklich was die Leute dazu bringt, so einen Kram zusammenzuschrauben. Doch letztlich: Das Programm war kostenlos beim Brenner dabei - da sollte man sich vielleicht nicht beschweren.