マイクロソフトは22日、都内において64bit対応のWindowsに関する技術説明会である「Microsoft Windows 64-bit Edition Technology Tour 2004」を開催した。内容は開発者を対象とした、64bit版のWindows上で32bit対応のWindowsアプリを動作させる「Windows 32 on Windows 64(WOW64)」の概要や、既存アプリを64bit対応にコンパイルしなおす場合の問題点などについての解説が主な内容となった。

64bit Windowsは開発者・ユーザ共に大きなメリットをもたらす

まず午前中は、64bit版Windowsの概略とロードマップ、アーキテクチャの概要などについての解説が行われた。最初のセッションに登場したMicrosoftのMark Franks氏は、64bit版のWindowsについて「従来に比べると、メモリ空間についての『4GBの壁』がなくなることから、より大きなデータベースをメモリ上に持てるようになるし、その際にも開発には特別なツールは必要なく、従来使用してきた統合環境などの慣れた環境で開発が行える」ことに加え、「NX(No eXecute)スイッチの導入によりバッファオーバーフローなどの問題が発生しにくくなることから、信頼性も大幅に向上するはずだ」と述べ、64bit版のWindowsが開発者に大きなメリットをもたらすことを訴えた。

Mark Franks氏	64bit環境に移行するメリット

その上で実際に64bit版のWindows Server並びにSQL Serverを利用しているユーザの例として、同氏は米航空のJetBlue Airwaysの例を紹介した。同社では頻繁に同社の飛行機を利用する顧客向けの会員サービスシステムを64bit版のWindows Serverなどに移行したところ、それまでに比べて秒間に処理できる最大トランザクションの量が約2倍に増加したそうだ。さらに32bit版で構築した場合は運用に8CPUのサーバが2台必要だと見積もられていたのに対し、64bit版では4CPUのサーバ1台で運用が行えた上、CPU使用率も当初30%を想定していたものが実際には10%で済んでいるという。

JetBlue Airwaysの例

さらに同氏は引き続き64bit版のプロダクトロードマップの紹介に移った。現在のところ64bit版のWindowsはItanium版のみが正式に出荷されている状況だが、x64(AMD64・64ビット拡張技術"EM64T")対応版については今年下半期の出荷予定。また64bitネイティブ版の.NET Frameworkも、正式版の提供は来年上半期となる予定で、「RC1については今年下半期に出す計画」(同氏)とのこと。

同氏はその後現在の市場動向の分析に移り、サーバ市場においては32bit市場でXeon・Opteronなどが急速に普及し「全ての32bitシステムが64bitもサポートするようになる」一方で、64bitではSPARCやPA-RISCなどの市場が縮小し「Itaniumなどのシェアが拡大する」と予測。またユーザ側の64bitシステムへの移行に関する関心もかなり高まってきているとして、早期に64bit版のWindowsへの対応が必要になると参加者に呼びかけていた。

プロダクトロードマップ	このように64bit環境へのユーザの関心は高まってきている

WOW64でできることとできないこと

続いて登場したMicrosoftのClyde M. Rodriguez氏は、冒頭で実際に32bit版と64bit版のWindowsでメモリ確保のデモを行い、32bit版では2GB弱しかメモリが確保できなかったのに対し64bit版では9GB以上のメモリが確保できる様子を参加者に見せ、64bit版の優位性を示した。また同氏は32bit版と64bit版のWindowsのメモリ空間に関する比較の中で「32bit版のWindowsでは1アプリ当たりの仮想メモリ空間は最大でも3GBまでだが、64bit版なら32bitアプリでも1アプリあたり4GBの仮想メモリ空間を確保できる(注:ただし再コンパイルが必要)」と述べ、32bitアプリしか使わない場合でも64bit版のWindowsを利用したほうがよい場合があることを訴えた。

32bit環境でのメモリ確保のデモ	同じデモを64bit環境で行ったところ。これはまだ途中の画面だが最終的には9633MBを確保できた

Clyde M. Rodriguez氏	メモリ空間に関する32bit環境と64bit環境の比較

そこで問題になるのが、どうやって64bit版のWindowsで32bit版アプリを走らせるかだが、ここで使われるのが冒頭でも名前を挙げた「WOW64」。同環境ではほとんどの32bitアプリが動作することになっているのだが、問題は32bitアプリでも中に16bitコードを含んでいるアプリは動かないということ。同氏は「Microsoftの社内でも、32bitアプリの多くは歴史的理由から16bitコードを含んでいることが多いが、そのようなコードは変換が必要になる」と述べ、一部の32bitアプリについてはプログラムの書き直しが必要になる可能性を示した。

そして同氏は実際にWOW64上で32bitアプリを走らせるデモを行った。WOW64では、32bitアプリは通常の「Program Files」ディレクトリではなく「Program Files (x86)」ディレクトリにインストールされるほか、従来「%systemroot%\system32」に収められていた32bitのDLL群は「%systemroot%\syswow64」に収められ、レジストリ位置も変更される。ただしアプリからはこれらの違いは見えないようになっているとのこと。

WOW64環境でのリダイレクトについて	このように64bit版Windowsでは「Program Files」と「Program Files (x86)」の2つのフォルダが存在する

WOW64上でOffice2003のWord(もちろん32bit版)を起動した状態。syswow64にあるDLLが呼び出されているのがわかる

ただWOW64には当然制限もある。先程述べた16bitコードが動かないのはもちろんのこと、32bitと64bitのコンポーネントが同一プロセス空間では共存できないという制限があるため、例えば32bitのインストーラから64bitのDLLをレジストすることは普通のやり方ではできないし(逆も同様)、64bit版のInternet Explorerでは32bit用のActiveXコントロールは利用できない(やはり逆も同様)。ただしOut-of-processコンポーネントとしてであれば、32bitアプリから64bitのクライアントに接続したり、逆に64bitアプリから32bitのコンポーネントを利用したりといったことは可能になっているということで、実際にその様子もデモされた。

WOW64環境でサポートされないもの	WOW64でのCOMコンポーネントの制限

32bit版のクライアントから……	このように64bitのCOMコンポーネントを呼び出すことも可能