Diese Bilder sollten IMHO einer breiteren Öffentlichkeit nicht mehr länger vorenthalten werden:

...und auch das ist lustich:

Mannomann, Der Dirkie und sein Blog war ganz offensichtlich der erste aus der Entwicklerriege von επτ€σ, nicht die schmutzigen alten Männer aus Mission Control. Und nein, wir haben uns nicht abgesprochen!

Und ein weiterer kleiner Einschub, bevor es mit der großen 64-bit Windows Reihe weitergeht, aber diesmal thematisch eigentlich ganz passend.

Besucher in Mission Control haben gesehen, daß bei mir zwei Maschinen am Platz stehen. Eine davon ist eine fast 4 Jahre alte P4-Maschine mit 1GB RAM, mit der ich meine Hauptarbeit erledige. Daneben steht eine mittlerweile 3/4 Jahr alte Maschine mit einem frühen Athlon64 die mit der x64 Edition von XP RTM läuft. Leider kann ich diese Maschine nicht wirklich nutzen, weil ich darauf kein VMWare 4 zum Laufen kriege, erst die 5er Version von VMWare unterstützt auch 64 bittige Hosts. Und mit VMWare 5 bei επτ€σ ist das ja so eine Sache, "but that's a whole different kettle of fish".

Daheim in Crailsheim habe ich seit gut einer Woche ein feines kleines Maschinchen, das meinen Park an Rechnern ideal ergänzt. Es ist der Rechner, den Fujitsu-Siemens z.Z. als "Deutschland-PC" vercheckt und ist, soweit ich das Ganze beurteilen kann, ein beachtliches Stück Hardware für einen äußerst moderaten Preis von 999 Euros. Die Maschine läuft mit einem Dual Core Athlon64X2 mit einem Quantispeed-Rating von 3800 und einem NVidia nForce4-Chipsatz, besitzt leider nur 1GB RAM (das bleibt nicht lange so, isch' schwör!), aber hat dann so Highlights wie eine 250GB Serial-ATA Festplatte, DVD Writer und TV-Karte. Vorinstalliert kommt eine XP Media Center Edition mit SP2, also ein herkömmliches x86-Betriebssystem. Inwieweit sich die Media Center Edition von XP Professional oder XP Home unterscheidet, weiß ich ehrlich gesagt gar nicht, für mich sah das Ganze wie eine Professional aus, denn während nach dem erstem Einschalten das Setup komplettiert wurde, wurde angeboten, eine Domain zu joinen. Wie auch immer, die Media Center Edition wurde von mir genau 4mal gebootet und seither nimmer. Das erste Mal, um das Setup zu komplettieren, das zweitemal um mit wupdmgr.exe alle Patches draufzuspielen, das dritte Mal um mit einem geeigneten Tool die am Stück formatierte Festplatte neu zu partitionieren und die Media Center Edition auf die ersten 80GB einzudampfen, und das vierte Mal, um die beiden neuen 80GB Partitionen zu formatieren. Ab da wurde die x64 Edition RTM von XP eingespielt und oh Wunder: Das Setup lief ohne einen Muckser und problemlos durch. Da auf heise online ein Artikel über den Rechner kam, in dem erwähnt wurde, daß darin eine OEM-Version des Asus A8NE verbaut wurde, schnell auf asus.com.tw und dann die nächste Überraschung: Alle Treiber für das Mobo gibt's auch als x64-Versionen und sind WHQL-zertifiziert. Die einzige Hardware, für die ich bis jetzt noch keinen x64-Treiber gefunden habe, ist die TV-Karte.
Aber das interessanteste für den geneigten Leser ist sicherlich die Frage: Wie schnell ist das Biest? Also habe ich jetzt mal einen kleinen Testparcour gemacht um zu sehen, wie sich die Kiste mit anderen Rechnern, die ich so habe (inklusive der beiden Rechner an meinem Arbeitsplatz) so schlägt. Der Testparcour besteht aus:

• CHEKOV Meine Dual Celeron 466 Kiste in Crailsheim mit W2K Professional SP4. Eigentlich meine Lieblingsmaschine weil meistens ausreichend schnell und mit 2 Prozessoren auch flink im UI wenn's mal auf einem Prozessor wieder etwas länger dauert.
• SULU Mein PIII Coppermine mit 1 GHz Takt und nur einem Prozessor und 1.5 GB RAM. Auf ihm läuft XP Professional. Eine identische Maschine (SPOCK) steht in meiner Hütte in Bernhausen direkt neben επτ€σ.
• PICARD Mein Notebook mit einem Pentium M 1300 und 768 MB RAM, auch mit XP Professional
• SAAVIK Besagte neue x64 Maschine
• ES-ES128 Meine steinalte Single Processor P4-Maschine bei επτ€σ und Quell' aller meiner Leiden bei der täglichen Arbeit
• C64 Mein Single Processor x64 bei επτ€σ mit einem Athlon64 3200 und 1.5 GB RAM und einem NVidia nForce3-Chipsatz

Mein "Benchmark" bestand darin, mit VC6 den aktuellen Build des επτ€σ Management Agents komplett im Debugbuild zu übersetzen. Und hier die Zeiten:

Man sieht also, daß erstaunlicherweise SAAVIK geringfügig langsamer ist als C64. Keine Ahnung woran das liegt, vielleicht liegt es daran, daß auf SAAVIK bereits mehr im Hintergrund läuft, wie etwa die VMWare 5.5 Beta, aber wahrscheinlich ist das I/O Subsystem von C64 einfach etwas schneller, evtl. ist die Festplatte bei SAAVIK einfach langsamer. Aber wenn man dann mal die Prozessorlast von beiden Maschinen vergleicht, wird man feststellen daß SAAVIK im Mittel zu etw 45% ausgelastet ist während des Builds - das ist ja auch klar, ein Build ist eine sequentielle Aufgabe und kann so ohne weiteres nicht parallelisiert werden und beschäftigt damit weitestgehend nur einen der beiden Cores. Anders bei C64: Während des Builds "steht" die Maschine weil sie, wenn sie nicht gerade auf I/O wartet, zu 90 bis 100% ausgelastet ist. Man kann also davon ausgehen, daß sich aufgrund der beiden Cores von SAAVIK das Ergebnis schnell wandelt, wenn beide Maschinen gleichzeitig beispielsweise noch eine VMWare Session hosten müßten.

Das interessanteste ist aber, daß ich mit SAAVIK, SPOCK, SULU und PICARD nun mittlerweile 4 Maschinen mein Eigen nenne, die schneller sind als mein Arbeitsplatzrechner bei επτ€σ. Scheint so, als wäre mein Stundensatz noch nicht hoch genug, das gibt Munition für die nächsten Gehaltsverhandlungen :-)

(Edited: Zeiten von CHEKOV von 559s auf 359s korrigiert, Typos fixed)

Jetzt mal ein kleines Intermezzo in der 64-bit Serie:

Heute wurde ich von einem Kollegen darauf hingewiesen, daß mein Code bei ihm nicht buildet, weil eine Datei strsafe.h nicht gefunden werden kann. Es stellte sich im weiteren Zweierlei heraus. Zum einen war bei dem Kollegen gerade das Netzlaufwerk weg, wo das W2K3 Server PlatSDK liegt, deshalb konnte über den include-Suchpfad die strsafe.h nicht gefunden werden, ich war also erstmal aus dem Schneider. Zum anderen aber offenbarte der Kollege, daß ihm der Zweck dieses Headerfiles nicht bekannt war. Wir beschlossen daher gemeinsam, daß ich darüber Bloggen sollte.

Die Datei strsafe.h ist ein Headerfile, das eine Riesenmenge an Funktionen für sicheres Stringhandling beinhaltet. Im Prinzip sind das alles inline-Funktionen, die sichere Wrapper rund um die Standard-C-runtime Funktionen wie sprintf und seine Freunde bietet. Darum ist strsafe sehr unkompliziert anzuwenden, weil man keine lib braucht und alles portabel in diesem einen Headerfile implementiert ist, das man lediglich nach den Headern der Runtime includieren muß. Das Ziel von strsafe.h ist es, die als unsicher verschrienen C-Runtime-Funktionen wie strcat, strcpy, gets, sprintf, strlen, vsprintf durch sicherere Varianten zu ersetzen, mit denen kein buffer overrun, sei es durch user input oder durch fehlerhafte Programmlogik entstanden, mehr möglich ist. Oder aus der msdn Doku zitiert:

"The advantages of the Strsafe functions include:

• The size of the destination buffer is always provided to the function to ensure that the function does not write past the end of the buffer.
• Buffers are guaranteed to be null-terminated, even if the operation truncates the intended result.
• All functions return an HRESULT, with only one possible success code (S_OK).
• Each function is available in a corresponding character count (cch) or byte count (cb) version.
• Most functions have an extended ("Ex") version available for advanced functionality."

Am Besten finde ich die ...Ex Funktionen, mit denen man beispielsweise in einer Schleife einen Buffer wie mit sprintf und einem Formatstring Stück für Stück befüllen kann und in jedem Schleifendurchlauf bekommt man mit [out]-Variablen das neue Stringende und die restliche Größe des Buffers zurück. Quasi sprintf on steroids!

Weil die Datei erst vor wenigen Jahren entstanden ist, ist sie natuerlich bei VC6 nicht mit in der Grundausstattung. Man muss ein halbwegs neues PlatSDK installiert haben und da ist die Datei dann dabei. Und natürlich gibt es alle Funktionen in ANSI, Unicode und character-set-agnostic Varianten.

So, wir wissen nun nicht nur über das Schisma zwischen AMD64 und IA64 was den Bau von Prozessoren angeht, sondern wir wissen auch, daß es in Form des W2K3 Server SP1 PlatSDK auch frei erhältlich geeignete Entwicklungstools gibt, mit denen man zumindest mal alles für die x64 Plattform übersetzen kann, was auf makefiles basiert. Aber natürlich ist es ein Ding der Unmöglichkeit, sorgsam gepflegte dsw und dsp files von VC6 oder ihre Äquivalente in den neueren Entwicklungsumgebungen gegen makefiles einzutauschen. Glücklicherweise gibt es aber hier Abhilfe in Form eines kaum bekannten Kommandozeilenparameters von Visual Studio, dem switch /useenv. Wird msdev mit diesem Switch gestartet, so übernimmt es für alle Pfade, die unter "Tools"-"Options"-"Directories" angezeigt werden, nicht diejenigen, die es in der Registry findet unter HKEY_CURRENT_USER\Software\Microsoft\Devstudio\6.0\Build System\Components\Platforms\Win32 (x86)\Directories, sondern befüllt diese Werte mit den Werten aus den Environmentvariablen %INCLUDE%, %LIB% usw.

Das bedeutet, um mit Visual Studio 6.0 komfortabel ein x64 Binary erstellen zu können, muss man eigentlich nur aus einer der Buildkonsolen des PlatSDKs folgendes aufrufen:

msdev /useenv

denn die Buildkonsolen des PlatSDK bringen die korrekten Environmentvariablen für das jeweilige Buildtarget mit. Diese Konsolen rufen beim Start zu diesem Zweck die Batchdatei setenv.cmd in der Root der PlatSDK-Installation mit entsprechenden Parametern für das jeweilige Buildtarget auf. Um mir selbst die Sache zu vereinfachen/vereinheitlichen und um auf jedem meiner Rechner (wo überall das PlatSDK irgendwo anders im Filesystem liegt) den Start von msdev für x64 als Target zu gestatten, habe ich meine PlatSDK-Installation jeweils für "Authenticated Users" als Share "platsdk$" freigegeben. Die Datei msdev.exe ist eh auf jeder meiner Maschinen über den Suchpfad startbar, sodass ich zum Starten einer x64 Entwicklungsumgebung nur ein einheitliches batch file aufrufe (das natürlich auch in mein cvs eingecheckt ist) mit folgendem Inhalt:

call \\127.0.0.1\platsdk$\setenv.cmd /X64 /DEBUG
start msdev /useenv

Und voilá, ich kann aus dieser VC6-Devstudio Instanz für x64 builden. Voraussetzung ist allerdings für das Ganze, daß man ein aktuelles Service Pack für VC6 installiert hat (out-of-the-box mit VC6 Golden Code geht das nicht) und man muss schon mindestens einmal seit der VC6-Installation auch den msdev gestartet haben (lazy programming bei MS?).

So, wir können jetzt also schon mal builden aus Devstudio heraus, aber sobald man das für ein bestehendes x86-Projekt tut, hagelt es natürlich Fehlermeldungen von Compiler und Linker wie nix Gutes. Was man zu tun hat um zu einem sauberen x64 Build zu kommen, ausgehend von einem funktionierenden x86-Build, darüber schreibe ich dann das nächste Mal.