我并不是说这个问题是一个火焰诱饵，但我将使用Microsoft及其win32 API作为遗留API的一个例子。
现在我想知道的是，微软正在花费大量资金和精力维护他们的遗留API，包括保持API运行所需的所有“故障/错误/解决方法”。现在我知道在Windows 7中，他们为客户提供了一种在“Windows XP”VM中运行应用程序的方法，这将是他们开始清理win32 API的一种方式，因为他们可以推动所有应用程序进入“Windows XP”VM。
所以现在我想知道的是，是否有可能以一种客户/程序仍然可以访问和使用它的方式虚拟化遗留API，同时又能够利用更新的版本/ API ？因为据我所知，如果应用程序在“Windows XP”VM中运行，它将无法访问Windows 7的任何较新的API /功能。
答案 0 :(得分：1)
这是一个有趣的问题，至少在我看来，这是我的一些想法。
您的理解是正确的，在XP VM中运行的应用程序只能访问VM中XP提供的Win32 API。我看到微软增强特定API的方法的众多方法之一是使用增强/固定功能创建新功能，并通过将Ex甚至ExEx附加到原始名称来命名新功能，例如
GetVersion
GetVersionEx
对于接受结构指针的函数，通过使用结构的大小来确定所需的功能，对结构进行“版本化”，因此较旧的代码将传递结构的先前大小，而较新的代码将传递给更新更大的结构和API相应地起作用。
我猜测，问题已经变得不仅仅是API如何工作的差异，而是操作系统和内部结构的功能更加不可或缺，这些结构的变化非常大，可以说是编写得很糟糕的代码实际上已被打破
至于你的实际问题，我想这将是非常艰难的。即使有人想让操作系统根据可执行文件的PE头中的目标操作系统版本调整它执行代码的方式，如果将较新的DLL加载到针对最新操作系统的进程中会发生什么，现在应该如何操作系统代码执行时处理这个？恕我直言，我认为这将是一个非常具有挑战性的问题，其中一个陷阱最终会失败。
当然，这只是我对这个主题的原始想法，所以我可能100％错误，并且有一些简单的方法，但没有想到。
答案 1 :(得分：1)
当问题出现时让我困惑的是，自从九十年代中期NT问世以来，Windows一直在这样做。这就是NT运行DOS和Win16程序的方式，以及它如何运行。 NTVDM虚拟化层在Win32下运行16位应用程序，核心操作系统几乎没有特别支持。这只是一个例子 - 另一个是WINE，根据我的理解，它在一个API集上运行Windows应用程序是一个非常合理的工作，它与windows的非常不同。所以这绝对是可能的。
更为相关的问题是微软会考虑它的原因。为了让你认为有必要，你必须要考虑两件事。 1）使用和更换win32 API有更好的方法.2）维护Win32 API是一种负担。
这两个都值得怀疑。在内核职责的情况下，例如访问硬件和同步以及执行线程，进程和内存，Win32 API做得非常好，并且最终非常接近内核的真正功能。如果您认为有更好的API，那么这必然意味着还有更好的内核。我个人认为NT现在不需要更换。对于图形和窗口，令人钦佩的是gdi32有点长。但是，微软通过将WPF与它一起构建来解决这个问题。这就带来了负担问题。好吧，确定有两个API需要维护，但如果你在WPF之上虚拟化GDI，你仍然必须保持两者，所以没有任何好处。并行运行的优点是GDI已经存在并且已经过测试。您所要做的就是修复偶尔出现的错误，而新的虚拟化层必须重新编写和测试，这需要时间来使WPF更好。
在保持反击的方面，这并不像听起来那么重。它主要是一个测试问题 - 您必须测试API行为不会改变，但是再次 - 这些测试已经编写完成，所以它实际上不是任何额外的工作。
所以，回答一个问题的问题，他们为什么要打扰？