◆x64の活用
安心してx64に移行するためのポイント
これまで説明したように，x64 Editionは既存の32ビット環境と高い互換性を備え，移行するメリットが多い。だが，32ビット・アプリケーションとの互換性が高いとはいえ，注意すべき点がいくつかある。
ここではWindows上で動作する，ネイティブ・アプリケーションと.NETアプリケーションの2つについて，ユーザーあるいは開発者として注意すべき点を説明する。これらの点さえ押さえておけば，x64 Editionへの移行はスムーズに行くはずだ。
必ず64ビットデバイス・ドライバが必要
32ビットWindowsからx64 Editionに移行するに当たって，最も大きな障害になるのがデバイス・ドライバである。x64 Editionでは，32ビットのドライバは使えないからだ。必ず64ビット版を使用する必要がある。
x64 EditionのインストールCDには，相当する32ビットWindowsのインストールCDと同じデバイス用の64ビット・ドライバが含まれる予定だ。ただ，プリンタ・ドライバのように，機器の性能を100％引き出すためにメーカー製のドライバが必要な機器もある。また，比較的新しい機器については，WindowsのインストールCDにはドライバが含まれていないこともある。
まず，GUI環境であるWindowsを利用するのに不可欠なグラフィックス・ドライバが重要だ。市場シェアの大きいATI Technologies，NVIDIA，S3（VIA Technologies）の各社は，x64 Edition用の64ビット・ドライバを既にWebサイトで配布している。これらのメーカー製のグラフィックス・コントローラを利用するならば問題ないはずだ（図16[拡大表示]）。
次に重要なのはネットワーク・カードのドライバだ。これについては，x64 EditionのインストールCDに，Intel製やVIA Technologies製，Realtek製など主要なコントローラ向けのドライバが標準で用意されている。大方は問題ないだろう。もしも使用しているネットワーク・カードのドライバがx64 EditionのインストールCDに入っていなくても，今ではネットワーク・カードは安く買えるので，新しいものに買い換えるのも1つの手だ。
問題はプリンタである。Windows XP Professional x64 Editionには，いくつかのプリンタ・ドライバが標準で含まれていた。ただし，それらは比較的古い機種向けのもので，おおむね最近3年以内に出た機種のドライバはないと考えた方がよい。実際，日経Windowsプロ編集部で日常的に使用しているセイコーエプソンのLP-8900（2002年1月発売）用ドライバはなかった。ただし，各メーカーとも，x64 Editionの正式出荷後には対応ドライバを配布する見込みである。
そのほかのデバイスに関しても，64ビットへの移行に際しては，使用しているハードウエアに対応した64ビット・ドライバが用意されていることを必ず確認する必要がある。
実装されていないサブシステムがある
x64 Editionでは，既存の32ビット・アプリケーションがそのまま動作する。だが，32ビットWindowsで動作したすべてのアプリケーションが動作するかというと，そうではない。32ビットWindowsには実装されているのに，x64 Editionに実装されていないサブシステム＊があるからだ。
x64 Editionには，OS/2サブシステム，POSIX＊サブシステム，WOW（Win16サブシステム）が実装されていない。OS/2サブシステムやPOSIXサブシステムを利用したアプリケーションはほとんどないので，これらが実装されていなくても，問題になることはほとんどないだろう。それに比べて16ビット・アプリケーションが動作しない影響は少なからずある。
まず比較的多いのが，インストーラに16ビット・アプリケーションを利用しているものだ。アプリケーション自体は32ビットでも，インストーラが16ビットだと，インストールできないのでx64 Editionでは動かせない（一部の16ビット・インストーラには対応している）。もしも，独自に開発したアプリケーションの中に16ビットのインストーラを利用しているものが残っているようならば，早いうちに32ビット・インストーラに切り替えるべきである。
同様に，MS-DOS用のアプリケーションは動作しない。アーカイバやテキスト・エディタに，手になじんだMS-DOS用のアプリケーションを使い続けているユーザーは注意が必要だ。コマンド・プロンプトは用意されているが，16ビットのMS-DOS用アプリケーションは動作しない（図17[拡大表示]）。
独自開発したMS-DOSプログラムのソース・コードが残っていれば，32ビットまたは64ビットのコンソール・プログラムとして再コンパイルすれば動作する。今すぐ手に入るx64対応の64ビット・コンパイラには，Intel C++ Compiler 8.1がある。2005年後末に出荷開始予定のVisual Studio 2005にも，標準でx64用の64ビット・コンパイラが含まれる。
ただし，これらのコンパイラは，64ビット・モードではインライン・アセンブラに対応していない。アセンブリ言語でコーディングするには，別のファイルにして64ビット版MASM（Visual Studio 2005に付属）でアセンブルした後，リンクする。その際，メモリー・モデルや，関数に対する引数の受け渡し規則に注意が必要である。64ビットWindowsでは，第4引数まではレジスタで渡し，第5引数以降をスタックで渡す。
64ビットから32ビットを呼び出せない
64ビットWindowsでは，32ビット・アプリケーションと64ビット・アプリケーションが同時に動作するが，DLLの呼び出しに制限がある。64ビット・アプリケーションが呼び出せるDLLは64ビット版のみで，32ビット版DLLは呼び出せない。逆に，32ビット・アプリケーションが呼び出せるのは32ビットDLLだけで，64ビットDLLを呼び出せない（いずれもインプロセスDLLの場合）。
このことは，特にInternet Explorer（IE）でActiveXコントロールを使ったページを閲覧するときに注意が必要だ。例えばWindows Updateのページなどである。既に述べたように，x64 Editionには，32ビット版と64ビット版の2つのIEが含まれている。だが，ActiveXコントロールは今のところ32ビット版しかない。64ビットIEでは，ActiveXコントロールを利用するWebページを開けない（図18[拡大表示]）。ただしWindows Updateの場合は，32ビット版IEで同じページを開き直すので，問題はないだろう。
また，64ビット・アプリケーションを独自開発する場合は，32ビット版DLLを呼び出せない。既存のアプリケーションのソース・コードを基に64ビット化する場合は注意が必要だ。DLLも独自開発のものならば，DLLを64ビット化すれば済む。だが，DLLが他社製の場合は，それを64ビット化するのは難しい場合があるだろう。
そのようなときは，ローカル・プロシージャ・コール＊を利用する方法が採れる。64ビット・アプリケーションと32ビット・アプリケーションは，ローカル・プロシージャ・コールで通信できる（図19[拡大表示]）。32ビットDLLを呼び出すラッパー・アプリケーションを作り，64ビット・アプリケーションからはラッパー・アプリケーションを介して32ビットDLLの機能を使うようにする。
