我有一个现有的应用程序，它有一个广泛的C++模型，我想连接到一个漂亮的现代Windows 7或8 UI。我们应用程序的当前（古老的）用户界面是在早期的Windows XP/95/98时代使用纯Win32 API开发的。我们的代码目前正在通过Visual Studio 2010进行编译/链接。
Windows上似乎有很多不同的API开发"标准"：Win32、MFC、ATL、COM和。NET。在过去的14年里，我的工程师们几乎一直在拖微软的路线：2001年，"MFC死了——我们必须转向ATL"（我们没有）。然后".NET将替换MFC"（它似乎没有）。
因此，现在我们准备转储旧的UI代码。如果能使用一套可靠高效的标准，那就太好了，但我们也可以快速创建UI。抛开QT（我在stackoverflow上读到了很多有争议的优点和缺点）：
1） Windows7&8是使用MFC或。NET？
2） 对于。NET方法（假设有充分的理由选择.NET），我们是否可以将C++模型代码UNMANAGED与。NET应用程序？
3） 即使我们的应用程序最初不是为Metro外观设计的，在Visual Studio 2012中进行开发是否至关重要？
4） 桌面应用程序开发是否需要考虑其他微软工具包？
Stephen
看看我在2011年给出的这个答案。我认为它今天仍然有效；考虑到微软最近重新转向C++，情况可能更糟。我不确定MFC中对win8有多少额外的支持，但如果你没有完全切换到Metro（我想你不会；如果你有一个"产品"，你需要支持旧的Windows至少5年？），那就没那么重要了。
我还没有看到。Net/WPF应用程序，感觉像C++一样"坚固"（是的，我意识到这些在技术上是正交的，但实际上，谁在C++中构建.Net UI？）。我理解为什么人们想要离开MFC；我并不是不了解它的负面影响。IMO，归根结底是：你对快速发展有多重视？对于某些应用程序（业务线、使用寿命短的产品）来说，上市时间和更改速度比"扎实"的设计更重要。对于其他（专业工具、系统软件）来说，创建具有良好用户体验的坚实软件更为重要。我还没有看到在更"现代"的框架中这样做的生产软件（而不是"技术演示"）；MFC（或者我可能应该说"通过C++使用win-api"，但MFC在这方面有足够的能力让积极因素胜过消极因素）应用程序（仍然）（通常）是最好的工具。IMO.
最后要考虑的是你的开发者。如果他们已经为MFC编程15年了，那么他们的职业生涯很可能会陷入困境。如果你坚持要继续使用MFC，你可能会疏远他们。你必须权衡其中的商业风险与技术考虑因素（我从你的问题中得出你是企业主的结论）。如果您愿意私下与我联系进行后续讨论，请随时与我联系。
-
你可以选择任何一种方法。然而NET在用户界面设计中更为常见，如果您需要一个灵活的用户界面，它有很多优点（在更快的开发方面）。
-
是的。C++/CLI可以很好地将本机代码与桥接。NET用户界面。
-
没有。您可以在VS2010中执行此操作。话虽如此，VS 2012确实有很多优点，尤其是在使用C++时。升级可能是有益的。
-
我会看看WPF。新的Windows8用户界面可能很有趣，但可能很难与以前的代码库一起使用。此外，它将无法在较旧的操作系统上工作。根据我的经验，WPF是目前最好的、正在改进的选项（.NET 4.5中有许多改进），它支持将现有的代码库与新的用户界面技术混合使用。
一个非常容易说的解决方案是将整个C++代码移植到。NET的C#或C++／CLI，然后将其与WPF接口。这可能很复杂，但是，您可以完全在中轻松地进行编码。NET（3.5 SP1和Visual Studio 2010首选）。
您还可以将现有代码接口到。NET通过COM Interop使用WPF。COM互操作本质上注册一个。NET组件作为系统中的COM组件。调用CLR时，CLR执行代码执行并编组程序以调用（更多信息-msdn.microsoft.com/en-us/library/zsfww439（v=vs.80）.aspx）。
最后一种方法是转储MFC并直接调用Windows（Win32）API。与其他方法相比，Windows API可以更容易地在代码中使用。在现代Windows API中，GDI+（图形设备接口）是在DirectX（DWM和DXGI）之上实现的，可以通过COM轻松扩展，是WPF和现代UI的一种可行的替代方案。
任何人都不应该创建基于MFC和Win32的新项目。Windows现代用户界面和统一的API是未来。我不这么认为。Net是每个应用程序的答案，尤其是对于具有大量C++本机代码的项目。我们知道微软正在开发统一的API。我希望这就是这个问题的答案。