2010-03-15 75 views
4

是否有任何指導方針如何以儘可能小的痛苦過渡到x64?Windows開發:x86到x64轉換

假設,我有一個用C++編寫的windows本機x86可執行文件。 EXE本身很好地工作,但也有由兩者,即前EXE和外部x64進程託管的DLL。像這樣的設置,我需要重寫哪些部分?

我將不勝感激一個更一般的答案,或者可能是一個給出一些理論背景的參考鏈接。謝謝

回答

3

SDK article列出了64位Windows的注意事項。 MSVC++的具體注意事項是listed here。一般來說,只編譯你的代碼將會消除大部分問題。我不能評論你的具體情況,但不夠詳細。

+0

一個問題是處理指針大小的問題不太可能顯示出來。他們有一個警告,但通常主要是指完美的代碼。 – 2010-03-15 21:03:39

5

一般來說,我建議的方法是單元測試地獄。建立你的測試,以便他們都傳遞32位實現,然後開始在64位上構建和測試。這是值得予以特別的重視,你做任何下面的代碼的任何部分:通過網絡(尤其是類型,如size_t現在將是一個不同的大小

  • 流數據通過這個代碼你去改變之類的東西size_tlong到明確的32或64位的typedef)
  • 加載/保存二進制數據到文件(同上重新:爲size_t /長)
  • 與硬編碼值,如爲0xFFFFFFFF
待辦事項位變換

除了測試儘可能多的代碼路徑之外,確實沒有捷徑。工作的輕鬆程度將取決於代碼的可移植性。您可能是幸運的...

2

我發現清除錯誤的最好方法是審覈您的代碼以執行以下任何操作並將其修復到32位世界中,然後啓動端口。

  • 使用無類型的容器和強制類型而不是正確的容器。
  • 歸檔

的案件時,當你真的需要做的DWORD/PTR的事情使用強制類型存儲指針的DWORD值不管出於什麼原因,通常作爲最終序幕容器

  • 鑄造存儲將類型更改爲DWORD_PTR。

    我見過很多使用CStringToPtr的代碼,而不是使用適當類型的CMap <>。

    所有這些東西都可能在64位上編譯(因爲演員沒有任何警告),然後落在他們的臉上。如果他們使用了正確的類型並且沒有強制轉換,那麼代碼將首次運行。

    此外,檢查任何設置WndProc的子類代碼 - 你需要一個不同的標誌來設置這在64位Windows上。

    如果使用MFC,您也將(無益地)發現容器大小現在返回64位大小計數而不是32位大小計數,這意味着您的32位/ 64位歸檔將被打破。你必須在你走的時候解決這個問題。我們用一些聰明的技巧創建了我們自己的定製MFC實現,以允許我們對64位盒上的32位檔案進行反序列化,反之亦然。