Thomas Woelfers Baustatik Blog

Baustatik-Software und was sonst des Weges kommt

Update von "D.I.E. Baustatik"

Ab sofort ist ein Update für die "Baustatik" im Downloadbereich verfügbar. Details dazu finden sich wie immer im Update-Protokoll.

Wir versuchen bereits seit einiger Zeit, jeweils um den Monatsanfang eine neue Version bereitzustellen. Der erste Grund dafür ist relativ einfach: An der Baustatik wird intensiv gearbeitet, und in einem Monat kommen immer wieder eine ganze Menge an neuen Funktionen zusammen. Der zweite Grund hängt mit dem Fehlermeldungsmechanismus zusammen, den wir von Anfang an in der Baustatik eingebaut hatten: Aufgrund der bei den Fehlermeldungen mitgelieferten Daten sind wir normalerweise recht schnell in der Lage, das Problem zu beheben. Meist handelt es sich dabei um eher "lokale" Probleme - also um solche, die bei genau einem Kunden vorkommen, bei anderen Kunden aber eher sehr unwahrscheinlich sind.

(Als Beispiel für einen solchen Fall: Wir hatten in diesem Monat eine Fehlermeldung die das laden eines Projektes betraf. Grund des Fehlers: Die Daten zum Projekt waren auf einem NAS System, und wurden per "Offline Files" in Windows zur Verfügung gestellt. Im vorliegenden Fall mussten aber neue Kopien abgeholt werden, nur war das NAS System noch nicht hochgefahren. Nach meiner Einschätzung ist das ein klarer Problemfall, der zwar einmal vorkommen wird - danach aber nie wieder...)

Trotzdem wollen wir die "Klärungen" für solche Probleme (die wir natürlich trotzdem einbauen, auch wenn es sehr unwahrscheinlich ist, das ein gleich gelagertes Problem nochmals auftritt) möglichst schnell für jedermann zur Verfügung stellen: Je weniger "unerklärliche" Probleme es gibt, um so besser...

Daher der Monats-Zyklus für die Verteilung der Updates.

MSDN Reader verfügbar

Vom MSDN Magazin gibt es nun den MSDN Reader. Dabei handelt es sich um eine WPF Anwendung (mit Quellcode), mit der man die Online-Variante des Magazins "hübscher" lesen können soll. Und in der Tat lesen sich die Artikel besser als per Browser - allerdings fand ich die Navigation ein wenig schlechter: Das mag Gewöhnungssache sein - ich werde das auch jeden Fall noch eine Zeitlang ausprobieren. "Auf Anhieb" war ich allerdings ein wenig verloren - irgendwie habe ich den Eindruck, das die Sache mit dem Reader nicht übersichtlicher wird.

Grundlegendes zu WOW64

Bei WOW64 handelt es sich um den x86 Emulator, der es ermöglicht, 32bit Windows-Anwendungen auf einem 64bit Windows-System (also XP 64 oder Vista 64) auszuführen. Die Referenzinformationen dazu finden sich bei MSDN.

Was man auf jeden Fall darüber wissen sollte ist folgendes: WOW64 verwendet einen Registry Redirector (Umleiter) und einen Dateisystem Redirector, um 32bit Anwendungen eine logische Sicht auf das Dateisystem und die Registry zu verschaffen, die mit dem tatsächlichen Layout nichts zu tun hat. Anders ausgedrückt: Die Registry und das Dateisystem sind unter 64bit Windows anders organisiert als unter 32bit Windows, und WOW64 kümmert sich darum, das beides für 32bit Anwendungen trotzdem so aussieht, wie diese das erwarten.

Die Systemprorgamme mit 64 Bit finden sich auf der Platte in %windir%\system32, und das Verzeichnis für 32bit findet sich unter %windir%\SysWow64. (Es gibt ein paar weitere Unterschiede, aber das ist der wichtigste.)

Wie erwähnt sieht auch die Registry anders aus - wie man leicht überprüfen kann, wenn man die "richtige" Version von Regedit.exe verwendet: Es gibt nämlich 2 davon. Um die 64bit Variante der Registry anzusehen, verwendet man %windir%\system32\regedit.exe und um die 32bit Variante zu betrachten %windir%\SysWow64\regedit.exe. (Startet man Regedit einfach von der Kommandozeile die man über cmd.exe vom Start-Menü geöffnet hat, bekommt man die 64bit Variante.)

Kommende Attraktionen

In der nächsten Version des Faltwerks gibt es eine neue Version, nach der ich schon häufiger gefragt worden bin: Import von Knotendaten aus Excel. Um die Funktion zu benutzen, braucht man zunächst passenden Daten in Excel. Im Wesentlichen sind das drei nebeneinander liegende Spalten, die die Knotenkoordinanten enthalten: Also eine Spalte für X, eine für Y und eine für Z.

Dann markiert man einen Bereich innerhalb dieser drei Spalten - eben den, der die gewünschten Koordinanten enthält.

Sind die gewünschten Koordinanten markiert, kopiert man die Daten in die Zwischenablage.

Im Faltwerk kann man diese Daten dann mit dem Befehl "Aus Excel importieren" einladen.

Wie gesagt: Ab der nächsten Version :-)

Schwer zu finden: Die Videos zum Faltwerksprogramm

Für den Einstieg in das Faltwerksprogramm haben wir schon vor einiger Zeit diverse Videos produziert - die waren auch hier im Blog Stück für Stück veröffentlicht worden. Die Videos kann man auch über die ganz normale Dokumentation zum Programm erreichen. Diese findet sich sowohl offline unter dem "Hilfe" Befehl im Programm als auch hier auf dem Webserver: Faltwerks-Dokumentation

In der Dokumentation klappt man zunächst "Faltwerk" und dann "Programmübersicht" auf. Darin befindet sich dann die Seite mit dem Titel "Erste Schritte" - und dort ist auch der Link zur Videosammlung. Oder hier: Faltwerk-Videos

Warum es ein Update ohne Benachrichtigung gab

Wer unseren Download-Bereich immer genau im Auge behält (Zugegeben: tut vermutlich niemand, schliesslich gibts ja immer die Update-Mails und den Update-RSS Feed :-) ), der wird heute etwas merkwürdiges festgestellt haben: Es gab ein Update für das "setup.zip" (das ist das Installationsprogramm für Xpla, Xrst, etc.) - aber es gab keine Update-Email dazu. Warum?

Der Grund ist einfach: Das Update heute enthielt keinerlei Veränderungen an den Statikprogrammen - nur das "setup" selbst hatte ein Veränderung erfahren. Und diese eine Änderung betraf - zumindest soweit mir das bekannt ist - nur einen einzigen Kunden. Dieser Kunde hatte eine, im Vergleich zu den Installationen bei anderen Kunden, eher ungewöhnliche Installation: Die Programme waren auf einer XP Pro Workstation installiert, die zum einen Domain-Mitglied war (nicht sooo ungewöhnlich, denn das sind unsere Rechner in München auch alle) und zum anderen ein französisches XP verwendete.

Nun ist es so das das Setup seit der letzten oder vorletzten Version das Programm "DIEUserPermission" das man braucht, wenn man ohne administrative Rechte arbeiten will (was man sollte), automatisch im Zuge der Installation ausführt. Das Programm kam aber mit dem französischen Windows nicht klar - und darum hatte der Kunde Probleme: Die Software liess sich bei Ihm nicht mehr installieren.

Dieses Problem wurde beseitigt und ein neues Setup.zip gebaut - und weil es nur einen einzelnen Kunden betraf haben wir keine eMail rausgeschickt.

LookupAccountName API - woher man den Namen bekommt

Es gibt einige "bekannte" (well-Known) SIDs - so zum Beispiel die der Gruppe "Jeder" (Jedermann, Everyone, World). Nun ist es so, das man für verschiedene APIs, so zum Beispiel LookupAccountName den zum SID passenden String benötigt. Also eben "jeder". Dummerweise sind diese Strings aber solche, die lokalisiert werden: Bei unterschiedlichen Sprachversionen von Windows, muss man da auch den zur Sprache passenden String übergeben. Mit anderen Worten: "everyone" funktioniert eben nicht "einfach so".

Nun ist es deutlich schwieriger an diesen String zu gelangen, als man meinen möchte. Im Prinzip gibt es zwar die API LookupAccountSid die trotz Ihres Namens nicht die SID zu einem Account, sondern den Account-Name (und die Domäne) zu einer SID liefert. Die ist aber ein bisschen schwer zu bestücken. Wer aber auch einmal das Problem hat, den übersetzten Namen für einen "well known" SID zu brauchen, der kann mit folgendem Beispielcode vielleicht etwas schneller zu Ziel kommen: Hier wird (ohne jegliche Fehlerbehandlung) der Name der "Everyone" Gruppe ermittelt. Viel Vergnügen damit. :-)

class EveryoneGroup
{
public:
 EveryoneGroup()
 {
  PSID pEveryoneSID = NULL;
  SID_IDENTIFIER_AUTHORITY SIDAuthWorld = SECURITY_WORLD_SID_AUTHORITY;

  if(AllocateAndInitializeSid(&SIDAuthWorld, 1,
       SECURITY_WORLD_RID,
       0, 0, 0, 0, 0, 0, 0,
       &pEveryoneSID))
  {
   SID_NAME_USE snu;
   char *name = 0;
   char *domain = 0;
   unsigned long namesize = 0;
   unsigned long domainsize = 0;

   LookupAccountSid(0, pEveryoneSID, name, &namesize, domain, &domainsize, &snu);
 
   int ret = GetLastError();
   if (ret == ERROR_INSUFFICIENT_BUFFER)
   {
    name = (char *) HeapAlloc(GetProcessHeap(), 0, namesize);
    if( name)
    {
     domain = (char *) HeapAlloc(GetProcessHeap(), 0, domainsize);
     if( domain)
     {
      if ( LookupAccountSid(0, pEveryoneSID, name, &namesize, domain, &domainsize, &snu))
      {
       groupName = name;
          HeapFree( GetProcessHeap(), 0, domain);
          HeapFree( GetProcessHeap(), 0, name);
          FreeSid( pEveryoneSID);
      }
     }
    }
   }
  }
 }
  
 CString Name()
    {
  return groupName;
 }
  
private:
 CString groupName;

};

Virtual PC: Wirklich praktisch

Ich wüsste gar nicht mehr, was ich ohne das (kostenlose) Virtual PC tun soll: Jetzt bin ich bereits bei 8 virtuellen PCs angekommen - und das sind nur die, die sich auf meiner Workstation befinden.

Der Rechner "French" betreibt zur Zeit ein französisches Windows XP Pro als Domain-Mitglied, weil bei einem Kunden in dieser Konfiguration ein Problem mit unserem Installationsprogramm auftritt, das ich gerade suche. Dann gibt es eine Vista Home Premium Edition (für Testzwecke), eine virtuelle Maschine die unsere Setups herstellt, einen W2K3 Standard-Server fürs testen von Website-Funktionen, und ein "normales" XP Pro zum testen von fertigen Installationsprogrammen.

Ebenfalls zum testen der Programme dient eine Windows 2000 Workstation. Dann gibts da noch eine Maschine mit der ich mir gerade den Windows 2008 Server ansehe - und schliesslich eine Maschine, in der der VC++ 6.0 Compiler und die Quellcodes für die "alten" Programme installiert ist: Damit kann ich hier auch mal an diesen Programm rumschrauben, ohne das der VC6 direkt auf meinem Arbeitsplatzrechner installiert sein muss.

Praktische Sache.