64 bit Windows - Teil 3
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.
Trackback address for this post
5 comments
Und: Das alles setzt voraus, dass man eine geeignete VMWare Version hat, die auch auf 64-bittiger Hardware läuft. Das ist zum einen in der einen oder anderen Firma ein bürokratisches und budgettechnisches Problem, zum anderen natürlich ein Problem des GSX-Server, der der Workstation immer a bissal hinterherhinkt. Wenn vielleicht noch dieses Jahr VMWare 5.5 releast wird, dann dauert es mit Sicherheit ein weiteres Jahr, bis der passende GSX-Server verfügbar ist und ein weiteres bis die Bürokratie gemahlen hat. Und wer weiß ob uns bis dahin das Problem überhaupt noch interessiert...?
Und ich dachte wir bewegen uns hier in einem technischen Abschnitt des Blogs und ging vom optimalen Fall aus (Hardware da und bezahlt, VMware Lizenz beschafft und Guest-OS installiert ;-) ).
Comments are closed for this post.