將現有C++代碼移植到Windows 8/Windows Phone 8
英文原文：Porting Existing C++ Code to Windows 8/Windows Phone 8
將 C++ 應用程序向 Windows 8/Windows Phone 8 遷移時，首先要考慮的是用戶界面。幾乎沒有哪個應用的界面能適合以觸摸為中心的 Windows 8 界面。UI 層有四個選項：
- DirectX 與C++
- XAML 與C++
- XAML 與 .NET
- Windows RT 之上的 HTML5 </ul>
因為 UI 需要重寫而非移植，本文不會涉及這些技術。
很多 Win32 和 COM API 直接無法使用了。其他 API 也會受到一些限制，因此即便有的 API 仍然存在，其行為與過去可能也不太一樣。之所以限制這些 API，除安全性之外，還因為它們對電池續航時間有負面影響，或者因為無法匹配新的應用程序生命周期。此外，所有的 GDI 子系統都被禁用。
與傳統的 COM 不同，開發者無法定義自己的跨應用通信協議。而且因為套接字限制，簡單地監聽本地端口也不再有效。這一決策背后的基本理論是“WinRT 應用程序應該是完全隔離的”。這意味著開發者無法一次性安裝一個應用程序集。
開發者可以通過宏 WINAPIFAMILYPARTITION 來獲取編譯錯誤信息，從而確定哪些 API 不再支持。這個過程可能會讓人有點沮喪，比如下面這種情形：如果禁用的 API 調用使用了缺失的結構體，那么缺失結構體的報錯信息會分散開發者的注意力。
微軟的 Tarek Madkour 建議使用 Windows 應用程序驗證工具包（Windows Application Certification Kit）而非宏來遷移現有的庫。我們可以這樣做，創建一個新的基于 XAML 的應用程序，并引用所有要移植的庫。然后運行一次該應用程序以便它部署在計算機上。下一步對應用程序運行驗證工具包，這樣就可以生成需要替換或移除的 API 列表。
這方面還有一個資源：Windows 應用商店應用中 Windows API 的替換選擇（Alternatives to Windows APIs in Windows Store apps）。
線程
WinRT 不支持經典的 CreateThread API 調用。這種功能一般使用 WinRT ThreadPool 類來實現。WinRT ThreadPool 的一個主要缺點是標準的 Windows 應用程序沒有相應支持。下面幾個可選項沒有類似限制。
對于尋求高級抽象的人而言，并行模式庫任務（Parallel Patterns Library Tasks）提供了另一種選擇。
更低層次地訪問可以使用 C++ 的 std::thread 和 std::future。從更廣的角度看，微軟想要在其所有的設備和操作系統上支持標準C++。
最底層的選擇是 VC++ 運行時的 beginthread 函數。根據 Tarek 的說法，它提供了“最強的能力，不過控制不好可能砸到自己的腳”。不過這里請注意：Tarek 的說法與微軟的描述正相反，上面鏈接說不支持該 API。
異步
許多要基于 Windows 8 開發應用程序的C#、VB 和 C++ 開發者應該熟悉新的異步模式與 lambda 表達式語法。
庫的暴露
雖然大部分庫可以直接用 C++ 編寫，但是任何需要暴露給其他語言的部分都應該選擇以C++/CX 編寫的組件的形式。從性能上看，這種方式一般比正常的 C++ 鏈接方式要差，因此 C++ 程序不應使用這樣的庫。
WinRT 應用程序既不支持C也不支C++/CLI。