最近我正在阅读我们将无法赢得 Windows 8 Metro 风格的文章
运行现有的应用程序
我发现用Windows Runtime (WinRT) 来思考问题更容易。基于 ARM 的 Windows 8 系统将仅支持 WinRT 程序。基于 x86 的 Windows 8 系统能够运行 WinRT 程序和现有的 Win32 程序。
暗示（或者可能是假设？）所有 Metro 风格的应用程序都是 WinRT 应用程序。当然，WinRT 旨在用于构建Metro style applications。我可以想象构建看起来像 Metro 应用程序的传统 Win32 应用程序 - 大方形活动磁贴、延伸到可见桌面左右两侧的应用程序表面等。我不确定这些是否真的会被视为“Metro 风格”应用程序如果它们的构建方式与 Metro 应用程序相同。
现有应用程序不会在基于 ARM 的 Windows 8 系统上运行，也不会在基于 x86 的 Windows 8 系统的非桌面部分中运行。它们将在基于 x86 的 Windows 系统的桌面部分中运行。这是 Visual Studio 运行的地方，也是 PhotoShop 可能运行的地方，也是当前在 Windows 7 上运行的所有程序的运行地方。
这是否意味着 Windows 正在走向杀死 VC++ 或 MFC？
绝对不是。 MFC 应用程序可以在基于 x86 的系统上的 Windows 8 桌面环境中正常运行。 MFC 应用程序将不在基于 ARM 的 Windows 8 系统上运行 - 但是有很多地方 MFC 应用程序无法运行。
对于 VC++，你可以构建 Metro 风格的应用程序using C++，如果你愿意，你只需要遵循 Metro “风格”。
我是否有可能为所有窗口保留相同的代码库
版本？
这取决于“所有 Windows 版本”的含义。今天在基于 Windows 7 x86 的系统上运行的代码明天将在基于 Windows 8 x86 的系统上运行。如果那是您的目标市场，那么您就完成了，您无需更改代码。你唯一不会拥有的是一个活跃的瓷砖。但是您可以使用 Metro 风格 API 构建一个活动磁贴，并在有意义的情况下将其绑定到您的应用程序的逻辑中。
如果您想要支持基于 ARM 的 Windows 8 系统以及基于 x86 的系统，或者如果您希望您的所有程序在基于 x86 的系统上运行时都具有 Metro 的外观和感觉，那么您必须更改您的程序使用 HTML/CSS 或 XAML 和 WinRT API 而不是 MFC 和 Win32 API。
或者，如果您想要两个世界，也许您甚至可以将程序的逻辑与 UI 分离，然后围绕该通用逻辑构建 MFC 皮肤和 Metro 皮肤
我有用于 winsock 和 MFC 的替代 API 吗？
对于网络，您可以在 JavaScript、Visual Basic、C# 和 C++ 中使用 number of classes。要构建 UI，您可以使用 HTML/CSS 或使用 XAML。
或者，如果适合您的需要，您可以继续使用 MFC。您可能永远不会构建一个带有 Multiple Document Interface 和选项卡式 UI 的 Metro 风格应用程序！