微軟給64位元應用程式開發的建議

微軟寄望Whidbey解決所有問題

為了維持與增進現有應用程式的價值，微軟認為比起重新撰寫應用程式具經濟效益，升級比較具有經濟效益。32位元相容限制

處理程序方面，64位元Windows的遠端程序呼叫（RPC）支援32位元和64位元的處理程序，但是一種位元的處理程序，只能載入同一種DLL，例如64位元處理程序無法載入32位元DLL，因為32位元的DLL會使用4KB的×86頁框，64位元DLL會使用到8KB。不同位元的COM元件與用戶端也不能彼此溝通，例如64位元的用戶端也無法存取32位元的COM元件，反之亦然。

32和64位元的Windows開發環境差距不大，現有的API勢必會有所改變，不過微軟仍企圖以兩種環境、單一程式碼的方式，達到降低開發人員學習曲線的目的。

微軟開發工具的編譯器，已經增加了/WP64的切換參數。編譯器也會提供啟用P64資料模型的選項，假如發生指標截除（pointer truncation）和不適當的資料型態轉換（cast），編譯器會發出警示。由於32和64位元不同的運算環境，資料模型也會不同，64位元Windows將會移除所有的資料型態轉換，或是在整數或長整數的指標變數，利用對應比較的方式，讓編譯器可以接受指定。

驅動程式方面，64位元Windows只接受原生64位元的驅動程式，這些驅動程式也必須支援即插即用（PNP）。DDK的驅動程式模型，將會一直會以Windows 2000的標準為規範。

微軟提供WOW64的技術，以便讓64位元環境能夠執行32位元的應用程式。WOW64不支援處理程序同時包含×86和IA-64程式碼的狀況，處理程序必須各自獨立。少數DLL需要轉換，例如ntdll.dll、user.dll和gdl.dll，其他的DLL可以繼續維持×86 32位元Windows的雙位元形態。32位元DLL之所以能夠相容於64位元Windows，主要是透過WOW64模擬器，從核心記憶體管理員模擬出4KB的頁框得到。不過這種模擬也有一些限制，一部份會真正對應到記憶體的API，像AWE就無法使用；WOW64不支援2GB以上的記憶體存取，既然只是為了提供32位元相容，微軟希望記憶體需求假如超過2GB以上，應該尋求64位元的原生應用程式。

當32位元應用程式想要存取Windows的System32目錄時，WOW64會加以攔截，而64位元應用程式會繼續使用system32目錄。為了能夠同時彙整32和64位元應用程式註冊機碼，WOW 64的「Registry Reflector」將會重新導向系統登錄檔（Registry）的設定，讓這些應用程式與COM元件註冊得以共存。如此一來，32位元應用程式可以繼續沿用先前的登錄檔架構，事實上，64位元Windows會將32位元應用程式登錄另外區分。64位元的.NET Framework

微軟認為在現階段如果想要移轉32位元的應用程式到64位元平臺，最好先衡量自己手上的專案規模，開發人員可以先用64位元的編譯器試著編譯32位元程式碼，區分出程式碼中有哪些是共用的元件或相依元件，並且確認現有程式碼中，哪些是過去前人遺留下來的程式碼或組合語言程式碼。然後可以開始了解64位元環境提供新資料型別和新作業系統不支援的功能。微軟特別強調「單一程式碼不等於測試單一化」。

現有的.NET Framework，包括1.0和1.1都不支援64位元Windows，現在的Visual Studio也沒有支援遠端除錯和跨平臺交叉編譯（cross compilation），開發人員只能用平臺的SDK編譯器和除錯器來工作。

開發人員如果想簡化撰寫程式碼，只能期盼Visual Studio .NET的下一版Whidbey。Whidbey可以在64位元Windows用WOW的方式執行，支援遠端除錯；Whidbey開發出的應用程式可以繼續使用，不需要重新編譯，並且支援IA64和AMD64的處理器，程式碼可以在×86、IA64和AMD64之間相互移轉。Whidbey支援.NET Framework相關的程式語言，如Visual C++、Visual C#、Visual Basic等。

Whidbey預計在2005年上半可以取得，不過這也要看Windows Server 2003 SP1和64位元Windows用戶端作業系統的時程。文⊙李宗翰