...someplace, where there isn't any trouble? Do you suppose there is such a place, Toto?

Greatest Air Guitarists of Space and Time

Sodele, mir fällt gerade nichts Gescheites ein, also hier ein paar gefällige Bilder aus Mission Control. Geradeso recht zum Warmlaufen für das Luftgitarrenbild aller Luftgitarrenbilder, das demnächst hoffentlich mein Depp-uty hier präsentieren und SFR sicher zur Weißglut bringen wird. Aber was soll's...

Hier erstmal der DEI. Daß ein Spickzettel eigentlich immer hilfreich ist, wissen wir spätestens seit Lehmann, Cambiasso und Ayala. Aber zum Gitarrestimmen?

Fast schon hendrixianisch anmutend: The Guitar Artistry of Tobias "Excel" Decker. Eigentlich ist er ja unser Hausmeister, aber wir lassen ihn weiter im Glauben, Projektleiter zu sein. Das hebt nämlich die Stimmung.

So, und zu guter letzt zeigt uns dieser Hexenmeister seinen schwierigsten Akkord, den man mit zwei Händen und aufrechtstehender Gitarre spielen muss. Es ist ein F#-7 b9 b17.

(Ein Klick auf ein Bild öffnet es in hoher Auflösung in einem separaten Browserfenster)

PREFast mit VS2005 unter XP x64 Edition

Link: http://mcblogs.craalse.de/sku?title=prefast_fur_die_normalsterblichen_unter&more=1&c=1&tb=1&pb=1

Letzte Woche habe ich hier beschrieben, wie man mit dem Vista Beta PlatSDK die PREFast Option nutzen kann. Leider funktioniert das nicht ganz so reibungslos, wenn man dieses PlatSDK auf einer x64 Edition von Windoze installiert: Die für PREfast erforderlichen Dateien werden auf dieser Plattform nämlich schlicht und einfach vergessen. Um das geradezubiegen kopiert man sich die Dateien mspft80.dll, c1ast.dll und c1xxast.dll von einer x86 Installation ins Verzeichnis <platsdk-Dir>\vc\bin sowie die Datei mspft80ui.dll ins Verzeichnis <platsdk-Dir>\vc\bin\1033. Vermutlich reicht es auch schon, von einer Team-Edition von VS2005 diese Dateien zu einer Professional-Installation hinzuzufuegen und schon läuft PREfast auch ganz ohne ein Vista-PlatSDK.

Customizing von Visual Studio 2005 Pfaden

Visual Studio 2005 hat ein von VS6 stark differierendes Verhalten, was das Customizen von Pfaden für Header, Libraries und Executables angeht. Dieser Blogpost soll hier etwas Licht ins Dunkel bringen.

Mit VS6 war die Welt schön und gut und einfach. Pfade konnte man kinderleicht ergänzen durch Manipulieren der named String Values unter

"HKEY_CURRENT_USER\Software\Microsoft\Devstudio\6.0\Build System\
Components\Platforms\Win32 (x86)\Directories"

Installierte man ein PlatSDK, so musste man hier normalerweise selber Hand anlegen und die Pfade ergänzen.

Ganz anders die Situation bei VS2005. Hier gibt es erstmal eine Reihe von XML-Dateien mit der Endung .config unter <vcinstalldir>\vc\vcpackages, pro Target (also x86, x64, CE, und VC-Express(?)) eine. Diese Dateien sind ab Werk erstmal generisch, enthalten also keine absoluten Pfade sondern arbeiten mit Platzhaltern ähnlich den Umgebungsvariablen. So wird etwa das VS2005 Installationsverzeichnis durch den String $(VCInstallDir) repräsentiert und andere Pfade durch ihre Environmentvariablen selber in äquivalenter Notation ($(SystemRoot), $(ProgramFiles), etc...).

Ändert man nun irgendwelche Einstellungen in VS2005 interaktiv, dann werden diese Einstellungen nicht in den o.g. .config-Dateien gespeichert, sondern es wird im Profil des Users eine Datei namens VCComponents.dat erzeugt.
Sie ist zu finden unter

"%USERPROFILE%\Local Settings\Application Data\
Microsoft\VisualStudio\8.0"

und ist eine UNICODE-Textdatei im Ini-Format (ich wußte es, INI wird niemals sterben!) und stellt einen per-User Override der .config-Dateien dar. Sobald also diese Datei im Profil des Users zu finden ist, wird für den entsprechenden User das VS2005 mit den dort eingetragenen Pfaden gestartet.

Soweit ist die Sache ja nun noch verständlich: Es gibt eine Ab-Werk-und-per-Maschine- Konfiguration in der .config-Datei, und eine optionale per-User-Konfiguration in VCComponents.dat im Profil des Users, statt wie früher bei VC6 im per-User-Registry-Hive. Dadurch daß man sich die letztgenannte Datei löscht, kommt man automatisch wieder zum Auslieferungszustand von VS2005 zurück, ist das nicht praktisch?

Spannend wird das Ganze aber, wenn man sich, wie ich unlängst, ein zu VS2005 passendes Platform-SDK installiert. Da gibt es zum gegenwärtigen Zeitpunkt nur das aktuelle Vista-Platform SDK. Installiert man dieses, so ändert sich erstmal überhaupt nichts. Denn um es verwenden zu können (außer Doku zu lesen), muß man ja erstmal dafür sorgen, daß eine installierte Version von VS2005 von diesem PlatSDK Wind bekommt. Das kann man old-fashioned machen wie früher, also die Pfade von Hand eintragen. Aber woher weiß ich denn wie eine amtliche Eintragung aller Pfade aussieht, inklusive Pfaden zu den neuen Tools, zum Framework SDK und pipapo? Bei früheren PlatSDKs war das einfach: include-Pfad und lib-Pfad ergänzen und fertig, aber jetzt mit diesem aufgeblähten Ungetüm von VS2005, dem neuen PlatSDK und dem .NET-Framework?

Da ist dann dieser Startmenüeintrag namens "Visual Studio Registration" - "Register Windows SDK Directories with Visual Studio 2005" schon sehr verführerisch, soll er doch sicherstellen, daß das installierte PlatSDK sauber und reibungslos in VS2005 integriert wird. Klickt man ihn nun also an, passiert folgendes:

  • erstmal wird eine VCComponents.dat im Profil des ausführenden Users erbarmungslos eliminiert. Da gehen sie dahin, meine mühsam zusammengestoppelten Pfade...
  • Dann werden in die .config-Dateien unter <vcinstalldir>\vc\vcpackages die neuen Pfade reingemergt. Von einem Backup der alten Dateien keine Spur. Meine Hoffnung ist ja, dass die Deinstallation dieses (Beta-)PlatSDKs alles wiederherstellt. Wenn nicht: Das war ja "Beta", ich wußte ja worauf ich mich einlasse...

Die Integration des Vista-PlatSDKs ändert also systemweit die Einstellungen für VS2005, man tut gut daran, sich vorher ein Backup der .config-Dateien zu machen (oder von einer Maschine herzukopieren, wo kein PlatSDK installiert ist) und sich von einer gegebenenfalls vorhandenen VCComponents.dat auch ein Backup zu machen. Gleichzeitig zeigt mir diese Vorgehensweise einmal mehr, daß man in diese beiden Dateien, wie auch in die Registry Keys für VC6, eigentlich selber nichts eintragen sollte, sondern eigene Header und Libraries immer über projektspezifische Pfadangaben ergänzen sollte, denn sonst kann man sich die Arbeit des Zusammenstopelns der Pfade jedesmal neu machen, wenn man ein neues PlatSDK installiert und ausprobiert, und kann vor allem nicht leicht durch Umkopieren der Datei VCComponents.dat mal mit und mal ohne das Platform-SDK oder mit mehreren PlatSDKs gleichzeitig hantieren. Wem das allzu abwegig vorkommt, dem sei gesagt, daß der derzeitige Buildprozeß bei επτ€σ nacheinander mit dem Windows-2000-PlatSDK von 1999, dem Windows 2003 Server PlatSDK vom Februar 2003, dem Windows 2003 Server SP1 PlatSDK vom Mai 2005 und Teilen des mit VS2005 ausgelieferten PlatSDKs übersetzt und linkt - und dies alles mit VC6-basierten Builds.

VMWare Workstation 5.52 released

Siehe

http://www.vmware.com/download/ws

Laut Release Notes unterstützt diese Version gegenüber der letzten Version (5.51 Build #19175) eine Reihe weiterer Betriebssysteme als Wirt und als Gäste und enthält Bugfixes. Neue Funktionalität gibt es augenscheinlich nicht.

Life in Mission Control

Damit jeder 'mal sieht, was ich täglich so in Mission Control zu ertragen habe, hier mein kindischer Depp-uty in einer seiner typischen Posen:



(Ein Klick auf das Bild öffnet es in hoher Auflösung in einem separaten Browserfenster)

<< 1 ... 23 24 25 26 27 28 29 30 31 32 33 ... 46 >>