Windows 遗留API的虚拟化以及与更现代的API共存？

我并不想让这个问题成为一个火上浇油的诱饵，但我将使用微软及其win32 API作为遗留API的一个示例

现在我想知道的是，微软正在花费大量的金钱和精力来维护他们的遗留API，包括保持API功能不变所需的所有“故障/bug/解决方法”。现在我知道，在Windows 7中，他们为客户提供了一种在“Windows XP”VM中运行应用程序的方法，这将是他们开始清理win32 API的一种方法，因为他们可以将所有应用程序推送到“Windows XP”VM中

---

所以现在我想知道的是，是否有可能以这样的方式虚拟化遗留API，即客户/程序仍然可以访问和使用它，同时能够利用较新的版本/API？因为据我所知，如果应用程序在“Windows XP”虚拟机中运行，它将无法访问Windows 7的任何较新API/功能。

这是一个有趣的问题，至少对我来说，以下是我的一些想法

您的理解是正确的，在XP VM中运行的应用程序只能访问XP在VM中提供的Win32 API。我所看到的微软增强特定API的方法有很多种，其中之一就是创建具有增强/修复功能的新函数，并通过在原始名称后附加Ex甚至ExEx来命名新函数

GetVersion
GetVersionEx

对于接受结构指针的函数，通过使用结构的大小来确定所需的功能，“版本化”结构，因此较旧的代码将传递以前大小的结构，而较新的代码将传递较新的较大结构和相应的API函数

我猜，问题已经变得不再只是API工作方式的差异，而是操作系统的功能和内部结构的整体，这些结构发生了显著的变化，可以说写得不好的代码被有效地破坏了

至于你的实际问题，我想会很难回答。即使有人认为让操作系统根据可执行文件PE头中的目标操作系统版本调整其执行代码的方式，如果将更新的DLL加载到针对最新操作系统的进程中，会发生什么情况，那么当代码执行时，操作系统应如何处理？嗯，我认为这将是非常具有挑战性的，一个充满陷阱的人最终会失败

---

当然，这只是我对这个话题的原始想法，所以我可能100%错了，还有一些简单的方法没有出现在我的脑海中。

当这个问题出现时，让我困惑的是，Windows从90年代中期NT问世以来就一直在这样做。这就是NT运行DOS和Win16程序的方式，也是它一直以来的方式。NTVDM虚拟化层在Win32下运行16位应用程序，核心操作系统很少提供特殊支持。这只是一个例子——另一个例子是WINE，据我所知，WINE在API集上运行windows应用程序非常合理，API集与windows非常不同。所以这绝对是可能的

更重要的问题是微软为什么会考虑这个问题。为了让你认为这是必要的，你必须考虑两件事。1） 有更好的方法取代win32 API，2）维护win32 API是一项负担

这两个问题都值得怀疑。在内核任务的情况下，比如访问硬件、同步和执行线程、进程和内存，Win32 API做得非常好，最终与内核的实际功能非常接近。如果您认为有更好的API，那么这一定意味着也有更好的内核。我个人认为NT现在不需要更换。对于图形和窗口，令人钦佩的是gdi32有点长。但微软通过在其旁边构建WPF解决了这个问题。这就带来了负担问题。当然，有两个API需要维护，但是如果您在WPF之上虚拟化GDI，那么您仍然需要维护这两个API，因此没有任何好处。并行运行两者的优点是GDI已经存在并且已经过测试。您所要做的就是修复偶尔出现的bug，而新的虚拟化层则需要重新编写和测试，这就需要花费时间来改进WPF

就维持背部同胞而言，这并不像听起来那么沉重。这主要是一个测试问题——您必须测试API行为是否没有改变，但同样地——这些测试已经编写好了，因此实际上没有任何额外的工作

---

所以，用一个问题来回答一个问题，他们为什么要费心呢？

当然，.NET是一个隐藏Win32的API层。伙计，我希望我能接受这两个答案，因为他们都以不同且出色的方式回答了我的问题！