CN101048735A - 用于经由上下文策略控制来控制应用程序间关联的系统和方法 - Google Patents

Abstract

用于控制多个软件应用程序和资源的互操作的方法包括，截取从第一应用程序到第二应用程序或资源的通信、将该通信定向至上下文管理系统、生成该通信的上下文候选列表、根据为这些上下文定义的至少一个策略评估候选列表以标识该通信的结果动作和名字空间、以及在所标识的名字空间内如由这些策略所定义地执行该动作。该方法还包括跟踪第二应用程序的一个或多个版本，以及跟踪应用程序和/或资源名的演变。该方法还包括标识与候选列表上的上下文相关联的一个或多个操作，并在进一步通信之前执行所标识的操作。

Description

用于经由上下文策略控制来控制应用程序间关联的系统和方法

相关申请的交叉引用

本申请要求于2004年8月3日提交的美国临时专利申请第60/598,234号的优先权，该申请的整体内容通过引用包含在此。

技术领域

本发明涉及计算机软件，尤其涉及操作系统软件。

背景

在众多环境中，尤其在其中经由网络交付应用程序的环境中，最重要的特征是在无需复杂安装的情况下在进行中(on the fly)运行应用程序的能力。一般在某些现有技术的系统中，花费了大量努力来修改客户机系统以显现如程序被安装一般，或来实际安装软件本身，然后回退这些修改以还原成原始配置。这样做出现了多个问题：应用程序与计算机当前配置之间的冲突、相同或不同应用程序的多个实例、回退过程的复杂性需要应用程序经历严格的过程以确保其所有修改都被考虑到，而多个应用程序对共享文件和系统组件的使用复杂化了回退和安装过程。

在众多应用程序执行环境内，期望隔离应用程序以防止由于交际性(sociability)和版本控制问题引起的系统故障。然而，隔离将会阻止这些程序互操作，除非被配置成这样做。该问题在“虚拟安装”环境中尤其尖锐，软件应用程序借由虚拟安装在操作系统内执行，但实际上未安装在该操作系统(OS)中，或在某些情况中，在进行中被安装并被移除。

发明概述

根据本发明的实施例针对当或者未被设计成应用程序间可通信和关联或者经由默认行为求要附加的系统配置的环境存在时便于应用程序间通信和关联。这些实施例保留系统的原始前提，提供应用程序的运行时隔离，但允许在严格管理和操作策略下的互操作性。

根据本发明的一个方面，用于控制多个软件应用程序和资源的互操作的方法包括，截取从第一应用程序到第二应用程序或资源的通信、将该通信定向至上下文管理系统、生成该通信的上下文候选列表、根据为这些上下文定义的至少一个策略评估候选列表以标识该通信的结果动作和名字空间、以及所标识的名字空间内如由这些策略所定义地执行该动作。该方法还包括跟踪第二应用程序的一个或多个版本，以及跟踪应用程序和/或资源名的演变。该方法还包括标识与候选列表上的上下文相关联的一个或多个操作，并在进一步通信之前执行所标识的操作。候选列表从一个或多个分布式的上下文中生成。这些通信包括进程间通信、操作系统调用、API调用或库调用的至少其中之一。上下文包括全局上下文、受管上下文、本地系统上下文、系统虚拟上下文、厂商上下文、用户上下文、会话上下文、共享上下文或隔离上下文的至少其中之一。策略包括用于标识何时应用策略的匹配助记法(mnemonic)、多个请求相关参数以及用于应用策略的规则的至少其中之一。

根据本发明的另一方面，用于定义将在其它应用程序或资源内执行的应用程序的替换名字空间的方法包括，截取对公用名资源的调用、标识该调用的目标名字空间、将公用名转换成可由该名字空间内的应用程序使用的本地名，以及提供对由该本地名标识的资源的访问。该方法还包括，跟踪应用程序的一个或多个版本，以及跟踪应用程序或资源名的演变。本地名也可被转换成绝对名，使得对由该本地名标识的资源的访问可简化成对由替换名字空间中的不同本地名标识的资源的访问。标识目标名字空间的步骤包括一个或多个分布式查询，其中对目标名字空间的至少一个查询可对跟踪一个或多个系统公用的名字空间的管理系统执行。

根据本发明的另一方面，用于控制多个软件应用程序和资源的互操作的系统包括，生成通信的上下文的候选列表的上下文管理系统、根据为这些上下文定义的至少一个策略评估候选列表并且还标识该通信的结果动作和名字空间的策略引擎、以及将从第一应用程序到第二应用程序或资源的通信定向到上下文管理系统的虚拟环境管理器，该虚拟环境管理器接收指示所标识的名字空间内的如由该至少一个策略定义的结果动作的指令。

本发明提供用于在不改变客户计算机的操作系统的情况下创建应用程序软件环境的系统，该系统包括操作系统抽象和保护层，其中所述抽象和保护层被介入运行的软件应用程序与所述操作系统之间，借此提供了可在其中运行应用程序的虚拟环境，并基本上消除了应用程序级交互。较佳地，对操作系统的任何直接改变在运行的应用程序的上下文内选择性进行，且抽象和保护层根据管理设置动态改变虚拟环境。此外，在某些实施例中，系统不断监视共享系统资源的使用并用作对系统组件应用和移除改变的服务。

因此例如，在基于Windows操作系统且其中对Windows Registry(注册表)的所有操作均经由Win32 API的实施例中，系统较佳地提供用于挂钩函数的手段，借此每次调用所述函数时，另一函数或应用程序将截取调用，且该系统最好挂钩每一合适的API函数以服务于不论是由从服务器运行的应用程序作出的还是由应用程序针对正被积极管理的配置键作出的请求。

通过如其中相同的参考字符指的是所有不同视图中的相同部分的附图中所示，阅读本发明的实施例的以下更具体描述，本发明的前述和其它特征和优点将是显而易见的。

附图简述

图1是示出本发明、操作系统与软件应用程序的相对关系的框图示意图；

图2是示出以私有上下文和服务运行的两个应用程序的框图示意图；

图3是示出两个应用程序运行同时操作系统提供系统资源的共享视图的框图示意图；

图4是示出操作系统防护和子系统的框图示意图；

图5示出了根据本发明的实施例的包括含有一个或多个计算设备的多个系统的示例性主机操作系统，其中整个系统的视图对应于全局上下文；

图6和7示出了根据参考图5示出的示例性系统中的实施例的不同上下文，诸如全局、受管、本地系统、系统虚拟、厂商、用户、会话、共享和隔离上下文；

图8示出了根据本发明的实施例的利用彼此和操作系统的资源的两个应用程序以及这些资源的三个不同的配置文件的框图；

图9示出了根据本发明的实施例的用于确定相关上下文和可用范围的软件核心的框图；

图10示出了根据本发明的实施例的由进程管理器使用的进程树；

图11示出了根据本发明的实施例的包括系统可用上下文表以及上下文之间的关联的上下文管理器的示意图；以及

图12示出了根据本发明的实施例的被附连于另一程序的资源树的资源的示意图。

较佳实施例的详细描述

现在参考图1，示出了显示本发明、操作系统和软件应用程序的相对关系的框图示意图。本发明的较佳实施例提供了名为“操作系统防护”的操作系统抽象和保护层100。众多操作系统10在内部提供断层域(fault domain)以保护应用程序50使其在运行时免于彼此影响。然而，共享的系统资源和众多其它操作系统特征使这种保护域被妥协。操作系统抽象和保护层100将提供应用程序50之间附加的、程序上受控的屏障，以消除大多数应用程序级交互。与将改变包含在运行的应用程序的上下文内相对，部署在应用程序50与操作系统10之间的操作系统抽象和保护层100选择性地允许对操作系统10的直接改变。例如，在基于Windows的系统中，对Windows Registry的所有操作一般经由Win32 APL完成。如下所述，可挂钩如QueryRegEx和GetProfileString的系统函数，使得每次调用它们时，另一函数或应用程序将截取调用。本发明的操作系统防护100将挂钩每一合适的API函数以服务由正被积极管理的应用程序作出或由应用程序针对正被积极管理的配置项作出的请求。以此方式，本发明的实施例可在不对最终用户的系统进行任何实际修改的情况下创建应用程序环境，除非明确配置成这样做。而且，由应用程序在运行时进行的任何修改可被容易地持久化或消除。

如此处所使用的，术语“操作系统防护”定义了运行的应用程序与目标计算机或客户计算机的操作系统之间的提供可供应用程序在其中运行的虚拟环境的层。该虚拟环境具有若干目的。首先，它防止运行的应用程序对客户计算机进行修改。如果应用程序尝试改变客户计算机的底层操作系统设置，则这样的设置将被保护且仅在虚拟环境中“进行”。例如，如果应用程序尝试改变如MSVCRT.DLL的共享对象的版本，则这种改变对该应用程序本地化，且驻留在客户计算机上的代码保持未被改变。

第二，本发明的实施例在不执行安装的情况下向运行的应用程序提供了显现为安装环境的一种环境，因此是“伪安装”或拟安装。所有设置在正被服务的应用程序运行时或当该应用程序需要该特定设置时即时引入虚拟环境内。例如，如果诸如Adobe Photoshop的计算机程序期望看到HKEY_LOCAL_MACHINE\Software\Adobe下的一组Windows Registry条目，且由于Photoshop从未被安装，因此它们不存在于客户计算机上，则根据本发明的这一方面制作的系统将向Photoshop编程代码“显示”这些注册表条目，就如同它们驻留在该客户计算机上一般。

其次，本发明的实施例防止可能存在于客户/用户机器上的信息干扰或修改应用程序的行为。例如，如果用户拥有位于HKEY_LOCAL_MACHINE\Software\Adobe下的Photoshop的旧版本的已存在的注册表条目，但现在想要操作新版本，则这些条目可向新应用程序隐藏以防止冲突。

最后，本发明的实施例解锁当应用程序当前被写时可能不存在的应用程序行为。这是经由根据管理设置来动态改变虚拟环境的能力来进行的。例如，在企业软件应用程序的典型实例中，客户应用程序可能期望从注册表中的设置中读取用户应连接的数据库的地址的设置。因为该注册表键通常存储在HKEY_LOCAL_MACHINE中，因此该设置对整个客户计算机是全局的。用户在不重新安装客户机或了解如何修改该注册表键的情况下仅可连接至一个数据库，且当每次他们想要运行应用程序时都这样做。然而，通过实现本发明，应用程序的两个实例现在可运行在同一客户计算机上，各自连接至不同的数据库。

上下文

提供了这种功能，每一应用程序就能够在系统内的私有上下文中运行。对应用程序而言，它拥有其自己对系统及其行为的视图。本发明的实施例通过固有本质来提供此功能。参考图2，可向两个单独的应用程序52、54，或同一应用程序(图1中所示的50)的两个实例提供其中它们将显现为拥有系统服务、配置和数据的分开或不同的副本的私有上下文。在较佳实施例中，这是系统的默认行为。

通过扩展此概念，本发明的实施例的操作系统防护100也可提供其中两个或多个应用程序52、54可共享其虚拟设置中的某些或全部的共享的、受控的上下文。这对诸如Microsoft Office的应用程序套件或对存在其它应用程序的情况下不同地执行的应用程序而言是重要的。例如，众多应用程序使用Microsoft Word作为进行邮件合并或文档创建功能的引擎。应用程序必须知道Word已安装或存在，且能够接入其功能。在较佳实施例中，同一应用程序的两个实例默认将共享单个上下文，而两个单独的应用程序将维护私有上下文。参考图3，两个应用程序52、54可运行，同时操作系统防护100提供可用系统资源的共享视图。

设计

如图4中所示，操作系统防护由以下子系统组成：核心102、配置管理器104、文件管理器106、共享对象管理器108、设备管理器110、字体管理器112、进程管理器120、进程环境管理器114、加载器116以及恢复管理器118。除核心102、进程管理器120以及加载器116以外，所有其它子系统都是虚拟系统的特征，虚拟系统将在后文中进一步详细描述。核心102主要负责管理应用程序及其如由配置文件定义的上下文。

由操作系统防护提供的进程管理器120允许向核心102通知可能受关注的任何进程或线程事件。也向依赖于操作系统的实现提供抽象层以便管理进程空间和操控线程处理。进程可被分组在一起成为应用程序束(bundle)。应用程序束是全部彼此共享其虚拟资源的一组进程。例如，Microsoft Word和Microsoft Excel可能想要共享虚拟注册表和虚拟文件系统以便能够作为应用程序套件在一起工作。进程管理器120称这些应用程序束为“应用程序”。关于应用程序的信息将一直存在直到进程管理器120被告知释放该应用程序。如果另一进程需要被加载到应用程序束内，则只要该应用程序还未被释放就可以这样做。

本发明的实施例的加载器子系统116被用来允许虚拟环境来被换入或换出运行的系统。虚拟子系统中的每一个能够为加载器116串行化其配置，并经由逆过程检索它。此外，加载器116能够分阶段加载/卸载以及将单个阶段的结果组合成一单一环境描述。

注册表和配置

各应用程序需要不同数量的配置信息以便正确操作。存在0到数千条配置记录以便应用程序读取其配置。在Windows上，存在配置信息的两个公共位置，即Windows Registry和系统级初始化文件win.ini和system.ini。此外，\WINDOWS\SYSTEM目录是供各应用程序写入应用程序专用配置或初始化文件的公共位置。应用程序也可使用其本地应用程序目录中的配置或数据文件来存储附加的配置信息。通常，这些信息难以处理，由于它是专用格式的。在除Windows以外的平台上，不存在Registry的对等物，但存在配置信息的公共目录。X Windows具有应用程序默认的目录。Macintosh具有System Folder(系统文件夹)，而其它操作系统将具有相应的特征。重要地，如图2中可见，注意到在大多数UNIX系统上，每一单独的应用程序52、54通常本地存储其自己的配置62、64。

本发明的实施例包括虚拟Windows Registry组件，它向应用程序提供全功能的注册表，但防止对底层系统注册表的修改。将呈示应用程序期望访问的所有键，但它们仅可存在于虚拟注册表中。以此方式，本发明的操作系统防护100以及Windows Registry形成用于访问注册表的两阶段的过程。如果应用程序需要访问键，则它将查询Registry。操作系统防护将以该键及其值(如果已知)响应。否则，它将允许请求直达Windows Registry。如果尝试修改该值，则操作系统防护将允许修改仅对它自己发生。当下一次应用程序访问该键时，它将被呈示于操作系统防护中，且该请求将不流到真实的Registry，从而保持其不被改变。

操作系统防护使用的键在三个分开的部分中指定。这些操作系统防护键在这些部分中被指定为修改现有键、删除键的呈示、或向注册表添加新键的命令。以此方式，虚拟注册表可恰如系统意图地显现。这是重要的，因为键的呈现与否可与键实际值一样重要。

在实施例中，操作系统防护首先加载包含用于应用程序的基本注册表条目的数据文件。然后加载包含用户偏好的第二数据文件。最后，操作系统防护可任选地加载包括不允许用户覆盖的策略项的一组键。这三个文件逐层向上加载，每一文件中的重复项覆盖其之前文件中的各项。用户首次运行应用程序时，将不存在第二数据文件，因为不存在任何用户专用信息，仅有应用程序默认信息。然而，在每一会话之后，操作系统防护将保存用户的改变，生成供将来会话中使用的第二数据文件。

可按照两种方式修改配置文件。首先，可由应用程序直接编辑该文件。在此情形中，后文中所述的操作系统防护文件子系统将解决对文件进行的修改。其次，在较佳实施例中，应用程序可调用Windows API调用族即GetProfileString、WriteProfileString等来修改这些文件。在这种情况下，本发明的实施例的操作系统防护恰如上述地截取这些调用并从内部服务它们。

共享对象

由操作系统和运行的应用程序使用的众多组件跨若干应用程序或实例共享。一般，这是个非常好的想法。它节省磁盘空间，不要求同一文件的众多副本。它也给操作系统厂商和第三方提供创建并分发常用代码库的能力。在Windows平台上，动态链接库即DLL通常在应用程序内或跨应用程序共享。在其它平台上，也有同样问题。在Macintosh、INIT及其它系统上，为各应用程序加载组件。这些组件可具有多个版本，一次仅使用其中一个版本。在UNIX系统上，例如“.so”库文件等动态共享对象由应用程序使用来加快加载时间、节省磁盘空间及其它。众多程序使用默认的“libc.so”。然而，这种库文件一般是对诸如libc.so.3等其自己的某个版本的符号链接。实际上，这种特征造成了严重的破坏。这些共享的组件常常经历修订，同一组件的众多版本可用于安装。应用程序创作者发现他们的软件仅可能与共享的组件的各种版本中的一个或一些一起工作。因此，实际上，应用程序一般安装它们所需的版本，而盖写其它存在的版本。这可能造成运行在系统上的其它应用程序发生故障。

在Windows 98、Windows 2000上，Microsoft创建了Windows受保护文件系统(WPFS)来允许系统管理员在应用程序的基目录中创建名为XXXX.LOCAL的文件，其中XXXX是不带扩展名的可执行文件名。这使得Windows加载器在LoadLibrary执行期间更改其解析路径引用的方法。然而，这对于完全解决问题是不够的。首先，设置XXXX文件取决于系统管理员的知识，而这有很大差异。其次，组件版本必须经历倒转回至原始版本，然后将该组件安装在本地目录中，然后创建“.LOCAL”文件。这对除了置于WINDOW\SYSTEM中的最基本组件以外的任何组件而言，都不是直接了当的过程。而且，这种解决方案不能覆盖所有所需的功能。在LoadLibrary期间，取决于组件是作为显式还是隐式的LoadLibrary的结果被解析，以及是否存在指示它是命名还是公知的DLL的Registry Key，Windows使用不同路径解析语义。在这种情况中，LoadLibrary调用将总是解析到WINDOWS\SYSTEM目录。

DLL及其它共享组件也保持引用计数语义以确保除非没有被运行的应用程序引用，否则组件将不被改变。实际上，仅来自操作系统厂商的应用程序及操作系统本身良好地服从该协议。

作为一般规则，期望共享对象总是解析到正确的组件。为了提供这种功能，需要理解应用程序能够与之一起工作的组件的版本或版本的范围。然后，当应用程序要运行时，本发明应确保组件被正确解析。在本发明中，如有需要，使WPFS或其它操作系统提供的能力的使用自动化是可接受的。在这种情况下，必须检测所需组件并将它们置于本地文件系统中。这比仅监视安装更为复杂，因为如果所需的组件已经存在，安装程序通常将不安装它。

期望找出确保命名对象也被正确加载的方法。在Windows平台上，MSVCRT.DLL是该问题领域内的重要的故障原因。如果维护该对象的多个版本，则前述Registry键可被动态改变，以允许LoadLibrary函数解析正确的组件版本。确保正确组件加载的另一合理方法是动态编辑进程环境以使用有效搜索路径。该搜索路径将确保本地组件在系统范围组件之前被解析。正确共享对象的解析的另一可能方法是通过使用符号链接。可对共享组件进行符号链接，它在运行时由计算机的文件系统解析至所需组件。最后，对来自共享对象文件的信息的实际的打开/读/关闭请求可由本发明截取，并针对可能存在于本地系统上或本发明的子系统内的文件的正确版本进行动态响应。

存在若干特殊形式。在Windows平台上，OLE、ODBC、MDAC……以及多个其它厂商专用组件被写成将在若干或所有运行的进程之中全局共享。在OLE的情况中，甚至在单独进程之间共享数据和存储器空间。与这些组件中的多个一样，OLE防止一次运行其自身一个以上的副本。OLE也有需要为特定应用程序加载特定版本的众多隐错和特征。在本发明中，应用程序能够加载OLE所需的任何版本，仍旧允许与使用OLE的同一版本的其它组件共享的语义。

一般，共享对象应被私有加载以确保防止冲突，除非是被特别配置成这样。用于允许私有加载组件的方法决不应阻止它被干净地卸载或为另一软件应用程序正确加载，而无论该软件应用程序是否由操作系统防护积极管理与否。此外，如果系统崩溃，则要求从该崩溃恢复到干净的状态，而不曾盖写或修改底层操作系统。

文件

众多应用程序使用应用程序内的数据文件来存储配置条目或其它应用程序数据。本发明的实施例提供非常类似此前所述的虚拟注册表的虚拟文件系统。在应用程序启动之前，本发明的实施例可加载文件系统改变的列表，包括要隐藏的文件和要添加到虚拟环境的文件或要重定向至虚拟环境内的另一文件的文件。无论何时应用程序访问或修改任何文件，操作系统防护均检查该文件是否必须被重定向，且如果是，则在较佳实施例中，将请求重定向至操作系统防护配置中所指定的位置。

如果应用程序试图创建新文件或打开现有文件以写在用户的本地驱动器上，则操作系统防护必须确保该文件在重定向的位置中被实际创建或修改。如果应用程序在稍后被重新加载，则该文件映射必须被重新加载到操作系统防护虚拟环境中。当请求是修改驻留在用户的本地驱动器上的现有文件时，操作系统防护必须在继续该请求之前将所述文件复制到重定向点。被重定向的文件可以与原始文件不同名以确保文件路径的安全映射。在实施例中，以此方式处理INI文件以便在允许最大应用程序兼容性的同时提供最大系统安全性。

本发明的实施例对于通过网络交付的应用程序特别有用。在这样的实现中，重要的是理解软件应用程序是由若干种数据构成，其中软件应用程序所使用的大多数文件最好被安装在单独的逻辑驱动器上。包括基于文件和基于注册表的配置，可以是用户专用或系统范围的。所使用的应用程序交付系统应对每一文件标记它是这些类型中的哪个类型的。该信息向操作系统防护系统提供提示以便正确操作。

设备驱动程序

众多应用程序使用设备驱动程序或其它操作系统级软件以实现其诸如硬件支持或直接与操作系统低级交互的功能中的某些。在本发明的实施例中，操作系统防护提供动态地以及尽可能私有地将这些组件添加到应用程序的虚拟环境或从中移除的能力。

众多设备驱动程序被构建成可动态加载。只要有可能，较佳实施例是动态加载所有设备驱动程序。如果设备驱动程序要求在引导时静态加载，则必须在运行应用程序之前向用户提供该知识。一旦系统被重新引导之后，应用程序应从它停止的位置继续。然而，很大比例的设备驱动程序不是动态可卸载的。尽管动态卸载驱动程序是较佳的，但如果这不能实现，则将标记该驱动程序以便在下一次重新引导时移除，且应使用户知晓此情况。如果在下一次重新引导之前该应用程序被第二次运行，则系统仍应知晓该驱动程序的存在，而不试图第二次安装，等待终止以将该组件重新标记为可在下一次重新引导时移除。

因为对每一设备驱动程序类均存在基本的相似与区别，所以表征这些基本相似与区别以确保本发明的实施例可正确作用是很重要的。不希望加载和卸载经常存在的系统硬件的设备驱动程序。应理解，尽管在程序设计简易性意义上而言，这不是较佳实施例，但它处于本发明的范围内，且可能由于诸如使用本发明的实施例交付和运行的应用程序的发证协定时的限制等特定原因而被要求。

在非Microsoft平台上，一般区别非常大地处理各种设备驱动程序。Macintosh系统支持静态和动态驱动程序两者，而它们均经由相同方法安装或移除。与Macintosh系统文件夹链接将提供必要的支持。对UNIX系统，设备驱动程序一般需要对运行的UNIX内核的修改，继之以重新引导。该过程可能非常复杂。在实施例中，该过程被自动化；包括一旦应用程序完成之后即重新设置内核。该过程的一般参数与上述的Windows应用程序过程参数相同，编译的实际处理步骤和熟悉这样的操作系统的个人可执行重新引导。

最后，本领域的技术人员将理解期望能够跨越系统故障恢复和移除驱动程序。因此，维持系统完整性所需的任何数据或过程被包括在本发明的实施例中。本领域中的技术人员也可理解，不是所有类型的设备驱动程序均可经由本发明的实施例方便或高效设置的，尤其是与附连持久硬件的设备相关联的那些。

其它项

在本发明的实施例中，认识到存在若干组件，其行为或存在性在替换操作系统上是不同的。这些组件包括字体、进程、环境变量等。

某些应用程序需要安装字体以便正确执行。所需的任何字体将在操作系统防护的配置文件中指定。操作系统防护将在运行应用程序之前启用这些字体，且如有需要，则在运行之后移除它们。大多数系统除用于注册字体或使系统知晓它们的存在的过程以外还具有用于存储字体的公共区，操作系统防护将利用这些可用方法。

在Windows上，字体被复制到\WINDOWS\FONTS目录。然而，这不保证字体可供运行的程序使用。在较佳实施例中，如果程序使用Windows API来访问字体，则字体将需要以诸如CreateScalableFontResource/AddFontResource的Win32API调用注册。这将字体插入系统字体表内。一旦完成之后，操作系统防护可使用如RemoveFontResource的另一合适的API调用移除字体，然后将文件从系统中移除。作为另一实施例，操作系统防护可如虚拟注册表方法中所述地挂钩API函数。此外，操作系统防护可使用其文件子系统来避免将实际字体文件置于运行的程序中。

在Macintosh上，该过程极其类似，且基于Macintosh系统文件夹中的文件和注册激活。然而，在UNIX上，该过程取决于应用程序。一般，字体资源作为解析在正确位置中的常规文件被添加到系统，因此它们可按名访问。在众多Motif系统中，需要将字体描述置于字体资源文件内，这将允许字体被解析。Motif或X应用程序可经由解析子系统或经由直接调用来调用字体。近来，众多基于Motif和CDE的系统利用Adobe可缩放附录字体。这些字体需要经由Adobe型管理系统管理。然而，存在例外，且如上所述，存在Windows或其它操作系统默认字体管理系统的替换。Adobe型管理器提供该过程的一些替换接口，其它第三方型管理系统也一样。在大多数情况中，应决定是支持该接口还是忽视它。操作系统防护的目的不在于为所有这些系统提供统一层，而是仅为操作系统自己的子系统这样做。

众多应用程序需要设置环境变量。这在UNIX系统上最常见，也由最初写在UNIX上并被移植到Windows操作系统的软件大量使用。Windows操作系统上的应用程序非常依赖于DOS PATH环境变量，且通常设置它们自己的应用程序专用条目。在Windows 9x/Me环境上，存在众多环境设置，由于其核心是DOS子系统，因此这些设置可应用。如果应用程序要求特定变量的存在、或在现有环境变量中设置值，则所需环境变量将在操作系统防护的配置文件中指定。操作系统防护将在应用程序的主进程运行时为其设置这些变量。由于当应用程序操作时一般不改变环境设置，因此虚拟环境将不捕捉这些调用，也不象注册表和配置子系统那样提供功能的全部补充。

恢复

在前述部分中所示的某些情况中，必须对操作系统进行实际修改。这对设备驱动程序和字体而言是频繁的。此外，可对需要被持久化并在应用程序下一次运行时可用的虚拟环境进行改变。要求操作系统防护系统能够从对系统的改变恢复，在其最早可能有机会时从系统移除该改变。或者，如果系统在应用程序执行期间崩溃，则操作系统防护应跟踪足够的信息以在系统被重新引导等时移除对系统的任何改变，且应跟踪对虚拟环境进行的改变。在较佳实施例中，这被实现为事务日志，但在其它实施例中，可实现为可在系统启动时读取因此可回退改变的某个其它类似组件。

控制虚拟化

本发明的一重要方面涉及对操作系统防护能够进行的虚拟化的众多方面的控制。在较佳实施例中，存在能够确定要软件系统中要控制的正确方面的探测程序(instrument program)。还包括允许管理员和最终用户察看和修改要由系统虚拟化的那些项的方法。

在自动化的程序中，观察要控制的应用程序以便估计控制的各方面。自动化的程序能够在应用程序的安装进程期间、应用程序的运行时期间或其组合时执行该任务。在较佳实施例中，操作系统防护被嵌入包封器应用程序中。在安装之后，或当一次或多次使用软件之后，包封器应用程序将向操作系统防护查询其所有动作的详细列表。从这张动作列表中，包封器应用程序将创建之后使用时加载和运作操作系统防护所需的配置文件。

如果被用作安装进程的一部分，则在实施例中，操作系统防护将起到仅允许安装进入其环境的虚拟层的作用。当安装之后，所有文件、设定等可被转储以便稍后重新加载。以此方式，安装将保持原始系统不变，且将自动创建必要的配置文件。当在应用程序使用期间使用时，操作系统防护能够记录对环境的差别性修改或重新编纂配置文件。

操作系统防护将其信息传给包封器应用程序以便进行后处理。在较佳实施例中，除系统可创建的自动条目之外，还以操作系统专用和应用程序或域专用知识对包封器应用程序编程。这种知识用于更改进程的输出以便反映配置项或其它条目的已知使用。在较佳实施例中，采用基于规则的系统来将观察到的行为与已知情形进行比较以便实现对编码的改变。

包封器应用程序也用作进程的配置输出的观察器和/或编辑器。在较佳实施例中，这种编辑器允许系统管理员添加、编辑或从配置中删除一个或一组项。当经由编辑器观察配置时，管理员也可复制配置、按需改变特定项以实现应用程序级或用户定制的改变。

现在参考图1，按功能示出本发明的实施例。在此实施例中，示出了两组应用程序/用户数据60。操作系统防护100阻止应用程序50的两个实例彼此干扰。此外，如上所述，操作系统防护100用作抽象层，并因此收集应用程序软件50与客户计算机的实际操作系统10之间的命令和通信。如由箭头图形示出，某些命令位于操作系统防护与软件应用程序之间，这与典型安装不同，在后者中这些命令相反可由操作系统本身操作，导致可能不必定是操作员预期的对客户计算机的改变。另一方面，其它命令通过操作系统防护，然后被传递给操作系统本身。

众多软件应用程序被设计成结合另外一个或多个应用程序操作。这可以是诸如Microsoft Office等软件的情况，其中一组应用程序作为单一的单元被打包并出售，且通常被创建成一起工作。这也可由被设计成“插入”另一应用程序或以某种方式与之通信的众多软件应用程序证实。

尽管这是常见的功能，但众多软件分发系统难以使这些相互关系充分工作。这可能是由于在应用程序打包期间、将应用程序集成到最终用户环境期间、或运行时中对相互依存性的不正确解析引起的。

现今存在众多形式的软件分发，包括打包软件分发、电子软件分发(ESD)、软件点播分发以及诸如Microsoft公司提供的ClickOnce系统等若干下一代分发系统。这些分发系统中的每一个展示了涉及软件被如何分发、如何安装和移除以及如何主机与操作环境和其它应用程序两者交互的若干基本模式。

软件分发

尽管软件仍可由诸如CD-ROM或软盘的物理介质提供，但对大多数形式的软件，电子分发手段成为普遍。存在众多形式的ESD系统，诸如由诸如Microsoft、Marimba、Altiris等厂商提供的设计成供公司使用的那些系统，以及诸如DigitalRiver等提供的设计成供因特网或公共访问网络使用的那些系统。ESD系统以可按照某种完全或相对自动化的方式被下载并安装的安装包的形式向最终用户或公司提供应用程序软件。当使用该软件时，这通常引起诸如冲突的依存性或其它误配置的安装问题。

其它软件厂商开发了用于当软件被使用或“点播”时分发软件的系统。在这些系统中，应用程序包在按需基础上被分发给需要使用该软件的最终用户系统。软件然后可在运行中安装或从目标系统中移除，或在某些情况下被“虚拟安装”，借此当软件实际上未被安装的情况下可如同它被安装一般在最终用户系统上执行。虚拟安装技术确保应用程序如同它被安装、但将应用程序与操作环境和其它应用程序隔离一般运行。

已向市场推出若干其它技术，诸如Microsoft的ClickOnce或Sun的JavaManagement Framework。在众多这些系统中，通过防止软件安装修改其主机环境来从概念上消除安装软件的问题。这通过要求任何遵循的软件从诸如配置文件等无害内部源收集其所有配置，且不使用任何系统范围注册表或其它应用程序配置实体来完成。软件也被限制不得要求在主机操作系统内设置或以任何方式修改其主机。

一般，软件则可被视为经由修改其主机配置、通过模拟修改但实际不执行修改的虚拟安装、或通过由创建自包含软件来限制环境修改安装在目标操作环境中。在这些系统中，软件的移除依赖于它被如何安装。如果正常安装，则它必须由逆过程或卸载程序回退。这些程序经常失败，并引起对主机环境的损害。对虚拟安装系统，软件从未安装，因此无需移除。对自包含环境，移除通过确保也可非侵入性进行的简单卸载过程被简化。

集成问题

在所有所述系统和用于软件执行的任何系统中，存在关于如何表征并推动一个或多个软件应用程序与其主机环境和/或要安装或运行在同一环境中的其它一个或多个应用程序的可能的交互的问题。众多应用程序或者被设计成一起工作、相互通信，或者被设计成通过修改其主机环境来工作。存在众多其它模式的应用程序间关联，此处所述的这些仅用作要解决的问题的示例性情况，而该问题普遍存在于所有或大多数已知的模式中。

设计成彼此一起工作的应用程序一般遵循若干模式之一。首先，众多应用程序是供其它应用程序“插入”的主机。对此的一示例是Adobe Photoshop或AutodeskAutoCAD，它们为第三方软件厂商提供创建其主应用程序的扩展的能力。当存在这种插件时，Photoshop用户界面将对最终用户显现不同外观，包含由插件提供的新功能。不存在对最终用户可视改变的要求。这仅是常见插件的一种操作模式。

或者，某些程序可通过利用未公开的(undocumented)程序接口或修改其运行时行为——尽管原始厂商不旨在如此——来模拟“插件插入”的外观。存在提供其它软件程序的包封器的若干程序，诸如将程序及其用户界面嵌入另一程序内。当选择包封器内的某些功能时，主机可驱动该另一应用程序来执行某些工作。这也可以是松散集成，诸如通过创建不主宿其它软件应用程序仅当用户请求时启动该应用程序的“运行器”程序。

若干应用程序使用其它应用程序来执行其部分工作。诸如PDA应用程序的软件使用诸如Microsoft Outlook的联系人管理器作为其用于同步化联系人信息的数据仓库。Outlook未被装运成PDA应用程序的一部分，但该软件可与之通信以执行其同步化任务。众多程序利用Microsoft Word来执行Mail Merge(邮件合并)功能。

程序也可经由标准或专用手段来彼此通信以执行工作。这可以是诸如经由COM/DCOM、MTS、CORBA、SOAP或其它手段进行的远程过程调用(RPC)等。这可以是原始TCP/IP通信会话、或甚至诸如HTTP请求等。此处的主要问题在于相互通信的可用性可能会改变主应用程序行为的方式。作为示例，包转储器或通信故障查找程序通常能够查看并格式化众多不同的通信协议。然而，如果未处在使用CORBA的环境中，则无需配置该协议。这种配置可通过检测其主机或附近主机是否被配置使用该协议来完成。

程序也可经由共享数据文件或公共数据库来松散互操作。这可以是通过简单的文件共享或通过诸如OLE或OpenDoc等复合文档接口。在复合文档情况中，特定的复合文档将依赖于可主宿其内部文档结构的各个片段的软件应用程序的存在和集成。在数据库系统的情况中，耦合通常非常松散，但仍要求提供某些配置以造成集成。

最后，当存在不同配置的类似操作系统时众多程序可不同操作，或可具有配置特定主机操作环境或其它软件应用程序的目的。一简单的示例程序是TweakUI，用于改变Microsoft Windows桌面环境和该操作系统的众多其它方面的配置的程序。

在上述所有情况中，软件应用程序或者假定在其世界观中独自存在，或者当存在其它应用程序或主机环境时有意不同地工作。这可给所述软件分发系统带来一问题。通常，在分发或安装时不是所有可能的关联均已知。因此，分发系统必须提供适应改变的手段。

一旦为分发配置了应用程序之后，如果环境改变，则应用程序常常必须被重新配置。此外，在配置期间，其所有关联必须已知，否则它可能不能被正确配置。在虚拟安装环境的情况中，默认行为是有意地分离任何程序连接。因此，必须提供克服这种限制的手段。或者在自包含环境的情况中，必须找到不违反容器范例的合理关联手段。

可视性/可发现性

为了使两个应用程序能互操作，它们必须在某刻彼此可见。这或者可经由在安装或运行时的发现手段，或可通过在这些时候一个程序的可为另一程序所见的某种表现或界面来实现。

可视性问题可能相当复杂，因为程序通常使用非确定性或未公开的手段来找到彼此。例如可通过寻找将要与之集成的应用程序的存在性来确定存在与否。这可通过搜索其一个或多个可执行组件、在诸如Windows Registry等公共注册表内搜索其配置、搜索应用程序在诸如执行快捷方式等某些公共位置内的轨迹或其在UNIX/var/opt或/etc文件系统位置中的配置、在公共位置处搜索其一个或多个接口、向其主机操作环境查询其存在性或众多替换方法之一来完成。

对诸如虚拟安装技术的系统，即使程序被配置成在目标主机上执行，经由这些搜索手段进行的发现也可能失败。使用虚拟安装技术，在主机环境上不存在程序的轨迹。其可用性的仅有知识存在于被配置成将应用程序交付给主机的服务器处。而且，某些虚拟安装系统向如桌面系统等提供主机集成，因此使得仅此一种形式的发现可行，即使应用程序未被配置成以此方式进行其发现。虚拟安装的软件组件默认地对除实际软件自身以外的任何一方均不可见。因此，要进行发现，必须提供推动的替换手段。

在自包含环境的情况中，软件组件在主机环境内的实际表现可能有显著变化。例如Microsoft ClickOnce技术可将软件应用程序的可执行组件置于主机环境内向系统的其余部分隐藏或可在其存在过程上改变的一位置处。

也可经由软件的集中或分散的仓库来进行发现。诸如UDDI或JNDI的系统提供在接口层发现软件应用程序的手段。在UDDI内存在记录隐含软件在预定义或动态端点的可用性。在虚拟安装技术中，该端点常可仅存在于虚拟安装环境内，使得该环境内的UDDI查询可解析应用程序的存在，而在该环境外部它将不会这样做。或者，UDDI或JNDI查询将解析至仅是虚拟应用程序的代理的动态端点。

发现的问题由安装时和安装后的改变进一步复杂化。如果一个应用程序被安装在机器上，且它可与另一应用程序集成，但第二应用程序未被安装，则该应用程序不可配置自己来互操作。如果随后安装了第二应用程序，则通常用于配置互操作的逻辑仅在第一软件应用程序的安装时进行。因此，第一应用程序必须被重新安装以提供集成。

而且，如果应用程序被配置成与第二应用程序集成，且第二应用程序被移除，则第一应用程序必须能够进行重新配置或者处理移除过程。如实际可见，往往不是这样。第二应用程序的移除可能引起第一应用程序失败或者行为不良。

应用程序的存在性也可在运行时确定，且引起对应用程序的行为改变。软件应用程序可通过尝试在已知接口处与另一程序对话、寻找其在主机上运行的进程、查找其一个或多个应用程序窗口、或使用诸如MTS、CORBA或DCOM的代理服务来检测另一程序。

相互通信

一旦应用程序被配置成互操作，则它们必须仍具有相互通信的手段。在正常的单用户执行环境中，这很少是问题，除非在主机配置中改变了什么引起执行失败。然而，在虚拟安装环境、多系统环境中或在多用户系统中，在没有附加配置的情况下相互通信可能不能正确工作。

在操作系统防护的正常操作模式中，默认通信端点被重定目标以移除与某个现有端点之间的冲突的可能性。因此，当一个应用程序试图与另一应用程序通信时，即使两个应用程序均存在且被配置成彼此知晓，通信也将失败。这是该系统对每一通信端点将被不同地重定目标的保证的结果。因此，必须由操作系统防护提供一系统以协调重定目标的过程以确保通信会话正确连接并操作。

对多用户环境，问题类似。如果程序将要由同一主机上的一个以上用户使用，则通信端点必须在每个用户的基础上可变，并对每一用户重定相同的目标。在Microsoft Terminal Services或Citrix MetaFrame中，诸如信号量和互斥体的通信端点已经被重写成一终端会话内唯一，然而同一程序在单个会话中的多个实例仍可表现出这个问题。此外，诸如套接字、COM、命名管道等标准通信一贯对机器是全局的，且不能以任何方式改变，因此造成问题发生。

操作系统集成

大多数现代软件以某种方式被设计成与其主机操作环境集成。桌面类软件一般提供程序快捷方式或其它简单的手段以访问软件产品。这些快捷方式允许操作系统显示用于运行产品的用户界面。在大多数情况下，服务器类软件提供用于管理和简单启动/关闭配置的界面。

在所有情况中，主机操作系统必须提供访问所安装的软件的某种手段。最常见地，诸如Windows Shell或UNIX CDE或KDE的桌面外壳程序被用于提供软件的公共观感(look-and-feel)和集成点。软件厂商负责以正确的手段安装其软件以与这些接触点集成。这些界面中的某些如快捷方式一般简单，其它的则较为复杂，诸如当用户在鼠标上右击时所使用的上下文菜单。

也存在允许使用公共命令或用户界面来管理软件和硬件的管理界面。如Microsoft Management Console或Microsoft Windows Installer或Linux rpm数据库等提供查找操作系统内管理信息的公共位置。

当存在可被添加或移除、虚拟安装或点播提供的软件时，这些界面也必须是动态的或能够被动态管理。可使操作系统的操作行为反映其现用应用程序的本质。

版本控制

由于存在软件程序或其界面的一个以上的版本，进一步加剧了集成和互操作的问题。如果两个程序可通信，且程序之一具有多个版本，则必须要有了解要使用程序的哪个版本的手段。通常，仅有程序的一个版本可与调用程序正确操作。以这种方式，了解在两个程序之间存在依存性。然而，如果程序的两个版本均可正确工作，则依存性必须以指示版本独立性的方式明确表示。

诸如Microsoft COM体系结构的众多系统提供版本化的接口以便程序相互通信。在这种系统中，向程序接口给定全局唯一的标识符GUID以及一个或多个名字以便使用来标识其自己。此外，可向程序给定独立于版本的标识符。该标识符隐含程序可与之通信，而不考虑程序的版本。

实际上，当实际上存在版本依存性时这些类型的标识符经常被误用。大多数新程序员想当然地认为如果他们使用独立于版本的标识符，则它将总是解析至他们想要查找的目标。这令已经构建的程序必须总是与依存的软件的最近版本正确工作。如果依存的软件改变了，且即使存在独立于版本的接口也不再兼容，则问题仍将发生。这将留待软件分发系统来解决这些错误，而这往往不能被解决。

或者，众多程序不具有依存于或独立于版本的接口，但仍具有仅可通过测试或常规实践理解的版本依存性。驱动另一程序的用户界面的程序经常期望其Windows控件位于特定的物理位置，或具有特定的类名。同一程序的另一版本可能不遵守这些期望。在这种情况下，驱动程序仅可正确使用该软件的第一版本。

该问题的逆命题也存在。如果存在需要驱动另一程序或与之通信、且仅可使用诸如Windows类名的特定端点来这样做的程序时，要驱动的软件的两个单独的版本可能实际使用同一端点。在这种情况下，需要允许驱动程序连接至该软件在期望端点处的正确版本，但仍便于软件使用同一端点的另一版本的操作。

命名

所述的问题的一个重要部分在于理解名字的基本问题。名字以多种形式出现，且在不同情形或“上下文”中可以是众多非常不同的事物。

在计算机系统中，命名对象几乎可以是任何事物。文件具有名字：“C:\Windows\notepad.exe”。注册表键：“HKLM\Software\Microsoft\Windows\CurrentVersion\Run”。命名管道：\\PIPE\ExamplePipe。字体：“Tahoma Bold”。HTTP通信的TCP端口：80。数据库中的表的名字：USERS。甚至全局唯一标识符GUID根本上也是某个对象的名字。在实际使用时，以使其名字显著的方式命名众多其它对象。新闻报道的标题、新闻报道的作者或其出版商。

一旦对象被命名之后，存在隐含的理解，即可使用所提供的名字定位该对象。如果两个对象具有相同的名字，则必须提供解析适当的目标对象的进程。如果单独的应用程序尝试利用公共对象，则正常地，该应用程序将解析该单个对象。然而，如果一个应用程序修改该对象，通常期望使得经修改的对象不再由另一应用程序使用。因此，每一应用程序需要具有解析使用相同名字的不同对象的方发，以及跟踪改变的对象的手段。

而且，如果命名对象存在，且同一对象存在于虚拟安装的应用程序内，则虚拟应用程序将通过解析其内部对象来工作，但仍存在为位于虚拟环境外的程序定位虚拟对象的需求。

因此，在其中应用程序和对象可具有可变生存周期、在其生存周期上有不同的意义以及潜在的冲突的网络中，需要统一的解决方案来管理这些对象的交互。当前技术的系统，诸如JNDI或UDDI依赖于系统范围的信息注册表提供不反映这些特征的绝对信息。JNDI查询能够通过创建接合点来联合不同的名字空间。然而，需要系统用户单纯靠不制造命名冲突来处理命名冲突。实际上，这是非常困难的，因为众多系统必须具有对对象的公共但不同的定义以便执行它们的工作。JNDI系统不提供折叠或合并名字空间的任何手段，也不提供版本控制或冲突管理的任何手段。

上下文

当在要处理的情景的上下文中提供适当的配置、命名对象或接口的能力存在时，就可解决对上述问题的解决方案。此处所述的实施例示出a)自动理解软件程序的相互依存性、b)创建程序可在其中共享和/或修改其主机操作环境的相似视图的操作上下文、c)控制这些上下文的启用或特性以及d)便于这些程序原本可能失败的相互通信和互操作的系统。

这些实施例提供以受控的方式操作主机操作环境中的一个或多个程序并将多个系统的行为耦合在一起的方发。在图5中所示的示例性系统150中，可存在一个或多个计算设备。这些设备可以是单用户155或多用户156设备，其中操作系统和一个或多个应用程序将执行。也可存在诸如像数据库服务器、文件服务器或其它商务营运(line-of-business)应用程序服务器等服务器系统的基础架构服务158，以及用于管理网络和系统的某些基础架构157。

当软件应用程序在设备网络内执行时，它将因此具有与若干级上的其它软件交互的能力。在较佳实施例中，基本级包括：全局、受管、本地系统、系统虚拟、厂商、用户、会话、共享和隔离。这些级在图6和7中示出。这些分组将被称为上下文，对应于应用程序在其内执行以扩充来允许基于策略的交叉环境交互的控制的运行时环境。本领域中的技术人员可以认识到，可简单地创建其它上下文，此处所定义的那些旨在成为本发明的应用的示例。

全局上下文201是图5中所示的实施例中整个系统的视图。存在于全局上下文内的对象或名字如安全性策略允许可由所有用户和所有软件程序看见并共享。在替换实施例中，全局上下文可被更改成覆盖了覆盖公司的所有机器的公司上下文204、用于公司之间共享计算的联合上下文206、以及覆盖所有参与实体的全局201或分布上下文。

受管上下文207是某个管理范围内的机器、用户、资源和/或应用程序的集合的广泛的视图。该范围可以是由诸如ESD解决方案或虚拟安装系统214之一的分发系统管理的系统的集合。它可延伸跨越部门(division)内公司边界，或如果管理系统将由诸如ASP的服务供应商202主宿，则该上下文可延伸跨越供应商的顾客系统204、205。存在该上下文，使得实现本发明的方法的任何系统可与其它管理系统、及其自身的其它实例互操作。

本地系统上下文302提供特定机器301或虚拟机器(诸如VMWare分区)内的所有操作的视图。这等效于Microsoft Terminal Service(终端服务)的“全局”上下文。由Citrix和Microsoft提供的现有技术的系统试图通过将机器细分成全局和会话专用名字空间来解决这些上下文问题中的某些。

系统虚拟上下文310允许诸如由虚拟安装技术或操作系统防护交付的那些程序与本地操作系统共享操作和对象，使得它们均在同一名字空间内操作。特定的系统虚拟上下文将一个或多个应用程序与操作系统封装在一起。不存在所有应用程序以相同方式与OS共享的要求。

厂商上下文允许软件厂商创建包括存在于机器内但涉及使用其软件或硬件的系统的所有操作的范围。实施例中的一个示例是由系统管理的将与同一机器上的其它软件共同存在的软件。在厂商上下文内，软件基于什么受管和什么不受管来分组。

用户上下文211提供将操作分组成由用户进行的那些操作的能力。注意到，该上下文不限于存在于单个机器上。该上下文可延伸跨越正代表该用户执行操作的多个机器或会话。这种行为允许用户与网络中运行的一个以上的会话在它们正执行的应用程序之间具有协调。

会话上下文212将操作限制于一个用户在一个机器上的操作。这与TerminalService的本地用户名字空间或其中登录到机器内的用户将具有可标识范围的UNIX telnet/tty会话相关。

如图7中所示，共享上下文312提供管理地定义的唯一的、依存于共享配置的范围。该范围允许两个或多个程序共享配置和对象，或为彼此可见。在本发明的较佳实现内，存在多个共享的上下文。每一上下文包含一个名字以及定义共享行为的一组策略。以此方式，应用程序的多个不同段可共享重叠行为。

如图7中所示，隔离上下文311是虚拟安装的应用程序的默认行为。在此范围中，应用程序与所有其它程序完全隔离，且在某种意义上不可见，所有正常接口和命名对象均不存在于该上下文外。

这些示例上下文示出本发明的实施例在设计上如何不需为明确分层的。尽管操作系统防护作为操作系统和单个应用程序之间的以及多个应用程序之间的一层，但不存在应用程序或上下文应阶式分层限制。这种效果可容易地被实现，但本发明的系统能够不受网络或系统体系结构约束地将1到n个环境耦合在一起。这允许构想各种上下文，诸如用户上下文，它如指示可横跨多个机器。

操作特征

实施例中的系统被设计成截取程序与主机操作系统的、程序彼此的、并且在操作系统内的正常通信的软件层。在替换实施例中，系统被实现为用于编译成特别启用来利用该系统的功能的程序的代码库。每一单独的应用程序请求然后可在其具体操作上下文内评估。该系统将查看所有类型的请求，诸如文件系统请求、注册表请求、共享对象、字体、代码库等。这些请求一般是针对配置项、命名对象或通信接口，但不限于此，它们将被一律称为资源。资源具有可变的生存周期且在超出其使用期限外可以持续或不持续。

在图8中所示的系统中，示出利用彼此和操作系统的资源的两个应用程序。示出了三个不同的情形。一个是其中一程序即应用程序A 402试图使用被配置成仅供其自己使用的资源即资源集1 404。另一情形是应用程序A 402试图使用配置成供另一程序使用的资源，即被配置成供应用程序B 403使用的资源集3 406。最后一个是其中这两个程序均试图访问可被配置成供每一程序访问的共享资源即资源集2 405。注意到，该视图在功能上等效于美国专利申请09/859,209号“OperatingSystem Protection and Abstraction Layer(操作系统保护和抽象层)”中的示意图，但它被示出以阐明过程。

该示意图示出该系统的基本前提，借此一个或多个资源可被配置成属应用程序私有，或者这些资源可被共享。共享可作为可供一个或多个程序使用的资源体进行，诸如共享库的集合。也可被执行以便允许一个程序与另一程序共享其资源。相反，私有性确保一个程序的资源不可供另一程序使用。在所有情况中，中介层负责允许或拒绝共享操作，或将操作定向至替换上下文。

在本发明的实施例中，每一集合404、405、406中的资源被存储在单独的名字空间容器对象中。这些对象允许名字空间类型和上下文的组合的可分开的存储。名字空间容器的一示例是Microsoft Office的用户个人设定(用户上下文)的文件系统容器。这些容器允许资源的存储以本地化且独立的方式、适于每一组合地进行，然后根据当前系统动态置入正确的名字空间中。资源可被持久化在名字空间容器中，或仅持久化重新创建合适资源或命名对象所需的元数据。

可理解，可利用众多形式的存储、数据结构等来实现这种功能或其等效特征。例如，名字空间容器可以是包含与存储在本地或网络文件系统中的资源集相关联的所有数据和元数据的单个文件。在另一示例实施例中，名字空间容器可以是将请求转发给底层或远程系统的代理对象。

在本发明的系统中，存在三种互操作的基本模型。生产者/消费者模型，其中一个应用程序可向另一应用程序提供资源服务。该模型的特征是单向关联，其中一个或多个程序可依存于另一程序在提供资源或服务，但反过来则没有要求。在这种模型中，消费者将被限制对生产者的必要集成点的访问。因此，生产者的环境和名字空间容器一般将不能由消费者访问，而是仅允许所配置的资源或程序性接口。这种模型的一示例是，诸如为诸如由Great Plains使用Microsoft Excel以从其保存的会计数据来生成电子表单的功能而对诸如Microsoft Office等程序的常见使用。Excel和Great Plains作为独立程序是有用且具有功能的，但它们在一起可加强这项功能。Great Plains仅需程序上驱动Excel，而不需对Excel自身的内部配置或状态的任何访问。

第二模型是对等模型，其中一个或多个程序能够协作共享资源。在这种模型中，共享被允许，但修改如策略所定义的被严格且特别控制。对等的环境和资源将显现为共同存在为单个名字空间中的一个集合，但将根据此处所定义的策略分开处理。这种模型的示例是共享的数据库驱动程序或Microsoft Office插件。数据库驱动程序由机器上的众多程序共同使用。为了正确工作，这些其它程序必须可访问涉及驱动程序配置的信息。

最后，系统支持非互操作模式，其中不存在共享，这是当未定义任何依存性或上下文时的默认情况。或者，如上所示，可创建与该模式相关的隔离上下文。

当图8中的主程序即应用程序A 402正操作时，它将请求资源。应用程序请求中的每一个由软件核心评估以确定其相关上下文和可用范围。该核心在图9中详细示出。当接收到请求510时，上下文管理器503请求其资源由进程管理器504标识。

进程管理器504负责保持运行在其主机上的进程以及由这些进程505采取的操作的视图。该视图与父子进程和线程的进程树相关。这允许系统建立理解哪一资源池是操作中的特定进程或线程的默认资源池的基库。

源解析阶段是重要的步骤，因为众多请求将显现为来自操作系统，而实际上它们源自应用程序。对此的示例是文件系统调用。对文件的写请求可由操作系统延迟，但对应用程序履行。稍后，当操作系统将写刷新至磁盘时，该请求将来自操作系统自身。为了使上下文管理正确工作，该请求必须被系回其始发程序。示出另一示例性情况，其中一程序代表诸如Microsoft Windows Application Management服务的另一程序工作。在这种情况下，一程序将请求Windows Application Management服务执行某个安装任务，诸如在主机系统上注册其组件。仅查看特定请求的进程所有者的系统将确定该活动是操作系统本身的一部分，还是将其系至ApplicationManagement服务。然而，期望的结果是这些动作被系至请求执行这些服务的程序。

在本发明的实施例的示例性实现中，装备了操作环境的公共接口和通信通路。这些装备接口被用于捕捉有助于标识源上下文的信息。如上所述，装备WindowsApplication Management服务的请求接口以标识安装请求的调用程序。该API调用的内容被发送给进程管理器504来存储以供将来使用。在该API调用的有效生存周期期间，进程管理器504可在表中保存该信息，并将其用作查找请求所有者的一种手段。

请求作为请求对象510被传送通过系统。如上所述，该对象包含与发起该对象的API调用相关联的属性，此外，请求包含例如关于其子系统的数据、请求类型(例如，创建、查询、删除)、目标以及父请求。在实施例中，请求对象被实现为与请求的每一目录/子系统相关的面向对象类。这允许每一子系统511在不影响本发明的其它部分的接口的情况下存储请求专用信息。

当接收到解析请求时，进程管理器504搜索其进程、线程及动作树以找到候选源。该进程表505在图10中示出，包含进程标识符(PID)、线程标识符(TID)以及状态或动作对象指针(SPtr)的列表。每一条目是可以是一个或多个进程对象的父亲的进程对象。父子关系反映主机操作系统的关系。如有必要，每一进程对象603包含指向保存对过去动作的引用的状态对象604的指针。在较佳实施例中，每一动作可由操作、操作数据以及请求该操作的源进程标识符组成。实际上，还存储其它数据，诸如例如，该操作的结果即成功或失败、以及其结果代码、涉及该操作的定时或生存周期信息以及该操作的安全性证书。

如果进程或线程与动作相关联，则搜索进程列表以标识该动作是否匹配当前请求。在之前Windows Application Management服务的示例中，由始发程序进行的API调用将造成在Windows Application Management服务进程对象下创建状态对象。该状态对象将标识，始发程序是所请求的动作的源。当Application Management服务试图通过采取诸如创建或修改文件的动作来履行该API请求时，进程管理器将找到Windows Application Management服务的进程对象下与该调用相关联的状态对象，但将返回该文件实际正由使用该服务的始发程序创建。

一旦了解请求源之后，进程管理器504将请求所有者的进程和线程id，及其真正的源(而这些可能是相同的)返回给上下文管理器503，在那里它被匹配于其一个或多个上下文。如图11中所示，在一个实施例中，上下文管理器503包含系统可用上下文以及上下文之间的关联的表。上下文将包含基本标识符(CID)以及其上下文类型(Ctype)。上下文自身然后需要指向启用或禁用功能互相关的一个或多个策略对象705的指针(PoPtr)。策略对象将包含其自己的标识符和用于标识机器子系统的匹配助记法以及请求相关参数和用于应用操作的规则，诸如资源的源名字空间容器和命名对象的变换操作。一示例策略是应对本地系统名字空间容器进行的任何修改，例如对匹配例如Microsoft Word文件类型的文件(*.doc)的写、删除等。本领域中的技术人员可以认识到，该策略可按照各种形式编纂。

该表可在应用程序在系统中使用时被静态和/或动态构建，且可使用诸如散列表、列表等任何技术完成。当应用程序被启动时，该表可被加载以指示该应用程序的所有相关联程序、名字空间容器和上下文关系。本发明的系统的实施例也允许上下文管理器503经由管理接口外部地查询，以加载新上下文或响应于系统配置中的改变。因此，如果添加了与运行的程序对等的应用程序，则该应用程序的上下文信息可被加载到实况系统内。此外，上下文管理器503可经由该接口向外部管理系统通知其运行的或所加载的上下文，使得这些可与其它机器共享。本领域中的技术人员可理解，这也可与另一机器直接进行。

上下文管理器将上下文的候选列表馈送给策略引擎506。除用户、机器或系统专用策略以外，每一上下文的策略被应用于确定在特定上下文内解析请求的需求以及加强安全性。该进程快速限制要在其内评估请求的候选上下文的个数。将在以下章节更详细描述策略引擎506。

然后，该请求由相关资源管理子系统——无论是文件系统、注册表还是其它——在每一上下文内评估一次或多次。每一请求的结果然后可由上下文管理器分析，且净结果被返回给调用进程。上下文管理器能够经由其环境表将请求映射到合适的子系统中，其中它跟踪虚拟应用程序和对象或正被管理但被完全安装或配置在其主机上的应用程序。

实际上，存在需要以这种方式管理的若干类操作：读、写、查询/查找、创建、重命名/修改、列举和删除。在较佳实施例中，还处理众多其它操作，较易于在不详述所处理的所有操作的细节的情况下描述基本系统模型。通过分开处理每一类操作，系统使得能够创作允许对资源的读访问但可拒绝或定向写访问至替换资源、名字空间容器等的策略。

在读操作中，系统具有履行读请求的众多选择。如果读是针对文件的，则该文件可存在于一个或多个上下文内。由上下文管理器确定评估什么。本领域的技术人员可以理解，这可按照若干方式来提供。请求可在所有上下文中作出，然后可根据其规则进行要利用哪一响应或如何组合响应的确定。请求可由可用上下文过滤，被确定哪一上下文优先，且仅在该上下文中作出该请求。或者作为示例，请求可接连在每一上下文中被评估，直到满足某一成功准则。在读操作的情况中，可由上下文支持读操作的数据的能力来指示成功。

上下文管理器也能够高速缓存其解析处理结果以作出遵循不需整个解析阶段的模式的公共请求。此外，上下文管理器能够经由上下文的散列分布查询。该散列过程允许系统快速查阅其表并查询其它表，而无需执行全操作查询。

从以上示例中的文件可从一个应用程序的上下文中读取，但当它被写至应用程序时，实际写操作将在另一应用程序的上下文内发生中可见上下文方法的重要性。系统的这种行为能够允许系统彼此互操作，但仍维持彼此隔离或独立。如由操作系统防护说明书所述，作为操作系统的一部分的文件可在运行程序的上下文内被查看，但如果程序试图修改该文件，则该修改可保持在程序上下文内而不滤过至操作系统。

重命名和删除操作也一样。在一个上下文中删除的文件对另一上下文可能是必要的。因此，本发明的系统不仅保存关于删除和重命名的存在性信息和配置，而且也保存例如其跟踪信息。

查询过程是最直接了当的。与读操作一样，它可按照分层方式、经由分组优先级或系统所选择的任何方式履行。然而，该操作的目的在于确认命名对象在正确上下文内的存在性或向其返回句柄。本发明的系统应用上下文策略以确定什么是正确的对象、它在当前上下文中是否可见以及如何内部管理其范围。

在本发明的实施例中，系统也能够处理上下文列举和交织(interleaved)的查询。通过遍历树结构或向系统要求某一资源的内容列表来访问操作系统或其应用程序内的众多数据结构或资源。实际上，这些操作要求上下文和资源的交织。作为示例，应用程序可具有与其相关联的资源。然而，该资源仅当另一程序与其自身相关联且现用时有效。

如图12中所示，资源可被附连至另一程序的资源树。因此，在对该资源的查询期间，系统必须能够交织两个单独配置的名字空间。但是，如果策略不允许联合操作，则既不进行对命名对象的直接访问，也不对其进行列举。在附图中所示的示例中，一应用程序即应用程序A使用表示Windows Registry键对象的三个项配置。仅当第二应用程序即应用程序B被配置在与应用程序A共享的上下文内时，对象HKLM\Software\Drawing Vendor\Photo Editor\Plugins\Pinhead Software\InlinePlugins\Snapshot 805才将存在。

即使该对象实际上存在于应用程序A中也一样。如果项“Pinhead Software”802不存在于应用程序A的上下文中，则它可能进退两难。系统被设计成由于不存在跟踪至资源的路径因此不能对该资源列举，且也不能对其直接访问，除非次级应用程序存在，这两者才能进行。而且，如果应用程序B被单独实例化，则由于相同原因，其可被另一资源802、803访问的资源将不能存在。

名字空间管理

在其最基本形式中，上下文是用于展示应用程序的资源的单独名字空间以及用于将对这些项进行的操作持久化的方法。名字空间是其中将唯一名字映射到某个可标识资源的域或范围。操作系统防护层是创建并管理该替换名字空间的中介。应用程序不知晓该中介。它们仅以给定名字创建对象，并预期能够在稍后以同一名字引用这些对象。该层管理多个名字空间，但使它们向执行的应用程序或系统的其余部分显现为单个名字空间。以这种方式，向操作网络150提供的单个资源实际上可由来自各个不同名字空间的多个资源支持。

默认地，中介层创建使加载的每一程序实例具有私有名字空间的隔离的上下文。当应用程序创建并使用资源时，对象名将被本地化以仅存在于特定应用程序实例内。这一般是通过确保对象仅实际存在于程序的范围内来完成的，但也可通过在较大名字空间内散列对象名且能够经由逆过程检索它来完成。以此方式，另一程序不对中介的功能进行反向工程就不能够请求不存在于其名字空间内的对象。

应用程序所使用来引用对象的名字将被称为公共名。系统上的两个单独的应用程序可使用相同的公共名字，但指的是不同对象。中介负责创建对应于正确对象的实例专用名。这被称为本地名。对每一本地名，存在整个系统上唯一的附加的绝对名。对使用其绝对名的对象的每个引用将引用同一对象。

公共名由应用程序指定。本地名由中介在运行时通过评估其上下文内的公共名来动态生成。系统不需生成绝对名，但可选择基于程序的依存性及其上下文关系。从不向应用程序告知绝对名。由中介负责将本地名映射到绝对名，以及将正确的公共名映射到本地名，反之亦然。

当存在上下文时，如果同一上下文中的两个应用程序使用相同的公共名创建并访问对象，则它们将能够引用同一对象。中介负责连接对象请求。存在连接这些请求的若干方法。在较佳实施例中，中介层通常将选择以相同方式在同一上下文中散列对象名。某些其它操作可仅通过将请求重定向给不同名字的对象来履行。对松散连接的上下文中的应用程序，系统所使用的功能允许系统利用快速搜索方法来定位对象并在对象之间进行关联。在较佳实施例中，使用利用本地结果高速缓存的分布式查找以快速解析名字。

在系统的示例中，程序可尝试利用在三个位置中可用的资源。首先，它在程序的主配置、以及次级依存配置中可用。它也可作为操作系统的一部分。在我们的示例中，将选择文件MSCOMCTL.OCX。正常地，该资源具有公共名C:\Windows\System32\MSCOMCTL.OCX。使用操作系统防护，中介层允许该名字存在于所有三个配置中。对所有配置，该对象的公共名相同。

中介层允许所述程序具有使用相同名字的对象的副本。此外，次级配置可具有使用不同名字的对象，但在其配置中指定向系统告知该对象的公共名为C:\Windows\System32\MSCOMCTL.OCX的虚拟化命令。这允许操作系统防护在除实际使用对象的名字空间或存储位置以外的不同名字空间或存储位置中存储对象，在运行时映射这些名字空间以浮现其行为。

在该示例中，所有三个对象具有相同的公共名。上下文解析过程将选择哪一对象实际优先。然后，系统将生成或使用正确本地化的名字。在这种情况中，系统将能够选择主配置中的对象，并选择在该程序实例的上下文内映射本地名。

随着上下文的范围变大并变宽，系统也能够提供名字空间管理器508功能来创建、查询以及检索名字空间映射。当程序正常地尝试使用公共名来利用资源时，管理器能够使用具有该公共名的资源查询其关于其它程序的列表。如果其它程序中的任何一个共享上下文，则这然后可由上下文管理器使用。如果这样，则可进行映射以确保共享程序使用同一资源。这可通过强制对同一本地名的使用或通过对系统绝对名的使用来完成。这对延伸至超出机器边界以外的上下文尤其有用。

注意，该操作可导致检索名字空间容器并加载其中所包含的资源的元数据的加载器509的副作用。由于资源可具有可变化的生存周期，因此名字空间管理器508实现各种资源管理操作，包括引用计数/跟踪、容器的加载和定型，在某些情况中还包括预测虚拟化(speculative virtualization)。

预测虚拟化是在对文件、注册表键或其它资源进行的诸如读和写操作的操作期间使用的进程。当资源被打开或查询时，系统可假定该资源稍后将被更改，且可执行附加的策略以确定诸如写的进一步操作将在该系统中产生什么影响。系统然后可提前或在后台中执行这些操作以避免它们实际执行时造成的进一步的成本或延迟。与所有推测性操作一样，如果后续的操作未被执行，则系统必须能够撤销该动作。在本发明的实施例中，系统使用预测虚拟化以协助避免即写即复制(copy-on-write)操作的高成本。当文件被改变时，如果文件较大、文件在远程位置或这两者同时成立时，即写即复制语义可招致高成本。该过程允许即写即复制动作提早、在后台中进行以避免该操作的运行时成本。

该名字空间管理器也可在系统的管理层内操作，且可以是在操作系统防护内操作的同一实际管理器，但可被配置成应答系统范围的查询。或者它可以是专用应用程序。该管理功能起到提供已配置绝对名的仓库并将它们映射到大范围上下文的作用。

该名字空间管理器还可管理每个名字空间内的名字的时间演变。这可用于确保即使用于散列的标准算法可能包括时间变量，每次也都以同一方式散列特定对象名。通过这样做，可向操作提供时间敏感的上下文或语义。此外，这可通过在系统内存储使用和映射信息来完成。

如果一对象在过去由程序在一个接口处请求，且现有同一名字的新接口可用，则该时间敏感行为可确保系统映射至老接口。这作为系统中的默认进行。如果期望映射至新接口，则能够声明性断言对新版本的使用。当存在具有多个版本的软件系统以及诸如此处所考虑的一系统时，能够确保恰以由软件系统的创作者或管理者配置的方式来创建并使用资源。

作为相关示例，众多系统使用分布式功能调用，诸如DCOM或CORBA或甚至HTTP RPC。两个程序可被配置成彼此依存，这允许进行通信。用于连接程序的公共名包含地址和接口。在DCOM的情况中，存在主宿分布式查询及其COM UID以便公告其接口的机器。主机的公共名可已经映射至本地名。当远程程序试图对主机和UID寻址时，系统可将地址和UID均映射成对应于该本地名，或者它可激活替换主机来确保提供了接口的正确版本。如上所述，远程程序所使用的公共名到主机所使用的本地名的映射可由系统通过在名字空间管理器内查找资源的绝对名或者通过向主机系统的名字空间管理器查询其公共到本地名映射来内部地完成。如果接口的次级版本存在，则名字空间管理器能够以反映远程激活的合适版本的替换映射来响应。

上下文策略

以上注意到，需要合适的机制来管理其中操作可横跨多个上下文的情况。这些互操作的本质可引起命名冲突，造成有必要决定优先级顺序的情况或用于解析改变操作的影响的情况。系统管理员、或在需要的情况中最终用户或软件厂商建立用于控制操作的策略的能力是与以上定义的上下文的存在性正交的。期望提供对上下文宏观和微观调节的能力以便进行迅速配置但粒度精细的控制的能力。

本发明的系统的实施例提供经由基于XML的配置文件描述应用程序与操作系统的相互依存性的手段。本领域的技术人员应理解，该过程可按照众多方式提高，在此处仅描述一种。

在图8的系统中，应用程序A具有配置文件a.config 408，而应用程序B具有配置文件b.config 409、以及在c.config 410中描述的共享资源集。为了建立程序之间的相互依存性，<CONTEXT>命令被置于a.config 408中，以指示这两个程序应在共享上下文内共同存在。在该示例中，上下文是名为EXAMPLE、上下文范围为Peer(对等)的Shared(共享)上下文。

在系统中，不需要在两个程序描述中均有该标签才能使其被使用。只有在它需被评估时才需如此，它必须具有特定安全性域内的相关性。因此，除非用户对这两个程序均有权限，否则可与另一程序共享的该程序将不会建立上下文。

此外，可提供协助理解和评估上下文的系统。作为示例，如果需要受管上下文，则系统要求理解哪些系统参与该上下文。这或者可由上下文的每一成员评估，或者可由系统范围的服务全局评估，且当评估该上下文时将其提供给每一机器。这在之前作为上下文管理器系统及其管理接口部分描述。本发明的系统通过允许创建与软件包描述分开来描述上下文关系的策略文件来推动这种行为。

策略文件可用于创建系统的默认行为，或建立供系统使用的基本上下文。在任何时候，系统可将策略加载或重载至其策略引擎，供其子系统使用。可应用允许策略仅被应用于特定用户、分组、机器或其它相关配置的其它修饰符(modifier)和变量。可以理解，对此技术可应用任何数量的变型以便控制这些策略的应用，但基本的控制是决定上下文是否要被应用以及其运行时行为是什么。策略也可被数字签署以确保其在整个系统中的完整性，并避免用户创作更改上下文行为的策略。

在单独配置项级，系统也能够指定仅向上下文控制展示特定资源。这种利用在两个程序需要通信且仅需能够连接其通信接口而不需理解任何配置细节时极其有用。而且，这有助于将一个程序修改另一程序的能力圈在(corral)总体配置的小子集中。在当前示例中，共享资源集在c.config中声明存在它用作资源\\pipe\testresource的主机的会话上下文。与该资源集运行在相同会话中的任何应用程序可利用该命名资源，并可在HKLM\Software\Test\Value处查看其别的配置数据。在本发明的实施例中，如果任何特定资源被命名，则仅这些资源被共享。否则，当没有指定任何资源时，所有资源隐含根据上下文指示被共享。

策略指示也有助于定义操作类的结果。这种类型的指示的一个简单的示例是声明对Windows Registry的任何修改应进入用户的个人设置名字空间容器内的策略。这种类型的策略允许交叉剪接(cross-cutting)不仅应用于特定应用程序而且还应用于多个上下文以及多个名字空间和容器的定义。

也对所有上下文配置允许修饰符，它允许每一规范为只读或读写的。默认行为是上下文专用的。此外，在允许对知晓上下文的关联进行写的情况中，重要的是标识写将在哪一上下文内进行。这将在稍后更详细讨论。然而，配置文件可覆盖系统的正常行为以指定特定目标。

本发明的系统所提供的另一修饰符是覆盖所建立的上下文的优先级的顺序的能力。可在对等之间确定任何特定关系。在这种情况中，信息的所有者自然负责信息生存周期。然而，可能期望进行修改的程序仅在其自身内看到修改。如果两个程序位于共享上下文内，则修改将不以这种方式持久化。修饰符可强制进行该替换行为。

确定和控制上下文

为了系统可实行，它必须提供确定最佳行为的某种自动化手段。默认地，操作系统防护将程序配置成在隔离上下文中存在，除非程序被明确打包成位于同一上下文内。打包在同一应用程序环境下的所有程序应共享该一个上下文。然而期望进一步自动化如上所述的可互操作的上下文的创建。本发明的系统提供检测并配置这些上下文的若干手段以及用于控制行为的策略。

在应用程序安装期间，系统允许安装直接配置其目标上下文。在虚拟安装软件或操作系统防护的情况中，这是特定程序的隔离上下文。将对所安装的一个或一组应用程序特别创建新的配置环境。通过向系统指示增强现有配置的期望，诸如在现存应用程序的上下文内执行安装程序，安装将以加性的方式在环境内进行。

对以诸如经由ESD系统的标准手段分发并安装的软件，该软件正常地将被安装到本地系统上下文内。与操作系统防护的系统相对，正常地，应用程序级软件和操作系统存在于机器内的相同位置处。在较佳实施例的系统中，软件可被配置成被安装到安装时所选的单独上下文内。正常地，取决于所期望的行为，这将是厂商、用户或会话上下文之一，但可以是可用上下文中的任何一个。作为示例，由厂商Microsoft提供的所有软件可被安装在Microsoft应用程序的上下文内。

使用这种方法，系统可将安装的对象重定向到替换存储位置，并创建在运行时映射的公共名。这允许在不损害机器或其隐含的对象名字空间的情况下，将应用程序安装到机器上。系统也可允许将软件安装到重定目标的系统、虚拟机、仿真环境或目的地主机，以便在实际安装到目标机器上之前创建配置。这允许在运行时创建虚拟环境，而不需为虚拟安装准备软件的先验步骤。

如在以往的应用中所述，一旦安装完成，操作系统防护将下载其配置。在该下载期间，可针对某些模式分析该配置。这些模式被用于装备程序并从公共命名问题中抽象程序。作为示例，众多程序当被安装时“个性化”其自身，并将关于安装用户或该程序曾运行其上的机器的信息写到其配置内。系统移除这些本地名，并使用公共名替代。或者，如果程序在其安装期间创建了ODBC DSN，则系统将知道要创建对ODBC子系统的适当版本的创建依存性。

这些模式可在安装期间被实况启用。这些模式可以是应用程序专用模板或通用的经验规则。一示例是安装到Microsoft Office内的程序将搜索HKEY_LOCAL_MACHINE\Software\Microsoft\Office注册表键。实现这些方法的系统可提供实现这些模板的内部规则或可安装模板的可配置集合。

在本发明的实施例中，搜索Microsoft Office的程序可查询以上命名注册表键。在该查询期间，如果Microsoft Office软件被安装在本地机器上，则将在该新软件包内创建依存性以确保Office存在供该程序使用且创建了一上下文以确保程序在本地机器上彼此可见。如果Microsoft Office软件是虚拟安装包的一部分，则系统将在其名字空间管理器内找到该注册表键，并找到该新软件包可能需要与之互操作的上下文的列表。然后能够创建对虚拟包的依存性并创建互操作的共享上下文。

在本发明的实施例中，可用软件包被存储在一个或多个仓库中。配置和上下文信息可由系统的上下文管理器容易地查询。当进行请求时，可针对整个仓库为候选上下文和依存性匹配该请求。在Microsoft Office示例的情况下，系统不需模板，而是将对Microsoft Office的查询解析为从仓库内的应用程序传入。系统然后能够实例化Office应用程序及其配置，并为正安装的程序创建上下文和依存性。

默认地，系统试图尽可能地严格，仅以共享所需的那些资源配置开放或共享度尽可能低的上下文。提供接口以更改上下文策略和配置，并迅速消除资源级命令以及设置包范围共享或改变上下文。

考虑到可应用本发明的原理的各种实施例，应理解，示出的实施例仅是示例性的，且不应用作限制本发明的范围。例如，流程图的步骤可按照不同于所述的顺序采取，且可在示意图中使用更多或更少的特征。尽管本发明的各个特征被描述为以软件实现，但可替换使用硬件或固件实现的其它实施例，反之亦然。

对本领域的普通技术人员而言，显然用于经由上下文策略控制来控制应用程序间关联的系统和方法中所涉及的方法可被具体化成包括计算机可用介质的计算机程序产品。例如，这样的计算机可用介质可包括可读存储器设备，诸如硬盘驱动器设备、CD-ROM、DVD-ROM或计算机磁盘，其上存储计算机可读程序代码片段。计算机可读介质也可包括通信或传输介质，诸如总线或其上承载程序代码片段作为数字或模拟数据信号的光学、有线或无线通信链路。

其它方面、修改和实施例位于所附权利要求书范围之内。

Claims (15)

1.一种用于控制多个软件应用程序和资源的互操作的方法，所述方法包括：

截取从第一应用程序到第二应用程序或资源的通信；

将所述通信定向至上下文管理系统；

生成所述通信的上下文候选列表；

根据为这些上下文定义的至少一个策略评估所述候选列表以标识所述通信的结果动作和名字空间；以及

在所标识的名字空间内如由所述至少一个策略所定义地执行所述动作。

2.如权利要求1所述的方法，其特征在于，还包括跟踪所述第二应用程序的一个或多个版本。

3.如权利要求1所述的方法，其特征在于，还包括跟踪应用程序和/或资源名的演变。

4.如权利要求1所述的方法，其特征在于，还包括：

标识与所述候选列表上的上下文相关联的一个或多个操作；以及

在进一步通信之前执行所标识的一个或多个操作。

5.如权利要求1所述的方法，其特征在于，所述生成候选列表的步骤包括从一个或多个分布式的上下文中提供上下文。

6.如权利要求1所述的方法，其特征在于，通信包括进程间通信、操作系统调用、API调用或库调用的至少之一。

7.如权利要求1所述的方法，其特征在于，上下文包括全局上下文、受管上下文、本地系统上下文、系统虚拟上下文、厂商上下文、用户上下文、会话上下文、共享上下文和隔离上下文的至少之一。

8.如权利要求1所述的方法，其特征在于，所述至少一个策略包括用于标识何时应用所述策略的匹配助记法、多个请求相关参数以及用于应用所述策略的规则的至少其中之一。

9.一种用于定义将在其它应用程序或资源内执行的应用程序的替换名字空间的方法，所述方法包括：

截取对公共名资源的调用；

标识所述调用的目标名字空间；

将所述公共名转换成可由所述名字空间内的应用程序使用的本地名；以及

提供对由所述本地名标识的资源的访问。

10.如权利要求9所述的方法，其特征在于，还包括跟踪应用程序的一个或多个版本。

11.如权利要求9所述的方法，其特征在于，还包括跟踪应用程序或资源名的演变。

12.如权利要求9所述的方法，其特征在于，所述本地名也可被转换成绝对名，使得对由所述本地名标识的资源的访问可简化成对由替换名字空间中的不同本地名标识的资源的访问。

13.如权利要求9所述的方法，其特征在于，所述标识目标名字空间的步骤包括一个或多个分布式查询。

14.如权利要求13所述的方法，其特征在于，对所述目标名字空间的至少一个查询可对跟踪一个或多个系统公用的名字空间的管理系统执行。

15.一种用于控制多个软件应用程序和资源的互操作的系统，所述系统包括：

生成通信的上下文的候选列表的上下文管理系统；

根据为所述上下文定义的至少一个策略评估所述候选列表的策略引擎，所述策略引擎还标识所述通信的结果动作和名字空间；以及

将所述通信从第一应用程序定向到第二应用程序或资源的虚拟环境管理器，所述虚拟环境管理器接收指示所标识名字空间内由所述至少一个策略定义的结果动作的指令。

Images