Weiter geht's! In diesem Teil der Serie will ich darauf eingehen, was es mit meiner anfänglichen Zurückhaltung auf sich hat, was den Einsatz von MFC auf x64 angeht. Ich will außerdem ein Wort über Visual Studio 6 auf x64 verlieren und was über's Debuggen von nativen x64-Anwendungen erzählen.

Doch zu aller erst ein Zitat von Mark Russinovich aus seinem vorletzten Blog Posting was die Zukunft des IA64 angeht:

"...you might have noticed that there?s little support for Itanium, which reflects my belief, and I think that of others, including Microsoft and Dell, that Itanium has a limited future, one only guaranteed so long as there are no 64-way Opteron systems."

OK, jetzt zu dem MFC für x64: Die gute Nachricht ist ja, wie bereits erwähnt, daß mit dem allerneuesten PlatSDK vom Mai 2005 auch MFC libraries shippen, die man auch genauso wie im letzten Beitrag dieser Serie beschrieben, benutzen kann, um auch MFC-Applikationen zu übersetzen. Diese funktionieren auch exakt so wie erwartet, bis auf den ....., tja, hüstel, ... Shared MFC Debug Build und zwar in der ANSI wie in der Unicode-Variante. Wenn man in dieser Buildumgebung Binaries buildet, so erhält man zwar keinen Fehler während des Builds, aber die Binaries laufen schlicht und einfach nicht, sie werden mit einer Fehlermeldung gleich während der Initialisierung beendet. Das gilt sowohl für exe files wie auch für DLLs die man mit diesen beiden Targets buildet. Will man einen shared debug build mit MFC auf x64, bleibt einem daher nichts anderes übrig, als von MS die shared libs für MFC Version 7.1 anzufordern, so wie sie in einer x86-Version mit Visual Studio 2003 mitkommen. Wie das geht, ist beschrieben im KB-Artikel
875446 "How to obtain the 64-bit version of the Visual C++ 7.1 libraries and build tools". Im Prinzip muß man eine Emailadresse bei MS anschreiben und zum Ausdruck bringen, daß man gerne die 7.1er MFC libs für x64 hätte. Dann erhält man Post von denen zurück und muß ein paar Fragen beantworten und eine EULA abnicken. Als nächstes muß man einen ftp-Zugang stellen, wo dann die Kontaktperson bei MS die libs ("SDKAMD64") draufkopiert. Ja, und man darf IIRC keine Produkte shippen die mit diesen libs gemacht wurden.

Wenn man also MFC Code hat, der anders als der von επτ€σ so programmiert ist, daß er mit jeder MFC-Version funktioniert, nicht nur mit der aus VC6, dann kann man für seine Shared MFC Debug Builds einfach die Suchpfade so umstellen, so daß sie auf das SDKAMD64 zeigen.

So und jetzt zum Debuggen. Der in VC6 integrierte Debugger ist ein x86-Debugger und der kann natürlich auf einer x64-Umgebung überhaupt nicht verwendet werden. Glücklicherweise kommen aber mit dem PlatSDK vom Mai 2005 eine aktualisierte Version der Debugging Tools for Windows mit, und damit der WinDbg (sprich: "Wind-Bag") für x64. Mit dem läßt sich sehr komfortabel alles Debuggen, was man an x64 Binaries so erzeugen kann, so daß eigentlich nur der Wechel der Tools ein bißchen lästig ist. Um den Code zu schreiben und zu übersetzen, setzt man also Visual Studio 6 ein, um zu Debuggen nimmt man dann den WinDbg. Was aber wirklich doof ist an der Situation, ist daß man den Debugger von VC6 auch nicht mehr richtig zum Debuggen vonn x86-Prozessen auf einer x64-Maschine verwenden kann, denn sobald man aus dem Debugger heraus seinen Debuggee beendet, der Prozeß sich also nicht selbst beendet hat, lebt der Debuggee als Zombieprozeß weiter. Das sieht zwar erstmal nicht schlimm aus, aber weil der Prozeß weiterlebt, hat man Probleme, wenn man einfach nur im Code des Debuggee was ändern weill und ihn dann neu übersetzen will, denn man kann ja die exe oder DLL nicht überschreiben. Und weil man den Debuggee nur beenden kann, indem man seinen Elternprozeß (also msdev.exe) beendet, muß man devstudio beenden und neu starten, um das Binary des Debuggees neu zu erzeugen. Ziemlich lästig ist das. Ich denke, wenn man auf einer x64-Maschine VC6 benützen will um x86 Binaries zu entwickeln, testen und debuggen, so sollte man das in einer VMWare Session tun tun, die auf dem x64-Host läuft.

So, was ich beim nächsten Mal schreibe muß ich erst noch rausfinden. Folgende Themen sind noch zu beackern:

• Datentypen auf x64
• Wann braucht man überhaupt native Binaries für x64?
• Die Sache mit der File System Redirection und der Registry Redirection
• Häufig gemachte Fehler bei x64 Ports