一般移植指導方針

  • 發行項

將 32 位應用程式移植到 64 位 Microsoft Windows 會比將 16 位應用程式移植到 32 位 Windows 更容易。 不過，移動會更順暢地進行一些仔細規劃。 以下是一些一般指導方針。

規劃

  • 判斷埠所需的工作量。 藉由識別下列專案來量測涉及多少工作：

    • 問題 32 位程式碼。 使用 64 位編譯器編譯 32 位程式碼，並檢查錯誤和警告的範圍。
    • 共用元件或相依性。 判斷應用程式中哪些元件源自其他小組，以及這些小組是否打算開發 64 位版本的程式碼。
    • 舊版或元件程式碼。 16 位 Windows 應用程式不會在 64 位 Windows 上執行，而且必須重寫。 雖然 x86 元件程式碼是在 WOW64 中執行，但您可能想要重寫此程式碼，以利用 Intel Itanium 架構的速度。

  • 移植整個應用程式，而不只是其部分。

    雖然您可以使用 /LARGEADDRESSAWARE：NO 將應用程式片段移植到 2G，或將程式碼限制為 2G，但此策略會利用短期的困難性來交易。

    注意

    ARM64 二進位檔會忽略 /LARGEADDRESSAWARE：NO。

     

  • 尋找不會移植的技術替代專案。

    某些技術，包括 DAO (Data Access Object) 和 Jet Red 資料庫引擎，將不會移植到 64 位 Windows。

  • 將您的 64 位版本視為個別的產品版本。

    即使您的 64 位產品可能會共用與 32 位相同的程式碼基底，但它需要額外的測試，而且可能有其他版本考慮。

部署

  • 立即開始開發符合規範的程式碼。

    開發人員可以使用最新的 Windows 標頭檔與新的資料類型，開始撰寫相容的程式碼，而不會影響 32 位的軟體發展。 如需詳細資訊，請參閱 準備 64 位 Windows。

  • 請確定您的程式碼可以同時針對 32 位和 64 位 Windows 進行編譯。

    新的資料模型的設計目的是要允許從單一程式碼基底建置 32 位和 64 位應用程式，但修改很少。 SQL Server和 Windows 開發小組正從相同的程式碼基底開發 32 位和 64 位版本的產品。

  • 使用編譯器的新優化功能來獲得最佳效能。

    Intel Itanium 處理器的程式碼優化比 x86 更重要。 編譯器假設許多先前由微控制器處理的優化函式。 您可以使用編譯器的兩個新優化功能，將 64 位應用程式的效能最大化： 設定檔引導式優化 和 整個程式優化。 這兩個功能都會產生較長的建置時間，而且需要早期開發良好的測試案例。

    設定檔引導式優化 牽涉到雙步驟編譯器。 在第一次編譯期間，會檢測程式碼以擷取執行行為。 這項資訊會在第二次編譯期間使用，以引導所有優化功能。

    整個程式優化 會分析所有應用程式檔中的程式碼，而不只是單一程式碼。 此方法會以數種方式提升效能，包括更好的內嵌，以及改善的副作用分析和自訂呼叫慣例。

測試

  • 判斷您要測試在 WOW64 中執行的 64 或 32 位程式碼。

    有些應用程式包括原生 64 位程式碼，以及 WOW64 中執行的 32 位程式碼。 在開發測試計劃時仔細調查此情況，並決定是否您的測試控管應該是 64 位、32 位或組合。 您通常需要在 64 位 Windows 上測試應用程式的 64 位和 32 位版本。

  • 測試常用的 32 位元件。

    首先，將您的程式碼重新編譯至 64 位並進行測試。 其次，修正問題、在 32 位中重新編譯，然後進行測試。 第三，重新編譯至 64 位並測試。

  • 測試 COM 和 RPC 元件。

    請確定 32 和 64 位 COM 和 RPC 元件都正確通訊。 您可能也必須透過網路測試與 16 位元件的通訊。

  • 在 64 位 Windows 上測試 32 位版本。

    客戶可以在 64 位 Windows 上繼續使用 32 位應用程式，其中效能和記憶體問題不是主要考慮。

  • 測試不同的記憶體組態。

    在伺服器上新增大量記憶體有時會在應用程式或作業系統中公開先前未察覺的問題。