完全支持 Windows 7 的 Microsoft Application Virtualization (App-V) 4.6 即將發(fā)布；很多計劃部署 Windows 7 的客戶都將 App-V 納入為他們的桌面轉換項目的組件。（操作系統(tǒng)部署常常會使“最新桌面”或“下一代桌面”計劃中的應用程序和基礎結構發(fā)生重大改變。）

當 IT 專業(yè)人員考慮同時對 App-V 和 Windows 7 進行投資時，幾乎總會提出以下問題：

◇ 聽說 App-V 是一個應用程序兼容性解決方案。這是否意味著它可以幫助我的應用程序與 Windows 7 兼容？

◇ 我是否需要對已為當前的 Windows XP 桌面創(chuàng)建的 App-V 程序包重新排序？

◇ 將 App-V 用作部署解決方案時，我該怎么做才能解決不兼容應用程序問題？

下面開始逐個探討這些問題。

Microsoft App-V 是不是應用程序兼容性解決方案？

Microsoft App-V 首先是應用程序管理和部署解決方案，它可為企業(yè)帶來明顯好處：降低打包成本，提高系統(tǒng)穩(wěn)定性，通過動態(tài)訪問軟件資產為現(xiàn)在移動性很高的工作人員提供支持。但是，在營銷宣傳中，人們過多使用了應用程序兼容性這個術語，隨著時間的推移，該術語已被曲解為：App-V 可幫助解決應用程序與操作系統(tǒng)之間的兼容性問題。大多數(shù)情況下，它是無法解決這些問題的。（現(xiàn)在的例外情況主要是歷史原因造成的，不應夸大它的作用，因此，我在此不進行詳細介紹。）

對于客戶因此產生的混淆，我們在措辭上進行了一定的澄清；我們現(xiàn)在已不使用“應用程序兼容性”這個術語，而是直接談及基本優(yōu)點：可以減少應用程序之間的沖突（請注意，我們有意避開了“兼容性”這個詞），因此，可以顯著減少回歸測試。

產品團隊對應用程序與操作系統(tǒng)兼容性的官方觀點如下：

從以前的討論可知，App-V 不是通用的應用程序與操作系統(tǒng)兼容性解決方案；不過，如果應用程序兼容性填充程序允許某個應用程序以本機方式（非虛擬化）在給定 Windows 版本上運行，則在大多數(shù)情況下，對于大多數(shù)填充程序而言，該應用程序將在對填充的應用程序虛擬化之后與 App-V 一起運行。因此，一般而言，只要填充的應用程序能夠以本機方式在目標操作系統(tǒng)版本上運行，App-V 就支持應用程序使用填充程序（這些填充程序是作為 Microsoft 的應用程序兼容性工具的組成部分提供的）。

因此，很顯然，App-V 無意作為應用程序與操作系統(tǒng)兼容性解決方案。（我們將在本文后面部分討論如何將填充程序與 App-V 結合起來。）讓我們看一看應用程序虛擬化對操作系統(tǒng)兼容性產生的其他影響。

#p#

Microsoft App-V 是不是程序包兼容性解決方案？

當我們談及應用程序兼容性時，自然要將程序包兼容性與運行時兼容性區(qū)分開。事實上，我們所建議的應用程序兼容性測試過程（如我在 2009 年 6 月的規(guī)劃您的應用程序兼容性項目文章中的圖 3 所示）將安裝測試與運行時測試區(qū)分開。讓我們從產品團隊官方指南開始：

通常，可以在一個操作系統(tǒng)上排序，然后在另一個操作系統(tǒng)上運行虛擬化應用程序；但是，這種方案既取決于應用程序，也取決于操作系統(tǒng)，未必適用于所有應用程序/操作系統(tǒng)組合，因為 App-V 不是通用的操作系統(tǒng)兼容性解決方案。如果遇到問題，客戶可能需要在運行 App-V 客戶端的操作系統(tǒng)環(huán)境中進行排序，以便解決這些問題。

這聽起來并不怎么樣，官方觀點基本上是“視情況而定”。但是，當您要考慮衡量風險時，請比較現(xiàn)在所使用的三種基本安裝技術：

Setup.exe：這種方式將運行任意代碼，從而該任意代碼將與應用程序本身的任意代碼面臨相同的潛在運行時問題，因此必須徹底進行測試。

Windows Installer：這種方式也運行代碼來執(zhí)行安裝，但所運行的代碼大部分是結構化的聲明代碼。只有自定義操作的命令性代碼是任意的，因此，除了規(guī)則中的可量化變化之外（這些規(guī)則會影響針對數(shù)據(jù)庫運行的代碼以及自定義操作中的任意代碼的處理），有望獲得更好（不過仍不完美）的兼容性，需要的測試也會更少。

Microsoft App-V：這種方法根本不必運行代碼。它只是在一個作為虛擬文件系統(tǒng)的數(shù)據(jù) Blob 上進行復制，然后說“好的，您的虛擬文件系統(tǒng)在這里。”這樣，您主要關注的問題不是應用程序是否會安裝（復制一個數(shù)據(jù) Blob 畢竟真的很容易），而是應用程序的運行時兼容性。因此，在所有三種技術中，這種方式的安裝測試是最短的。那真是太好了！

因此，盡管沒有官方說法表示程序包會全部正常運行，但這種信息流傳開來的主要原因似乎是，很多人都將安裝問題與運行時問題混為一談。一般而言，如果投資于 Microsoft App-V，就有望大大降低應用程序安裝測試的預計成本。

#p#

應用程序與 Microsoft App-V 一起打包時，如何解決運行時兼容性問題？

還記得支持聲明中誘人的說法嗎？“App-V 將支持應用程序使用填充程序（這些填充程序是作為 Microsoft 的應用程序兼容性工具的組成部分提供的）....”實際上如何去實現(xiàn)這一點？這兩種程序是否基本上兼容？

令人高興的是，答案是肯定的。事實上，可以通過幾種不同的方式做到這一點。

填充程序簡要介紹

對于不熟悉填充程序的人來說，填充程序是 Microsoft 很少使用的四字母單詞之一，它不是某種縮寫詞。它以英語單詞“shim”（墊片）進行比喻，這是一個工程術語，用于描述插在兩個物體之間，使它們更好地配合在一起的木片或金屬片。在我們的特定環(huán)境下，兩個物體就是應用程序和 Windows，而墊片材料是使兩者更好地一起發(fā)揮作用的附加代碼，如圖 1 和 2 所示。
 

圖 1 應用填充程序之前，應用程序與 Windows 直接交互。

圖 2 應用填充程序之后，應用程序與 Windows 間接交互；填充程序代碼注入后，它可以修改向 Windows 發(fā)出的請求和/或來自 Windows 的響應。

填充程序的作用是通過 API 偵聽實現(xiàn)的。Windows API 是使用 DLL 集合實現(xiàn)的。每個針對 Windows 構建的應用程序都導入這些 DLL，并在內存中維護一個由所有這些功能的地址構成的表。因為 Windows 功能的地址位于一個表中，所以，填充程序引擎直接用填充程序 DLL 的地址替換該地址。應用程序通常不知道要將請求發(fā)送到填充程序 DLL 而不是發(fā)送到 Windows 本身，Windows 也不知道請求是來自應用程序以外的源（因為填充程序 DLL 只不過是應用程序進程內的另一個 DLL）。

例如，一個十分常用的填充程序是版本欺騙填充程序。為了實現(xiàn)此填充程序，將偵聽幾個用于確定運行應用程序的 Windows 版本的 API。通常，這種信息將傳遞給 Windows 本身，后者會如實應答。但在應用填充程序之后，這些 API 將被偵聽。這樣，將返回一個不同的 Windows 版本（例如，Windows XP 而不是 Windows 7），而不是將請求傳遞給 Windows。如果應用程序編寫為只在 Windows XP 上運行，這樣可以騙過應用程序，使它認為自己正在正確的操作系統(tǒng)上運行。（通常，這樣就可以解決應用程序兼容性問題?。?/p>

使用填充程序，可以采用很多技巧。例如， 

◇ ForceAdminAccess 填充程序嘗試使應用程序確信當前用戶是本地管理員組的成員，即使他并不是該組成員。（如果您不是本地管理員，很多應用程序會徹底失敗，不過，您可以使用其他一些技巧（如 UAC 文件和注冊表虛擬化）來解決初始檢查所引起的問題。）實現(xiàn)這種檢查的方法可以非常簡單。例如，此填充程序從 shell32.dll 偵聽 API IsUserAnAdmin。所填充的功能的完整源代碼（與實際 API 相比，具有極好的性能特性）只返回 TRUE。

◇ WrpMitigation 填充程序使應用程序安裝程序相信，它們可以寫入受 Windows 資源保護 (WRP) 功能保護的文件。如果嘗試寫入受保護的文件，該填充程序首先創(chuàng)建一個新的臨時文件，一旦句柄關閉就將其標記為已刪除，然后將句柄返回到該臨時文件，就好像它是實際受保護的文件。應用程序將舊版本 kernel32.dll 或 shell32.dll（或者在將其打包時它所選擇的任何其他文件）安裝到臨時文件中，但隨后該臨時文件消失，受保護文件的經過修補的最新匹配版本保留在文件系統(tǒng)中。這樣，WRP 仍可確保您不會在自己的計算機上最終得到來自 Windows 95 的舊版本 shell32.dll，但在使用此填充程序時，安裝程序不會因 ACCESS_DENIED 而失敗。

◇ CorrectFilePaths 填充程序可將文件從一個位置重定向到另一個位置。因此，如果應用程序嘗試寫入 c:\myprogramdir（不會使用 UAC 文件和注冊表虛擬化對它進行自動修復），則可以將在運行時修改的文件重定向到基于每個用戶的位置。這樣，您可以以標準用戶的身份運行而不必放寬訪問控制列表 (ACL) 限制，因為您知道，安全人員不愿意放寬 ACL。

◇ 有數(shù)百個通用填充程序可用來解決應用程序兼容性問題，利用這些修補程序可節(jié)省大量的成本。例如，客戶常常在以下情況下使用填充程序：

◇ 供應商已停止經營，因此無法獲得更新版本。如果您無法承擔從新供應商處獲得另外的應用程序或自己構建新版本的費用，這樣可以為您爭取一些時間。

◇ 應用程序不是十分重要，不值得投資于更新版本（伴隨著支持聲明），但您的用戶樂于使用它，所以您不介意他們是否運行不受支持的版本。

◇ 應用程序是內部開發(fā)的，但您不想非要等到團隊發(fā)布完全更新的版本。相反，您愿意采用臨時性修補程序，允許開發(fā)團隊在應用程序的下一次計劃發(fā)布時發(fā)布永久性修補程序。通過這種方法，就不再需要停止所有應用程序開發(fā)活動，可以投入時間和資源來修復兼容性 Bug。您可以使用臨時性修補程序，并允許團隊發(fā)布包含開發(fā)過程中已實現(xiàn)的新功能的修補程序。

利用填充程序解決應用程序兼容性問題，可以顯著節(jié)省成本，大大加速 Windows 7 的部署。

#p#

在企業(yè)環(huán)境中管理填充程序的方法

在我于 2007 年 11 月發(fā)表的在企業(yè)環(huán)境中管理填充程序白皮書中，概括了在決定如何在組織中將填充程序作為應用程序兼容性解決方案進行管理時，大多數(shù)人會選擇的兩種主要方式。簡單地說，它們是：

集中管理的單個填充程序數(shù)據(jù)庫 通過這種方式，可以部署集中管理的單個填充程序數(shù)據(jù)庫，這種數(shù)據(jù)庫包含所有需要使用填充程序的應用程序的條目。這之后，發(fā)現(xiàn)其他應用程序需要使用修補程序時，可向中央數(shù)據(jù)庫推出更新。這就是 Microsoft 所使用的方法。在發(fā)布 Windows 7 時，我們提供了一個系統(tǒng)填充程序數(shù)據(jù)庫，它可以對數(shù)千個應用程序進行修復，在我們發(fā)現(xiàn)其他需要修復的應用程序時，則通過 Windows Update 向該數(shù)據(jù)庫發(fā)布更新。您也可以這樣做：將一個填充數(shù)據(jù)庫放到主映像中，通過系統(tǒng)管理軟件（如 System Center Configuration Manager）進行更新。

基于每個應用程序的填充程序數(shù)據(jù)庫 另外，您也可以直接向應用程序部署應用程序修補程序。如果只有一兩個應用程序需要修補程序，某些客戶會選擇這種方式，因為在小型環(huán)境中，與設置一個用于管理中央數(shù)據(jù)庫的進程相比，這種方式成本更低。基于每個應用程序的填充程序數(shù)據(jù)庫的一個明顯缺點是，如果存在問題，更新填充程序數(shù)據(jù)庫將會很困難。不過，App-V 沒有這個缺點，現(xiàn)在，您可以對基于每個應用程序的數(shù)據(jù)庫進行更新，然后將更新后的版本傳送給用戶。（不過，您將會看到，這引入了另外一個更加明顯的缺點。）

Microsoft App-V 的軟件部署方法拓寬了在企業(yè)范圍內部署應用程序修補程序的選擇，您可以選擇一種最適合組織中現(xiàn)有進程模型的方法。

#p#

使用集中管理的單個填充程序數(shù)據(jù)庫來填充 App-V 應用程序

從策略角度看，要部署集中管理的單個填充程序數(shù)據(jù)庫并由使用 App-V 進行排序的應用程序選擇該數(shù)據(jù)庫，您必須做什么？很簡單，按常規(guī)方法安裝即可！使用 App-V 安裝的應用程序的啟動方式與應用程序的常規(guī)啟動方式大致相同，這種應用程序使用應用了填充程序的加載程序機制。它們只是通過代理進程來啟動。具體地說，sfttray.exe（而不是資源管理器）負責啟動新的進程。因此，進程樹如圖 3 所示。
 

圖 3 代理進程樹

應用程序啟動時，它像任何其他應用程序一樣運行加載程序。Microsoft Application Virtualization 客戶端接口層 (sftintf.dll) 調用 CreateProcessW，后者調用內部的 API CreateProcessInternalW。填充程序引擎是在 CreateProcessInternalW API 中調用的，填充程序與該進程綁定。

那么，這就相當容易了。還有什么問題嗎？是的，有一個。它不能很好地處理提升。例如，您不能簡單地要求對某個應用程序進行提升（使用 RunAsAdmin 填充程序），也不能對需要使用 ElevateCreateProcess 進行提升的應用程序的問題進行修復。為什么呢？原因是氣泡圖。

例如，我們來看一個嘗試自行啟動一次自動更新的應用程序（遺憾的是，這是一個十分常見的任務）。在以本機方式運行時，它產生了一個問題，即它使用了無法調用提升的 CreateProcess API。它隨后返回錯誤 -1073740756 – STATUS_ELEVATION_REQUIRED。ElevateCreateProcess 填充程序捕獲這個返回值，然后調用應用程序信息服務來提供提升。但該服務無法找到要提升的應用程序，因為該服務位于氣泡圖之外！

因此，只要應用程序不需要提升，在已創(chuàng)建一個進程的情況下，部署單個填充程序數(shù)據(jù)庫解決方案就十分容易，您只需繼續(xù)做相同的事情。

#p# 

使用基于每個應用程序的填充程序數(shù)據(jù)庫來填充App-V 應用程序

通過部署填充程序來解決應用程序兼容性問題的另一種方法是隨應用程序部署填充程序。在 MSI 環(huán)境中，通常將 .sdb 文件包括在安裝程序中，然后加入一個自定義操作，該自定義操作針對它所放置的 .sdb 文件調用 sdbinst。這樣，會將自定義填充程序數(shù)據(jù)庫作為安裝程序的一部分來安裝。（如果您隨后需要對該應用程序的填充程序進行更新，則需要找到所有已安裝的客戶端，并運行一個腳本來安裝更新，這會使事情變得有些復雜。）

您可以使用 App-V 完成幾乎相同的工作。您可將填充程序數(shù)據(jù)庫 (.sdb) 文件包括在序列本身之中，這樣 .sdb 文件就位于氣泡圖內。首先，對需要使用填充程序的應用程序進行排序，以便其正常運行。然后，將自定義填充程序數(shù)據(jù)庫放入 system32 中。

（盡管我通常會建議人們絕不要將任何內容放到 system32 中，除非您的工資單是由 Steve Ballmer 簽發(fā)的，并且您的上級包括 Steven Sinofsky；在這種特定情況下，我才會選擇這樣做，因為這樣可簡化腳本編寫，system32 將在您的路徑中，并且不會在生產系統(tǒng)的 system32 中實際留下任何內容，就像是在虛擬文件系統(tǒng)的 system32 中那樣）。

做完這項工作后，我將編輯 .sprj 文件。我瀏覽到“虛擬文件系統(tǒng)”選項卡，然后單擊“視圖”|“虛擬文件系統(tǒng)”|“添加”。然后，我瀏覽到放置 .sdb 文件的位置 (c:\windows\system32\appshim.sdb)，并單擊“確定”。此時，該 .sdb 文件將位于氣泡圖內，并在安裝 softgrid 軟件包時進行安裝。因為該文件是容器的一部分，所以它將作為應用程序的一部分進行傳送（可在更新應用程序時進行更新）。

當然，要使用應用程序修補程序，只是將 .sdb 文件放到文件系統(tǒng)中還不夠，還必須安裝這些修補程序。不過，填充程序數(shù)據(jù)庫必須安裝在 App-V 氣泡圖的外面。如果將填充程序數(shù)據(jù)庫安裝在氣泡圖內，則在創(chuàng)建進程之前，不會發(fā)現(xiàn)虛擬化的 .sdb 文件；創(chuàng)建進程之后，填充程序找到該文件并針對它進行操作已經太晚。您需要使填充程序數(shù)據(jù)庫在創(chuàng)建進程時能夠被氣泡圖外面的加載程序訪問。

令人高興的是，App-V 包含一個將腳本作為應用程序啟動進程的一部分來運行的機制。如果您使用最喜歡的文本編輯器來查看應用程序的 OSD 文件，就會發(fā)現(xiàn)只能對 XML 進行編輯。<SOFTPGK> 元素包含一個 <IMPLEMENTATION> 元素、一個 <DEPENDENCY> 元素、一個 <PACKAGE> 元素、一個 <ABSTRACT> 元素、一個 <MGMT_SHORTCUTLIST> 元素和一個 <MGMT_FILEASSOCIATIONS> 元素。<DEPENDENCY> 元素是您需要編輯的元素，您將添加子 <SCRIPT> 元素，以便安裝自定義填充程序數(shù)據(jù)庫。下面是一個腳本示例，該腳本可在應用程序啟動時安裝自定義填充程序數(shù)據(jù)庫，并在應用程序退出時將其刪除（因此，這是一種可清理其身后內容的 JIT 安裝，是 App-V 的一個重要目標）：
 

通過該腳本，您可從 App-V 氣泡圖的外面調用填充程序數(shù)據(jù)庫安裝程序 (sdbinst.exe)，但要使用位于 App-V 氣泡圖內部的 .sdb 的一個參數(shù)，該 .sdb 隨后將作為應用程序部署序列的一部分進行部署。因此，應用程序修補程序的部署和更新十分容易，就像它們是該應用程序的任何其他部分一樣。

自定義填充程序數(shù)據(jù)庫的安裝過程要求擁有管理員權限；在運行時進行安裝這是否會發(fā)生問題？您不希望您的用戶擁有管理員權限，您的用戶也不希望每次啟動應用程序時都不得不單擊 UAC 對話框。令人高興的是，您無需那樣做；對 sdbinst.exe 的調用會自動提升。安裝填充程序的進程樹如圖 4 所示。

圖 4 填充程序安裝進程樹

將創(chuàng)建一個命令 Shell，該命令 Shell 隨后調用 sdbinst.exe 來安裝自定義填充程序數(shù)據(jù)庫。在調用應用程序信息服務（提供提升的服務）之前，會失敗兩次，其錯誤為 STATUS_ELEVATION_REQUIRED。上述服務調用 consent.exe，后者對策略進行檢查以確定是否應提升應用程序。策略（在虛擬環(huán)境中）返回“是”而無需提示用戶；consent.exe 批準提升，并創(chuàng)建 sdbinst.exe 的一個提升實例，該實例將安裝自定義填充程序數(shù)據(jù)庫。但是請務必注意，不提示就提升的策略只有在您能提升的情況下才會無提示運行。如果您是標準用戶，則每次啟動應用程序都會出現(xiàn)一條需要管理員憑據(jù)的提示，每次關閉應用程序也是如此。因為在標準用戶環(huán)境中人們非常不希望出現(xiàn)這種情況，所以，只有在已部署本地管理員用戶的情況下，這種方法才有效。我們希望只有極少的用戶需要應用這種方法！

#p#

結論

Microsoft Application Virtualization 是一個功能強大的應用程序管理和部署工具。如果在 Windows 7 遷移計劃中使用該工具，有可能降低安裝測試過程中的成本（不過，成本不會降到 0）。

繼續(xù)利用大多數(shù)同樣的過程，還可以使用填充程序解決應用程序兼容性問題。如果要在組織范圍內部署單個填充程序數(shù)據(jù)庫，要進行的轉換任務很少，只需小心避免提升填充程序（與在 App-V 環(huán)境中通常應避免提升的情況大體一樣）。如果要部署基于每個應用程序的填充程序，可以使用一些適當?shù)姆绞絹泶虬筒渴饝贸绦虻奶畛涑绦驍?shù)據(jù)庫，不過，這種情況下，有一個顯著的缺點，即無法合理地以非管理員用戶的身份運行應用程序。因此，強烈建議（就像在基于 MSI 的應用程序部署中那樣）盡量以集中管理的單個數(shù)據(jù)庫的形式部署填充程序，這種情況下，可以使用現(xiàn)有的系統(tǒng)管理軟件進行部署。如果采用這種方式，將來在您的用戶中，以非管理員身份運行的用戶的比重會越來越大。

Chris Jackson（“應用程序兼容性專家”）是 Microsoft 的首席顧問，也是 Windows 應用程序體驗 SWAT 團隊的技術主管。Jackson 是在 Windows 應用程序兼容性領域享有盛名的專家，他根據(jù)多年與企業(yè)客戶和獨立軟件供應商合作的實際經驗，負責創(chuàng)建在 Microsoft 內部和外部使用的技術文檔、培訓和服務項目?？赏ㄟ^ Jackson 的廣受歡迎的博客與他聯(lián)系。

原文地址

本文來源：微軟TechNet中文站