Bevor jemand auf die Idee kommt, daß die Serie über 64-bit Windows schon beendet ist, geht's nun weiter. Wir wissen bereits, daß die einzige Hardwareplattform für x64, die mittelfristig weitere Verbreitung finden wird, die AMD64/EM64T-Plattform ist und nicht IA64. Weiterhin wissen wir, daß man aus der Kombination mit aktuellem PlatSDK (das Windows 2003 SP1 PlatSDK) und VC6 eine Entwicklungsumgebung zustande bringt. Was wir noch nicht wissen, ist, was man ändern muß um auch einen sauberen Build für x64 hinzukriegen. Und darum geht es in dieser Folge.

Wir fangen an, indem wir erstmal mit dem Projektwizard aus VC6 ein Projekt erzeugen. VC6 starten wir dazu nicht bereits jetzt wie in der letzten Folge beschrieben aus einer PlatSDK Buildkonsole, sondern starten msdev "ganz normaaaaal" (Roy Makaay) aus dem Startmenü. Wir nehmen auch erstmal kein MFC-Projekt, sondern ein Projekt vom Typ "Win32 Application". Als Untertyp wählenden wir "A typical "Hello World!" application". Was eine typische Hello-World-Application ist, hat sich mir zwar bis zum heutigen Tag noch nicht vollständig erschlossen, aber wie sie ausschaut ist klar: Eine Applikation mit GUI, Messageloop und indirektem (event-driven) Zeichnen in der Client-Area des Applikationsfensters, dazu ein Menü, über das die Applikation beendet werden kann oder eine modale Dialogbox angezeigt werden kann. Wir erzeugen also das Projekt und übersetzen es einmal im Win32 Debug Build, um sicherzugehen, daß das Projekt auch wirklich einwandfrei buildet. Nun beenden wir msdev wieder.

Jetzt starten wir eine PlatSDK Buildconsole. Zu diesem Zweck wählen wir aus dem Startmenü den Eintrag "Microsoft Platform SDK for Windows Server 2003 SP1" -
"Open Build Environment Window" -
"Windows XP 64-bit Build Environment" -
"Set Windows XP x64 Build Environment (Debug)"
worauf sich eine Konsole öffnet. Von hier aus starten wir msdev.exe mit dem Kommandozeilenparameter /useenv. Da drin checken wir zur Sicherheit nochmal ab, ob auch wirklich die korrekten Pfade verwendet werden. Wir wählen zu dem Zweck den Menüpunkt "Tools" - "Options" aus. Der sechste Tab in diesem Property Sheet heißt "Directories". Wenn hier für "Include files" und für "Library files" Pfade aus dem PlatSDK drin stehen, dann paßt alles.

Als erstes fügen wir nun erstmal einmal neue Buildtargets hinzu. Unter "Build" - "Configurations..." fügen wir ein Target "x64 Debug", ausgehend vom Debug Build, und ein Target "x64 Release", ausgehend vom Release Build, hinzu. Dann wechseln wir zum Target "Win32 x64 Debug" und öffnen für unser Projekt die "Project Settings". Unter C/C++ ändern wir erstmal unter "General" die Debug Info von "Program Database for Edit and Contimue" ab auf "Program Database". Als nächstes gehen wir auf die Kategorie "Code Generation" und wählen statt einer single-threaded runtime eine multithreaded runtime. Dann gehen wir in das mehrzeilige Editfeld mit dem Label "Project Options" und editieren. Ja, da drin darf man auch editieren. Wir schmeißen die Option /GX und /GZ raus und ergänzen stattdessen die Optionen /EHsc und /Wp64. Nun gehen wir auf den Linker Tab und die Kategorie "Debug". Dort entfernen wir das Häkchen bei "Separate Types". Schlußendlich gehen wir auch hier in das mehrzeilige Editfeld "Project Options" und ergänzen am Ende (wichtig: AM ENDE!) /machine:AMD64. Nun machen wir einen "Rebuild All" für dieses Target. Wir werden zwei Compilerwarnungen erhalten und Gazillionen von Linkerfehlern vom Typ "unresolved external symbol __security_cookie". Um den Linkerfehler zu beseitigen müssen wir nämlich noch eine lib ergänzen, die man unter x64 praktisch immer für die C-runtme braucht. Zu dem Zweck gehen wir wieder auf die Project Settings und ergänzen im Link-Tab unter der Kategorie "Input" im Feld "Object/library modules" die library bufferoverflowu.lib. Die beiden Warnungen kriegen wir mit einfachen casts zu int weg, sie rühren daher, dass ein WPARAM keine 32-bit mehr breit ist wie ein int und dass strlen einen size_t zurückliefert, der auch keine 32-bit mehr breit ist. All diese Schritte können wir nun auch für den x64 Releasebuild ausführen. Wer bis jetzt gut aufgepaßt hat, wird feststellen, daß ich bisher noch nichts drüber geschrieben habe, daß wir eigentlich auch eine x64-Maschine zum Entwickeln brauchen. Und in der Tat, alles bisher läßt sich auf einer normalen x86-Umgebung durchführen, weil die x64-Compiler des PlatSDKs Cross-Compiler sind und eigentlich x86-Binaries. Aber wenn wir nun einmal unser Binary ausführen oder debuggen wollen, brauchen wir natürlich spätestens jetzt eine Kiste auf der die x64 Edition von XP oder dem W2K3 Server läuft. So, das nächste Mal schauen wir uns an, was es damit auf sich hat, daß ich erstmal kein MFC-Projekt machen wollte und wir schauen uns die Situation an, wo wir VC6 auf einer x64-Edition von XP/W2K3 Server ausführen und unser Binary auf dieser Plattform debuggen wollen.