移植に関する一般的なガイドライン

32 ビット アプリケーションを 64 ビット Microsoft Windows に移植すると、16 ビット アプリケーションを 32 ビット Windowsに移植するよりも簡単になります。 ただし、慎重な計画を立てれば、移動がよりスムーズに進みます。 一般的なガイドラインを次に示します。

計画

• ポートに必要な作業の大きさを決定します。 次の項目を特定して、作業の量を測定します。

  • 問題 32 ビット コード。 64 ビット コンパイラで 32 ビット コードをコンパイルし、エラーと警告の範囲を調べます。
  • 共有コンポーネントまたは依存関係。 アプリケーション内のどのコンポーネントが他のチームからのものか、それらのチームが 64 ビット バージョンのコードを開発する予定かどうかを判断します。
  • レガシ コードまたはアセンブリ コード。 16 ビット Windows ベースのアプリケーションは 64 ビット Windowsで実行されないため、書き換える必要があります。 x86 アセンブリ コードは WOW64 で実行されますが、Intel Itanium アーキテクチャの速度を活用するために、このコードを書き換える必要があります。

• アプリケーションの一部だけでなく、アプリケーション全体を移植します。

  アプリケーションの一部を移植することも、/LARGEADDRESSAWARE:NO を使用してコードを 2G に制限することも可能ですが、この戦略は長期的な痛みのために短期的な利益を交換します。

  Note

  /LARGEADDRESSAWARE:NO は ARM64 バイナリでは無視されます。

   

• 移植されないテクノロジの代わりを見つけます。

  DAO (データ アクセス オブジェクト) や Jet Red データベース エンジンなどの一部のテクノロジは、64 ビット Windowsに移植されません。

• 64 ビット バージョンを個別の製品リリースとして扱います。

  64 ビット製品は 32 ビットと同じコード ベースを共有している場合でも、追加のテストが必要であり、他のリリースに関する考慮事項がある場合があります。

開発

• 今すぐ準拠コードの開発を開始します。

  開発者は、最新のWindows ヘッダー ファイルと新しいデータ型を使用して、32 ビット製品開発に悪影響を及ぼさない準拠コードの記述を開始できます。 詳細については、「64 ビット Windowsの準備」を参照してください。

• コードを 32 ビットと 64 ビットの両方のWindows用にコンパイルできることを確認します。

  新しいデータ モデルは、32 ビットと 64 ビットのアプリケーションを、変更がほとんどない 1 つのコード ベースから構築できるように設計されました。 SQL ServerとWindows開発チームは、同じコード ベースから 32 ビットと 64 ビットバージョンの製品を開発しています。

• 最適なパフォーマンスを得るためのコンパイラの新しい最適化機能を使用します。

  Intel Itanium プロセッサのコード最適化は、x86 よりも重要です。 コンパイラは、以前にマイクロプロセッサによって処理された最適化関数の多くを前提としています。 コンパイラの 2 つの新しい最適化機能 ( プロファイルガイド付き 最適化と プログラム全体の最適化) を使用して、64 ビット アプリケーションのパフォーマンスを最大化できます。 どちらの機能もビルド時間が長くなり、適切なテスト シナリオの早期開発が必要になります。

  プロファイルガイド付き最適化 には、2 段階のコンパイル プロセスが含まれます。 最初のコンパイル時に、実行動作をキャプチャするためにコードがインストルメント化されます。 この情報は、すべての最適化機能をガイドするために、2 回目のコンパイル時に使用されます。

  プログラム全体の最適化 では、1 つのアプリケーション ファイルだけでなく、すべてのアプリケーション ファイル内のコードが分析されます。 この方法では、インライン化の向上や副作用分析やカスタム呼び出し規則の改善など、いくつかの方法でパフォーマンスが向上します。

テスト

• WOW64 で実行されている 64 ビット コードと 32 ビット コードのどちらをテストするかを決定します。

  一部のアプリケーションには、WOW64 で実行されているネイティブ 64 ビット コードと 32 ビット コードの両方が含まれます。 テスト 計画の開発中にこれを詳細に調査し、テスト ツールを 64 ビット、32 ビット、または組み合わせにするかどうかを決定します。 多くの場合、アプリケーションの 64 ビット バージョンと 32 ビット バージョンの両方を 64 ビット Windowsでテストする必要があります。

• よく使用される 32 ビット コンポーネントをテストします。

  まず、コードを 64 ビットに再コンパイルし、テストします。 次に、問題を修正し、32 ビットで再コンパイルしてからテストします。 3 つ目は、64 ビットに再コンパイルしてテストします。

• COM および RPC コンポーネントをテストします。

  32 ビットと 64 ビットの COM コンポーネントと RPC コンポーネントの両方が正しく通信していることを確認します。 また、ネットワーク経由で 16 ビット コンポーネントとの通信をテストする必要がある場合もあります。

• 64 ビット Windowsで 32 ビット バージョンをテストします。

  お客様は、パフォーマンスとメモリの問題が大きな考慮事項ではない 64 ビット Windowsで引き続き 32 ビット アプリケーションを使用できます。

• さまざまなメモリ構成をテストします。

  サーバーに大量のメモリを追加すると、アプリケーションまたはオペレーティング システムで以前に気付かれていない問題が発生することがあります。