傳統API的虛擬化與更現代化的API共存？

Question

我不是說這個問題是一個火焰誘餌，但我將使用微軟和他們的win32 API作爲遺留API的一個例子。

現在我想知道的是，微軟在維護其遺留API方面花費了大量資金和精力，其中包括使API功能保持一致所需的所有「毛刺/錯誤/解決方法」。現在我知道，在Windows 7中，他們爲客戶提供了一種在「Windows XP」虛擬機中運行他們的應用程序的方式，這將是他們開始清理win32 API的一種方式，因爲他們可以將所有該應用程序進入「Windows XP」虛擬機。

因此，現在我想知道的是，是否有可能虛擬化遺留的API，使得客戶/程序仍然可以訪問和使用它，但同時能夠利用較新的版本/ API？因爲據我瞭解，如果應用程序運行在「Windows XP」VM中，它將無法訪問任何Windows 7的新API /功能。

Answer 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一起構建WPF解決了這個問題。這隨後帶來了負擔問題。那麼，肯定有兩個API需要維護，但是如果你在WPF之上虛擬化了GDI，那麼你仍然必須維護這兩個API，因此沒有任何好處。並行運行的優點是GDI已經存在並且已經過測試。所有你需要做的就是修復偶爾的錯誤，而新的虛擬化層必須重新編寫和測試，這需要一段時間才能讓WPF變得更好。

就保持揹負而言，這不像聽起來那麼重要。這主要是一個測試問題 - 你必須測試API行爲不會改變，但是再次 - 這些測試已經被寫入，所以它不是真的任何額外的工作。

因此，要回答一個問題，爲什麼他們會打擾？

Answer 2

這是一個有趣的問題，至少對我來說，這是我的一些想法。

您的理解是正確的，運行在XP虛擬機上的應用程序只能訪問虛擬機中XP提供的Win32 API。一，我已經看到微軟的方式，加強特定API的許多方面是與增強/固定功能創建新的功能，並將其命名由追加Ex和甚至ExEx原來的名稱新的功能，例如

GetVersion 
GetVersionEx 

對於接受指向結構的指針的函數，結構通過使用結構的大小來確定所需的功能來進行「版本化」，所以較舊的代碼將傳遞結構的先前大小，而較新的代碼將通過較新的較大結構化和API功能相應。

我猜，這個問題已成爲它不再是如何在API的工作和有變化顯著不夠，可以說是糟糕的代碼的內部結構只是差異，但更完整操作系統的功能被有效打破。

至於你的實際問題，我想這將是相當艱難的。即使有人想過讓操作系統根據可執行文件的PE頭中的目標操作系統版本來調整它如何執行代碼，如果將新的DLL加載到針對最新操作系統的進程中，會發生什麼情況，現在操作系統在代碼執行時處理這個問題？恕我直言，我認爲這將是非常具有挑戰性的，一個陷入最終會失敗的陷阱。

當然，這只是我對這個話題的原始想法，所以我可能100％錯了，有一些簡單的方法，只是沒有想到。