虚拟化 频道

虚拟环境中使应用程序与Windows 7兼容

  应用程序与 Microsoft App-V 一起打包时,如何解决运行时兼容性问题?

  还记得支持声明中诱人的说法吗?“App-V 将支持应用程序使用填充程序(这些填充程序是作为 Microsoft 的应用程序兼容性工具的组成部分提供的)....”实际上如何去实现这一点?这两种程序是否基本上兼容?

  令人高兴的是,答案是肯定的。事实上,可以通过几种不同的方式做到这一点。

  填充程序简要介绍

  对于不熟悉填充程序的人来说,填充程序是 Microsoft 很少使用的四字母单词之一,它不是某种缩写词。它以英语单词“shim”(垫片)进行比喻,这是一个工程术语,用于描述插在两个物体之间,使它们更好地配合在一起的木片或金属片。在我们的特定环境下,两个物体就是应用程序和 Windows,而垫片材料是使两者更好地一起发挥作用的附加代码,如图 1 和 2 所示。

如何解决运行时兼容性问题?

  图 1 应用填充程序之前,应用程序与 Windows 直接交互。

如何解决运行时兼容性问题?

  图 2 应用填充程序之后,应用程序与 Windows 间接交互;填充程序代码注入后,它可以修改向 Windows 发出的请求和/或来自 Windows 的响应。

  填充程序的作用是通过 API 侦听实现的。Windows API 是使用 DLL 集合实现的。每个针对 Windows 构建的应用程序都导入这些 DLL,并在内存中维护一个由所有这些功能的地址构成的表。因为 Windows 功能的地址位于一个表中,所以,填充程序引擎直接用填充程序 DLL 的地址替换该地址。应用程序通常不知道要将请求发送到填充程序 DLL 而不是发送到 Windows 本身,Windows 也不知道请求是来自应用程序以外的源(因为填充程序 DLL 只不过是应用程序进程内的另一个 DLL)。

  例如,一个十分常用的填充程序是版本欺骗填充程序。为了实现此填充程序,将侦听几个用于确定运行应用程序的 Windows 版本的 API。通常,这种信息将传递给 Windows 本身,后者会如实应答。但在应用填充程序之后,这些 API 将被侦听。这样,将返回一个不同的 Windows 版本(例如,Windows XP 而不是 Windows 7),而不是将请求传递给 Windows。如果应用程序编写为只在 Windows XP 上运行,这样可以骗过应用程序,使它认为自己正在正确的操作系统上运行。(通常,这样就可以解决应用程序兼容性问题!)

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

  ForceAdminAccess 填充程序尝试使应用程序确信当前用户是本地管理员组的成员,即使他并不是该组成员。(如果您不是本地管理员,很多应用程序会彻底失败,不过,您可以使用其他一些技巧(如 UAC 文件和注册表虚拟化)来解决初始检查所引起的问题。)实现这种检查的方法可以非常简单。例如,此填充程序从 shell32.dll 侦听 API IsUserAnAdmin。所填充的功能的完整源代码(与实际 API 相比,具有极好的性能特性)只返回 TRUE。

  WrpMitigation 填充程序使应用程序安装程序相信,它们可以写入受 Windows 资源保护 (WRP) 功能保护的文件。如果尝试写入受保护的文件,该填充程序首先创建一个新的临时文件,一旦句柄关闭就将其标记为已删除,然后将句柄返回到该临时文件,就好像它是实际受保护的文件。应用程序将旧版本 kernel32.dll 或 shell32.dll(或者在将其打包时它所选择的任何其他文件)安装到临时文件中,但随后该临时文件消失,受保护文件的经过修补的最新匹配版本保留在文件系统中。这样,WRP 仍可确保您不会在自己的计算机上最终得到来自 Windows 95 的旧版本 shell32.dll,但在使用此填充程序时,安装程序不会因 ACCESS_DENIED 而失败。

  CorrectFilePaths 填充程序可将文件从一个位置重定向到另一个位置。因此,如果应用程序尝试写入 c:\myprogramdir(不会使用 UAC 文件和注册表虚拟化对它进行自动修复),则可以将在运行时修改的文件重定向到基于每个用户的位置。这样,您可以以标准用户的身份运行而不必放宽访问控制列表 (ACL) 限制,因为您知道,安全人员不愿意放宽 ACL。

  有数百个通用填充程序可用来解决应用程序兼容性问题,利用这些修补程序可节省大量的成本。例如,客户常常在以下情况下使用填充程序:

  供应商已停止经营,因此无法获得更新版本。如果您无法承担从新供应商处获得另外的应用程序或自己构建新版本的费用,这样可以为您争取一些时间。

  应用程序不是十分重要,不值得投资于更新版本(伴随着支持声明),但您的用户乐于使用它,所以您不介意他们是否运行不受支持的版本。

  应用程序是内部开发的,但您不想非要等到团队发布完全更新的版本。相反,您愿意采用临时性修补程序,允许开发团队在应用程序的下一次计划发布时发布永久性修补程序。通过这种方法,就不再需要停止所有应用程序开发活动,可以投入时间和资源来修复兼容性 Bug。您可以使用临时性修补程序,并允许团队发布包含开发过程中已实现的新功能的修补程序。

  利用填充程序解决应用程序兼容性问题,可以显著节省成本,大大加速 Windows 7 的部署。

看更多TechNet精彩文章

0
相关文章