一般的な移植ガイドライン

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

計画

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

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

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

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

  注意

  ARM64 バイナリの場合、/LARGEADDRESSAWARE:NO は無視されます。

   

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

  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 ビット アプリケーションを使用できます。

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

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