用于由应用程序访问由操作系统所提供的资源的方法和系统的制作方法

专利名称：用于由应用程序访问由操作系统所提供的资源的方法和系统的制作方法
技术领域：
本发明涉及管理由计算机对软件应用程序的执行，并且特别涉及用于降低在不同的应用程序之间和由相同的计算机系统执行的相同应用程序的单独用户之间的兼容性并且和社交性问题的方法和设备。
背景技术：
计算机软件应用程序，在执行和安装期间，充分利用由计算机的操作系统提供的各种本机资源。传统的单用户计算机描绘在图1A中。如图1A所示的，操作系统100提供的本机资源可能包括文件系统102，注册表数据库104和对象106。文件系统102为应用程序提供打开、创建、读取、拷贝、修改和删除数据文件150、152的机制。数据文件150，152可以被在目录160、162的逻辑分层结构中编组在一起。注册表数据库104存储关于在物理上附联到计算机的硬件、哪些系统选项已经被选择、计算机存储器怎样设立、应用程序专用数据的各种项目以及当操作系统100被起动之时应该存在什么应用程序的信息。如图1A所示的，注册表数据库104被公共地组织在″键″170、172的逻辑分层结构，″键″170，172是注册表值的容器。操作系统100还可以提供多个多个通信和同步对象106，包括信号量，分段，互斥体，定时器，变异株(mutant)以及管道。通过操作系统100而变为可用的文件系统102、注册表数据库104、对象106以及任何其他本机资源一起在贯穿本文献自始至终都将被称为″系统层″108。由系统层108提供的资源对于任何应用程序或者系统程序112、114都是可用的。
然而，当试图去执行或者安装两个不兼容应用程序112，114之时，就会出现问题。如图1A所示的，两个应用程序APP1 112和APP2 114，在操作系统100的“顶上”执行，也就是说，所述应用程序充分利用由操作系统提供来访问本机资源的函数。当所述应用程序在执行期间或者在安装过程期间以相互排斥的方式充分利用本机资源102，104，106之时，就说所述应用程序相互之间是不兼容的。APP1 112可能需要或者可能尝试去安装，位于路径名为c:\windows\system32\msvcrt.dll的文件，并且APP2 114可能需要或者可能尝试去安装位于相同路径名的第二不同文件。在此情况下，APP1 112和APP2 114无法在相同的计算机上加以执行，就说它们相互之间是不兼容的。对于其他本机资源，也可能会遇到类似的问题。这对于需要在相同操作系统100环境中一起安装或者执行APP1 112和APP2 114这二者的计算机用户而言，再怎么好也是不方便的。
图1B描绘了支持代表若干用户并发执行的应用程序112，114，112′，114′的多用户计算机系统。如图1B所示的，APP1的第一实例112和APP2的第一实例114在第一用户会话的上下文110中执行，APP1的第二实例112′在第二用户会话的上下文120中执行，并且APP2的第二实例114′在第三用户会话的上下文130中执行。在此环境中，如果APP1的两个实例112，112′和APP2的两个实例114，114′充分利用本机资源102，104，106，就好像只有单个用户执行所述应用程序一样，在此时就会出现问题。例如，APP1 112可以把应用程序专用数据存储在注册表键170中。当在第一用户上下文110中执行的APP1的第一实112和在第二用户上下文120中执行的APP1 1第二实例112′的都试图去把配置数据存储到相同的注册表键170之时，就将会为一个用户存储不正确的配置数据。对于其他本机资源，也会发生类似的问题。
本发明致力于解决这些应用程序的兼容性和社交性问题。

发明内容
本发明允许在单个计算机上安装和执行相互不兼容的应用程序和相同应用程序的不兼容版本。除此之外，它还允许在多用户计算机上安装和执行曾为单用户计算机所创建的或者曾在不考虑当在多用户计算机执行之时出现的那些问题的情况下所创建的程序。所描述的方法和设备可应用于单用户计算环境，所述单用户计算环境包括多个用户可以相继地使用单个计算机的环境以及多个用户并发地使用单个计算机的多用户计算环境。本发明虚拟化对本机资源(诸如文件系统，注册表数据库，系统对象，窗口类和窗口名称)的用户和应用程序访问，而不用修改应用程序或者基础的操作系统。除此之外，虚拟化的本机资源可以按照本机格式存储(也就是说，虚拟化的文件被存储在文件系统中，虚拟化的注册表条目被存储在注册表数据库中，等等)，这样就允许查看和管理虚拟化的资源能够使用标准工具和技术来实现。
在一个方面，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的方法。对资源和与该资源相关联的标识符的请求由在应用程序隔离环境之内执行的进程接收。确定所请求的资源驻留在应用程序隔离环境之外的位置。对资源和与该资源相关联的标识符的请求被重定向到所确定的位置。使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
在另一个方面，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的方法。对资源和与该资源相关联的标识符的请求被接收。在应用程序隔离环境之内执行的进程确定所请求的资源驻留在应用程序隔离环境之外的位置。对资源和与该资源相关联的标识符的请求被重定向到所确定的位置。使用驻留在所确定位置中的资源的实例来应答对资源的请求。
在再一个方面，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的方法。对资源和与该资源相关联的标识符的请求被接收。确定所请求的资源驻留在应用程序隔离环境之外的位置。在应用程序隔离环境之内执行的进程把对资源和与该资源相关联的标识符的请求重定向到所确定的位置。使用驻留在所确定的位置中的资源的实例来应答对资源的请求。
在再又一个方面，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的方法。对资源和与该资源相关联的标识符的请求被接收。确定所请求的资源驻留在应用程序隔离环境之外的位置。对该资源和与该资源相关联的标识符的请求被重定向到所确定的位置。在应用程序隔离环境之内执行的进程使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
在一个方面，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的系统，包括资源，第一进程，第二进程，第三进程和第四进程。第一进程在应用程序隔离环境之内执行并且接收对该资源和与该资源相关联的标识符的请求。第二进程确定该资源驻留在应用程序隔离环境之外的位置。第三进程把对该资源和与该资源相关联的标识符的请求重定向到所确定的位置。第四进程使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
在另一个方面，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的系统，包括资源，第一进程，第二进程，第三进程和第四进程。第一进程接收对该资源和与该资源相关联标识符的请求。第二进程在应用程序隔离环境之内执行并且确定该资源驻留在应用程序隔离环境之外的位置。第三进程把对该资源和与该资源相关联标识符的请求重定向到所确定位置。第四进程使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
在再一个方面，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的系统，包括资源，第一进程，第二进程，第三进程和第四进程。第一进程接收对该资源和与该资源相关联的标识符的请求。第二进程确定该资源驻留在应用程序隔离环境之外的位置。第三进程在应用程序隔离环境之内执行并且把对该资源和与该资源相关联的标识符的请求重定向到所确定的位置。第四进程使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
在再又一个方面中，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的系统，包括资源，第一进程，第二进程，第三进程和第四进程。第一进程接收对该资源和与该资源相关联的标识符的请求。第二进程确定该资源驻留在应用程序隔离环境之外的位置。第三进程把对该资源和与该资源相关联的标识符的请求重定向到所确定的位置。第四进程在应用程序隔离环境之内执行并且使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
在一个方面，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的方法。对资源和与该资源相关联的标识符的请求由在应用程序隔离环境之外执行的进程接收。确定所请求的资源驻留在应用程序隔离环境之内。把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境。使用驻留在应用程序隔离环境之内的资源的实例来应答对该资源的请求。
在另一个方面，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的方法。接收对资源和与该资源相关联的标识符的请求。在应用程序隔离环境之外执行的进程确定所请求的资源驻留在应用程序隔离环境之内。把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境。使用驻留在应用程序隔离环境之内的资源的实例来应答对该资源的请求。
在又一个方面，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的方法。接收对资源和与该资源相关联的标识符的请求被接收。确定所请求的资源驻留在应用程序隔离环境之内。在应用程序隔离环境之外执行的进程把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境。使用驻留在应用程序隔离环境之内的资源的实例来应答对该资源的请求。
在再又一个方面，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的方法。接收对资源和与该资源相关联的标识符的请求。确定所请求的资源驻留在应用程序隔离环境之内。把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境。在应用程序隔离环境之外执行的进程使用驻留在应用程序隔离环境之内的资源的实例来应答对该资源的请求。
在一个方面，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的系统，包括资源，第一进程，第二进程，第三进程和第四进程。第一进程在应用程序隔离环境之外执行并且接收对该资源和与该资源相关联的标识符的请求。第二进程确定该资源驻留在应用程序隔离环境之内。第三进程把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境。第四进程使用驻留在应用程序隔离环境中的资源的实例来应答对该资源的请求。
在另一个方面，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的系统，包括资源，第一进程，第二进程，第三进程和第四进程。第一进程接收对该资源和与该资源相关联的标识符的请求。第二进程在应用程序隔离环境之外执行并且确定该资源驻留在应用程序隔离环境之内。第三进程把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境。第四进程使用驻留在应用程序隔离环境中的资源的实例来应答对该资源的请求。
在又一个方面，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的系统，包括资源，第一进程，第二进程，第三进程和第四进程。第一进程接收对对资源和与该资源相关联的标识符的请求。第二进程确定该资源驻留在应用程序隔离环境之内。第三进程在应用程序隔离环境之外执行并且把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境。第四进程使用驻留在应用程序隔离环境中的资源的实例来应答对该资源的请求。
在再又一个方面，本发明涉及一种用于由应用程序访问由操作系统所提供的资源的系统，包括资源，第一进程，第二进程，第三进程和第四进程。第一进程接收对资源和与该资源相关联的标识符的请求。第二进程确定该资源驻留在应用程序隔离环境之内。第三进程把对资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境。第四进程在应用程序隔离环境之外执行并且使用驻留在应用程序隔离环境中的资源的实例来应答对该资源的请求。
在一个方面，本发明涉及一种把应用程序与隔离环境相关联的方法。请求的应用程序的位置被获得。在请求的应用程序和应用程序隔离环境之间的关联被创建。该关联被存储。把所请求的应用程序启动到应用程序隔离环境之中。
在一个实施例中，获得所请求的应用程序的位置包括定位在第二应用程序隔离环境上的所请求的应用程序。在另一实施例中，把该关联创建在所请求的应用程序和第二应用程序隔离环境之间。
在另一个方面，本发明涉及一种用于把应用程序与隔离环境相关联的环境，包括应用程序隔离环境，重定向器和关联。该应用程序隔离环境包括应用程序隔离范围和用户隔离范围。该重定向器获得由代表用户执行的进程所做出的对该应用程序的请求，获得该请求的应用程序所驻留在的位置，并且把来自所确定的位置的所请求的应用程序启动到应用程序隔离环境之中。在所请求的应用程序和应用程序隔离环境之间的关联由重定向器来维持。
在一个实施例中，该重定向器驻留在应用程序隔离环境上。在另一实施例中，该重定向器定位在第二应用程序隔离环境上的所请求的应用程序。在又一个实施例中，该重定向器查阅在所请求的应用程序和所请求的应用程序所驻留在的位置之间的存储的关联，用以确定所请求的应用程序所驻留在的位置。在再一个实施例中，该重定向器包括文件系统过滤器驱动器。


本发明用后附的权利要求中特别地点出。以上所描述的本发明的优点以及发明本的其他优点通过参考结合附图所给出的以下描述可以得到更好的理解，在附图中图1A是支持代表用户的两个应用程序的执行的现有技术操作系统环境的框图；图1B是支持代表若干用户的多个应用程序的并发执行的现有技术操作系统环境的框图；图2A是应用程序兼容性和社交性问题已经降低的计算机系统的实施例的框图；图2B是应用程序兼容性和社交性问题已经降低的计算机系统的实施例的图；图2C是示出把进程与隔离范围关联所采取的步骤的一个实施例的流程图；图3A是示出虚拟化对计算机系统中的本机资源的访问所采取的步骤的一个实施例的流程图；图3B是在执行模式中识别替换实例所采取的步骤的一个实施例的流程图；图3C是描绘当接收到一个用于打开本机资源的请求之时(该请求表明该资源正在被打开目的是去修改它)识别文字(literal)资源而在安装模式下所采取得步骤的一个实施例的流程图；图3D是描绘当接收到一个创建虚拟资源的请求之时识别文字资源而在安装模式下所采取的步骤的一个实施例的流程图。
图4是描绘在所描述的虚拟化的环境中打开文件系统中的条目所采取的步骤的一个实施例的流程图；图5是描绘在所描述的虚拟化环境中从文件系统删除条目所采取的步骤的一个实施例的流程图；图6是描绘在所描述的虚拟化环境中列举文件系统中的条目所采取的步骤的一个实施例的流程图；图7是描绘在所描述的虚拟化环境在文件系统中创建条目所采取的步骤的一个实施例的流程图；图8是描绘在所描述的虚拟化环境中打开注册表键所采取的步骤的一个实施例的流程图；
图9是描绘在所描述的虚拟化环境中删除注册表键所采取的步骤的一个实施例的流程图；图10是描绘在所描述的虚拟化环境中列举注册表数据库中的键的子键所采取的步骤的一个实施例的流程图；图11是在所描述的虚拟化的环境中创建注册表键所采取的步骤的一个实施例的流程图描绘；图12是描绘虚拟化对命名对象的访问所采取的步骤的一个实施例的流程图；图13是描绘在所描述的环境中虚拟化窗口名称和窗口类所采取的步骤的一个实施例的流程图；图13A是描绘确定文字窗口名称和窗口类名称所采取的步骤的一个实施例的流程图；图14是描绘在所描述的虚拟化环境中调用进程外COM服务器所采取的步骤的一个实施例的流程图；图15是使用文件类型关联来虚拟化应用程序调用所采取的步骤的一个实施例的流程图；以及图16是描绘把进程从源隔离范围移动到目标隔离范围所采取的步骤的一个实施例的流程图。
索引索引的目的是帮助读者遵循对本发明的论述1.0隔离环境概念概述1.1应用程序隔离1.2用户隔离1.3本机资源的聚合视图1.4进程与隔离范围之间的关联1.4.1范围外的进程与隔离范围之间的关联2.0虚拟化机制概述3.0在隔离环境中的安装4.0详细的虚拟化示例4.1文件系统虚拟化4.1.1文件系统打开操作
4.1.2文件系统删除操作4.1.3文件系统列举操作4.1.4文件系统创建操作4.1.5短文件名称管理4.2注册表虚拟化4.2.1注册表键打开操作4.2.2注册表键删除操作4.2.3注册表键列举操作4.2.4注册表创建操作4.3命名对象虚拟化操作4.4窗口名称虚拟化4.5进程外COM服务器虚拟化4.6虚拟化的文件类型关联4.7进程在隔离环境之间的动态移动具体实施方式
1.0隔离环境概念概述1.1应用程序隔离现在参考图2A，示出了在应用程序兼容性和应用程序社交性问题已经降低了的操作系统100的控制下运行的计算机的一个实施例。操作系统100经由它的系统层108使应用程序112，114可以使用各种本机资源。系统层108所包括的资源的视图将被称为术语″系统范围″。为了避免应用程序112，114访问本机资源102，104，106，107产生冲突，就提供了隔离环境200。如图2A所示，隔离环境200包括应用程序隔离层220和用户隔离层240。从概念上讲，隔离环境200经由应用程序隔离层220给应用程序112，114提供唯一的本机资源视图，所述本机资源诸如文件系统102，注册表104，对象106和窗口名称107。每个隔离层修改提供给一个应用程序的本机资源视图。由一个层所提供的本机资源的修改视图被称为该层的″隔离范围″。如图2A所示的，所述应用程序隔离层包括两个应用程序隔离范围222，224。范围222代表提供给应用程序112的本机资源的视图，范围224代表提供给应用程序114的本机资源的视图。因此，在图2A所示出的实施例中，给APP1 112提供有文件系统102′的专用视图，同时还给APP2 114提供有文件系统102″的也是专用的另一个视图。在一些实施例中，应用程序隔离层220给执行在操作系统100的顶部上的每个单独应用程序提供本机资源102，104，106，107的专用视图。在其他实施例中，可以把应用程序112，114编组成集合，在这些实施例中，应用程序隔离层220为每个应用程序集合提供本机资源的专用视图。可以把冲突的应用程序置于到相互独立的组中，用以增强应用程序的兼容性和社交性。在又一些实施例，属于一个集合的应用程序可以由于管理员加以配置。在一些实施例中，″直通″隔离范围能够被定义成确切地对应于系统范围。换言之，在直通隔离范围之内执行的应用程序直接地对系统范围操作。
在一些实施例中，还把应用程序隔离范围划分成分层的子范围。主子范围包含基础应用程序隔离范围，附加子范围包含对这一该应用程序的多个执行实例可见的范围的各种修改。例如，子范围可以对体现应用程序的补丁级别或者附加特征的安装或者除去的变化的范围的修改。在一些实施例中，可变为正在执行的应用程序的实例可见的附加子范围的集合是可配置的。在一些实施例中，那个可见的子范围的集合对于正在执行的应用程序的所有实例而言都是相同的，不管该应用程序正在代表哪个用户在执行着。在其他实施例中，可见的子范围集合对于正在执行该应用程序的不同用户可能会有变化。在另外的实施例，可以定义子范围的各种集合，并且对于要使用哪个集合，用户可以作出选择。在一些实施例中，当不再需要子范围之时，可以丢弃子范围。在一些实施例中，包含在子范围的集合中的修改可以归并在一起而形成单个子范围。
1.2用户隔离现在参考图2B，描绘了应用程序兼容性和应用程序社交性问题已经降低的多用户计算机。该多用户计算机在系统层108中包括本机资源102，104，106，107以及紧挨着的上面所论述的隔离环境200。应用程序隔离层220按照上面所描述的那样发挥作用，给应用程序或者应用程序组提供本机资源的修改视图。用户隔离层240，在概念上，给应用程序112，114提供以下本机资源视图，该本机资源视图还根据应用程序代表其执行的那个用户的用户身份标识作出改动。如图2B所示的，用户隔离层240可以被视为包括多个用户隔离范围242′，242″，242，242′，242″，242(总体上是242)。用户隔离范围242提供本机资源的应用程序专用视图的用户专用视图。例如，给在用户会话110中代表用户″a″执行的APP1 112提供一个文件系统视图102′(a)，该文件系统视图由用户隔离范围242″和应用程序隔离范围222这二者来改动或者修改。
换言之，用户隔离层240为每个单独用户通过把由用户隔离范围242所提供的用户专用视图修改”分层”在由应用程序隔离范围222所提供的应用程序专用视图修改上(它又被分层在由于系统层所提供的系统范围宽的本机资源视图上)来改动本机资源视图。例如，当APP1的第一实例112访问注册表数据库104的条目之时，就查阅第一用户会话和应用程序专用的注册表数据库104′(a)的视图。如果所请求的注册表键在注册表104′(a)的用户专用视图中找到了，那么就把该注册表键返回到APP1 112。如果没有找到，则查阅应用程序专用的注册表数据库104′的视图。如果所请求的注册表键在注册表104′的应用程序专用视图中找到了，那么就把该注册表键返回给APP1 112。如果没有找到，那么就把在系统层108中的注册表数据库104中所存储的注册表键(即，本机注册表键)返回给APP1 112。
在一些实施例中，用户隔离层240为每个单独用户提供隔离范围。在其他实施例中，用户隔离层240为用户组提供隔离范围，其可以用在组织之内的角色来定义或者可以由管理员预先确定。在又一些其他实施例中，不提供任何用户隔离层240。在这些实施例中，应用程序所看见的本机资源视图是由应用程序隔离层220所提供的本机资源视图。隔离环境200，尽管相对于支持由各种用户对应用程序的并发执行的多用户计算机加以描述，但是它也可以使用在单用户计算机上，用以致力于解决不同的用户在相同计算机系统上顺序的执行应用程序所导致的应用程序兼容性和社交性问题以及相同用户安装和执行不兼容程序所导致的那些问题。
在一些实施例中，用户隔离范围还被划分成子范围。由用户隔离范围对呈现给在那个范围执行的应用程序的视图的修改是包含在该范围中的子范围之内的修改的聚合。子范围被分层在相互的顶上，并且在该聚合视图中，对更高子范围中的资源的修改重载对在更低层中相同资源的修改。
在这些实施例中的一些实施例中，这些子范围中的一个或者多个可以包含对用户专用的视图的修改。在这些实施例中的一些实施例中，一个或者多个子范围可以包含对用户集合专用的视图的修改，用户集合可以由系统管理员定义，或者在操作系统中定义为用户组。在这些实施例中的一些实施例中，这些子范围之一可以包含特定的登录会话专用的视图的修改，并且因此在当该会话结束之时丢弃它们。在这些实施例中的一些实施例中，与用户隔离范围相关联的应用程序实例对本机资源的改变总是影响这些子范围之一，并且在其他实施例中，那些变化可以影响不同的子范围，这取决于所改变的特定资源。
1.3本机资源的聚合视图以上描述的概念上的体系结构允许向代表用户执行的应用程序呈现本机资源的聚合或者统一的虚拟化视图(该视图是应用程序和用户的组合专用的)。此聚合的视图可以被称为″虚拟的范围″。向代表用户执行的应用程序实例呈现反映本机资源的所有可操作的虚拟化实例的本机资源的单个视图。概念上，此聚合的视图首先由操作系统在系统范围所提供的本机资源集合组成，该本机资源集合与包含在适用于执行的应用程序的应用程序隔离范围中的修改相重叠，还与包含在适用于代表用户执行的应用程序的用户隔离范围中的修改相重叠。系统范围中的本机资源特征在于对于该系统上的所有用户和应用程序都是共用的，除了操作系统权限拒绝对特定用户或者应用程序访问的地方之外。对包含在应用程序隔离范围中的资源视图的修改的特征在于对与那个应用程序隔离范围相关联的应用程序的所有实例都是共用的。对包含在用户隔离范围中的资源视图的修改的特征在于对与适用的应用程序隔离范围相关联并且代表与用户隔离范围相关联的用户执行的所有应用程序都是共用的。
此概念能够扩展到子范围；对包含在用户子范围中的资源视图的修改对于与适用的隔离子范围相关联并且代表与用户隔离子范围相关联的用户或者用户组执行的所有应用程序都是共用的。在贯穿此说明书自始至终，应该理解的是每当总体上参考″范围″之时，在范围和子范围都存在之处，它也预计指子范围。
当应用程序请求列举本机资源(诸如文件系统或者注册表数据库的一部分)之时，虚拟化的列举通过首先列举本机资源的″系统范围″的实例，即在系统层中可见的实例(如果存在的话)来构造。接着，列举所请求的资源的″应用程序范围″的实例，也即，在适当的应用程序隔离范围中所找到的实例(如果存在的话)。在应用程序隔离范围中所遇见的任何列举的资源都被添加到该视图。如果所列举的资源已经存在于该视图中(因为它过去也存在于该系统范围中)，那么就把它替换成在应用程序隔离范围中所遇见的资源的实例。类似地，列举所请求的资源的″用户范围″的实例，也即，在适当的用户隔离范围中所找到的实例(如果存在的话)果。再一次把在用户隔离范围中所遇见的任何列举的资源都添加到该视图。如果该本机资源已经存在于该视图中(因为它过去就存在于该系统范围中或者存在于该适当的应用程序隔离范围中)，那么就把它替换成在用户隔离范围中所遇见的资源的实例。照此，本机资源的任何列举都将正确地反映所列举的本机资源的虚拟化。概念上，相同的方法也适用于列举包括多个子范围的隔离范围。列举单独的子范围，在聚合视图中，来自更高子范围的资源替代来自的更低子范围的匹配实例。
在其他实施例中，列举可以从用户隔离范围层向下执行到系统层，而不是从系统层反过来执行到用户隔离范围层。在这些实施例中，列举用户隔离范围。然后，列举应用程序隔离范围并且把出现在应用程序隔离范围中但是未曾在用户隔离范围列举过的任何资源实例添加到构造中的该聚合视图。能够为仅仅出现在该系统范围中的资源重复一个类似的过程。
在又一些实施例中，所有隔离范围可以同时被列举并且各自的列举可以被分别组合。
如果一个应用程序试图去打开本机资源的一个已有实例，但是却没有修改该资源的目的，那么返回给该应用程序的专用实例就是在虚拟范围中所见的一个实例，或者等效地是在所请求的资源的双亲的虚拟化的列举中会出现的实例。根据隔离环境，该应用程序比方说正在请求去打开一个″虚拟的资源″，并且用于满足该请求的本机资源的特定实例比方说就是对应于所请求的资源的“文字资源″。
如果一个代表用户执行的应用程序试图去打开资源并且表明它正在这样做且目的是去修改该资源，那么应用程序实例通常就被给与一个要修改的那个资源的私有拷贝，原因在于在应用程序隔离范围和系统范围中的资源对于代表其他用户执行的应用程序而言是共用的。典型地，产生该资源的用户范围的拷贝，除非该用户范围的实例已经存在了。对由虚拟范围所提供的聚合视图的定义意味着把应用程序范围的或者系统范围的资源拷贝到用户隔离范围的动作并不为所关注的用户和应用，不为任何其他用户，不为任何其他应用程序实例而改变由虚拟范围所提供的聚合视图。由代表用户执行的应用程序实例对所拷贝的资源所做的后续的修改并不影响任何其他不共享相同的用户隔离范围的应用程序实例的聚合视图。换言之，那些修改并不为其他用户，也不为与相同的应用程序隔离范围不相关联的应用程序实例而改变本机资源的聚合视图。
1.4进程与隔离范围之间的关联应用程序可以被安装到特定的隔离范围中(以下更加详细地加以描述)。安装到隔离范围中的应用程序总是被与该范围相关联。作为选择，可以把应用程序启动到特定的隔离范围之中，或者启动到多个隔离范围中。实际上，一个应用程序被启动并且被与一个或者多个隔离范围相关联。该相关联的隔离范围，或者范围，给进程提供本机资源的特定视图。也可以把应用程序启动到系统范围之中，也就是说，可以不把它们与任何隔离范围相关联。这兼顾了在隔离环境之内选择性地执行操作系统应用程序(诸如Internet Explorer)以及第三方应用程序。
不管把应用程序安装在哪里而把应用程序启动到到隔离范围之内的这种能力减轻了应用程序兼容性和社交性问题，而不需要在隔离范围之内独立地安装该应用程序。这种选择性地把所安装的应用程序启动到不同的隔离范围中的能力提供了让需要助手应用程序的应用程序(诸如Word，Notepad等)具有让那些助手应用程序用相同的规则集合来启动的能力。
进而，把应用程序启动到多个隔离的环境之内的这种能力兼顾到在隔离的应用程序和公共应用程序之间能有更好地整合。
现在参考图2C，在简洁的总观中，一种用于把进程与隔离范围相关联的方法，包括把进程启动到挂起状态中(步骤282)的步骤。与所希望的隔离范围相关联的规则被获取(步骤284)，并且把该进程的标识符并且所获取的规则存储在存储器元件中(步骤286)，然后恢复所挂起的进程(步骤288)。拦截或者钩住由该进程所作出的对访问本机资源的后续的调用(步骤290)，并且与该进程标识符相关联的规则(如果存在的话)被使用来虚拟化对所请求的资源的访问(步骤292)。
还参考图2C，更详细地，把一个进程启动到挂起状态中(步骤282)。在一些实施例中，使用客户发动器程序来完成此任务。在这些实施例的一些中，该发动器特别地被设计成用于把一个进程启动到选定的隔离范围中。在其他实施例中，该发动器例如通过命令行选项接受所希望的隔离范围的规定而作为输入，。
与希望的隔离范围相关联的规则被获取(步骤284)。在一些实施例中，所述规则被从持久的存储元件(诸如硬盘驱动器或者其他固态存储器元件)中所获取。所述规则可以被存储为关系数据库，平面文件数据库，树形结构的数据库，二进制树结构，或者其他持久的数据结构。在其他实施例中，所述规则可以被存储在特别配置来存储它们的数据结构中。
进程的标识符，诸如进程id(PID)和所获取的规则被存储在存储器元件中(步骤286)。在一些实施例中，一个核心模式驱动器被提供，该核心模式驱动器接收关于新进程创建的操作系统消息。在这些实施例中，PID和所获取的规则可以被存储在驱动器上下文中。在其他实施例中，提供文件系统过滤器驱动器，或者微型过滤器，它拦截本机资源请求。在这些实施例中，PID和所获取的规则可以存储在该过滤器中。在其他实施例中，所有的拦截都通过用户模式挂钩来执行，并且根本就不存储任何PID。所述规则由用户模式挂钩设备在进程初始化期间来加载，并且任何其他组件都不需要去知道施加到该PID的规则，原因在于规则关联整个地是在进程中执行的。
所挂起的进程被恢复(步骤288)，并且拦截或者钩住由该进程作出的对访问本机资源的后续调用(步骤290)，并且与进程标识符相关联的规则(如果存在的话)被使用来虚拟化对所请求的资源的访问(步骤292)。在一些实施例中，文件系统过滤器驱动器或者微型过滤器，拦截对访问本机资源的请求并且确定与所拦截的请求相关联的进程标识符是否已经与一个规则集合相关联。如果已经相关联了，那么就使用与所存储的进程标识符相关联的规则来虚拟化请求访问本机资源的请求。如果还没有，那么就不加修改地让请求访问本机资源的请求通过。在其他实施例中，把动态链接库加载到新创建的进程中，并且该库加载隔离规则。在再一些其他的实施例中，核心模式技术(挂钩，过滤器驱动器，微型过滤器)和用户模式技术这二者都被使用来拦截对访问本机资源的调用。对于文件系统过滤器驱动器存储所述规则的实施例而言，该库可以从所述文件系统过滤器驱动器加载所述规则。
作为是与隔离范围相关联的进程的“孩子”的进程与它们的″双亲″进程的隔离范围相关联。在一些实施例中，当创建孩子进程之时，这是由核心模式驱动器通知文件系统过滤器驱动器来实现的。在这些实施例中，文件系统过滤器驱动器确定双亲进程的进程标识符是否与隔离范围相关联。如果是这样，那么文件系统过滤器驱动器就存储在新创建的孩子进程的进程标识符和双亲进程的隔离范围之间的关联。在其他实施例中，该文件系统过滤器驱动器能够被直接地从该系统调用，而不使用核心模式驱动器。在其他实施例中，在与隔离范围相关联的进程中，用于创建新进程的操作系统函数就被钩住或者拦截。当从这样的进程中接收到请求创建新进程的请求之时，在新孩子进程和双亲的隔离范围之间的关联就被存储。
在一些实施例中，范围或者子范围可以与单独的线程而不是整个进程相关联，这样就允许隔离以每个线程为基础地执行。在一些实施例中，可以为服务和COM+服务器使用每个线程的隔离。
1.4.1把范围外的进程与隔离范围相关联本发明的另一个方面在于能够把任何应用程序实例与任何应用程序隔离范围相关联起来，而不用管所述应用程序是安装到该应用程序隔离范围，安装到另一个应用程序隔离范围中还是没有安装在任何的应用程序隔离范围中。然而，没有被安装到特定应用程序范围中的应用程序在应用程序隔离范围和相应的用户隔离范围的上下文中也能够代表用户执行，原因在于它们的本机资源通过由用户隔离范围，应用程序隔离范围和系统范围所形成的聚合的虚拟范围可以由它们使用。在希望去在隔离范围中运行应用程序的情况下，这样就提供使直接地安装到系统范围中的应用程序能够在隔离范围之内运行而不需要相独立地把应用程序安装在隔离范围之内的能力。这样也提供能够在任何隔离范围的上下文中把直接地安装到系统范围中的应用程序用作助手应用程序。
每个应用程序实例，包括组成执行的应用程序的所有进程，与零个或者一个应用程序隔离范围相关联，并且通过扩展确切地与零个或者一个对应的用户隔离范围相关联。此关联由规则引擎在确定要把哪个规则(如果有的话)施加到资源请求之时使用。关联不必是针对应用程序安装到的那个应用程序隔离范围(如果有的话)。安装到隔离范围中的许多应用程序当运行在不同的隔离范围或者没有运行在隔离范围中之时将不能够正确地发挥作用，原因在于它们无法找到必要的本机资源。然而，因为隔离范围是包括系统范围的资源视图的聚合，所以安装在系统范围中的应用程序在任何应用程序隔离范围之内一般都能够发挥正确的作用。这就意味着助手程序以及进程外COM服务器，都能够由代表用户在特定隔离范围中执行的应用程序加以调用和执行。
在一些实施例中，安装在系统范围中的应用程序执行在隔离范围中，目的是为了把对计算机的文件和配置设定做了哪些改变识别为此执行的结果。因为所有受到影响的文件和配置设定被在用户隔离范围中隔离开，所以这些文件和配置设定是很容易就被识别的。在这些实施例的一些实施例中，这一点用在报告对由应用程序对文件和配置设定所作出的改变上。在一些实施例中，所述文件和配置设定被在应用程序执行结束之时删除，这样就有效地确保了对计算机的文件和配置设定的任何改变都不会被存储为应用程序执行的结果。在再一些其他的实施例中，所述文件和配置设定被选择性地删除，或者在应用程序的执行结束之时不被删除，这就有效地确保了对计算机的文件和配置设定的变化仅有一些才被存储为应用程序执行的结果。
2.0虚拟化机制概述现在参考图3A，示出了在执行模式中虚拟化对本机资源的访问所要采取的步骤的一个实施例，所述执行模式在以下将区别于安装模式。在简短的概述中，拦截或者接收用以访问本机资源的请求(步骤302)。所述请求标识访问要寻找的那个本机资源。确定关于如何对待所接收的访问请求的适用规则(步骤304)。如果该规则表明该请求应该被忽略，那么就让该访问请求通过，而不对系统层做修改(步骤306)，然后把返回给请求者(步骤310)。如果该规则表明对于该访问请求应该被重定向或者被隔离，那么就识别满足该请求的资源的文字实例(步骤308)，把对文字资源的修改或者替换请求传递到系统层(步骤306)，然后把该结果返回给请求者(步骤310)。
还参考图3，更详细地，拦截或者接收标识本机资源的请求(步骤302)。在一些实施例中，对本机资源的请求通过由操作系统为应用程序提供的用以产生本机资源请求的″挂钩″函数所拦截。在特定的实施例中，这被实现为动态链接库，该动态链接库被加载到由操作系统所创建的每个新进程的地址空间中，并且它在其初始化例程期间执行挂钩。把DLL加载到每一个进程中可以经由操作系统所提供的工具来实现，或者作为选择，通过修改DLL的可执行映象列表以便导入到磁盘文件中或者当该进程的可执行映象被从磁盘中加载之时导入到存储器中来实现。在其他实施例中，功能挂钩由服务，驱动器或者守护进程(daemon)来执行。在其他实施例中，对由操作系统所提供的可执行映象(包括共享库和可执行文件)可以做修改或者打补丁，以便提供功能挂钩或者直接地包括本发明的逻辑。对于该操作系统是微软WINDWOS操作系统系列中的一个操作系统的特定实施例而言，拦截可以通过核心模式驱动器挂钩系统服务分派表来执行。在再一些其他的实施例中，该操作系统可以提供允许第三方能够去挂钩用于请求访问本机资源的函数的工具。在这些实施例的一些实施例中，该操作系统可以经由应用程序编程接口(API)或者调试工具提供此工具。
在其他实施例中，本机资源请求被与本机资源相关联的驱动器堆栈或者处理程序堆栈中的过滤器拦截。例如，微软WINDOWS操作系统系列中的一些操作系统具有能力来把第三方过滤器驱动器或者微型过滤器插入到文件系统驱动器堆栈中，并且文件系统过滤器驱动器或者微型过滤器可以被是用来提供以下描述的隔离功能。在再一些其他的实施例中，本发明包括能够直接地并入本发明的逻辑的文件系统实现方案。作为选择，可以改写操作系统以便能够直接地提供以下描述的功能。在一些实施例中，以上列出的用于拦截或者接收对资源的请求的方法的一些或者全部的组合可以被同时使用。
在许多实施例中，只有那些用于打开现有的本机资源或者创建新本机资源的请求才被钩住或者拦截。在这些实施例中，对本机资源的初始访问就是引起资源被虚拟化的访问。在初始访问之后，正在请求的应用程序能够使用操作系统所提供的直接地识别文字资源的句柄或者指针或者其他标识符与操作系统就虚拟化资源而相互通信。在其他实施例中，请求对虚拟化的本机资源操作的其他类型的请求也被钩住或者拦截。在这些实施例的一些实施例中，由应用程序打开或者创建虚拟资源的请求返回不直接地识别文字资源的虚拟句柄，并且该隔离环境负责针对虚拟句柄把后续的请求翻译成对应的文字资源。在那些实施例的一些实施例中，附加虚拟化操作能够被推迟，一直到证明确实需要才进行。例如，把资源的私有可修改的拷贝提供到隔离范围的操作就能够能够推迟，直到用于改变该资源的请求被产生为止，而不是当在允许后续修改的模式下该资源被打开之时就开始该操作。
一旦本机资源请求被拦截或者接收，那么用于确定关于如何处理该特定的请求的适用规则就被确定(步骤304)。最适用的规则可以通过参考规则引擎，数据库规则或者包含使用适当的数据结构(诸如列表或者树结构)所组织的规则的平面文件来确定。在一些实施例中，给与优先级赋予规则，用于当施加两个或者多个规则之时优先级确定哪条规则将被视为是最适用的。在这些实施例的一些实施例中，规则优先级被包括在规则它们自身中，或者，作为选择，规则优先级可以被嵌入在用于存储规则的数据结构，例如，规则优先级可以用规则在树结构的位置来指示。所确定的规则可以包括关于如何去处理虚拟化的资源请求(诸如像，要把请求重定向到哪些文字资源)的附加信息。在特定的实施例中，规则是三元项，包括过滤器字段，动作字段以及数据字段。在此实施例中，过滤器字段包括是用来匹配接收的本机资源请求以便确定该规则对于所请求的资源名称是否是有效的过滤器。动作字段能够是″忽略″，″重定向″或者″隔离″。数据字段可以是关于当规则是有效的之时要采取的动作的任何附加信息，包括当规则是有效的之时要使用的功能。
规则动作″忽略″意味着该请求直接地对系统范围中所请求的本机资源操作。也就是说，该请求被不加改动地传递到系统层108(步骤306)，并且对该请求的完成，就好像不存在任何的隔离环境200一样。在此情况下，就说隔离环境是具有一个″洞″，或者该请求可以被称为″直通″请求。
如果该规则动作表明本机资源请求应该被重定向或者隔离，那么就识别满足该请求的文字资源(步骤308)。
规则动作″重定向″意味着该请求直接地对系统范围的本机资源操作，不过该本机资源与在该请求中所指定的资源不同。文字资源通过把所确定的规则的数据字段中所指定的或者所隐含的映射功能施加到所请求的本机资源的名称来识别。在最一般的情况下，可以把文字本机资源定位在系统范围中的任何地方。举一个简单的例子，规则{prefix_match(″c:\temp\，资源名称)，REDIRECT，replace_prefix(″c:\temp\″，″d:\wutemp\″，资源名称)}将把对文件c:\temp\examples\d1.txt的请求的访问重定向到文字文件d:\wutemp\examples\d1.txt。包括在规则的数据字段的映射功能和匹配功能还可以推广，以例如通过使用正则表达式来支持复杂的行为。一些实施例可以提供规定用于在用户隔离范围或者适用于代表用户执行的应用程序的子范围或者应用程序隔离范围或者适用于应用程序的子范围之内定位文字资源的映射功能的能力。进一步实施例可以提供指定在在适用于不同的应用的应用程序隔离范围之内定位文字资源的映射功能以便提供在隔离应用程序之间受控的交互形式的能力。在一些特别的实施例中，″重定向″动作能够被配置成提供等效于″忽略″规则动作的行为。在这些实施例中，文字资源恰好就是所请求的本机资源。当此条件被配置之时，隔离环境可以说是具有一个″洞，″或者是请求可以被称为″直通″请求。
″隔离″规则动作意味着该请求对使用适当的用户隔离范围和应用程序隔离范围所识别的文字资源操作。也就是说，该文字资源的标识符通过使用用户隔离范围，应用程序隔离范围，这两个范围，或者任意范围都不使用地修改所请求的本机资源的标识符来加以确定。所识别的特定文字资源依赖于所请求访问的类型和所请求的本机资源的实例是否已经存在于适用的用户隔离范围，适用的应用程序隔离范围以及系统范围中。
图3B描绘当接收到用以打开本机资源的请求表明了该资源正在被打开目的是要修改它之时识别文字资源(图3A中的步骤306)所要采取的步骤的一个实施例。简言之，确定所请求的本机资源的用户范围的实例，也即，存在于适用的用户范围或者用户子范围中的实例是否存在(步骤354)。如果存在，那么用户范围的实例就被标识为是对该请求的文字资源(步骤372)，并且该实例被打开然后被返回给请求者。如果用户范围的实例不存在，那么就确定所请求的本机资源的应用程序范围的实例是否存在(步骤356)。如果应用程序范围的实例存在，那么就把它标识为是″候选″资源实例(步骤359)，然后检查与候选实例相关联的权限数据，以便确定是否允许修改该实例(步骤362)。如果不存在任何应用程序范围的实例，那么就确定所请求的本机资源的系统范围的实例是否存在(步骤358)。如果它不存在，那么就把错误条件返回给请求者，表明所请求的虚拟化资源并不存在于虚拟范围中(步骤360)。然而，如果系统范围的资源存在，那么就把它标识为是候选资源实例(步骤361)，并且检查与候选实例相关联的权限数据以便确定是否允许修改该实例(步骤362)。如果它不存在，那么就把错误条件返回给请求者(步骤364)，表明是否允许修改该虚拟化的资源。如果该权限数据表明可以修改候选资源，那么就对本机资源的候选实例做用户范围的拷贝(步骤370)，把用户范围的实例标识为是对该请求的文字实例(步骤372)，打开它然后把它返回给请求者。
还参考图3，更详细地，确定用户范围的资源是否存在，或者换言之，所请求的资源是否存在于适用的用户范围或者子范围中(步骤354)。适用的用户范围或者子范围就是被分层在与产生该请求的应用程序相关联的应用程序隔离范围上的与用户相关联的范围。用户隔离范围或者子范围，在文件系统的情况下，可以是存在于用户隔离范围中的所有文件所存储在的目录。在这些实施例的一些实施例中，在用户隔离目录下的目录树结构反映所请求的资源的路径。例如，如果所请求的文件是c:\temp\test.txt并且用户隔离范围目录是d:\user1\APP1\，那么到用户范围的文字文件的路径就可能是d:\user1\APP1\c\temp\test.txt。在其他实施例中，到用户范围的文字的路径可以按照本机命名惯例来定义。例如，到用户范围文字文件的路径可以d:user1\APP1\device\harddisk1\temp\test.txt。在再一些其他的实施例中，用户范围的文件都可以被存储在具有挑选成是唯一的名称的单个目录中，并且数据库可以被是用来存储在所请求的文件名称和在该目录中所存储的对应的文字文件的名称之间的映射。在再一些其他的实施例中，文字文件的内容可以被存储在数据库中。在再一些其他的实施例中，本机文件系统为单个文件提供工具，用以包含多个独立命名的″流″，并且用户范围文件的内容被存储在系统范围中的相关联文件的附加流。作为选择，文字文件可以被存储在顾客文件系统中，该顾客文件系统可以被设计成优化磁盘使用率或者感兴趣的其他准则。
如果用户范围的资源实例不存在，那么就确定应用程序范围的资源是否存在，或者换言之确定所请求的资源是否存在于应用程序隔离范围中(步骤356)。以上所描述的方法被使用来做此确定。例如，如果所请求的文件是c:\temp\test.txt并且应用程序隔离范围目录是e:\APP1\，那么到应用程序范围的文件的路径就可以是e:\APP1\c\temp\test.txt。如上，到应用程序范围的文件的路径可以被按照本机命名惯例存储。上述的实施例也可以应用到应用程序隔离范围。
如果应用程序范围的资源不存在，那么就确定系统范围的资源是否存在，或者换言之，确定所请求的资源是否存在于系统范围中(步骤358)。例如，如果所请求的文件是c:\temp\test.txt，那么到系统范围的文件的路径是c:\temp\test.txt。如果所请求的资源不存在于系统范围中，就把所请求的资源不存在于虚拟范围中的指示返回给请求者(步骤360)。
不管所请求的资源的候选资源实例被定位在应用程序隔离范围中还是定位在系统范围中，都确定是否允许修改候选资源实例(步骤362)。例如，候选本机资源实例可以具有相关联的本机权限数据，本机权限数据指示不允许那个用户修改候选实例。另外，规则引擎可以包括配置设定，配置设定用于指示隔离环境去遵从或者重载资源的虚拟化拷贝的本机权限数据。在一些实施例中，规则可以为为一些虚拟资源指定要在其中发生修改的范围，例如系统范围或者应用程序隔离范围或者子范围，或者用户隔离范围或者子范围。在一些实施例中，规则引擎可以根据分层结构或者根据所访问的资源类型指定施加到虚拟化的本机资源的子集的配置设定。在这些实施例的一些实施例中，配置设定对每个原子本机资源可以是专用的。在另一个例子中，规则引擎可以包括配置数据，配置数据用于禁止或者允许修改某些类文件(诸如可执行代码或者MIME类型或者操作系统所定义文件类型)。
如果在步骤362确定不允许修改候选资源实例，那么就把错误条件返回给请求者，表明不允许对虚拟资源的写访问(步骤364)。如果在步骤362确定允许修改候选资源实例，那么就把候选实例拷贝到适当的用户隔离范围或者子范围(步骤370)。对于在把所请求的本机资源的逻辑分层结构维持在隔离范围中的实施例而言，把资源的候选实例拷贝到用户隔离范围可能需要在用户隔离范围中创建分层结构占位符(placeholder)。分层结构占位符是一个被置于分层结构中用以正确在隔离范围中定位拷贝的资源的节点。分层结构占位符不存储任何数据，被标识为是占位符节点，并且从它不能够是返回给请求者的文字资源这个意义上讲，它是″不存在的″。在一些实施例中，通过把事实记录在附联到一个节点或者该节点的双亲或者附联到系统层中的某个其他相关实体的元数据来完成把该节点标识为占位符节点。在其他实施例中，占位符节点名称的相独立知识库被维持。
在一些实施例中，规则可以指定可以在特定范围(诸如应用程序隔离范围)修改特定资源。在那些情况下，扩展在步骤370的拷贝操作，以确定是否允许在找到候选资源实例的范围或者子范围中修改候选资源实例。如果不允许，那么就把候选资源实例拷贝到在其中允许修改它的范围或者子范围，该范围或者子范围可能不总是用户隔离范围，并且把新拷贝标识为是文字资源实例(步骤372)。如果是这样，就把候选资源实例标识为是文字实例(步骤372)，并且打开它并且把结果返回给请求者(步骤306)。
向回参考图3A，文字资源实例，不管它是在步骤354中被定位的还是在步骤370被创建的，都打开它(步骤306)并且和把它返回给请求者(步骤310)。在一些实施例中，这一点是通过向操作系统发出一个″打开″命令并且把来自操作系统对″打开″命令的响应返回给请求者来实现的。
如果代表用户执行的应用程序删除了本机资源，那么就把本机资源的聚合视图呈现给该应用程序(因为该虚拟范围必须反映该删除)。用于删除资源请求是用于特殊类型修改的请求，一个通过把资源的存在完全除去来修改资源的请求也是。概念上，用以删除资源的请求以类似于在图3A中所概述的方式来进行，包括按照在图3B中所概述的那样确定文字资源。然而，步骤306对于隔离的资源和对重定向或者忽略的资源有不同的操作。对于重定向和忽略而言，文字资源被从系统范围删除。对于隔离，文字资源被″虚拟地″删除，或者换言之，把它已经被删除这一事实记录在用户隔离范围中。删除的节点不包含任何数据，被标识为是删除的，并且它和它的所有后继都“不存在”。换言之，如果它是该资源或者是另外会满足资源请求的资源的祖先，那么″资源没有找到″错误就被返回给请求者。进一步的细节将在第4节中概述4。在一些实施例中，通过把事实记录在附联到一个节点或者该节点的双亲或者附联到系统层中的某个其他相关实体的元数据来完成把该节点标识为的删除节点。在其他实施例中，删除的节点名称的相独立的知识库被维持在例如相独立的子范围中。
3.0在隔离环境中的安装上述的应用程序隔离范围能够被视为在其中相关联应用程序实例独立于任何用户，或者代表所有可能用户的等效物而共享资源的范围，该资源包括那些应用程序实例创建的资源。这种资源的主类是当应用程序被安装到操作系统上之时所创建的集合。如图1A所示的，两个不兼容应用程序不能被安装在相同的系统范围中，但是此问题却能够通过把那些应用程序中的至少一个安装到隔离环境中来解决。
隔离范围，或者与隔离范围相关联的应用程序实例，能够在″安装模式″中被操作来支持对应用程序的安装。这与以下结合图4-16描述的″执行模式″形成相对比。在安装模式下，应用程序安装程序与应用程序隔离范围相关联并且假设是代表所有用户在执行。应用程序隔离范围对那个应用程序实例的动作，就好像它是″所有用户″的用户隔离范围，并且对于那个应用程序实例，没有任何用户隔离范围是活动的。
图3C描绘当接收到用以打开本机资源的请求表明文字资源正在被打开目的是为了修改它之时识别文字资源而在安装模式中所采取的步骤的一个实施例。简言之，因为没有任何用户隔离范围是活动的，所就首先确定所请求的本机资源的应用程序范围的实例是否存在(步骤374)。如果应用程序范围的实例存在，那么就把它标识文字资源实例(步骤384)。如果没有任何应用程序范围的实例存在，那么就确定所请求的本机资源的系统范围的实例是否存在(步骤376)。如果它不存在，那么就把错误条件返回给请求者，表明所请求的虚拟化资源不存在于虚拟范围中(步骤377)。然而，如果系统范围的资源存在，那么就把它标识为候选资源实例(步骤378)，并且检查与候选实例相关联的权限数据以确定是否允许修改那个实例(步骤380)。如果不允许，那么就把错误条件返回给请求者(步骤381)，表明不允许修改虚拟化的资源。如果权限数据表明可以修改候选资源，那么因为用户隔离范围是活动的，就进行本机资源的候选实例的应用程序范围的拷贝(步骤382)，并且把应用程序范围的实例标识为对该请求的文字实例(步骤384)。在一些实施例中，把候选文件拷贝到由规则引擎所定义的位置。例如，规则可以指定把该文件拷贝到应用程序隔离范围。在其他实施例中，规则可以指定应该把文件拷贝到的那个特定应用程序隔离子范围或者用户隔离子范围。没有出现把文件拷贝到的那个隔离范围中的所请求的文件的任何祖先都被创建为是在隔离范围中的占位符，以便正确地在分层结构中定位拷贝的实例。
图3D示出当接收到一个创建本机资源的请求之时识别文字资源而在安装模式下所采取的步骤的一个实施例。简言之，因为没有任何用户隔离范围是活动的，所以首先确定请求的本机资源的应用程序范围的实例是否存在(步骤390)。如果应用程序范围的实例存在，那么就可以把错误条件返回给请求者，表明该资源不能被创建(因为它已经存在)(步骤392)。如果不存在任何应用程序范围的实例，那么可以确定请求的本机资源的系统范围的实例是否存在(步骤394)。如果系统范围的实例存在，那么就可以把错误条件返回给请求者，表明该资源不能够被创建(因为它已经存在)(步骤392)。在一些实施例中，使用来打开资源的请求可以指定该资源的任何现存的系统范围的实例都可以被重写。如果系统范围的资源实例不存在，那么就可以应用程序范围的资源实例标识为是将为完成该请求而创建的文字实例(步骤396)。
通过比较图3B、图3C和3D，能够看出安装模式是以和执行模式相似的方式来操作的，伴随有应用程序隔离范围代替用户隔离范围。换言之，修改持久的资源，包括创建新资源，发生在适当的应用程序隔离范围中，而不是发生在适当的用户隔离范围中。而且，对访问现有的隔离的资源的虚拟化也忽略适当的用户隔离范围并且开始搜索在应用程序隔离范围中的候选文字资源。
有两个另外的情况，其中应用程序隔离范围以此方式操作以包含对现有的资源的修改和创建新资源。首先，可以是配置成在没有用户隔离层的情况下操作的隔离环境，或者是配置成在没有用户隔离范围的情况下操作的虚拟范围。在此情况下，应用程序隔离范围就是能够隔离修改和新创建的资源的仅有的隔离范围。其次，支配虚拟资源的特定集合的规则可以指定它们要被隔离到适当的应用程序隔离范围而不是隔离到适当的用户隔离范围中。此外，这意味着遵从该规则对资源的修改和创建将被隔离到适当的应用程序隔离范围中，其中它们对于共享那个范围的所有应用程序实例都是可见的，而不是被隔离到用户隔离范围中，其中它们仅仅对执行那些应用程序实例的用户是才见的。
在再一些其他的实施例中，隔离环境可以被配置成允许某些资源在系统范围中是被共享的，也就是说，隔离环境可以对于一个或者多个系统资源都有效，就好像不存在任何的用户隔离范围和应用程序隔离范围存在一样。当以修改为目的而访问在系统范围中共享的系统资源之时，就决不拷贝它们，因为它们被所有的应用程序和所有的用户共享着，即，它们是全局对象。
4.0详细的虚拟化示例上述的方法和设备可以使用来虚拟化范围宽的多种本机资源108。以下详细地描述它们。
4.1文件系统虚拟化上述的方法和设备可以使用来虚拟化对文件系统的访问。如上所述，文件系统普遍被组织在目录的逻辑分层结构，目录自身也是文件并且还可以包含其他目录和数据。
4.1.1文件系统打开操作在简要的概述中，图4描绘在上述的虚拟化的环境中打开文件所采取的步骤的一个实施例。请求打开文件的请求被接收或者拦截(步骤402)。该请求包含文件名称，它被隔离环境当作虚拟文件名称对待。适用于文件系统打开请求目标的处理规则被确定(步骤404)。如果规则动作是″重定向″(步骤406)，那么在该请求中所提供的虚拟文件名称就被依照适用的规则映射到文字文件名称(步骤408)。把用以使用文字文件名称打开文字文件的请求传递到操作系统并且把来自来自于操作系统的结果返回给请求者(步骤410)。如果取而代之规则动作是″忽略″(步骤406)，那么该文字文件名称就被确定为恰好是虚拟文件名称(步骤412)，并且把打开文字文件的请求传递到操作系统并且把来自于操作系统的结果返回给请求者(步骤410)。如果在步骤406该规则动作是″隔离″，那么就把对应于在用户隔离范围中的虚拟文件名称的文件名称标识为候选文件名称(步骤414)。换言之，候选文件名称通过把映射虚拟文件名称适用的用户隔离范围专用的对应本机文件名称来形成。候选文件的存在的类别通过检查用户隔离范围和与候选文件相关联的任何元数据来确定(步骤416)。如果候选文件被确定具有″负存在″(因为候选文件或者它的在用户隔离范围中的祖先目录之一被标记为是删除的)，那么这就意味着请求的虚拟文件已知是不存在的。在此情况下，就把表明请求的文件没有找到的错误条件返回给请求者(步骤422)。如果取而代之在步骤416候选文件被确定为具有″正存在″(因为候选文件存在于用户隔离范围中并且没有被标记为是占位符节点)，那么该请求的虚拟文件就已知是存在的。把该候选文件标识为是对该请求的文字文件(步骤418)，并且把所发出的用于打开文字文件的请求和结果返回给请求者(步骤420)。然而，如果在步骤416，候选文件具有″中性存在″(因为候选文件不存在或者因为候选文件存在，但是却被标记为是占位符节点)，那么就还不知道该虚拟文件存在还是不存在。在此种情况下，就把对应于虚拟文件名称的应用程序范围的文件名称标识为候选文件名称(步骤424)。换言之，候选文件名称通过把虚拟文件名称映射对适用的应用程序隔离范围专用的对应本机文件名称来形成。候选文件的存在的类别通过检查应用程序隔离范围和与候选文件相关联的任何元数据来确定(步骤426)。如果候选文件被确定为具有″负存在″(因为候选文件或者它在应用程序隔离范围中祖先目录被标记为是删除的)，那么这就意味着所请求的虚拟文件已知是不存在的。在此情况下，把表明所请求的文件没有被发现错误条件返回给请求者(步骤422)。如果取而代之在步骤426候选文件被确定为具有″正存在″(因为候选文件存在于应用程序隔离范围中并且没有被标记为是占位符节点)，那么请求的虚拟文件就已知是存在的。检查该请求以确定打开请求是否表明目的是修改文件(步骤428)。如果不是，那么就把该候选文件标识为对该请求的文字文件(步骤418)，并且把所发出的打开文字文件的请求和结果返回给请求者(步骤420)。然而，在步骤428，如果确定出打开请求表明目的是修改该文件，那么就检查与该文件相关联的权限数据以确定是否允许修改该文件(步骤436)。如果不允许，那么就把错误条件返回给请求者(步骤438)表明不允许修改该文件。如果权限数据表明可以修改该文件，那么就把候选文件拷贝到用户隔离范围(步骤440)。在一些实施例中，把候选文件拷贝到由规则引擎所定义的位置。例如，规则可以指定把该文件拷贝到应用程序隔离范围。在其他实施例中，规则可以指定应该把该文件拷贝到的那个特定应用程序隔离子范围或者用户隔离子范围。没有出现在把该文件拷贝到的那个隔离范围中的请求的文件的任何祖先都被创建为是在隔离范围中的占位符，以便正确地在分层结构中定位拷贝的实例。该范围的实例被标识为是文字文件(步骤442)并且把发出的打开文字文件的请求和结果返回给请求者(步骤420)。返回到步骤426，如果候选文件具有中性存在(因为候选文件不存在，或者因为候选文件被查找到来但是却被标记为是占位符节点)，那么还尚不知道虚拟文件是存在还是不存在。在此情况下，把对应于虚拟文件名称的系统范围的文件名称标识为是候选文件名称(步骤430)。换言之，该候选文件名称确切地就是虚拟文件名称。如果候选文件不存在(步骤432)，那么就把表明虚拟文件未被找到的错误条件返回给请求者(步骤434)。如果相反候选文件存在(步骤432)，就检查该请求以确定打开请求是否表明目的是修改该文件(步骤428)。如果不是，就把候选文件标识为是对该请求的文字文件(步骤418)，并且把所发出的打开文字文件的请求和结果返回给请求者(步骤420)。然而，如果，在步骤428，确定出该打开请求表明目的是修改该文件，那么就检查与该文件相关联的权限数据以确定是否允许修改该文件(步骤436)。如果不允许，就把错误条件返回给请求者(步骤438)，表明不允许修改该文件。如果该权限数据表明可以修改该文件，就把候选文件拷贝到用户隔离范围(步骤440)。在一些实施例中，把该候选文件拷贝到由规则引擎所定义的位置。例如，规则可以指定把该文件拷贝到应用程序隔离范围。在其他实施例中，规则可以指定应该把该文件拷贝到的那个特定应用程序隔离子范围或者用户隔离子范围。没有出现在隔离范围中请求的文件的任何祖先被创建为是在隔离范围中的占位符，以便正确地在分层结构中定位拷贝的实例。该范围的实例被标识为是文字文件(步骤442)并且把所发出的打开文字文件请求和结果返回给请求者(步骤420)。
此实施例能够稍做修改，用以检查文件的存在而不是打开文件。把在步骤420中尝试打开文字文件替换成检查该文字文件的存在并且把状态返回给请求者。
还参考图4，并且现在更详细地，打开虚拟文件的请求被接收或者拦截(步骤402)。对应的文字文件可以属于用户隔离范围，应用程序隔离范围或者系统范围，或者可以把它的范围定到应用程序隔离子范围或者用户隔离子范围。在一些实施例中，该请求被代替操作系统功能或者代替用于打开文件的功能的功能钩住。在另一个实施例，挂钩动态链接库被使用来拦截该请求。挂钩函数可以执行在用户模式中或者执行在核心模式中。对于挂钩函数执行在用户模式中的实施例而言，当创建一个进程之时，挂钩函数可以被加载到该进程的地址空间中。对于挂钩函数执行在核心模式中的实施例而言，挂钩函数可以与在分派对本机文件的请求中使用的操作系统资源相关联。对于为每种类型的文件操作都提供相独立的操作系统函数的实施例而言，每个函数都可以被相独立地钩住。作为选择，可以提供单个挂钩函数，用以拦截对若干类型的文件操作的创建或者打开调用。
该请求包含文件名称，该文件名称被隔离环境作为虚拟文件名称来对待处理。通过查阅规则引擎来确定适用于文件系统打开请求的处理规则(步骤404)。在一些实施例中，使用包括在打开请求中的虚拟名称来确定适用于打开请求的处理规则。在一些实施例中，可以把规则引擎提供为是关系数据库。在其他实施例中，规则引擎可以是树形结构的数据库，哈希表，或者平面文件数据库。在一些实施例中，把为请求的文件所提供的虚拟文件名称用作进入规则引擎中用以定位施加到该请求的一个或者多个规则的索引。在这些实施例的特别实施例中，对于特别的文件，多个规则可以存在于规则引擎中，并且，在这些实施例中，与虚拟文件名称具有最长前缀匹配的规则就是施加到该请求的规则。在其他实施例中，进程标识符被使用来在规则引擎中定位施加到该请求的规则(前提是如果存在一条规则的话)。与一个请求相关联的规则可以是去忽略该请求，重定向该请求，或者隔离该请求。尽管在图4示为单个数据库事务或者在一个文件中的单个查找，但是规则查找可以作为一个规则查找系列来执行。
如果规则动作是″重定向″(步骤406)，那么就依照适用的规则把在该请求中所提供的虚拟文件名称映射到文字文件名称(步骤408)。把用于打开用文字文件名称所标识的文字文件的请求传递到操作系统并且把来自于操作系统的结果返回给请求者(步骤410)。例如，打开名称为″file_1″的文件的请求可以导致打开名称为″Different_file_1″的文字文件。在一个实施例中，这是通过调用原始版本的挂钩函数并且把形成的文字名称传递给该函数作为参数来实现的。对于使用文件系统过滤器驱动器的实施例而言，使用虚拟名称打开文件的第一请求导致从文件系统过滤器驱动器返回STATUS_REPARSE的响应，表明所确定的文字名称。I/O管理器然后用包括在STATUS_REPARSE响应中的确定的文字名称来重新发出文件打开请求。
如果取而代之规则动作是″忽略″(步骤406)，那么文字文件名称就被确定为确切地是虚拟文件名称(步骤412)，并且把打开文字文件的请求传递到操作系统并且把来自于操作系统的结果返回给请求者(步骤410)。例如，打开名称为″file_1″的文件的请求将导致打开实际上名称为″file_1″的文件。在一个实施例中，这是通过调用原始版本的挂钩函数并且把所形成的文字名称传递到该函数作为参数来实现的。
如果在步骤406规则动作是″隔离″，那么就把对应于虚拟文件名称的用户范围的文件名称标识为是候选文件名称(步骤414)。换言之，候选文件名称是通过把虚拟文件名称映射到适用的用户隔离范围专用的对应本机文件名称来形成的。例如，打开名称为″file_1″的文件的请求可能导致打开实际上名称为″Isolated_file_1″的文件。在一个实施例中，这是通过调用原始版本的挂钩函数并且把形成的文字名称传递给该函数作为参数来实现的。对于使用文件系统过滤器驱动器的实施例而言，使用虚拟名称打开文件的第一请求导致从文件系统过滤器驱动器返回STATUS_REPARSE响应，表明确定的文字名称。I/O管理器然后使用包括在REPARSE响应中的确定的文字名称重新发出文件打开请求。
在一些实施例中，为隔离请求的系统文件而形成的文字名称可以基于所接收的虚拟文件名称和范围专用的标识符。范围专用的标识符可以是与应用程序隔离范围、用户隔离范围、会话隔离范围、应用程序隔离子范围、用户隔离子范围或者以上各项的某一组合相关联的标识符。范围专用的标识符被使用来″弄乱(mangle)″在该请求中所接收的虚拟名称。
在其他实施例中，用户隔离范围或者子范围可以是一个目录，在该目录下存储存在于用户隔离范围中的所有文件。在这些实施例的一些实施例中，用户隔离目录之下的目录树结构反映所请求的资源的路径。换言之，文字文件路径是通过把虚拟文件路径映射到用户隔离范围来形成。例如，如果所请求的文件是c:\temp\test.txt并且用户隔离范围目录是d:\user1\APP1\，那么到用户范围的文字文件的路径就可以是d:\user1\APP1\c\temp\test.txt。在其他实施例中，到用户范围的文字的路径可以按照本机命名惯例加以定义。例如，到用户范围的文字文件的路径可以是d:\user1\APP1\device\harddisk1\ternp\test.txt。在再一些其他的实施例中，用户范围的文件都可以被存储具有挑选成是唯一的名称的单个目录，并且数据库可以被使用来存储在请求的文件名称和存储在该目录中的对应文字文件的名称之间的映射。在再一些其他的实施例中，文字文件的内容可以被存储在数据库中。在再一些其他的实施例中，本机文件系统为单个文件提供工具，用以包含多个独立命名的″流″，并且用户范围的文件的内容被存储为在系统范围中的相关联文件的附加流。作为选择，文字文件可以被存储在顾客文件系统中，该顾客文件系统可以被设计成用于优化磁盘使用率或者感兴趣的其他准则。
通过检查用户隔离范围和与候选文件相关联的任何元数据来确定候选文件的存在的类别(步骤416)。如果候选文件被确定具有″负存在″(因为候选文件或者它在用户隔离范围中的祖先目录之一被标记为是删除的)，那么这意味着请求的虚拟文件已知是不存在。在此情况下，把表明请求的文件没有被发现的错误条件返回给请求者(步骤422)。
在一些实施例中，关于文件的少量元数据可以被直接地存储在文字文件名称中，诸如通过用元数据指示符给该虚拟名称加上后缀，此处元数据指示符是唯一与特定的元数据状态相关联的字符串。元数据指示符可以指明元数据的一个或者若干比特或者对其编码。用虚拟文件名访问文件以检查由于存在元数据指示符的原因而导致可能的文字文件名的变化的请求，和获取文件自身的名称的请求被钩住或者拦截，以便用文字名称作出应答。在其他实施例中，该文件的一个或者多个备用名称可以根据虚拟文件名称并且元数据指示符来形成，并且可以使用由文件系统所提供的硬链路或者软链路工具来创建。如果给出了一个请求用以使用链路的名称来访问文件，那么隔离环境可以通过表明该文件没有被发现而向应用程序隐瞒这些链路的存在。特定链路的存在或者缺失可以为每个元数据指示符指明元数据的一个比特，或者可以有一个这样的链路，具有能够表现为多个状态以指明元数据的若干比特的元数据指示符。在再一些其他的实施例中，其中文件系统支持备用文件流，备用文件流可以被创建出来以包括元数据，流的大小表明元数据的若干比特。在再一些其他的实施例中，文件系统可以直接地提供为文件系统中的每个文件都存储某个第三方元数据的能力。
在这些实施例中的特定的一些实施例中，删除的文件或者文件系统元素的列表可以被维持并且可以被查阅，用以优化对删除的文件的这一检查。在这些实施例中，如果删除文件被重新创建，那么该文件名称就可以被从删除的文件的列表中除去。在这些实施例的其他实施例中，如果该列表增长到超过某一大小，那么就可以从该列表中除去文件名称。
如果取而代之在步骤416候选文件被确定为具有″正存在″(因为候选文件存在于用户隔离范围中并且没有被标记为是占位符节点)，那么该请求的虚拟文件就已知是存在的。把候选文件标识为是对该为该请求的文字文件(步骤418)，并且把所发出的用以打开文字文件的请求和结果返回给请求者(步骤420)。
然而，如果在步骤416，候选文件具由有″中性存在″(因为候选文件不存在，或者因为候选文件存在但是却被标记为是占位符节点)，那么就还尚不知道虚拟文件是存在还是不存在。在此情况下，把对应于虚拟文件名称的应用程序范围的文件名称标识为是候选文件名称(步骤424)。换言之，候选文件名称是通过把虚拟文件名称映射到适用的应用程序隔离范围专用的本机文件名称来形成。候选文件的存在的类别通过检查应用程序隔离范围和与候选文件相关联的任何元数据来确定(步骤426)。
如果应用程序范围的候选文件被确定为具有″负存在″(因为候选文件或者它在应用程序隔离范围中的祖先目录之一被标记为是删除的)，这就意味着请求的虚拟文件已知是不存在的。在此情况下，把表明请求的文件没有被发现的错误条件返回给请求者(步骤422)。
如果在步骤426候选文件被确定为具有″正存在″(因为候选文件存在于应用程序隔离范围并且没有被标记为是占位符节点)，那么该请求的虚拟文件就已知是存在的。检查该请求以确定该打开请求是否表明目的是修改文件(步骤428)。如果不是，那么就把候选文件标识为是对该请求的文字文件(步骤418)，并且把所发出的用以打开文字文件的请求和结果返回给请求者(步骤420)。
然而，如果在步骤428，确定出打开请求表明目的是修改该文件，那么就检查与该文件相关联的权限数据以确定是否允许修改该文件(步骤436)。在一些实施例中，该权限数据被与应用程序范围的候选文件相关联。在这些实施例的一些实施例中，把权限数据存储在规则引擎中或者存储在与该候选文件相关联的元数据。在其他实施例中，与候选文件相关联的权限数据由操作系统提供。另外，规则引擎可以包括配置设定，用于指示隔离环境遵从或者重载对资源的虚拟化拷贝的本机权限数据。在一些实施例中，规则可以为一些虚拟资源指定要在其中发生修改的范围，例如系统范围或者应用程序隔离范围或者子范围，或者用户隔离范围或者子范围。在一些实施例中，规则引擎可以根据分层结构或者所访问的资源类型指定施加到虚拟化的本机资源的子集的配置设定。在这些实施例的一些实施例中，配置设定对每个原子本机资源可以是专用的。在另一个例子中，规则引擎可以包括配置数据，用于禁止或者允许修改某些类文件(诸如可执行代码或者MIME类型或者由操作系统所定义的文件类型)。
如果与候选文件相关联的权限数据表明它不可以被修改，那么就把错误条件返回给请求者(步骤438)，表明修改文件不被允许。如果权限数据表明该文件可以被修改，那么将把该候选文件拷贝到用户隔离范围(步骤440)。在一些实施例中，把候选文件拷贝到由规则引擎所定义的位置。例如，规则可以指定把该文件拷贝到另一个应用程序隔离范围。在其他实施例中，规则可以指定应该把文件拷贝到的那个特定应用程序隔离子范围或者用户隔离子范围。没有出现在把该文件拷贝到的那个隔离范围中的请求的文件的任何祖先都被创建为是在隔离范围中的占位符，以便正确地在分层结构中定位该拷贝的实例。
在一些实施例中，元数据被与拷贝到隔离范围的文件相关联，它标识拷贝该文件的日期和时间。此信息可以被使用来比较与该文件的拷贝的实例相关联的时间标记和上次修改该文件的原始实例的时间标记或者上次修改位于更低隔离范围中的该文件的另一个实例的时间标记。在这些实施例中，如果该文件的原始实例或者位于更低隔离范围中的该文件的实例与晚于该拷贝的时间标记的时间标记相关联，那么就可以把该文件拷贝到隔离范围，用以更新该候选文件。在其他实施例中，该文件在隔离范围中的拷贝可以与标识包含被拷贝过的原始文件的范围的元数据相关联。
在进一步的实施例中，可以监视拷贝到隔离范围的文件(因为该文件已经被打开目的是修改它们)，以确定它们实际上是否被修改了。在一个实施例中，拷贝的文件可以被与当该文件被实际地修改之时所指定的标志相关联。在这些实施例中，如果拷贝的文件实际上没有被修改，那么就可以在把它关闭之后把它从它被拷贝到的范围以及与该拷贝的文件相关联的任何占位符中除去。
该范围的实例被标识为是文字文件(步骤442)并且把所发出的用以打开文字文件的请求和结果返回给请求者(步骤420)。
返回到步骤426，如果该候选文件具有中性存在(因为候选文件不存在，或者如果该候选文件被找到但是被标记为是占位符节点，那么还尚不知道虚拟文件是存在还是不存在。在此情况下，把对应于虚拟文件名称的系统范围的文件名称标识为是候选文件名称(步骤430)。换言之，候选文件名称恰好虚拟文件名称。
如果该候选文件不存在(步骤432)，就把表明虚拟文件未被找到的错误条件返回给请求者(步骤434)。如果相反该候选文件存在(步骤432)，那么将检查该请求以确定该打开请求是否表明目的是去修改该文件(步骤428)。
如上所述，如果候选文件正在被打开而目的不是去修改它，那么就把系统范围的候选文件标识为是对该请求的文字文件(步骤418)，并且把所发出的用以打开文字文件的请求和结果返回给请求者(步骤420)。然而，如果在步骤428，确定该打开请求表明目的是去修改该文件，那么就检查与该文件相关联权限数据，以确定是否允许修改该文件(步骤436)。在一些实施例中，权限数据与系统范围的候选文件相关联。在这些实施例的一些实施例中，权限数据被存储在规则引擎中或者被存储在与该候选文件相关联的元数据中。在其他实施例中，与候选文件相关联权限数据由操作系统提供。
如果与系统范围的候选文件相关联的权限数据表明该文件不可以被修改，那么就把错误条件返回给请求者(步骤438)，表明不允许修改该文件。然而，如果该权限数据表明文件可以被修改，那么就把该候选文件拷贝到用户隔离范围(步骤440)。在一些实施例中，把该候选文件拷贝到由规则引擎所定义的位置。例如，规则可以指定把该文件拷贝到应用程序隔离范围或者可以把它留在系统范围中。在其他实施例中，规则可以指定应该把该文件拷贝到的那个特别的应用程序隔离子范围或者用户隔离子范围。没有出现在隔离范围中的该请求的文件的任何祖先被创建为是在隔离范围中的占位符，以便正确地在分层结构中定位该拷贝的实例。
在一些实施例中，元数据与拷贝到隔离范围的文件相关联，它标识拷贝该文件之时的日期和时间。此信息可以被使用来比较与该文件的拷贝实例相关联的时间标记和上次修改该文件的原始实例时间标记。在这些实施例中，如果该文件的原始实例与晚于该拷贝文件的时间标记的时间标记相关联，那么原始文件就可以被拷贝到隔离范围，以更新该候选文件。在其他实施例中，拷贝到隔离范围的候选文件可以与标识从其拷贝了该原始文件的范围的元数据相关联。
在进一步实施例中，可以监视拷贝到隔离范围的文件(因为该文件已经被打开目的是修改它们)，以确定它们实际上是否被修改了。在一个实施例中，拷贝的文件可以被与当该文件被实际地修改之时所设定的标志相关联。在这些实施例中，如果拷贝的文件实际上没有被修改，那么就可以在把它关闭之后把它从它被拷贝到的范围以及与该拷贝的文件相关联的任何占位符中除去。在再一个实施例中，仅仅当该文件被实际地修改之时才把该文件拷贝到适当的隔离范围。
把该范围实例标识为是文字文件(步骤442)并且把所发出的用以打开文字文件的请求和结果返回给请求者(步骤420)。
4.1.2文件系统删除操作现在参考图5，在一个简洁的概况中，描绘了删除文件所采取的步骤的一个实施例。用以删除文件的请求被接收或者拦截(步骤502)。该请求包含文件名称，该文件名称被隔离环境当作虚拟文件名称对待处理。规则确定如何来处理文件操作(步骤504)。如果规则动作是″重定向″(步骤506)，那么就依照该规则把该虚拟文件名称直接地映射到文字文件名称(步骤508)。把用以删除文字文件的请求传递到操作系统并且把来自于操作系统的结果返回给请求者(步骤510)。如果该规则动作是″忽略″(步骤506)，那么就把文字文件名称标识为确切地就是虚拟文件名称(步骤513)，并且把删除文字文件的请求传递到操作系统并且把来自于操作系统的结果返回给请求者(步骤510)。如果该规则动作是″隔离″(步骤506)，那么就确定该虚拟文件的存在(步骤514)。如果该虚拟文件不存在，那么就把错误条件返回给请求者，表明该虚拟文件不存在(步骤516)。如果该虚拟文件存在，并且如果该虚拟化的文件指定目录而不是指定通常的文件，那么就查阅虚拟目录以确定它是否包含任何虚拟文件或者虚拟子目录(步骤518)。如果所请求的虚拟化文件是一个包含任何虚拟文件或者虚拟子目录的虚拟目录，那么该就不能够删除该虚拟目录并且返回一个错误消息(步骤520)。如果该请求的虚拟化文件是通常的文件或者是一个不包含任何虚拟文件也不包含任何虚拟子目录的虚拟目录，那么就标识对应于该虚拟文件的文字文件(步骤522)。检查与该文件相关联的权限数据以确定是否允许删除(步骤524)。如果不允许，那么就返回一个权限错误消息(步骤526)。然而，如果允许删除该文件，并且如果该文字文件就处在适当的用户隔离范围中(步骤528)，那么就删除该文字文件(步骤534)并且在该适当的用户隔离范围中创建代表该删除的虚拟文件的″删除″节点(步骤536)。然而，如果在步骤528确定出该文字文件不处于用户隔离范围中，但是却处于适当的应用程序隔离范围或者系统范围中，那么就创建不存在的请求文件的用户范围的实例的每个用户范围的祖先的实例并且把该它标记为是占位符(步骤532)。这么做是为了在用户隔离范围中维持目录结构的逻辑分层结构。然后在适当的用户隔离范围中创建代表该删除的虚拟文件的用户范围的″删除″节点(步骤536)。
还参考图5，更详细地，用于删除文件的请求被接收或者拦截(步骤502)。该文件可能属于用户隔离范围，应用程序隔离范围，系统范围，或者某个适用的隔离子范围。在一些实施例中，该请求被代替操作系统函数或者用以删除文件的函数的函数钩住。在另一个实施例中，挂钩动态链接库被使用来拦截该请求。挂钩函数可以执行在用户模式下，也可以执行在核心模式下。对于挂钩函数执行在用户模式下的实施例而言，当创建一个进程之时，该挂钩函数可以被加载到该进程的地址空间中。对于在该挂钩函数执行在核心模式下的实施例而言，该挂钩函数可以被与在分派对本机文件的请求中所使用的操作系统资源相关联。对于在为每一类型的文件都提供相独立的操作系统函数的实施例而言，每个函数可以被独立地钩住。作为选择，可以提供单个挂钩函数，它拦截对若干类型文件的创建或者打开调用。
该请求包含文件名称，它被隔离环境当做虚拟文件名称对待处理。通过查阅规则引擎来确定适用于删除操作的处理规则(步骤504)。在一些实施例中，为该请求的文件所提供的虚拟文件名称被使用来在规则引擎中定位施加到该请求的规则。在这些实施例中的特别实施例中，对特别的文件，多个规则可以存在于规则引擎，在这些实施例中，与虚拟文件名称具有最长前缀匹配的规则就是施加到该请求的规则。在一些实施例中，规则引擎可以被提供为是关系数据库。在其他实施例中，规则引擎可以是树形结构的数据库，哈希表或者平面文件数据库。在一些实施例中，在该请求中所提供的虚拟文件名称被用作进入到规则引擎中用以定位施加到该请求的一个或者多个规则的索引。在其他实施例中，进程标识符被使用来在规则引擎中定位施加到该请求的规则(如果存在一条规则的话)。与一个请求相关联的规则可以是去忽略该请求，重定向该请求，或者隔离该请求。尽管在图5中示为一系列的判定，但是规则查找可以作为单个数据库事务而发生。
如果该规则动作是″重定向″(步骤506)，那么就依照适用的规则把该虚拟文件名称直接地映射到文字文件名称(步骤508)。把删除文字文件的请求传递到操作系统并且把来自于操作系统的结果返回给请求者(步骤510)。例如，用以删除名称为″file_1″的文件的请求可以导致删除实际上名称为″Different_file_1″的文件。在一个实施例中，这是通过调用原始版本的挂钩函数并且该所形成的文字名称传递到该函数作为参数来实现的。对于使用文件系统过滤器驱动器的实施例而言，使用虚拟名称删除文件的第一请求导致从文件系统过滤器驱动器返回STATUS_REPARSE响应，表明确定的文字名称。I/O管理器然后用包括在STATUS_REPARSE响应中的确定文字名称重新发出文件删除请求。
在一些实施例中，与文字文件″Different_file_1″相关联的操作系统权限可以防止删除该文字文件。在这些实施例中，返回一条错误消息该文件不会被删除。
如果该规则动作是″忽略″(步骤506)，那么就把文字文件名称标识为确切就是虚拟文件名称(步骤513)，并且把删除文字文件的请求传递到操作系统并且把来自于操作系统的结果返回给请求者(步骤510)。例如，删除名称为″file_1″是文件的请求导致删除实际上名称为″file_1″的文件。在一个实施例中，这是通过调用原始版本的挂钩函数并且把所形成的文字名称传递到该函数作为参数来实现的。对于使用文件系统过滤器驱动器的实施例而言，使用虚拟名称来删除该文件的第一请求导致从文件系统过滤器驱动器返回STATUS_REPARSE响应，表明文字名称。I/O管理器然后使用包括在STATUS_REPARSE响应中的确定的文字名称重新发出文件删除请求。
在一些实施例中，与文字文件″file_1″相关联的操作系统权限可以防止删除文字文件。在这些实施例中，返回一条错误消息该文件不会被删除。
如果该规则动作是″隔离″(步骤506)，那么就确定该虚拟文件的存在(步骤514)。如果该文件不存在，那么就返回错误表明该文件没有被发现(步骤516)。
然而，如果在步骤518确定该文件存在但是它并不是通常的文件并且不是空的虚拟目录，即，它包含虚拟文件或者虚拟子目录，那么就返回一条错误消息表明该文件不可以被删除(步骤520)。
然而，如果确定该文件是存在的并且该请求的虚拟化文件就是通常的文件或者是空虚拟目录，即，它不包含任何虚拟文件也不包含任何虚拟子目录(步骤518)，那么就标识对应于该虚拟文件的文字文件(步骤522)。该文字文件名称是根据由隔离规则所指定的虚拟文件名称确定的。例如，删除名称为″file_1″的文件的请求可能导致删除实际上名称为″Isolated_file_1″的文件。在一个实施例中，这是通过调用原始版本的挂钩函数并且把所形成的文字名称传递到该函数作为参数来实现的。对于使用文件系统过滤器驱动器的实施例而言，使用虚拟名称删除文件的第一请求导致从文件系统过滤器驱动器返回STATUS_REPARSE响应，表明文字名称。I/O管理器然后使用包括在STATUS_REPARSE响应中的确定的文字名称重新发出文件删除请求。
一旦识别了该虚拟文件的文字文件，就确定该文字文件是否被可以删除(步骤524)。如果该文件不可以被删除，那么就返回一条错误表明该文件不会被删除(步骤524)。在一些实施例中，权限数据与系统范围的候选文件相关联。在这些实施例的一些实施例中，权限数据被存储在规则引擎中或者被存储在与候选文件相关联的元数据中。在其他实施例中，与该候选文件相关联的权限数据由操作系统来提供。
然而，如果允许删除文件，并且如果该文字文件就处于适当的用户隔离范围中(步骤528)，那么就删除该文字文件(步骤534)并且在适当的用户隔离范围中创建代表该删除的虚拟文件的″删除″节点(步骤536)。
然而，如果在步骤528确定出该文字文件不处于用户隔离范围中但却处于适当的应用程序隔离范围中或者处于系统范围中，那么就创建不存在的请求的文件的用户范围的实例的每个用户范围的祖先的实例并且把该示例标记为是占位符(步骤532)。这样做是为了在用户隔离范围中维持目录结构的逻辑分层结构。然后，在适当的用户隔离范围中创建代表该删除的虚拟文件的用户范围的″删除″节点(步骤536)。在一些实施例中，把删除的文件的身份标识存储在文件或者其他高速缓存存储器中用以优化对删除的文件的检查。
在一些实施例中，所定位的虚拟化文件可以与表明该虚拟化文件已经被删除的元数据相关联。在某一别的实施例中，虚拟化文件的祖先(例如，包含该文件的更高目录)与表明它被删除的元数据相关联。在这些实施例中，可以返回一条错误消息，表明该虚拟化文件确实不存在。在这些实施例的特定实施例中，删除的文件或者文件系统元素的列表可以被维持并且被查阅用以优化对删除的文件的这一检查。
4.1.3文件系统列举操作现在参考图6，在简单的概况中，示出在描述的虚拟化环境中列举目录所采取的步骤的一个实施例。用于列举的请求被接收或者拦截(步骤602)。该请求包含目录名称，该目录名称被隔离环境当做虚拟目录名称对待处理。概念上，按照在第4.1.1节中所描述的那样来确定虚拟目录的存在(步骤603)。如果该虚拟目录不存在，那么就把表明虚拟目录没有被发现的结果返回给请求者(步骤620)。如果取而代之该虚拟目录存在，那么就查阅规则引擎来确定用于在列举请求中所指定的目录的规则(步骤604)。如果该规则指定动作是″重定向″(步骤606)，那么就按照该规则所指定的那样来确定对应于该虚拟目录名称的文字目录名称(步骤608)并且列举用该文字名称所标识的文字目录，并且把列举结果存储在工作数据存储器中(步骤612)，之后是稍后所描述的步骤630。如果所指定的规则动作不是″重定向″而是″忽略，″(步骤610)那么该文字目录名称就恰好是虚拟目录名称(步骤613)并且列举该文字目录，并且把列举结果存储在工作数据存储器中(步骤612)，之后是稍后所描述的步骤630。然而，如果该规则动作指定″隔离，″那么首先就列举系统范围；也就是说，候选目录名称就恰好是虚拟目录名称，并且如果该候选目录存在，就列举它。把列举结果存储在工作数据存储器中。如果该候选目录不存在，工作数据存储器在此阶段就保持为空(步骤614)。接着，把该候选目录标识为是虚拟目录的应用程序范围的实例，并且确定该选目录的存在的类别(步骤615)。如果该候选目录具有“负存在″，即，它或者它在该范围的祖先之一被标记为是删除，那么在此范围之内，它已知是被删除的，并且这是通过清除工作数据存储器来实现的(步骤642)。如果取而代之该候选目录不具有负存在，就列举该候选目录并且把所获得的任何列举结果都归并到工作数据存储器中。特别是，为在该列举中的每一文件系统元素，确定它的存在的类别。具有负存在的元素被从该工作数据存储器中除去，并且具有正存在的元素，即，存在并且并且没有被标记为是占位符并且也没有被标记为是被删除的那些元素，被添加到工作数据存储器，替换掉对应的元素(如果一个元素已经存在于该工作数据存储器中)(步骤616)。
在任一情况下，都把该候选目录标识为是该虚拟目录的用户范围的实例，并且确定该候选目录的存在的类别(步骤617)。如果该候选目录具有“负存在″，即，它或者它在该范围中的一个祖先被标记为是删除的，那么在此范围之内，它已知是被删除的，并且这是通过此清除工作数据存储器(来表明的步骤644)。如果取而代之该候选目录不具有负存在，那么就列举该候选目录并且把获得的任何列举结果都归并工作数据存储器中。特别地，为该列举中的每个文件系统元素，都确定它的存在的类别。具有负存在的元素被从工作数据存储器中除去，并且具有正存在的元素，即，那些存在并且被标记为是占位符并且没有被标记为是被删除的元素，被添加到工作数据存储器，如果一个元素已经存在于工作数据存储器中，那么就替换对应的元素(步骤618)，之后就是以下所描述的步骤630。
然后，为所有三种类型的规则，执行步骤630。查询规则引擎以查找其过滤器匹配该请求的目录的直接孩子但是却不匹配该请求的目录自身的规则集合(步骤630)。为该集合中的规则，使用在第4.1.1节所概述的逻辑来查询其名称匹匹配在规则中名称的虚拟孩子的存在。如果该孩子具有正存在，那么就把它添加到工作数据存储器，替换已经在那里具有相同的名称的任何孩子。如果孩子具有负存在，那么就除去在工作数据存储器中对应于该孩子的条目(如果存在的话)。(步骤632)。最后，把所构造的列举然后从工作数据存储器返回给请求者(步骤620)。
还参考图6，更详细地，接收或者拦截用于列举目录的请求(步骤602)。在一些实施例中，该请求被替换操作系统函数或者用于列举目录的函数的函数钩住。在另一实施例中，挂钩动态链接库被使用来拦截该请求。该挂钩函数可以执行在用户模式中也可以执行在核心模式中。对于该挂钩函数执行在用户模式下的实施例而言，当创建进程之时，可以把该挂钩函数加载到该进程的地址空间中。对于该挂钩函数执行在核心模式下的实施例而言，该挂钩函数可以被与在分派对文件操作的请求中所使用的操作系统资源相关联。对于为每种类型的文件操作都提供相独立的操作系统函数的实施例而言，每个函数都可以被独立地钩住。作为选择，可以提供单个挂钩函数，它拦截对若干类型的文件操作的创建或者打开调用。
确定该虚拟目录的存在(步骤603)。这按照在第4.1.1节所描述的那样来实现。如果该虚拟目录不存在，那么它就不能够被列举，并且把表明该虚拟目录不存在的结果返回给请求者(步骤620)。
该请求包含目录名称，该目录名称被隔离环境当作虚拟目录名称处理对待。如果该虚拟目录存在，那么就通过查阅规则引擎来定位用于确定要如何处理列举操作的规则(步骤604)。在一些实施例中，该规则引擎可以被提供为是关系数据库。在其他实施例中，该规则引擎可以树形结构的数据库，哈希表，或者平面文件数据库。在一些实施例中，为该请求的目录所提供的虚拟目录名称被使用来在规则引擎中定位施加到该请求的规则。在这些实施例的特别实施例中，对于特别的目录，多个规则都可以存在于该规则引擎中，在这些实施例中，与该虚拟目录名称最有最长前缀匹配的规则就是施加到该请求的规则。在其他实施例中，进程标识符被使用来在该规则引擎中定位施加到该请求的规则(如果存在一个规则的话)。与请求相关联的规则可以是去忽略该请求，重定向该请求，或者隔离该请求。尽管在图6中示为是单个数据库事务或者在文件中的单个查找，但是规则查找可以作为一系列规则查找来执行。
如果规则动作是″重定向″(步骤606)，那么虚拟目录名称就被依照该规则直接地映射到文字目录名称(步骤608)。把列举文字目录的请求传递到操作系统(步骤612)并且按照稍后的描述来执行步骤630。例如，列举名称为″directory_1″的目录的请求可能导致列举名称为″Difierent_directory_1″的文字目录。在一个实施例中，这是通过调用原始版本挂钩函数并且把形成文字名称传递到函数作为参数来实现的。对于使用文件系统过滤器驱动器的实施例而言，使用虚拟名称打开列举的目录的第一请求导致″STATUS_REPARSE″请求响应，表明确定的文字名称。I/O管理器然后使用包括在该STATUS_REPARSE响应中的确定的文字名称重新发出对列举的目录打开请求。
如果该规则动作不是″重定向″(步骤606)，而是″忽略″(步骤610)，那么就把该文字目录名称标识为是恰好是虚拟目录名称(步骤613)，并且把列举文字目录的请求传递到操作系统(步骤612)并且按照稍后所描述的那样来执行步骤630。例如，列举名称为″directory_1″的目录的请求将导致列举实际上名称为″directory_1″的目录。在一个实施例中，这是通过调用原始版本的挂钩函数并且把所形成的文字名称传递到函数作为参数来实现的。对于使用文件系统过滤器驱动器的实施例而言，使用虚拟名称来列举目录的第一请求被过滤器驱动器不加修改地传递下去。
如果所在步骤610所确定的规则动作不是″忽略″而是″隔离″，那么就列举系统范围，也就是说，在该请求中所提供的虚拟名称被使用来标识列举的目录(步骤614)。把列举的结果存储在工作数据存储器中。在一些实施例中，该工作数据存储器由存储器元件组成。在其他实施例中，该工作数据存储器包括数据库或者文件或者固态存储器元件或者持久的数据存储器。
接着，把候选目录标识为是该虚拟目录的应用程序范围的实例，并且确定该候选目录的存在的类别(步骤615)。如果该候选目录具有“负存在″，即，它或者它在该范围中的祖先被标记为是删除，那么在此范围之内它就已知是被删除的，并且这是通过清除工作数据存储器来表明的(步骤642)。
在一些实施例中，关于文件的一些量的元数据可以直接地存储在文字文件名称中，诸如通过给虚拟名称加上一个元数据指示符的后缀，此处元数据指示符是唯一地与特定元数据状态相关联的字符串。该元数据指示符可以表明或者编码元数据的一个或者若干个比特。请求用虚拟文件名访问文件以检查由于存在元数据指示符而导致的文字文件名的可能的变化的请求和用于获取该文件自身的名称的请求被钩住或者拦截，以便用文字名称作出应答。在其他实施例中，该文件的一个或者多个备用名称可以根据虚拟文件名称和元数据指示符来形成，并且可以使用由文件系统所提供的硬链路或者软链路工具来创建。如果给出一个请求用于使用链路的名称来访问文件，那么这些链路的存在就可以由隔离环境通过表明该文件没有被发现项应用程序隐瞒。特定链路的存在者缺失都可以为每个元数据指示符指明元数据的一个比特，或者可以有一个具有元数据指示符能够呈现为多个状态以表明元数据的若干比特的链路。在再一些其他的实施例中，其中文件系统支持备用文件流，备用文件流可以被创建用以包括元数据，该流的大小表明元数据的若干比特。在再一些其他的实施例中，文件系统可以直接地提供为文件系统中的每个文件都存储某个第三方元数据的能力。在再又一个实施例中，相独立的子范围可以被使用来记录删除的文件，并且文件(没有被标记为是占位符)在那个子范围中的存在，就意味着该文件被删除。
如果取而代之该候选目录不具有负存在，那么就列举候选目录并且把所获得的任何列举结果归并到工作数据存储器中。特别地，为该列举中的每个文件系统元件，确定它的存在的类别。具有负存在的元素被从工作数据存储器中除去，并且具有正存在的元素，即，那些存在并且没有被标记为是占位符并且没有被标记为是被删除的元素，被添加到工作数据存储器，替换掉对应的元素(如果一个元素已经存在与工作数据存储器中)(步骤616)。
在任一情况下，把候选目录标识为是该虚拟目录的用户范围的实例，并且该候选目录的存在的类别被确定(步骤617)。如果该候选目录具有“负存在″，即，它或者它在该范围中的一个祖先被标记为是删除的，那么在此范围之内它就已知是被删除的，并且这是通过此清除工作数据存储器来实现的(步骤644)。如果取而代之该候选目录不具有负存在，那么该候选目录就被列举并且所获得的任何列举结果就被归并到工作数据存储器中。特别地，为该列举中的每个文件系统元素，确定它的存在的类别。具有负存在的元素被从工作数据存储器中除去，并且具有正存在的元素，即，那些存在并且没有被标记为是占位符并且没有被标记为是删除的元素，被添加到工作数据存储器，替换掉对应的元素(如果一个元素已经存在于工作数据存储器中)(步骤618)，之后是以下所描述的步骤630。
然后，对于所有三种类型的规则，执行步骤630。查询该规则引擎以查找其过滤器匹配该请求的目录的直接孩子但是却不匹配该请求的目录自身的规则集合(步骤630)。对于该集合中的每个规则，使用在第4.1.1节所概述的逻辑来查询其名称匹配该规则中的名称的虚拟孩子的存在。如果该孩子具有正存在，就把它添加到工作数据存储器，替换掉已经在那里的具有相同的名称的任何孩子。如果该孩子具有负存在，那么就除去在工作数据存储器中对应于该孩子的条目(如果存在的话)。(步骤632)。最后，把所构造的列举然后从工作数据存储器返回给请求者(步骤620)。
本领域普通技术人员将会认识到把上述的分层的列举过程做较小的修改就能够应用到列举包括多个隔离子范围的单个隔离范围的操作上。工作数据存储器被创建，相继的子范围被列举并且把结果归并到工作数据存储器中以形成隔离范围的聚合列举。
4.1.4.文件系统创建操作现在参考图7，在简单的概况中，示出在隔离环境中创建文件所采取的步骤的一个实施例。用于创建文件的请求被接收或者拦截(步骤702)。该请求包含文件名称，该文件名称被隔离环境当作虚拟文件名称来处理对待。试图去使用适用的规则，即，使用适当的用户和应用程序隔离范围使用全虚拟化打开所请求的文件，如以在4.1.1节中所描述的(步骤704)。如果访问被拒绝(步骤706)，那么就把访问拒绝错误返回给请求者(步骤709)。如果访问被许可(步骤706)，并且所请求的文件被成功地打开(步骤710)，那么就把所请求的文件返回给请求者(步骤712)。然而，如果访问被许可(步骤706)，但是该请求的文件却没有被打开(步骤710)，那么如果该请求的文件的双亲也不存在(步骤714)，就向请求者发出适合于该请求语义的错误(步骤716)。如果相反使用适当的用户和应用范围在全虚拟化的视图中找到了该请求的文件的双亲(步骤714)，那么规则就确定该文件操作如何被处理(步骤718)。如果该规则动作是″重定向″或者″忽略″(步骤720)，那么就依照规则把该虚拟文件名称直接地映射到文字文件名称。特别地，如果规则动作是″忽略″，那么就把该文字文件名称标识为确切地就是虚拟文件名称。如果取而代之，该规则动作是″重定向″，那么就根据该规则所指定的虚拟文件名称来确定文字文件名称。然后把创建该文字文件的请求传递到操作系统，并且把该结果返回给请求者(步骤724)。如果相反，在步骤720中所确定的该规则动作是″隔离″，那么就把该文字文件名称标识为是该虚拟文件名称在用户隔离范围中的实例。如果该文字文件已经存在，但是却与表明它是占位符或者它被删除的元数据相关联，那么就修改该相关联的元数据以便除去那些表明，并且确保该文件是空的。在任一情况下，把打开该文字文件的请求传递到到操作系统(步骤726)。如果该文字文件被成功地打开过了(步骤728)，那么就把该文字文件返回给请求者(步骤730)。如果相反，在步骤728，该请求的文件没有打开，就把当前不存在于用户隔离范围中的文字文件的每个祖先的占位符(步骤732)和用于使用文字名称去创建该文字文件的请求传递到操作系统并且把该结果返回给请求者(步骤734)。
还参考图7，更详细地，创建文件的请求被接收或者拦截(步骤702)。在一些实施例中，该请求被替换掉操作系统函数或者用于创建文件的函数的函数钩住。在另一实施例中，挂钩动态链接库被使用来拦截该请求。该挂钩函数可以执行在用户模式下也可以执行在核心模式下。对于该挂钩函数执行在用户模式下的实施例而言，当创建一个进程之时，就可以把该挂钩函数加载到该进程的地址空间中。对于该挂钩函数执行在核心模式中的实施例而言，可以把该挂钩函数与在分派对文件的请求中所使用的操作系统资源相关联。对于为每种类型的文件操作都提供相独立的操作系统函数的实施例而言，每个函数都可以被独立地钩住。作为选择，可以提供单个挂钩函数，它拦截对若干类型的文件操作的创建或者打开调用。
该请求包含文件名称，该文件名称被隔离环境当作虚拟文件名称对待处理。请求者试图去使用适用的规则，即，使用适当的用户和应用程序隔离范围使用全虚拟化打开请求的文件，如在第4.1.1中所描述的那样(步骤704)。如果在全虚拟化的打开操作期间访问被拒绝(步骤706)，那么就把访问拒绝错误返回给请求者(步骤709)。如果访问被许可(步骤706)，并且该请求的虚拟文件被成功地打开(步骤710)，那么就把对应的文字文件返回给请求者(步骤712)。然而，如果访问被许可(步骤706)，但是该请求的文件却没有被成功地打开(步骤710)，那么就已经确定出该虚拟文件是不存在的。如果该请求的虚拟文件的虚拟双亲也不存在，正如在第4.1.1中的过程所确定的那样(步骤714)，那么就向请求者发出适合于请求语义的错误(步骤716)。如果相反，使用适当的用户和应用范围在全虚拟化的视图中找到了该请求的虚拟文件的虚拟双亲(步骤714)，那么就通过查阅规则引擎来定位用于确定如何来处理创建操作的规则(步骤718)。在一些实施例中，该规则引擎可以被提供为是关系数据库。在其他实施例中，该规则引擎可以是树形结构的数据库，哈希表，或者平面文件数据库。在一些实施例中，为该请求的文件所提供的虚拟文件名称被使用来在规则引擎中定位施加到该请求的规则。在这些实施例的特别实施例中，对于特别的文件，多个规则都可以存在于该规则引擎中，并且在这些实施例的一些实施例中，与虚拟文件名称具有最长前缀匹配的规则就是施加到该请求的规则。在一些实施例中，进程标识符被使用来在规则引擎中定位施加到该请求的规则(如果一条规则存在的话)。与请求相关联的规则可以是去忽略该请求，重定向该请求，或者隔离该请求。尽管在图7中示为单个数据库事务或者在文件中的单个查找，但是该规则查找可以作为一系列的规则查找来执行。
如果该规则动作是″重定向″或者″忽略″(步骤720)，那么就依照规则把该虚拟文件名称直接地映射到文字文件名称(步骤724)。如果该规则动作是″重定向″(步骤720)，那么就根据由该规则所指定的虚拟文件名称来确定文字文件名称(步骤724)。如果该规则动作是″忽略″(步骤720)，那么该文字文件名称就被确定为确切地就是该虚拟文件名称(步骤724)。如果该规则动作是″忽略″或者该规则动作是″重定向″，那么就把使用所确定的文字文件名称创建该文字文件的请求传递到操作系统并且把来自于操作系统的结果返回给请求者(步骤724)。例如，创建虚拟名称为″file_1″的文件的请求就可能导致可以创建名称为″Different_file1″的文字文件。在一个实施例中，这是通过调用原始版本的挂钩函数并且把所形成的文字名称传递到该函数作为参数来实现的(步骤724)。对于使用文件系统过滤器驱动器的实施例而言，请求使用虚拟名称打开文件的第一请求导致″STATUS_REPARSE″的请求响应，它表明该确定的文字名称。I/O管理器然后就使用在STATUS_REPARSE响应中所包括的确定文字名称重新发出文件打开请求。
如果在步骤720中所确定的规则动作不是″忽略″也不是″重定向″而是″隔离″，那么就把该文字文件名称标识为是该虚拟文件名称在用户隔离范围中的实例。如果该文字文件已经存在，但是却与表明它是占位符或者它被删除的元数据相关联，那么就修改该相关联的元数据以便除去那些表明，并且确保该文件是空的。
在一些实施例中，关于文件的一些量元数据可以被直接地存储文字文件名称中，诸如通过给该虚拟名称添加上元数据指示符的后缀，此处元数据指示符是唯一地与特定元数据状态相关联的字符串。该元数据指示符可以表明或者编码或者元数据的若干比特。请求用虚拟文件名访问文件以检查由于元数据指示符的存在而导致文字文件名的可能的变化的请求并且请求获取该文件自身的名称的请求被钩住或者拦截，以便用该文字名称来应答。在其他实施例中，该文件的一个或者多个备用名称可以根据虚拟文件名称和元数据指示符来形成，并且可以使用由文件系统所提供的硬链路或者软链路工具来创建。如果给出了一个请求，请求使用链路的名称来访问文件，那么这些链路的存在可以被隔离环境通过表明该文件没有被发现向应用程序隐瞒。特定链路的存在或者缺失可以为每个元数据指示符指明元数据的一个比特，或者可以有一个这样的链路，具有能够表现为多个状态以指明元数据的若干比特的元数据指示符。在再一些其他的实施例中，其中文件系统支持备用文件流，备用文件流可以创建出来以包括元数据，流的大小指明元数据的若干比特。在再一些其他的实施例中，文件系统可以直接地提供为文件系统中的每个文件存储某一第三方元数据的能力。
在这些实施例中的特定的一些实施例中，删除的文件或者文件系统元素的列表可以被维持并且可以被查阅，用以优化对删除的文件的这一检查。在这些实施例中，如果删除文件被重新创建，那么该文件名称就可以被从删除的文件的列表中除去。在这些实施例的其他实施例中，如果该列表增长到超过某一大小，那么就可以从该列表中除去文件名称。
在任一情况下，把请求打开用户范围的文字文件的请求传递到操作系统(步骤726)。在一些实施例中，规则可以指定对应于该虚拟文件的文字文件应该被创建在不同于用户隔离范围的范围，诸如应用程序隔离范围，系统范围，用户隔离子范围或者应用程序隔离子范围。
如果文字文件被成功地打开了(步骤728)，就把文字文件返回给请求者(步骤730)。如果相反，在步骤728，该请求的文件未能打开，那么就为当前不存在于用户隔离范围中的文字文件的每个祖先创建占位符(步骤732)并且把请求使用文字名称创建文字文件的请求传递到操作系统并且把该结果返回给请求者(步骤734)。
此实施例用于具有仅仅支持每个调用/引用创建一个级别的API或者工具的操作系统。对于本领域技术人员而言显而易见是能够扩展到每个调用/引用多个级别。
4.1.5短文件名称管理在一些文件系统，可以向每个文件赋予短文件名称和长名称这两种名称。任一种名称都可以被使用来在上述的任何文件操作中访问文件。对于具有短文件名称和长文件名称这两种文件名称的每一文件而言，这就隐含地在分配给该文件的短文件名称和长文件名称之间创建了关联。在这些文件系统中的一些文件系统，短名称是由文件系统自动地分配给使用长文件名称所创建的文件的。如果在短文件名和长文件名之间的关联没有被隔离环境维持，那么处于相同目录但是却处于不同范围级别中的文件名称长度不同的文件却可以相同短文件名称，如果使用该短名称来访问虚拟文件，这就会导致多义性。作为选择，当把文件拷贝到用户隔离范围以供修改之时，该短文件名称可以变化，这就意味着不再能够使用原始短名称来访问虚拟文件了。
为了防止这些问题，首先，拷贝已打开目的是修改到″更高″范围的文件实例的文件系统操作保护在与该拷贝的实例相关联的短文件名和长文件名之间的关联。其次，为新创建的隔离文件创建唯一的短名称来代替由操作系统所分配的文件名称。所生成的短文件名称应该满足以下条件所生成的文件名称不匹配于处于在相同的隔离范围中的相同目录下或者处于在″较低″隔离的范围中的相同目录下的任何现有短文件名称。例如，给位于在用户隔离范围中的文件的实例所生成的短文件名应该不匹配处于该目录的应用程序范围的实例中或者处于该目录的系统范围的实例中的现有短文件名称。
现在参考图7A，示出在创建新文件之后分配唯一短文件名称所采取的步骤的一个实施例。在简短的概况中，检查以确定是否应该生成短文件名称(步骤752)。如果不应该，那么就返回一个状态，以表明将不生成任何短文件名(步骤754)。否则，就依照文件系统检查该文件名以确定它是否已经是合法的短文件名(步骤756)。如果它已经是合法的短文件名称，就返回一个状态，表明将不生成任何短名称(步骤754)。否则，就构造一个适合的短文件名(步骤758)。
还参考图7A，并且更详细地，作出检查以便确定是否应该生成短文件名称(步骤752)。在一些实施例中，可以根据存储该文件名所指代的文件的设备来作出这一判定。在其他实施例中，可以为某些范围或者子范围，或者为隔离环境作为洞而启用短文件名称的生成。在这些实施例的一些实施例中，注册表设定可以规定是否将为特别的文件名称生成短文件名。如果不应该生成任何短文件名，那么就返回一个状态，以表明将不生成任何短文件名(步骤754)。
否则，就检查该文件名以便确定它是否已经是合法的短文件名(步骤756)。在一些实施例中，合法的短文件名称在文件名中包含多达8个字符并且和在可选的扩展名中包含多达三个字符。在一些实施例中，合法的短名称包含仅仅合法字符，诸如A-Z，a-z，0-9，`，～，！，@，#，$，％，^，&，*，(，)，-，_，′，{，and}。在一些实施例中，开始的空格或者″.″或者嵌入一个以上的″.″是不合法的。如果所提供的文件名已经是合法的短文件名称，那么就返回一个状态，以表明将不生成任何的短文件名(步骤754)。
否则，如果在步骤756确定出该文件名是不合法的短文件名称，那么就构造一个合适的短文件名(步骤758)。在一些实施例中，这是通过使用长文件名中在短文件名称中使用起来是合法的某一些部分与编码的迭代计数相结合以形成候选短文件名称来实现的。该迭代计数在增加着，直到相关联的候选短文件名变为合适为止，也就是说，直到它是不被处于相同范围中的相同目录下或者处于更低范围中的相同目录下的任何其他文件使用的合法短文件名。在其他实施例中，把长文件名弄乱或者做哈希处理并且编码，然后与编码的迭代计数相结合来形成候选短文件名称。该迭代计数在增加着，直到相关联的候选短文件名变得合适为止，也就是说，直到它是不被处于相同范围中的相同目录下或者处于更低范围中的相同目录下的任何其他文件使用的合法短文件名。在所有这些实施例中，范围专用的字符串可以被并入到候选短文件名以增加几率一个合适的候选短文件名将能以低的迭代计数被查找。
4.2注册表虚拟化上述的方法和设备可以被使用来虚拟化对注册表数据库的访问。如上所述，注册表数据库存储关于在物理上附联到计算机的硬件、哪些系统选项已经被选择、计算机存储器怎样设立、应用程序特定的数据的各种项目以及当操作系统被起动之时应该存在什么应用程序的信息。注册表数据库普遍都被组织在″键″170，172的逻辑分层结构，所述键是注册表值的容器。
4.2.1注册表键打开操作在简洁的概况中，图8描绘了在上述的隔离环境中打开注册表键所采取的步骤的一个实施例。请求打开注册表键的请求被接收或者拦截，该请求包含注册表键名称，该注册表键名称被隔离环境当作虚拟键名称对待处理(步骤802)。适用于该请求中的虚拟名称的处理规则确定如何来处理注册表键操作(步骤804)。如果该规则动作是″重定向″(步骤806)，那么就把在该请求中所提供的虚拟键名称映射到由适用的规则所规定的文字键名称(步骤808)。把请求使用该文字键名称打开文字注册表键的请求传递到操作系统并且把来自于操作系统的结果返回给请求者(步骤810)。如果该规则动作不是″重定向″，而是″忽略″(步骤806)，那么就把该虚拟键名称标识为是文字键名称(步骤812)，并且把请求打开去文字注册表键的请求传递到操作系统并且把来自于操作系统的结果返回给请求者(步骤810)。如果在步骤806中所确定的该规则动作不是″重定向″也不是″忽略，″而是″隔离″，那么就把在该请求中所提供的虚拟键名称映射到用户范围的候选键名称，即，一个对应于适用的用户隔离范围专用的虚拟键名称的键名称(步骤814)。用户范围的候选键的存在的类别被通过检查用户隔离范围和与该候选键相关联的任何元数据来确定(步骤816)。如果该候选键被确定具有″负存在″(因为该候选键或者它在用户隔离范围中的一个祖先键被标记为是删除的)，那么这就意味着该请求的虚拟键已知是不存在的。在此情况下，把表明该请求的文件没有被发现的错误条件返回给请求者(步骤822)。如果取而代之在步骤816该候选键被确定具有″正存在″(因为该候选键存在于用户隔离范围中并且没有被标记为是占位符节点)，那么该请求的虚拟键就已知是存在的。把该候选键标识为是对该请求的文字键(步骤818)，并且把发出请求打开该文字键的请求和结果返回给请求者(步骤820)。然而，如果在步骤816，该候选键具有″中性存在″(因为该候选键不存在，或者该候选键存在但是被标记为是占位符节点)，那么就还尚不知道该虚拟键存在还是不存在。在此情况下，把对应于该虚拟键名称的应用程序范围的键名称标识为是候选键名称(步骤824)。换言之，该候选键名称是通过把虚拟键名称映射到适用的应用程序隔离范围专用的对应本机键名称来形成。该候选键的存在的类别通过检查应用程序隔离范围和与该候选键相关联的任何元数据来确定(步骤826)。如果该候选键被确定具有″负存在″(因为该候选键或者它在该应用程序隔离范围中的一个祖先键被标记为是删除的)，那么这就意味着该请求虚拟键已知是不存在的。在此情况下，把表明该请求的键没有被发现的错误条件返回给请求者(步骤822)。如果取而代之在步骤826该候选键被确定为是具有″正存在″(因为该候选键存在于该应用程序隔离范围中并且没有被标记为是占位符节点)，那么该请求的虚拟键就已知是存在的。检查该请求以确定打开请求是否表明目的是修改该键(步骤828)。如果不是，那么就把该候选键标识为是对该请求的文字键(步骤818)，并且把发出的请求打开该文字键的请求和结果返回给请求者(步骤820)。然而，如果在步骤828，确定出该打开请求表明目的是去修改该键，那么就检查与该键相关联的权限数据，用以确定是否允许修改该键(步骤836)。如果不允许，那么就把错误条件返回给请求者(步骤838)，表明不允许修改该键。如果该权限数据表明可以修改该键，那么就把该候选键拷贝到用户隔离范围(步骤840)。在一些实施例中，把该候选键拷贝到由规则引擎所定义的位置。例如，规则可以规定把该键拷贝到应用程序隔离范围。在其他实施例中，该规则可以规定应该把该键拷贝到的那个特定应用程序隔离子范围或者用户隔离子范围。把没有出现在把该键拷贝到的那个隔离范围中的该请求的键的任何祖先创建为是在该隔离范围中的占位符，以便正确地在分层结构中定位该拷贝的实例。把新拷贝的范围的实例标识为是文字键(步骤842)并且把发出的请求打开文字键的请求和结果返回给请求者(步骤820)。返回到步骤826，如果该候选键具有中性存在(因为该候选键不存在或者因为该候选键被找到了但是却被标记为是占位符节点)，那么就尚不知道该虚拟键是存在还是不存在。在此情况下，把对应于该虚拟键名称的系统范围的键名称标识为是候选键名称(步骤830)。换言之，该候选键名称就恰好是虚拟键名称。如果该候选键不存在(步骤832)，那么就把表明该虚拟键未被找到的错误条件返回给请求者(步骤834)。如果相反该候选键存在(步骤832)，那么就检查该请求以便确定打开请求是否表明目的是修改该键(步骤828)。如果不是，那么就把该候选键标识为是对该请求的文字键(步骤818)，并且把发出的请求打开该文字键的请求和结果返回给该请求者(步骤820)。然而，如果在步骤828，确定出该打开请求表明目的是修改该键，那么就检查与该键相关联的权限数据，用以确定是否允许修改该键(步骤836)。如果不允许，那么就把错误条件返回给请求者(步骤838)，表明不允许修改该键。如果该权限数据表明可以修改该键，那么就把该候选键拷贝到用户隔离范围(步骤840)。在一些实施例中，把该候选键拷贝到由规则引擎所定义的位置。例如，规则可以规定把该键拷贝到应用程序隔离范围。在其他实施例中，该规则可以规定应该把该键拷贝到的那个特定应用程序隔离子范围或者用户隔离子范围。把没有出现在该隔离范围中的请求的键的任何祖先创建为是占位符隔离范围，以便正确地在分层结构中定位该拷贝的实例。把新拷贝的范围实例标识为是文字键(步骤842)并且把发出的请求打开该文字键的请求和结果返回给请求者(步骤820)。
还参考图8并且更详细地，请求打开虚拟注册表键的请求被接收或者拦截(步骤802)。对应的文字注册表键可以属于用户隔离范围，应用程序隔离范围或者系统范围，或者它的范围可以属于应用程序隔离子范围或者用户隔离子范围。在一些实施例中，该请求被替换操作系统函数或者替换用于打开注册表键的函数的函数钩住。在另一个实施例中，挂钩动态链接库被使用来拦截该请求。该挂钩函数可以执行在用户模式下也可以执行在核心模式下。对于该挂钩函数执行在用户模式下的实施例而言，当创建进程之时，可以把该挂钩函数加载到该进程的地址空间中。对于该挂钩函数执行在核心模式下的实施例而言，该挂钩函数可以被与在分派对本机注册表键的请求中所使用的操作系统资源相关联。对于为每种类型的注册表键操作都提供相独立的操作系统函数的实施例而言，每个函数都可以被单独地钩住。作为选择，可以提供单个挂钩函数，它拦截创建或者打开对若干类型的注册表键操作的调用。
该请求包含注册表键名称，该注册表键名称被隔离环境当作虚拟注册表键名称来对待处理。通过查阅规则引擎来确定适用于注册表键打开请求的处理规则(步骤804)。在一些实施例中，该规则引擎可以被提供为是关系数据库。在其他实施例中，该规则引擎可以树形结构数据库，哈希表，或者平面文件数据库。在一些实施例中，为请求的注册表键所提供的虚拟注册表键名称被使用来在规则引擎中定位施加到该请求的规则。在这些实施例的特别实施例中，对于特别的注册表键，多个规则都可以存在于该规则引擎中，并且在这些实施例中，与该虚拟注册表键名称具有最长前缀匹配的规则就是施加到该请求的规则。在其他实施例中，进程标识符被使用来在规则引擎中定位施加到该请求的规则(如果一条规则存在的话)。与请求相关联的规则可以是去忽略该请求，重定向该请求，或者隔离该请求。尽管在图8中示为单个数据库事务或者在文件中单个查找，但是规则查找可以作为一系列规则查找来执行。
如果该规则动作是″重定向″(步骤806)，那么就依照适用的规则把在该请求中所提供的虚拟注册表键名称映射到文字注册表键名称(步骤808)。把请求使用该文字注册表键名称打开文字注册表键的请求传递到操作系统并且把来自于该操作系统的结果返回给请求者(步骤810)。例如，请求打开名称为″registry_key_1″的注册表键的请求就可能导致打开名称为″Different_registry_key_1″的文字注册表键。在一个实施例中，这是通过调用原始版本挂钩函数并且把所形成的文字名称传递到函数作为参数来实现的。在其他实施例中，概念上与文件系统过滤器驱动器工具相类似的注册表过滤器驱动器工具可以由操作系统提供。在这些实施例中，打开文字注册表键可以通过向注册表过滤器管理器发信号通知去使用确定的文字键名称来重新解析请求打开虚拟键的原始请求来应答该原始请求而实现。如果取而代之该规则动作是″忽略″(步骤806)，那么该文字注册表键名称就被确定为确切地就是该虚拟注册表键名称(步骤812)，并且把请求打开文字注册表键的请求传递到操作系统并且把来自于操作系统的结果返回给请求者(步骤810)。例如，请求打开名称为″registry_key_1″的注册表键将导致打开名称为″registry_key_1″的文字注册表键。在一个实施例中，这是通过调用原始版本的挂钩函数并且把所形成的文字名称传递到函数作为参数来实现的。在另一实施例中，这是通过向注册表过滤器管理器发信号通知继续以通常的方式去处理该原始的未经修改的请求。
如果在步骤806该规则动作是″隔离″，那么就把对应于该虚拟注册表键名称的用户范围的注册表键名称标识为是候选注册表键名称(步骤814)。换言之，该候选注册表键名称是通过把虚拟注册表键名称映射到适用的用户隔离范围专用的对应本机注册表键名称来实现的。例如，请求打开名称为″registry_key_1″的注册表键可能导致打开名称为″Isolated_UserScope_UserA_registry_key_1″的文字注册表键。在一个实施例中，这是通过调用原始版本的挂钩函数并且把所形成的文字名称传递到该函数作为参数来实现的。在其他实施例中，打开文字注册表键可以通过向注册表过滤器管理器发信号通知去使用确定的文字键名称来重新解析请求打开该虚拟键的原始请求来应答该请求。
在一些实施例中，为了隔离请求的虚拟注册表键而形成的文字名称可以基于所接收的虚拟注册表键名称和范围专用的标识符。该范围专用的标识符可以是与应用程序隔离范围，用户隔离范围，会话隔离范围，应用程序隔离子范围，用户隔离子范围或者以上的某一组合相关联的标识符。范围专用的标识符被使用来″弄乱″在该请求中所接收的虚拟名称。
在其他实施例中，用户隔离范围或者子范围可以是注册表键，在该注册表键下存储所有存在于该用户隔离范围中的键。在这些实施例的一些实施例中，在用户隔离键之下的键分层结构反映出所请求的资源的路径。换言之，该文字键路径是通过把虚拟键路径映射到用户隔离范围而形成的。例如，如果请求的键是HKLM\Software\Citrix\MyKey并且用户隔离范围键是HKCU\Software\UserScope\，那么到该用户范围的文字键的路径就可以是HKCU\Software\UserScope\HKLM\Software\Citrix\MyKey。在其他实施例中，到用户范围的文字的路径可以按照本机命名惯例来定义。例如，到用户范围的文字键的路径可以HKCU\Software\UserScop\Registry\Machine\Software\Citrix\MyKey。在再一些其他的实施例中，用户范围的键可以都被存储在具有挑选成是唯一的名称的单个键之下，并且数据库可以被使用来存储在请求的键名称和存储在用户隔离键中的对应于文字键的名称之间的映射。在再一些其他的实施例中，该文字键的内容可以被存储在数据库或者存储在文件存储器中。
候选键的存在的类别通过检查用户隔离范围和与该候选键相关联的任何元数据来确定(步骤816)。如果该候选键被确定具有″负存在″(因为该候选键或者它在用户隔离范围中的一个祖先键被标记为是删除的)，那么这这就意味着该请求虚拟键已知是不存在的。在此情况下，把表明该请求的键没有被发现的错误条件返回给请求者(步骤822)。
在一些实施例中，该文字注册表键可以被与表明该虚拟化的注册表键已经被删除的元数据相关联。在一些实施例中，关于注册表键的元数据被可以存储在由那个键所保持的不同的值中，那个值的存在对注册表API的通常应用程序的使用是隐瞒着的。在一些实施例中，关于注册表键的一些量的元数据可以直接地存储在文字键名称中，诸如通过给该虚拟名称添加一个元数据指示符作为后缀，此处元数据指示符是唯一地与特定元数据状态相关联的字符串。该元数据指示符可以表明或者编码元数据的一个或者若干比特。请求用虚拟名称访问该键以检查由于存在元数据指示符而导致该文字键名称的可能的变化的请求和请求获取该键自身的名称的请求被钩住或者拦截，以便用该文字名称做出应答。在其他实施例中，该元数据指示符可以被编码在子键名称或者注册表值名称中，而不是被编码在该键名称自身中。在再一些其他的实施例中，注册表键系统可以直接地提供为每个键都存储某个第三方元数据的能力。在一些实施例中，元数据被存储在的数据库在或者存储在独立于该注册表数据库的其他知识库中。在一些实施例中，相独立的子范围可以被使用来存储那些被标记为是删除的键。键在该子范围中的存在表明该键被标记为是删除的。
在这些实施例中的特定实施例中，删除的键或者键系统元素的列表可以被维持和被查阅，用以优化对删除的键的这一检查。在这些实施例中，如果删除的键被重新创建，那么该键名称就可以被从删除的键的列表中除去。在这些实施例的其他实施例中，如果该列表增长到超过某一大小，那么键名称就可以被除去该列表中除去。
如果取而代之在步骤816该候选键被确定是具有″正存在″(因为该候选键存在于用户隔离范围并且没有被标记为是占位符节点)，那么该请求的虚拟键就已知是存在的。把该候选键标识为是对该请求的文字键(步骤818)，并且把发出的请求打开该文字键的请求和结果返回给请求者(步骤820)。
然而，如果在步骤816，该候选键具有″中性存在″(因为该候选键不存在或者该候选键存在但是却被标记为是占位符节点)，那么就尚不知道该虚拟键存在还是不存在。在此情况下，把对应于虚拟键名称的应用程序范围的键名称标识为是候选键名称(步骤824)。换言之，该候选键名称是通过把该虚拟键名称映射对适用的应用程序隔离范围专用的本机键名称来形成的。该候选键的存在的类别是通过检查该应用程序隔离范围和与该候选键相关联的任何元数据来确定的(步骤826)。
如果该应用程序范围的候选键被确定是具有″负存在″(因为该候选键或者它在该应用程序隔离范围中的一个祖先键被标记为是删除的)，那么这就意味着该请求的虚拟键已知是不存在的。在此情况下，把表明该请求的键没有被发现的错误条件返回给请求者(步骤822)。
然而，如果在步骤826该候选键被确定为是具有″正存在″(因为该候选键存在于该应用程序隔离范围中并且没有被标记为是占位符节点)，那么该请求的虚拟键就已知是存在的。检查该请求以便确定打开请求是否表明目的是修改该键(步骤828)。如果不是，那么就把该候选键标识为是对该请求的文字键(步骤818)，并且把发出的请求打开该文字键的请求和结果返回给请求者(步骤820)。
然而，如果在步骤828，确定出该打开请求表明目的是修改该键，那么就检查与该键相关联的权限数据，以便确定是否允许修改的键(步骤836)。在一些实施例中，该权限数据被与应用程序范围的候选键相关联。在这些实施例的一些实施例中，把该权限数据存储在规则引擎中或者存储在与该候选键相关联的元数据。在其他实施例中，与该候选键相关联的权限数据由操作系统来提供。进而，该规则引擎可以包括配置设定，用于指示隔离环境去遵从或者重载资源的虚拟化的拷贝的本机权限数据。在一些实施例中，该规则可以为一些虚拟资源规定要在其中发生修改的范围，例如该系统范围或者应用程序隔离范围或者子范围，或者用户隔离范围或者子范围。在一些实施例中，该规则引擎可以根据分层结构规定施加到该虚拟化的本机资源的子集的配置设定。在这些实施例的一些实施例中，该配置设定对每个原子本机资源可以专用的。
如果与该候选键相关联的权限数据表明不可以修改它，那么就把错误条件返回给请求者(步骤838)，表明不允许修改该键。如果该权限数据表明可以修改该键，那么就把该候选键拷贝到用户隔离范围(步骤840)。在一些实施例中，把该候选键拷贝到由规则引擎所定义的位置。例如，规则可以规定把该键拷贝到另一个应用程序隔离范围。在其他实施例中，该规则可以规定应该把该键拷贝到的那个特定应用程序隔离子范围或者用户隔离子范围。将没有出现在把该键拷贝到的那个隔离范围中的该请求的键的任何祖先创建为是在该隔离范围中的占位符，以便正确地在分层结构中定位该拷贝的实例。
在一些实施例中，元数据被与所拷贝到隔离范围的键相关联，它标识拷贝该键之时的日期和时间。此信息可以被使用来比较与该键的拷贝的实例相关联的时间标记和上次修改该键的原始实例或者位于更低隔离范围中的键的另一个实例的时间标记。在这些实施例中，如果该键的原始实例，或者位于更低隔离范围中的该键的另一个实例被与与晚于该拷贝的键的时间标记的时间标记相关联，那么就可以把该键拷贝到隔离范围，用以更新该候选键。在其他实施例中，在隔离范围中对该键的拷贝可以与标识包含被拷贝过的原始键的范围的元数据相关联。
在进一步的实施例中，可以监视拷贝到隔离范围的键(因为该键已经被打开目的是修改它们)，以确定它们实际上是否被修改了。在一个实施例中，拷贝的键可以与当该键被实际地修改之时所设定的标志相关联。在这些实施例中，如果拷贝的键实际上没有被修改，那么就可以在把它关闭之后把它从它被拷贝到的范围以及与该拷贝的键相关联的任何占位符中除去。
该范围的实例被标识为是文字键(步骤842)并且把所发出的用以打开文字键的请求和结果返回给请求者(步骤820)。
返回到步骤826，如果该候选键具有中性存在(因为候选键不存在)，或者如果该候选键被找到但是被标记为是占位符节点，那么还尚不知道该虚拟键是存在还是不存在。在此情况下，把对应于虚拟键名称的系统范围的键名称标识为是候选键名称(步骤830)。换言之，该候选键名称恰好就是虚拟键名称。
如果该候选键不存在(步骤832)，就把表明虚拟键未被找到的错误条件返回给请求者(步骤834)。如果相反该候选键存在(步骤832)，那么将检查该请求以确定打开请求是否表明目的是去修改该键(步骤828)。
如上所述，如果该候选键正在被打开而目的不是去修改它，那么就把系统范围的候选键标识为是对该请求的文字键(步骤818)，并且把所发出的请求打开文字键的请求和结果返回给请求者(步骤820)。然而，如果在步骤828，确定出该打开请求表明目的是去修改该键，那么就检查与该键相关联的权限数据，以确定是否允许修改该键(步骤836)。在一些实施例中，权限数据与应用程序范围的候选键相关联。在这些实施例的一些实施例中，权限数据被存储在规则引擎中或者被存储在与该候选键相关联的元数据中。在其他实施例中，与该候选键相关联的权限数据由操作系统提供。另外，规则引擎可以包括配置设定，用于指示隔离环境去遵从或者重载资源的虚拟化拷贝的本机权限数据。在一些实施例中，规则可以为一些虚拟资源指定要在其中发生修改的范围，例如系统范围或者应用程序隔离范围或者子范围，或者用户隔离范围或者子范围。在一些实施例中，规则引擎可以根据分层结构规定施加到虚拟化的本机资源的子集的配置设定。在这些实施例的一些实施例中，配置设定对每个原子本机资源可以是专用的。
如果与该系统范围的候选键相关联的权限数据表明不可以修改该键，那么就把错误条件返回给请求者(步骤838)，表明不允许修改该键。然而，如果该权限数据表明可以修改该键，那么就把候选键拷贝到用户隔离范围(步骤840)。在一些实施例中，把候选键拷贝到由规则引擎所定义的位置。例如，规则可以规定把该键拷贝到应用程序隔离范围或者可以把它留在系统范围中。在其他实施例中，规则可以规定应该把该键拷贝到的那个特定应用程序隔离子范围或者用户隔离子范围。没有出现在隔离范围中的请求的键的任何祖先被创建为是在隔离范围中的占位符，以便正确地在分层结构中定位拷贝的实例。
在一些实施例中，元数据与拷贝到隔离范围的该键相关联，它标识拷贝该键的日期和时间。此信息可以被使用来比较与该键的拷贝的实例相关联的时间标记和上次修改该键的原始实例的时间标记。在这些实施例中，如果该键的原始实例与晚于该拷贝的键的时间标记的时间标记相关联，那么就可以把该原始键拷贝到隔离范围，用以更新该候选键。在其他实施例中，拷贝到该隔离范围的候选键可以被与标识从其拷贝过该原始键的范围的元数据相关联。
在进一步的实施例中，可以监视拷贝到隔离范围的键(因为该键已经被打开目的是修改它们)，以确定它们实际上是否被修改了。在一个实施例中，拷贝的键可以被与当该键被实际地修改之时所设定的标志相关联。在这些实施例中，如果拷贝的键实际上没有被修改，那么就可以在把它关闭之后把它从它被拷贝到的范围以及与该拷贝的键相关联的任何占位符节点中除去。
该范围的实例被标识为是文字键(步骤842)并且把所发出的请求打开文字键的请求和结果返回给请求者(步骤820)。
4.2.2注册表键删除操作现在参考图9，在简单的概况中，描绘了删除注册表键所采取的步骤的一个实施例。在能够删除一个键之前，首先必须用删除访问来成功地打开该键(步骤901)。如果该键没有被成功地打开，那么就返回一个错误(步骤916)。如果虚拟键被成功地打开，那么请求删除虚拟化的注册表键的请求就被接收或者拦截，该请求包括到对应于该虚拟键的文字键的句柄(步骤902)。规则确定如何来处理注册表键操作(步骤904)。除了检查适用于要删除的键的规则之外，还检查适用于直接子键的任何其他规则(步骤905)。对于适用于所找到的直接子键的每个规则而言，都试图去打开虚拟子键，该虚拟子键的名称由在步骤905所找到的规则中所给出的名称指定。如果其名称与在步骤905中所找到的一个规则相对应的子键被成功地打开了(步骤906)，那么就把该虚拟键视为具有子键，这就意味着它不能够被删除，然后返回一个错误(步骤907)。
如果在步骤905中所提取的所有虚拟键名称都已经被试图去打开过(步骤906)，那么就没有找到任何还存在的虚拟键，需要进一步的检查。如果该规则动作不是″隔离″，而是″重定向″，或者是″忽略″(步骤908)，那么就把请求删除文字注册表键的请求传递到操作系统并且把来自于操作系统的结果返回给请求者(步骤911)。然而，如果在步骤908中所确定的规则动作是″隔离″，那么就查阅聚合的虚拟化的注册表键，用以确定它是否包含任何虚拟子键(步骤914)。如果该虚拟化的键具有虚拟子键，那么就不能继续删除，并且返回一个错误，表明该键尚未被删除(步骤920)。如果该虚拟化的键不具有虚拟子键，那么就检查与该虚拟键对应的文字键，用以确定它是否屏蔽了在另一个范围级别中具有相同虚拟名称的范围键(步骤922)。如果对应于该虚拟键的文字键没有屏蔽具有相同虚拟名称但是范围不同的键，那么对应于该虚拟键的文字键就被删除，并且把结果返回(步骤926)。如果对应于该虚拟键的文字键屏蔽了具有相同虚拟名称但是范围却不同的键，那么就用一个表明它被删除的值来屏蔽对应于该虚拟键的文字键，并且把成功的结果返回给调用者(步骤924)。
还参考图9，更详细地，为了删除一个键，首先就必须用删除访问来打开该键(步骤901)。请求用删除访问打开键的请求包括该键的名称，该键的名称被隔离环境当做虚拟名称来对待处理。对全虚拟化键打开按照在第4.2.1节中所描述的那样来执行。如果虚拟化打开操作失败，那么就把一个错误返回给请求者(步骤916)。如果虚拟化打开操作成功，那么就把对应于该虚拟键的文字键的句柄返回给请求者。然后，请求删除在步骤901中打开了的注册表键的请求被接收或者拦截(步骤902)。该打开的文字注册表键可以属于用户隔离范围，应用程序隔离范围，系统范围，或者某一适用的隔离子范围。在一些实施例中，该删除请求被替换操作系统函数或者替换用于删除注册表键的函数的函数钩住。在另一个实施例中，挂钩动态链接库被使用来拦截该删除请求。该挂钩函数可以执行在用户模式下或者执行在核心模式下。对于挂钩函数执行在用户模式中的实施例而言，当创建一个进程之时，挂钩函数可以被加载到该进程的地址空间中。对于挂钩函数执行在核心模式中的实施例而言，挂钩函数可以与在分派对本机注册表键的请求中使用的操作系统资源相关联。在其他实施例中，概念上与文件系统过滤器驱动器工具相类似的注册表过滤器驱动器工具可以由操作系统来提供。本领域技术人员可以创建注册表过滤器驱动器，操作系统把请求执行注册表操作的请求传递到该注册表过滤器驱动器，由此提供拦截注册表操作请求的机制。对于为每种类型的注册表键函数都提供相独立的操作系统函数的实施例中，每个函数都可以独立地钩住。作为选择，可以提供单个挂钩函数，它用以拦截对若干类型的注册表键的创建或者打开调用。
该删除请求包含文字键句柄。与该句柄相关联的虚拟键名称是通过查询操作系统中与该句柄相关联的文字名称来确定的。查阅规则引擎，用以确定与该文字名称相关联的虚拟名称(如果存在的话)。确定如何来处理注册表键操作(步骤904)的规则是通过查阅规则引擎来获得的。在一些实施例中，要删除的虚拟注册表键的虚拟键名称被使用来在规则引擎中定位施加到该请求的规则。在这些实施例的特别实施例中，对于特别的虚拟注册表键，多个规则都可以存在于该规则引擎中，在这些实施例的一些实施例中，与该虚拟键名称具有最长前缀匹配的规则就是施加到了该请求的规则。在一些实施例中，该规则引擎可以被提供为是关系数据库。在其他实施例中，该规则引擎可以树形结构的数据库，哈希表，或者平面注册表键数据库。在一些实施例中，对应于在该请求中的虚拟键句柄的虚拟键名称被用作进入到规则引擎用以定位施加到该请求一个或者多个规则的索引。在一些实施例中，进程标识符被使用来在规则引擎中定位施加到该请求的规则(如果存在一条规则的话)。与该请求相关联的规则可以是去忽略该请求，重定向该请求，或者隔离该请求。规则查找可以作为一系列判定而发生，或者该规则查找可以作为单个数据库事务而发生。
要删除的键的虚拟名称被使用来查阅规则引擎，用以定位适用于要删除的该虚拟键的任何直接孩子键但是却不适用于要删除的该虚拟键的规则集合。不管那些孩子键是存在还是不存在，都定位此规则集合(步骤905)。如果适用于直接孩子键的规则集合不是空的，那么就提取这些规则中的每个规则的虚拟名称。接着，试图去执行所提取的每个虚拟孩子键名称的全虚拟化打开(步骤906)。如果对应于这些虚拟名称的任何虚拟名称的任何虚拟键都能够被成功地打开，那么这就意味着虚拟子键存在。这就意味着该虚拟键不能够被删除，因为它具有存在的虚拟孩子，并且返回一个错误(步骤907)。如果在检查适用于该虚拟键的直接孩子的所有规则集合(步骤905)，找不到任何存在的虚拟子键，那么删除就能够继续进行。例如，虚拟名称为″key_1″的键可能会具有适用于″key1\subkey_1″和″key1\subkey_2″的孩子规则。在此步骤中，试图执行对″key1\subkey_1″和″key1\subkey_2″的虚拟化打开。如果这些虚拟子键中的任一个虚拟子键都能够被成功地打开，那么删除将失败，并且返回一个错误(步骤907)。只有在这些虚拟子键中的任何一个子键都不存在之时，才能够继续删除。
如果该规则动作不是″隔离″，而是″重定向″，或者是″忽略″(步骤908)，那么就把请求使用文字键句柄删除文字注册表键的请求传递到操作系统并且把来自于操作系统的结果返回给请求者(步骤911)。如果该文字键包含文字子键，那么此请求将会失败。在一个实施例中，请求删除文字注册表键的请求是通过调用原始版本的挂钩函数并且把文字键句柄传递到该函数作为参数来实现的。在充分利用注册表过滤器驱动器的实施例中，这是通过用完成状态(它发信号通知操作系统对该请求执行正常处理)来应答该请求的。在一些实施例中，与该文字注册表键相关联的操作系统权限可以防止它的删除。在这些实施例中，返回一个错误消息该虚拟注册表键不会被删除。
如果在步骤908中所确定的规则动作是″隔离″，那么就查阅聚合的虚拟化注册表键，用以确定它是否包含任何虚拟子键(步骤914)。如果该请求的虚拟注册表键包含虚拟子键，那么该虚拟键就不能够被删除，并且把一个错误返回给调用者(步骤920)。
如果该请求的虚拟注册表键不包含虚拟子键，那么该虚拟键就能够被删除。接下来所采取的动作取决于包含要被删除的文字键的范围。例如，请求删除虚拟注册表键的请求可能导致删除应用程序范围的文字键。包含文字键的范围能够通过利用到该文字键的全路径查阅规则引擎来确定。
如果在特定范围中找到了要删除的文字键，并且该文字键屏蔽了在另一个范围中具有相同虚拟名称的另一个键，那么就把要删除的该文字键标记为是删除的，并且把结果返回给请求者(步骤924)。例如，如果具有相同虚拟名称的对应的应用程序范围的键或者具有相同虚拟名称的对应系统范围的键具有″正存在″，也就是说，存在于该范围中，那么就把对应于用户范围的文字键的虚拟键视为是用于屏蔽范围不同的键，并且不被标记为是占位符，并且不被视为是删除的。类似地，如果一个系统范围的键存在，就把应用程序范围的键视为是屏蔽对应于相同虚拟名称的系统范围的键，并且不被视为是删除的。
如果找到的要删除的文字键不是去屏蔽在另一个范围中具有相同虚拟名称的另一个键，那么就实际地删除要删除的文字键并且把结果返回(步骤926)。
在一些实施例中，与该文字注册表键相关联的操作系统权限可以防止删除该文字注册表键。在这些实施例中，返回一个错误消息该虚拟注册表键不会被删除。
在一些实施例中，该文字注册表键可以被与元数据相关联，它表明该虚拟化的注册表键已经被删除。在一些实施例中，关于注册表键的元数据可以存储在由那个键所保持的不同的值中，那个值的存在对注册表API的通常应用程序利用是隐瞒着的。在一些实施例中，关于注册表键的小量的元数据的可以被直接地存储在文字键名称中，诸如通过给该虚拟名称添加上元数据指示符作为后缀，此处元数据指示符是唯一地与特定元数据状态相关联的字符串。该元数据指示符可以表明或者编码元数据的一个或者若干比特。请求用虚拟名称访问该键以检查由于存在元数据指示符而导致该文字键名称的可能的变化的请求和请求获取该键自身的名称的请求被钩住或者拦截，以便用该文字名称做应答。在其他实施例中，该元数据指示符可以被编码在子键名称或者注册表值名称中，而不是编码在该键名称自身中。在再一些其他的实施例中，注册表键系统可以直接地提供为每个键存储某个第三方元数据的能力。在一些实施例中，元数据可以被存储在数据库中或者存储在独立于注册表数据库的知识库中。在一些实施例中，相独立的子范围可以被使用来存储被标记为是删除的键。该键在该子范围中的存在表明该键被标记为是删除的。
在这些实施例中的特定实施例中，删除的键或者键系统元素的列表可以被维持和被查阅，用以优化对删除的键的这一检查。在这些实施例中，如果删除的键被重新创建，那么该键名称就可以被从删除的键的列表中除去。在这些实施例的其他实施例中，如果该列表增长到超过某一大小，那么键名称就可以被从该列表中除去。
在一些实施例中，文字注册表键在相同范围中的祖先被与表明它被删除或者另外表明它要被删除的元数据相关联。在这些实施例中，可以返回一条错误消息，表明该虚拟化的注册表键不存在。在这些实施例中的特定实施例中，删除的注册表键或者注册表键系统元素的列表可以被维持和被查阅，用以优化对删除的注册表键的这一检查。
4.2.3注册表键列举操作现在参考图10，在简单的概况中，示出在所描述的虚拟化环境中列举键所采取的步骤的一个实施例。在能够列举键之前，首先必须要成功用列举访问打开键(步骤1001)。如果该键没有被成功地打开，那么就返回一个错误(步骤1040)。如果该虚拟键被成功地打开了，那么请求列举的请求就被接收或者拦截，该请求包括到对应于该虚拟键的文字键的句柄(步骤1002)。
确定对应于该句柄的虚拟键名称，并且查阅规则引擎，用以为在该列举请求中所指定的键确定规则(步骤1004)。如果该规则没有指定动作″隔离″，而相反指定″忽略″或者指定″重定向″(步骤1006)，那么就列举由该文字键句柄所标识的文字键，并且把列举结果存储在工作数据存储器中(步骤1012)，之后是稍后所描述的步骤1030。
然而，如果该规则动作指定″隔离″，那么首先就列举该系统范围；也就是说，该候选键名称就确切地是该虚拟键名称，并且如果该候选键存在，那么就列举它。把列举结果存储在工作数据存储器中。如果该候选键不存在，那么在此阶段，该工作数据存储器保持为空(步骤1014)。接下来，把该候选键标识为是该虚拟键的应用程序范围的实例，并且确定该候选键的存在的类别(步骤1015)。
如果该候选键具有“负存在″，即，它或者它在该范围中的一个祖先被标记为是删除的，那么在此范围之内，它就已知是被删除的，并且这是通过清除该工作数据存储器而表明的(步骤1042)。如果取而代之该候选键不具有负存在，那么就列举该候选键，并且把所获得的任何列举都归并到工作数据存储器中。特别地，为在该列举中的每个子键，来确定它的存在的类别。把具有负存在的子键从该工作数据存储器中除去，并且具有正存在的子键，即，那些存在并且没有被标记为是占位符并且没有被标记为是删除的子键，被添加到工作数据存储器，如果一个子键已经存在于该工作数据存储器中，那么就替换对应的子键(步骤1016)。
在任一情况下，把该候选键标识为是该虚拟键的用户范围实例，并且确定该候选键的存在的类别(步骤1017)。如果该候选键具有“负存在″，即，它或者它在该范围中一个祖先被标记为是删除的，那么在此范围之内，它就已知是被删除的，并且这是通过此清除该工作数据存储器来表明的(步骤1044)。如果取而代之该候选键不具有负存在，那么就列举该候选键，并且把所获得的任何列举结果都归并到工作数据存储器中。特别地，为该列举中的每个子键，都确定它的存在的类别。把具有负存在的子键从该工作数据存储器中除去，并且具有正存在的子键，即，那些存在并且没有被标记为是占位符并且没有被标记为是删除的子键，被添加到工作数据存储器，如果一个子键已经存在于该工作数据存储器中，那么就替换对应的子键(步骤1018)，之后是稍后所描述的步骤1030。
然后，为所有的三种类型的规则，执行步骤1030。查询该规则引擎，用以查找规则集合，该规则集合的过滤器匹配该请求的虚拟键名称的直接孩子，但是却不匹配该请求的虚拟键名称自身(步骤1030)。为该集合中的每条规则，确定其名称匹配该规则中的名称的虚拟孩子的存在。如果该孩子具有正存在，那么就把它添加到工作数据存储器，取代已经在那里具有相同名称的任何孩子。如果该孩子具有负存在，就除去在该工作数据存储器中对应于该孩子的条目(如果存在的话)。(步骤1032)。最后，然后把所构造的列举从该工作数据存储器返回给请求者(步骤1020)。
还参考图10，更详细地，为了列举一个键，首先必须用列举访问来打开它(步骤1001)。请求用列举访问打开该键的请求包括该键的名称，该键的名称被隔离环境当作虚拟名称来对待处理。对全虚拟化的键打开按照在第4.2.1节中是描述的那样来执行。如果该虚拟化的打开操作失败，就把一个错误返回给请求者(步骤1040)。如果该该虚拟化的打开操作成功，就把对应于该虚拟键的文字键的句柄返回给请求者。然后，请求列举在步骤1001被打开过的注册表键的请求被接收或者拦截(步骤1002)。该打开的文字注册表键可以属于用户隔离范围，应用程序隔离范围，系统范围，或者适用的隔离子范围。在一些实施例中，该列举请求被替换操作系统函数或者替换用于列举注册表键的函数的函数而钩住。在另一个实施例中，挂钩动态链接库被使用来拦截该列举请求。该挂钩函数可以执行在用户模式中或者执行在核心模式中。对于该挂钩函数执行在用户模式中的实施例而言，当创建一个进程之时，挂钩函数可以被加载到该进程的地址空间中。对于挂钩函数执行在核心模式中的实施例而言，挂钩函数可以与在分派对本机注册表键的请求中使用的操作系统资源相关联。在其他实施例中，概念上与文件系统过滤器驱动器工具相类似的注册表过滤器驱动器工具可以由操作系统来提供。本领域技术人员可以创建注册表过滤器驱动器，操作系统把请求执行注册表操作的请求传递到该注册表过滤器驱动器，由此提供拦截注册表操作请求的机制。对于为每种类型的注册表键函数都提供相独立的操作系统函数的实施例而言，每个函数都可以独立地钩住。作为选择，可以提供单个挂钩函数，它用以拦截对若干类型的注册表键函数的创建或者打开调用。
该列举请求包含文字键句柄。与该句柄相关联的虚拟键名称是通过查询操作系统中与该句柄相关联的文字名称来确定的。查阅该规则引擎，用以确定与该文字名称相关联的虚拟名称(如果存在的话)。
确定如何来处理注册表键操作(步骤1004)的规则是通过查阅规则引擎来获得的。在一些实施例中，要列举的虚拟注册表键的虚拟键名称被使用来在规则引擎中定位施加到该请求的规则。在这些实施例的特别实施例中，对于特别的虚拟注册表键，多个规则都可以存在于该规则引擎中，在这些实施例的一些实施例中，与该虚拟键名称具有最长前缀匹配的规则就是施加到了该请求的规则。在一些实施例中，该规则引擎可以被提供为是关系数据库。在其他实施例中，该规则引擎可以树形结构的数据库，哈希表，或者平面注册表键数据库。在一些实施例中，对应于在该请求中的虚拟键句柄的虚拟键名称被用作进入到规则引擎用以定位施加到该请求一个或者多个规则的索引。在一些实施例中，进程标识符被使用来在规则引擎中定位施加到该请求的规则(如果存在一条规则的话)。与一个请求相关联的规则可以是去忽略该请求，重定向该请求，或者隔离该请求。规则查找可以作为一系列判定而发生，或者该规则查找可以作为单个数据库事务而发生。
如果该规则动作不是″隔离″(步骤1006)，而是″忽略″或者是″重定向″，那么就使用该文字键句柄把请求列举该文字键的请求传递到操作系统，并且把列举结果(如果存在的和)存储在工作数据存储器中(步骤1012)，并且步骤1030按照稍后是描述的那样来执行。
在一个实施例中，这是通过调用原始版本的挂钩函数并且把所形成的文字名称传递到该函数作为参数来实现的。在其他实施例中，概念上与文件系统过滤器驱动器工具相类似的注册表过滤器驱动器工具可以由操作系统提供。在这些实施例中，列举该文字注册表键可以通过向该注册表过滤器管理器发信号去以通常的方式来处理未经修改的请求来应答请求列举该键的请求。
如果在步骤1010中所确定的该规则动作是″隔离″，那么就列举该系统范围。为了实现这一点，把该候选键标识为是对应于要列举的虚拟键的系统范围的键。该候选键被列举，并且列举的结果被存储在工作数据存储器中(步骤1014)。在一些实施例中，该工作数据存储器由存储器元件组成。在其他实施例中，该工作数据存储器包括数据库或者键或者固态存储器元件或者持久的数据存储器。
接着，把该候选键标识为是该虚拟键的应用程序范围的实例，并且确定该候选键的存在的类别(步骤1015)。如果该候选键具有“负存在″，即，它或者它在该范围中的一个祖先被标记为是删除的，那么在此范围之内，它就已知是被删除的，并且这是通过清除工作数据存储器来表明的(步骤1042)。
在一些实施例中，该候选注册表键可以与表明该候选注册表键已经被删除的元数据的相关联。在一些实施例中，关于注册表键的元数据可以存储在由那个键所保持的不同的值，那个值的存在对注册表API的通常应用程序使用是隐瞒着的。
在一些实施例中，关于注册表键的一些量的元数据可以直接地存储在文字键名称中，诸如通过给虚拟名称加上一个元数据指示符的后缀，此处元数据指示符是唯一地与特别的元数据状态相关联的字符串。该元数据指示符可以表明或者编码元数据的一个或者若干个比特。请求用虚拟名称访问该键以检查由于存在元数据指示符而导致的文字名称可能的变化的请求和用于获取该键自身的名称的请求被钩住或者拦截，以便用文字名称作出应答。在其他实施例中，该元数据指示符可以编码在子键名称或者注册表值名称中而不是编码在该键名称自身中。在再一些其他的实施例中，注册表键系统可以直接地提供为每个键都存储某个第三方元数据的能力。在一些实施例中，元数据被存储在数据库或者独立于注册表数据库的其他知识库中。在一些实施例中，相独立的子范围可以被使用来存储被标记为是删除的键。一个键在该子范围中的存在表明该键被标记为是删除的。
如果取而代之，在步骤1015，该候选键不具有负存在，那么就列举该候选键并且把所获得的任何列举结果都归并到工作数据存储器中。特别地，为在该列举中的每个子键，都确定它的存在的类别。具有负存在的子键被从工作数据存储器中除去，并且具有正存在的子键，即，那些存在并且没有被标记为是占位符并且没有被标记为是删除的子键，被添加到工作数据存储器，如果一个子键已经存在于工作数据存储器中，那么就替换对应的子键(步骤1016)。
在任一情况下，把该候选键标识为是该虚拟键的用户范围的实例，并且确定该候选键的存在的类别(步骤1017)。如果该候选键具有“负存在″，即，它或者它在该范围中的一个祖先被标记为是删除的，那么在此范围之内，它就已知是被删除的，并且这是通过清除工作数据存储器而表明的(步骤1044)。如果取而代之该候选键不具有负存在，那么就列举该候选键并且把所获得的任何列举结果都归并到工作数据存储器中。特别地，为在该列举中的每个子键，都确定它的存在的类别。负存在的子键被从工作数据存储器中除去，并且具有正存在的子键，即，那些存在并且没有被标记为是占位符并且没有被标记为是删除的子键，被添加到工作数据存储器，如果一个子键已经存在于工作数据存储器中，那么就替换对应的子键(步骤1018)，之后是以下所描述的步骤1030。
然后，为所有的三种类型的规则，执行步骤1030。查询该规则引擎，用以查找规则的集合，该规则的过滤器匹配该请求的键的直接孩子，但是却不匹配该请求的键自身(步骤1030)。为在该集合中的每个规则，确定虚拟孩子的存在，该虚拟孩子的名称匹配在该规则中的名称。在一些实施例中，这是通过检查适当的隔离范围并且与该虚拟孩子相关联的元数据来实现的确定。在其他实施例中，这是通过试图去打开该键来确定的。如果该打开请求成功，那么该虚拟孩子就具有正存在。如果该打开请求失败，且表明该虚拟孩子不存在，那么该虚拟孩子就具有负存在。
如果该孩子具有正存在，那么就把它添加到工作数据存储器，替换已经在那里具有相同名称的任何孩子。如果该孩子具有负存在，那么在该工作数据存储器中对应于该虚拟孩子的孩子(如果有的话)就被除去。(步骤1032)。最后，把所构造的列举然后从该工作数据存储器返回给请求者(步骤1020)。
本领域普通技术人员将会认识到把上述的分层的列举进程做较小的修改就能够应用到列举包括多个隔离子范围的单个隔离范围的操作上。工作数据存储器被创建，相继的子范围被列举并且把结果归并到工作数据存储器中以形成隔离范围的聚合列举。
4.2.4.注册表创建操作现在参考图11，在简单的概况中，示出在隔离环境中创建键所采取的步骤的一个实施例。用于创建键的请求被接收或者拦截(步骤1102)。该请求包含键名称，该键名称被隔离环境当作虚拟键名称来处理对待。试图去使用适用的规则，即，使用适当的用户和应用程序隔离范围使用全虚拟化打开所请求的键，如以在第4.1.1节中所描述的(步骤1104)。如果访问被拒绝(步骤1106)，那么就把访问拒绝错误返回给请求者(步骤1109)。如果访问被许可(步骤1106)，并且该请求的键被成功地打开(步骤1110)，那么就把所请求的键返回给请求者(步骤1112)。然而，如果访问被许可(步骤1106)，但是该请求的键却没有被成功地打开(步骤1110)，那么如果该请求的键的双亲也不存在(步骤1114)，就向请求者发出适合于该请求语义的错误(步骤1116)。如果相反使用适当的用户和应用范围在全虚拟化的视图中找到了该请求的键的双亲(步骤1114)，那么规则然后就确定该键操作如何被处理(步骤1118)。如果该规则动作是″重定向″或者″忽略″(步骤1120)，那么就依照规则把该虚拟键名称直接地映射到文字键名称。特别地，如果规则动作是″忽略″，那么就把该文字键名称标识为确切地就是虚拟键名称。如果取而代之，该规则动作是″重定向″，那么就根据该规则所指定的虚拟键名称来确定文字键名称。然后把创建该文字键的请求传递到操作系统，并且把该结果返回给请求者(步骤1124)。如果相反，在步骤1120中所确定的该规则动作是″隔离″，那么就把该文字键名称标识为是该虚拟键名称在用户隔离范围中的实例。如果该文字键已经存在，但是却与表明它是占位符或者它被删除的元数据相关联，那么就修改该相关联的元数据以便除去改那些表明，并且确保该键是空的。在任一情况下，把打开该文字键的请求传递到到操作系统(步骤1126)。如果该文字键被成功地打开过了(步骤1128)，那么就把该文字键返回给请求者(步骤1130)。如果相反，在步骤1128，该请求的键没有打开，就把当前不存在于用户隔离范围中的文字键的每个祖先的占位符(步骤1132)和用于使用文字名称去创建该文字键的请求传递到操作系统并且把该结果返回给请求者(步骤1134)。
还参考图11，更详细地，创建键的请求被接收或者拦截(步骤1102)。在一些实施例中，该请求被替换掉操作系统函数或者替换用于创建键的函数的函数钩住。在另一实施例中，挂钩动态链接库被使用来拦截该请求。该挂钩函数可以执行在用户模式下也可以执行在核心模式下。对于该挂钩函数执行在用户模式下的实施例而言，当创建一个进程之时，就可以把该挂钩函数加载到该进程的地址空间中。对于该挂钩函数执行在核心模式中的实施例而言，可以把该挂钩函数与在分派对键操作的请求中所使用的操作系统资源相关联。对于为每种类型的键操作都提供相独立的操作系统函数的实施例而言，每个函数都可以被独立地钩住。作为选择，可以提供单个挂钩函数，它拦截对若干类型的键操作的创建或者打开调用。
该请求包含键名称，该键名称被隔离环境当作虚拟键名称对待处理。在一些实施例中，该虚拟键名称可以被表示双亲键的句柄和到后继键的相对路径名称的组合。该双亲键句柄被与文字键名称相关联，该文字键名称自身就与虚拟键名称相关联。请求者试图去使用适用的规则，即，使用适当的用户和应用程序隔离范围使用全虚拟化打开虚拟键，如在第4.2.1中所描述的(步骤1104)。如果在全虚拟化的打开操作期间访问被拒绝(步骤1106)，那么就把访问拒绝错误返回给请求者(步骤1109)。如果访问被许可(步骤1106)，并且该请求的虚拟键被成功地打开(步骤1110)，那么就把对应的文字键返回给请求者(步骤1112)。然而，如果访问被许可(步骤1106)，但是该虚拟键却没有被成功地打开(步骤1110)，那么就已经确定出该虚拟键是不存在的。如果该请求的虚拟键的虚拟双亲也不存在，正如在第4.2.1中的过程所确定的那样(步骤1114)，那么就向请求者发出适合于请求语义的错误(步骤1116)。如果相反，使用适当的用户和应用范围在全虚拟化的视图中找到了该请求的虚拟键的虚拟双亲(步骤1114)，那么就通过查阅规则引擎来定位确定如何来处理创建操作的规则(步骤1118)。在一些实施例中，该规则引擎可以被提供为是关系数据库。在其他实施例中，该规则引擎可以是树形结构的数据库，哈希表，或者平面键数据库。在一些实施例中，为该请求的键所提供的虚拟键名称被使用来在规则引擎中定位施加到该请求的规则。在这些实施例的特别实施例中，对于特别的键，多个规则都可以存在于该规则引擎中，并且在这些实施例的一些实施例中，与虚拟键名称具有最长前缀匹配的规则就是施加到该请求的规则。在一些实施例中，进程标识符被使用来在规则引擎中定位施加到该请求的规则(如果一条规则存在的话)。与请求相关联的规则可以是去忽略该请求，重定向该请求，或者隔离该请求。尽管在图11中示为单个数据库事务或者在键中的单个查找，但是该规则查找可以作为一系列的规则查找来执行。
如果该规则动作是″重定向″或者″忽略″(步骤1120)，那么就依照规则把该虚拟键名称直接地映射到文字键名称(步骤1124)。如果该规则动作是″重定向″(步骤1120)，那么就根据由该规则所指定的虚拟键名称来确定文字键名称(步骤1124)。如果该规则动作是″忽略″(步骤1120)，那么该文字键名称就被确定为确切地就是该虚拟键名称(步骤1124)。如果该规则动作是″忽略″或者该规则动作是″重定向″，那么就把请求使用所确定的文字键名称创建该文字键的请求传递到操作系统并且把来自于操作系统的结果返回给请求者(步骤1124)。例如，创建名称为″key_1″的虚拟键的请求就可能导致创建名称为″Different_key_1″的文字键。在一个实施例中，这是通过调用原始版本的挂钩函数并且把所形成的文字名称传递到该函数作为参数来实现的(步骤1124)。在其他实施例中，概念上与文件系统过滤器驱动器工具相类似的注册表过滤器驱动器工具可以由操作系统提供。在这些实施例中，创建该文字注册表键可以通过向该注册表过滤器管理器发信号去使用所确定的文件键名称来重新解析请求创建虚拟键的原始请求来应答该原始请求。
如果在步骤1120中所确定的规则动作不是“忽略”，也不是“重定向”，而是“隔离”，那么就把该文字键名称标识为是该虚拟键名称在用户隔离范围中的实例。如果该文字键已经存在，但是却与表明它是一个占位符或者它被删除了的元数据相关联，那么就修改该关联的元数据，用以除去那些表明，并且确保该键是空的。
在一些实施例中，关于注册表键的元数据可以被存储在由那个键所保持的不同的值中，那个值的存在对于注册表API的通常的应用程序的使用是隐瞒着的。在一些实施例中，关于注册表键的小量的元数据可以被直接地存储文字键名称中，诸如通过给该虚拟名称添加上元数据指示符的后缀，此处元数据指示符是唯一地与特别的元数据状态相关联的字符串。该元数据指示符可以表明或者编码元数据的若干比特。请求用虚拟键名访问以检查由于元数据指示符的存在而导致文字键名的可能的变化的请求和请求获取该键自身的名称的请求被钩住或者拦截，以便用该文字名称来应答。在其他实施例中，该元数据指示符可以被编码在子键名称或者注册表值名称中，而不是编码在该键名称自身中。在再一些其他的实施例中，注册表键系统可以直接地提供为每个键都存储某个第三方元数据的能力。在一些实施例中，元数据可以被存储在数据库中或者存储在独立于注册表数据库的知识库。在一些实施例中，相独立的子范围可以被使用来存储被标记为是删除的键。键在子范围中的存在表明该键被标记为是删除的。
在这些实施例中的特定的一些实施例中，删除的键或者键系统元素的列表可以被维持并且可以被查阅，用以优化对删除的键的这一检查。在这些实施例中，如果删除键被重新创建，那么该键名称就可以被从删除的键的列表中除去。在这些实施例的其他实施例中，如果该列表增长到超过某一大小，那么就可以从该列表中除去键名称。
在任一情况下，把请求打开用户范围的文字键的请求传递到操作系统(步骤1126)。在一些实施例中，规则可以指定对应于该虚拟键的文字键应该被创建在不同于用户隔离范围的范围(诸如应用程序隔离范围，系统范围，用户隔离子范围或者应用程序隔离子范围)中。
如果该文字键被成功地打开了(步骤1128)，就把文字键返回给请求者(步骤1130)。如果相反，在步骤1128，该请求的键未能打开，那么就为当前不存在于用户隔离范围中的文字键的每个祖先创建占位符(步骤1132)并且把请求使用文字名称创建文字键的请求传递到操作系统并且把该结果返回给请求者(步骤1134)。
此实施例用于具有仅仅支持每个调用/引用创建一个级别的API或者工具的操作系统。对于本领域技术人员而言显而易见是能够扩展到每个调用/引用多个级别。
4.3命名对象虚拟化操作另一类系统范围的资源(它们可以使用上述的技术被虚拟化)是命名对象，该命名对象包括信号量，互斥体，变异株，可等待的定时器，事件，工作对象对象，分段(section)，命名管道以及邮件时隙(mailslot)。这些对象的特征在于它们典型地仅仅在创建它们的进程的持续时间期间才存在。用于这些对象的名称空间可以在整个计算机(在范围上是全局的)是有效的或者仅仅在单独的用户会话中是有效的(范围在对话上)。
现在参考图12，在简单的概况中，请求创建或者打开命名对象的请求被接收或者拦截(步骤1202)。该请求包含对象名称，该对象名称被隔离环境当作虚拟名称来对待处理。确定如何来对待该请求的规则(步骤1204)。如果该规则表明该请求应该被忽略(步骤1206)，那么就把文字对象名称确定为就是虚拟名称(步骤1207)，并且把请求创建或者打开文字对象的请求发给操作系统(步骤1214)。如果该确定的规则不是去忽略该请求，而相反则表明该请求应该被重定向(步骤1208)，那么就根据由重定向规则所规定的虚拟名称来确定该文字对象名称(步骤1210)，并且请求创建或者打开该文字对象的请求被发给操作系统(步骤1214)。如果该规则没有表明该请求应该被重定向(步骤1208)，而相反表明该请求应该被隔离，那么就根据由隔离规则所规定的虚拟名称来确定该文字对象名称(步骤1212)并且创建或者打开对该文字对象的命令被发给操作系统(步骤1214)。把由操作系统响应于所发出的创建或者打开命令而返回的文字对象的句柄返回给请求创建或者打开该虚拟对象的程序(步骤1216)。
还参考图12，更详细地，进程的请求创建或者打开命名对象的请求被拦截(步骤1202)。该命名对象可以属于会话范围或者它可以属于全局范围。在一些实施例中，该请求由替换操作系统函数或者替换用于创建或者打开命名对象的函数的函数而钩住。在另一个实施例，挂钩动态链接库被使用来拦截请求。该挂钩函数可以执行在用户模式中或者执行在核心模式中。对于该挂钩函数执行在用户模式中的实施例而言，当创建一个进程之时，该挂钩函数可被以加载到该进程的地址空间中。对于该挂钩函数执行在核心模式中的实施例而言，该挂钩函数可以被与在分派对系统对象的请求中使用的操作系统资源相关联。请求创建或者打开该命名对象的请求可以引用用于在进程间的通信和同步的并且由唯一的标识符所标识的宽范围的多种类系统范围的资源中的任何一个资源，该唯一标识符包括信号量，互斥体，变异株，可等待的定时器，文件映射对象，事件，工作对象，分段，命名管道以及邮件时隙。对于为每种类型的对象都提供相独立的操作系统函数的实施例而言，每个函数都可以被独立地钩住。作为选择，可以提供单个挂钩函数，它拦截创建或者打开对若干类型的对象的调用。
所拦截的请求包含对象名称，该对象名称被隔离环境当作虚拟名称来对待处理。通过查阅规则引擎来确定用于确定如何来对待对该对象的请求的规则(步骤1204)。在一些实施例中，该规则引擎可以被提供为是关系数据库。在其他实施例中，该规则引擎可以是树形结构数据库，哈希表，或者平面文件数据库。在一些实施例中，为该请求的对象所提供的虚拟名称被使用来在该规则引擎中定位施加到该请求的规则。在这些实施例的特别实施例中，对于特别的对象，多个规则都可以存在于该规则引擎中，在这些实施例中，与该虚拟名称之间具有最长前缀匹配的规则就是施加到了该请求的规则。在一些实施例中，进程标识符被使用来在该规则引擎定位施加到该请求的规则(如果一条规则存在的话)。与请求相关联的规则可以是忽略该请求，重定向该请求，或者隔离该请求。尽管在图12中示为一系列判定，但是该规则查找可以作为单个数据库事务而发生。
如果该规则表明该请求应该被忽略(步骤1206)，那么该文字对象名称就被确定为是该虚拟名称，并且把请求创建或者打开该文字对象的请求发给操作系统(步骤1214)。例如，请求创建或者打开名称为″Object_1″的命名对象的请求将导致创建实际上名称为″Object_1″的对象。在一个实施例中，这是通过调用原始版本的挂钩函数并且把所形成的文字名称传递到该函数作为参数来实现的。
如果通过访问该规则引擎所确定的规则不是去忽略该请求，而相反是表明该请求应该被重定向(步骤1208)，那么就根据由重定向规则所规定的虚拟名称来确定该文字对象名称(步骤1210)并且对文字对象的创建或者打开请求被发给操作系统(步骤1214)。例如，请求创建或者打开名称为″Object_1″的命名对象可能导致创建实际上名称为″Different_Object_1″的对象。在一个实施例中，这是通过调用原始版本的挂钩函数并且把所形成的文字名称传递到该函数作为参数来实现的。
如果该规则没有表明该请求应该被重定向(步骤1208)，而是相反表明该请求应该被隔离，那么就根据由隔离规则所规定的虚拟名称来确定该文字对象名称(步骤1212)并且把对该文字对象的创建或打开命令发给操作系统(步骤1214)。例如，请求创建或者打开名称为″Object_1″的命名对象的请求可能会导致创建实际上名称为″Isolated_Object_1″的对象。在一个实施例中，这是通过调用原始版本的挂钩函数并且把所形成的文字名称传递到该函数作为参数来实现的。
为了隔离请求的系统对象而形成的文字名称可以基于所接收的虚拟名称和范围专用的标识符。该范围专用的标识符可以是与应用程序隔离范围，用户隔离范围，会话隔离范围，或者它们三个的某种组合相关联的标识符。该范围专用的标识符被使用来″弄乱″在该请求中所接收的虚拟名称。例如，如果对于其相关联的标识符是″SA1″的应用程序隔离范围，对命名对象″Object_1″的请求是被隔离的，那么该文字名称就可以是″Isolated_AppScope_SA1_Object_1″。下表标识用会话隔离范围，或者用户隔离范围和应用程序隔离范围弄乱该对象的名称的影响。使用范围的组合的弄乱把在该表中所列出的限制组合起来。

对于操作系统是WINDOWS系列操作系统之一的实施例而言，对象范围可以通过来回切换与该对象相关联的全局/局部名称前缀而修改，对于隔离的应用程序而言，这与和使用会话专用的标识符来弄乱对象名称具有相同的影响。然而，对于非隔离的应用程序而言，来回切换全局/局部名称前缀也影响对象范围。
把由操作系统响应于在步骤1214中所发出的创建或者打开该命名对象的命令而返回的文字对象的句柄返回给请求创建或者打开该虚拟对象的程序(步骤1216)。
4.4窗口名称虚拟化可以使用上述的技术虚拟化的其他类的系统范围的资源是窗口名称和窗口类名称。图形软件应用程序使用窗口或者它的窗口类的名称作为一种识别方式，来识别应用程序是否已经在运行着并且用于其他形式的同步。现在参考图13，在简单的概况中，关于窗口名称或者窗口类的请求被接收或者拦截(步骤1302)。请求能够采用Win32 API调用的形式或者采用窗口消息的形式。两种类型的请求都被处理。那些请求包含或者请求获取窗口名称和/或窗口类名称，窗口名称和/或窗口类名称被隔离环境当作虚拟名称来对待处理。如果该请求是去获取用句柄所标识的窗口的窗口名称或者窗口类(步骤1304)，那么就查阅窗口映射表，用以确定该句柄和请求的关于该窗口的信息是否是已知的(步骤1306)。如果是已知的，那么就把来自该窗口映射表的请求信息返回给请求者(步骤1308)。如果不是已知的，那么就把该请求传递到操作系统(步骤1310)，并且把该结果返回给请求者(步骤1314)，在步骤1304，该请求提供窗口名称或者窗口类，那么就检查该请求检查，用以确定它是否指定由操作系统所定义的窗口的一个类(步骤1320)。如果它指定了，那么就把该请求发给操作系统并且把从操作系统返回的结果返回给请求者(步骤1322)。如果该请求没有指定由操作系统所定义的窗口的一个类，那么就根据该虚拟类名称和规则来确定文字类名称(步骤1324)并且根据虚拟窗口名称和规则来和文字窗口名称(步骤1326)。然后使用文字窗口和文字类名称把该请求传递到操作系统(步骤1328)。如果在步骤1324和1326中所确定的文字窗口名称或者文字窗口类名称不同于对应的虚拟名称，那么就更新该窗口句柄的窗口映射表条目，用以记录在该请求中所提供的虚拟窗口名称或者虚拟类名称(步骤1330)。如果来自操作系统的响应包括本机窗口名称或者类的本机标识，那么就用在该请求中所提供的虚拟窗口名称或者虚拟类名称来替换它们(步骤1312)并且把该结果返回给请求者(步骤1314)。
还参考图13，更详细地，关于窗口名称或者窗口类的请求被接收或者拦截(步骤1302)。那些请求包含或者请求获取窗口名称和/或窗口类名称，它们被隔离环境当作虚拟名称来处理。
如果该请求是去获取用句柄所标识的窗口的窗口名称或者窗口类(步骤1304)，那么就查阅映射表，用以确定该句柄和关于该窗口的请求信息是否是已知的(步骤1306)。在一些实施例中，使用由操作系统所提供的工具为每个窗口和窗口类存储附加数据，来取代存储映射表。
如果是，那么就把来自的窗口映射表的请求信息返回给请求者(步骤1308)。如果不是，那么就把该请求传递到操作系统(步骤1310)，并且把结果返回给请求者(步骤1314)。
如果在步骤1304，该请求提供窗口名称或者窗口类，那么就检查该请求，以便确定它是否指定由操作系统所定义的窗口的一个类(步骤1320)。如果它提供了，那么就把该请求传递到操作系统并且把从操作系统所返回的结果返回给请求者(步骤1322)。
如果该请求没有指定由操作系统所定义的窗口的一个类，那么就根据虚拟类名称和规则来确定文字类名称(步骤1324)并且根据虚拟窗口名称和规则确定文字窗口名称(步骤1326)。然后，使用文字窗口和文字类名称把该请求传递到操作系统(步骤1328)。在一些实施例中，窗口名称和窗口类名称可以原子，而不是字符串文字。典型地，应用程序把字符串置于原子表中和接收16比特的整数(称为原子)，该原子能够被使用来访问该字符串。
如果在步骤1324和1326中所确定的文字窗口名称或者文字窗口类名称不同于对应的虚拟名称，那么就更新该窗口句柄的窗口映射表条目，用以记录在该请求中所提供的虚拟窗口名称或者虚拟类名称(步骤1330)。
如果来自操作系统的响应包括本机窗口名称或者类的本机标识，那么就用在该请求中所提供的虚拟窗口名称或者虚拟类名称来替换它们(步骤1312)并且把该结果返回给请求者(步骤1314)。
现在参考图13A，按照在那里所示出的那样来确定文字窗口名称或者窗口类名称示出。查阅该规则引擎，以便确定施加到该请求的规则(步骤1352)。如果该规则动作是″忽略″(步骤1354)，那么就使该文字名称等于该虚拟名称(步骤1356)。然而，如果该规则动作不是″忽略″而是″重定向″(步骤1358)，那么就根据由重定向规则所指定的虚拟名称来确定文字名称(步骤1360)。然而，如果该规则动作不是″重定向″而是″隔离″，那么就使用范围专用的标识符根据虚拟名称来确定该文字名称(步骤1362)。
在一些实施例中，特定范围专用的标识符被规定在该规则中。在其他实施例中，所使用的该范围专用的标识符是一个与应用程序隔离范围相关联的标识符，发出请求的进程与该应用程序隔离范围相关联。这样就允许该窗口或者窗口类由与相同的应用程序隔离范围相关联的任何其他的应用程序来使用。在操作系统(诸如任何微软WINDOWS系列操作系统中的任何一种操作系统)中，此处窗口名称和类在一个会话之内已经被隔离，这就意味着只有执行在该相同会话中与相同的应用程序隔离范围相关联的应用程序才能够使用窗口名称或者类。
在一些系列的微软WINDOWS操作系统中，该窗口名称被用作为窗口在标题栏中的标题。人们希望处理非客户区的画图窗口消息，以确保在窗口标题栏中所显示的窗口标题反映出该虚拟名称而不是显示特定窗口的文字名称。当非客户区的画图消息被拦截之时，那么就从映射表中获取与该窗口相关联的虚拟名称(如果存在的话)。如果获取到了虚拟名称，那么就把虚拟名称用作窗口标题来绘制非客户区并且表明该请求消息已经被处理了。如果没有获取到任何虚拟名称，那么就使用该窗口的文字名称表明该请求是没有被处理的，这就把该请求转到用于绘制标题栏的原始函数上。
4.5进程外COM服务器虚拟化软件组件技术(诸如COM，CORBA，NET以及其他)允许软件组件被开发，部署，注册，发现，激活或者实例化以及被用作离散的单元。在大多数组件模型中，组件可以执行在调用者的进程中，也可以执行在相同的计算机上或者在完全独立的计算机上的相独立的进程中，不过一些组件仅仅可以支持这些情况的子集。
一个或者多个唯一的标识符标识这些组件。典型地，组件基础结构提供用于代理活动请求的服务或者守护进程(daemon)。希望开始使用组件的软件进程把一个请求传递给代理，用以激活用该组件标识符所指定的那个组件。该代理激活所请求那个组件(如果可能的话)，并且返回对被激活的实例的引用。在这些组件基础结构中的一些基础结构中，相同的组件的多个版本不可以共同存在，原因在于该组件标识符从一个版本到另一版本保持是相同的。
WINDOWS系列操作系统的一些成员提供称为COM的组件基础结构。COM组件(″COM服务器″)用称为类标识符(CLSID)的GUID而标识，并且每个组件提供一个或者多个接口，所述接口中的每个接口都具有它自己唯一的接口标识符(UIID)。COM服务控制管理器(CSCM)就是用于进程外激活请求的代理并且它提供允许调用者经由CLSID去请求激活COM服务器的接口。尽管以下的说明就COM服务器并且COM客户使用短语表达，但是本领域技术人员应该理解的是它适用于CORBA、NET和规定动态激活软件组件的其他软件体系结构。
当COM组件被安装到计算机上之时，它们把它们的CLSID与由CSCM启动COM服务器的新实例所需要的信息一起注册到注册表数据库中已知部分中。对于进程外的COM服务器，这可以包括到要运行的可执行体的路径和命令行参数。相同COM服务器的多个版共享相同的CLSID，因此每次只有一个版本能够被安装到计算机。
在某些实施例中，应用程序(充当COM客户)通过调用COM API(例如，CoCreateInstance()或者CoCreateInstanceEx())来实例化COM服务器。此调用的参数规定希望的活动上下文进程中；相同的计算机上的进程外；远程计算机上的进程外；或者允许COM子系统去确定要使用这三种情况中的哪一种。如果确定出需要进程外活动，那么就把包括CLSID的请求传递到CSCM。该CSCM使用注册表数据库定位路径和参数，该路径和参数是启动作为COM服务器的主的可执行体所需要的。当该可执行体被启动之时，它就使用COM APICoRegisterClassObject()来向CSCM注册它所支持的所有COM服务器的所有CLSID。如果该请求的CLSID被注册了，那么该CSCM把对该COM服务器的应用返回该调用者。在COM客户和COM服务器之间所有后续的交互独立于该CSCM而发生。
前面所描述的隔离环境200允许具有相同的CLSID的COM服务器的多个实例被安装在计算机上，它们中的每一个都处在不同的隔离范围中(它们中只有一个可以是系统范围)。然而，这单独地将不会使那些COM服务器可用于COM客户。
图14描绘虚拟化对COM服务器的访问所采取的步骤的一个实施例。在简单的概况中，为被启动到隔离范围之中的每个进程外COM服务器创建新的CLSID，以下称为被隔离的CLSID(或者ICLSID)(步骤1402)。根据定义，这是CLSID，并且因此在所有其他的CLSID之中必须是唯一的，换言之，它必须要具有GUID的性质。创建一个映射表，它把成对(CLSID，应用程序隔离范围)映射到ICLSID。为该ICLSID创建COM服务器注册表条目，该ICLSID描述如何去用在适当的应用程序隔离范围中开始COM服务器可执行体的启动参数来启动COM服务器(步骤1404)。由COM客户对COM API(诸如CoCreate Instance()和CoCreateInstanceEx()作出的调用被钩住或者拦截(步骤1406)。如果确定出(a)该请求能够由进程中COM服务器被满足或者(b)COM客户和COM服务器都不与任何隔离范围相关联，那么就把该请求不加修改地传递到原始COM API并且把结果返回给调用者(步骤1408)。识别要使用的COM服务器的适当的实例(步骤1410)。如果选定的COM服务器实例处于应用程序隔离环境中，那么就使用上面概述的数据结构来确定它的ICLSID。否则，就使用在该请求中的CLSID(步骤1412)。如果在步骤1412中识别出了一个ICLSID，那么就用ICLSID来调用原始CoCreateInstance()或者CoCreateInstanceEx()函数。这样就把该请求传递到CSCM(步骤1414)。该CSCM采用通常的方式通过在注册表中查找所请求的CLSID以确定启动参数来查找和启动COM服务器可执行体。如果请求了ICLSID，那么就查找在步骤1404中所描述的ICLSID系统范围注册表条目并且在适当的应用程序隔离范围中启动COM服务器(步骤1416)。所启动的COM可执行体使用它所支持的COM服务器的CLSID来调用所钩住的CoRegisterClassObject()API，然后把这些翻译成被传递到原始CoRegisterClassObject()API的适当的ICLSID(步骤1418)。当该CSCM接收到来自具有期望的CLSID的CoRegisterclassObject()调用的响应之时，它就把对那个COM服务器实例的引用返回给调用者(步骤1420)。
还参考图14，更详细地，为被启动到隔离范围之中的每个进程外COM服务器创建ICLSID(步骤1402)。在一些实施例中，该ICLSID是在安装COM服务器期间创建的。在其他实施例中，该ICLSID是安装之后立即就创建的。在再一些其他的实施例中，该ICLSID是在该COM服务器被启动到隔离范围之中之前创建的。在所有这些实施例中，该ICLSID可以通过钩住或者拦截用于在注册表数据库中创建或者查询CLSID条目的系统调用而创建。作为选择，该ICLSID可以通过钩住或者拦截用于创建COM服务器实例COM API的调用(诸如CoCreateInstance()和CoCreateInstanceEx()而创建。作为选择，在已经发生安装之后，可以观察到该注册表数据库的CLSID专用部分的变化。
创建一个映射表，它把成对(CLSID，应用程序隔离范围)连同具有那个ICLSID的COM服务器的适当的注册表条目映射到ICLSID，该ICLSID描述如何用在适当的应用程序隔离范围中开始COM服务器可执行体的启动参数来启动COM服务器(步骤1404)。在许多实施例中，此表被存储在持久的存储器元件中(诸如硬盘驱动器或者固态存储器元件)。在其他实施例中，该表可以被存储在注册表中，存储在平面文件中，存储在数据库中或者存储在易失性存储器元件中。在再一些其他的实施例中，可以把该表可以分布在注册表数据库的COM专用部分的各处，例如通过把此目的专用特定的新子键添加到由CLSID所标识的每个适当的COM服务器条目而分布。在此表中的条目可以通过钩住或者拦截用于在该注册表数据库中创建CLSID条目的调用在安装期间或者在安装之后立即创建，或者通过观察在已经发生安装之后注册表数据库的CLSID专用部分的变化而创建，或者通过钩住或者拦截用于创建COM服务器实例的COM API调用(诸如CoCreateInstance()和CoCreateInstanceEx())而创建。把COM服务器安装到特定的隔离范围中的安装可以被持久地记录下来。作为选择，把特定COM服务器和隔离范围映射到ICLSID的映射可以被动态地创建并且被存储为在非持久性数据库中的条目，或者存储为在注册表数据库中的条目。
由COM客户对COM的调用(诸如CoCreateInstance()和CoCreate InstanceEx())被钩住或者拦截(步骤1406)。如果确定出(a)该请求能够被进程中的COM服务器满足或者(b)COM客户和COM服务器这二者都驻留在系统范围中(步骤1407)，那么就把该请求不修改地传递到原始COM API并且把结果返回给调用者(步骤1408)。
如果该请求不能够被进程中的COM服务器满足并且不论是COM客户还是COM服务器都没有驻留在该系统范围中(步骤1407)，那么就识别要使用的COM服务器的适当实例(步骤1410)。对于COM客户执行在特定隔离范围中的实施例而言，可以首先把优先权给与安装到相同应用程序隔离范围中的COM服务器，然后是安装到系统范围中的那些(可能执行在客户的应用程序隔离范围中)，之后是安装在其他应用程序隔离范围中的COM服务器。在这些实施例的一些实施例中，安装到系统范围中的COM服务器可以和COM客户一样执行在相同应用程序隔离范围中。这可以通过规则引擎和管理设定加以控制，以便允许这对于在此模式下正确地执行的COM服务器而发生，但是对没有正确地执行的COM服务器却防止这发生。对于COM客户执行在系统范围中的实施例而言，可以把优先权给与系统范围COM服务器，之后是隔离范围中的COM服务器。该COM客户可以指定在创建该COM服务器的实例的调用中要使用的COM服务器。作为选择，配置存储器可以存储标识要被实例化的COM服务器的信息。在一些实施例中，该指定的COM服务器由另一个计算机所寄留，该另一个计算机可以是独立的，物理机或者虚拟机。上面结合步骤1404所描述的映射表可以被使用来查找适用的COM服务器的集合并且(如果必要的话)根据规则来计算优先权。
对于在适用的COM服务器存在于另一个计算机上的实施例而言，能够为要使用的ICLSID查询执行在远程计算机上的服务或者守护进程。如果COM客户挂钩确定需要一个远程COM服务器，那么该COM客户挂钩就首选查询该服务或者守护进程以确定要使用的CLSID/ICLSID。该服务或者守护进程确定对应于在该请求中所给出的CLSID的ICLSID。在一些实施例中，可以根据管理员定义的配置数据，包含在规则引擎中的规则，或者内置的硬编码逻辑来选择或者创建由该服务或者守护进程所返回的ICLSID。在其他实施例中，该请求可以指定要使用的服务器上的隔离范围。在再一些其他的实施例中，该请求的COM服务器可以被与服务器的系统范围相关联，在该情况下，就返回与该COM服务器相关联的CLSID。在再一些其他的实施例中，该请求的COM服务器可以被与该该服务器的隔离范围之一相关联，在此情况下，它返回与该COM服务器和隔离范围的实例相关联的ICLSID。在一些实施例中，上述的服务或者守护进程可以被使用来支持启动局部进程外的COM服务器。
如果所选定的COM服务器实例处于本地计算机上的应用程序隔离环境中，那么就使用结合步骤1404所描述的数据结构来确定它的ICLSID。如果取而代之所选定的COM服务器实例处于在本地计算机上的系统范围中，那么就使用在该请求中的CLSID(步骤1412)。在这些实施例的一些实施例中，就可以动态地创建使用该CLSID的COM服务器的条目。
如果ICLSID被返回，那么就把它传递到原始COM API来代替原始的CLSID。例如，可以把所确定的ICLSID传递到原始的CoCreateInstance()或CoCreate InstanceEx()函数，这样就把该请求传递到CSCM(步骤1414)。对于该COM服务器由另一个计算机所寄留的实施例而言，该CSCM把该ICLSID传递到寄留该COM服务器的计算机，此处该计算机的CSCM处理该COM服务器的启动。
该CSCM以通常的方式通过在该注册表中查找所请求的CLSID或者ICLSID以确定启动参数来查找并且启动该COM服务器可执行体。如果请求了ICLSID，那么就查找在步骤1404中所描述的ICLSID系统范围注册表条目，并且在适当的应用程序隔离范围中启动COM服务器(步骤1416)。
如果所启动的COM服务器实例执行在应用程序隔离范围中(而不管是安装在那个范围中还是安装系统范围中)，那么COM服务器实例的COM API函数CoRegisterClassObject()就被钩住或者拦截。使用在步骤1404中所定义的映射表把每个传递到CoRegisterClassObject()的CLSID都映射到对应的ICLSID。使用该ICLSID来调用原始CoRegisterClassObject()API(步骤1418)。
当该CSCM接收到来自具有期望的ICLSID的CoRegisterClassObject()调用的响应之时，它就把对那个COM服务器实例返回给调用者(步骤1420)。
当COM客户和COM服务器执行在应用程序隔离范围(包括不同的范围)和系统范围的任何组合中之时，这一技术支持COM服务器执行。该ICLSID对(CLSID所标识的)服务器和所希望的适当的隔离范围的组合是专用的。如果该服务器被安装到该系统范围中并且在其中执行，那么该客户仅仅需要确定正确的ICLSID(或者原始CLSID)。
4.6虚拟化的文件类型关联(FTA)文件类型关联是用于调用应用程序的执行的众所周知的图形用户接口技术。向用户展示代表数据文件的图形图标。该用户使用键盘命令或者使用定点设备(诸如鼠标)选择数据文件并且在该图标上点击或者双击以表明该用户想要去打开该文件。作为选择，在一些计算环境中，该用户在命令行提示符(代替命令)处输入到该文件的路径。该文件典型地具有相关联的文件类型指示，该相关联的文件类型指示被使用来确定当打开文件之时要使用的应用程序。这通常是使用一个把该文件类型指示映射到特定的应用程序的表来实现的。在系列微软WINDOWS操作系统中的许多操作系统中，该映射典型地被以元组方式存储注册表数据库中，该元组包括文件类型指示符和标识要执行的应用程序的全路径名，并且只有一个应用程序可以被与任何特定文件类型相关联。
在所描述的隔离环境中，应用程序的多个版本都可以被安装在单个计算机上并且在其上执行。因此，在这些环境中，在文件类型和相关联的应用程序之间的关系就不再是一对一的关系，而相反是一对多的关系。对于MIME附件类型而言，也存在类似的问题。在这些环境中，此问题是通过当选择来一个给定的文件类型之时替换标识要被启动的应用程序的路径名而解决的。该路径名被替换为选择器工具的路径名，该选择器工具向用户给出要启动的应用程序的选项。
现在参考图15，在简单的概况中，请求把文件类型关联数据写入到配置存储器的请求被拦截(步骤1502)。确定该请求是否正在更新息配置存储器中的文件类型关联信(步骤1504)。如果不是，即，如果该条目已经存在，那么就不发生任何的更新(步骤1506)。否则，就使用上面在第4.1.4或者4.2.4节中所描述的虚拟化技术创建新条目，或者更新现有的条目(步骤1508)。该新条目或者被更新的条目(该条目针对适当的隔离范围而被虚拟化了)把该文件类型映射到选择器工具，该选择器工具允许用户去选择当查看或者编辑该文件之时要使用多个应用程序的哪个应用程序。
还参考图15，更详细地，请求把文件类型关联数据写入到配置存储器的请求被拦截(步骤1502)。在一些实施例中，该配置存储器是WINDOWS注册表数据库。请求把数据写入到该配置存储器的请求可以由用户模式挂钩函数，核心模式挂钩函数，文件系统过滤器驱动器，或者微型驱动器而拦截。
确定该请求是否寻求去更新在该配置存储器中的文件类型关联信息(步骤1504)。在一个实施例中，这是通过检测此该拦截的请求是否表明它的目的是去修改该配置存储器来实现的。在另一实施例中，把该请求的目标与包括在该请求中的信息相比较，以确定该请求是否在试图去修改该配置存储器。对于在该配置存储器是注册表数据库的实施例而言，请求修改注册表的请求被拦截，正如在第4.2节所描述的。
如果确定出该请求没有试图去更新该配置存储器，那么就不发生任何的更新(步骤1506)。在一些实施例中，确定出没有做出任何去更新该配置存储器的试图，原因在于该拦截的请求是读请求。在其他实施例中，当在该配置存储器中的目标条目和包括在该拦截的请求中的信息完全相同或者大体上完全相同之时，可以作此确定。
然而，如果在步骤1504中确定出该请求目的是去更新该配置存储器，那么就在该配置存储器中创建新条目，或者更新现有的条目(步骤1508)。在一些实施例中，规则确定在哪个隔离范围中创建或者更新该条目。在一些实施例中，是在系统范围或者应用程序隔离范围中，创建新条目或者更新现有的条目。在许多任何实施例中，是在适当的用户隔离范围中创建新条目或者更新现有的条目。如果创建了新条目，那么它并不标识在该拦截的请求中所标识的应用程序，而是列出一个选择器应用程序作为要在访问特定类型的文件之时要使用的应用程序。在一些实施例中，当安装新版本的应用程序之时，或者当安装了另一个用于处理相同文件类型的应用程序之时，或者当应用程序注册或者取消注册它自己处理那种特定类型的文件之时，就自动地更新该选择器工具。在一些实施例中，该选择器工具能够在它的合适的应用程序的列表中并入任何注册来处理维持在其他范围(诸如系统范围)和应用范围(如果该选择器工具执行在用户范围中)中的配置存储器的部分中的相同文件类型的任何应用程序。如果现有的条目被更新了，并且该现有的条目已经把该选择器应用程序列为当使用那个特定文件类型的文件之时要使用的应用程序，那么就可以更新由该选择器为那种文件类型而呈现的应用程序列表，用以包括该更新的应用程序。如果更新了该现有的条目，但是它却没有列出该选择器应用程序，那么就让该更新的条目去把该选择器应用程序列为当使用那个特定文件类型的文件之时要使用的应用程序。在这些实施例中，可以把与相关联的应用程序相关的信息存储在相关联的配置文件中，或者在一些实施例中，存储为注册表数据库中的条目。
该选择器应用程序可以向用户呈现与选定的文件类型相关联的应用程序的列表。该应用程序还可以允许该用户去挑选用户想要使用来处理该文件的应用程序。该选择器然后在适当的范围系统范围；应用程序隔离范围；或者用户隔离范围中启动该应用程序。在一些实施例中，该选择器工具维持与文件类型相关联的缺省应用程序的身份标识。在这些实施例中，该缺省的应用程序可以由没有访问桌面或者被配置成使用该缺省的处理程序的进程使用，而不向用户展示选项。
4.7进程在隔离环境之间的动态移动本发明的附加方面是用于在不同的虚拟范围之间移动运行着的进程的工具。换言之，在应用程序正在执行的同时，可以把由隔离环境200展示给应用程序实例的本机资源的聚合视图改变成不同的聚合视图。这样就在该进程正在运行的同时允许把已经被在特定隔离范围之内隔离的进程“移动”到另一个隔离范围。这对于系统服务或者进程(每次它们中只有一个实例可以执行)(诸如在窗口操作系统中的MSI服务)特别有用。还可以使用本发明的这一方面来允许用户顺序地工作在若干隔离范围中。
参考图16，在简单的概况中，示出一个用于在一个隔离范围和第二隔离范围之间，或者在系统范围和隔离范围之间移动进程的进程的一个实施例。正如在此说明书中所使用的，术语″目标隔离范围″将被使用来指代正在把进程移动到的那个隔离范围(包括系统范围)，并且术语″源隔离范围″将被使用来指代该进程正在被从其移动开的那个隔离范围(包括系统范围)。如图所示的16，在简单的概况中，一种用于把进程移动到目标隔离范围的方法，包括步骤确保该进程处于安全状态(步骤1602)；在规则引擎中把该进程的关联从它的源隔离范围移动到目标隔离范围(步骤1604)；为任何过滤器驱动器或者挂钩而把该进程的关联从源隔离范围移动到目标隔离范围(步骤1606)；并且允许该进程恢复执行(步骤1608)。
还参考图16，更详细地，当正在把进程移动到不同的隔离范围的同时，该进程应该处于″安全″状态(步骤1602)。在一些实施例中，监视该进程，用以确定它没有在处理请求的时间。在这些实施例中，当没有任何请求被进程处理之时，该进程被视为是处于适合移动的″安全″状态中。在这些实施例的一些实施例中，一旦该进程被视为是处于″安全″状态中，那么就延迟到该进程的新请求，直到该进程被移动为止。在其他实施例中，诸如结合诊断应用程序的实施例中，可以提供用户接口来触发隔离范围的改变。在这些实施例中，该用户接口可以运行把要移动的进程置于″安全″状态中的代码。在再一些其他的实施例中，管理程序可以通过延迟所有进入到该进程的请求并且等待该进程去完成任何活动的请求的执行来迫使该进程进入到″安全″状态中。
把与目标隔离范围相关联的规则加载到该规则引擎中(如果它们尚不存在于规则引擎中的话)(步骤1603)。
在规则引擎中改变该进程与源隔离范围之间的关联(步骤1604)。如上所述，进程能够被与任何隔离范围相关联。该关联被该规则引擎使用在对虚拟本机资源的每一个请求上，用以确定施加到该请求的规则。通过在规则引擎中改变适当的数据结构就能够把应用程序实例与目标隔离范围相关联。在一些实施例中，写入新的数据库条目，它把该进程与新隔离范围相关联。在其他实施例中，重写用于存储与该进程相关联的隔离范围的标识符的树节点，用以标识该新的隔离范围。在再一些其他的实施例中，能够做出操作系统请求，用以为进程分配附加存储器，以存储与目标隔离范围相关联的规则，或者在一些实施例中，存储该规则的标识符。
该关联或者该规则无论被存储在规则引擎之外的何处，诸如过滤器驱动器，核心模式挂钩，或者用户模式挂钩，都改变该进程与源隔离范围的关联(步骤1606)。对于在进程和隔离范围规则之间的关联是根据PID而加以维持的实施例而言，就改变在进程PID和规则集合之间的关联。对于PID没有被使用来维持在进程和适用的隔离规则集合之间的关联的实施例而言，可以改动用户模式挂钩函数，用以访问与目标隔离范围相关联的规则集合。对于与隔离范围的规则集合的进程关联被维持在规则引擎的实施例而言，改变以上在步骤1604中存储在规则引擎中的关联是足够的。
该进程被允许在新隔离范围中恢复执行(步骤1610)。对于新请求被延迟了或者被禁止产生的实施例而言，就把那些请求发给该进程和允许新请求。
在一个特别有用的方面，上述的方法可以被使用来虚拟化MSI，由微软出品并可用于微软WINDOWS的系列操作系统中的一些操作系统的安装打包以及安装技术。通过由这一技术为安装所打包的应用程序称为MSI包。支持这一技术的操作系统具有辅助安装MSI包的WINDOWS服务，称为MSI服务。此服务在系统上有单个实例。希望安装MSI包的进程，在向该MSI服务发出COM调用的会话中运行一个MSI进程。
MSI安装能够被虚拟化，用于把MSI包安装到应用程序隔离环境中。从概念上讲，这能够通过钩住或者拦截在对MSI服务的安装会话中向MSI API所做出的调用来实现。互斥体能够被使用来确保每次只有一个安装发生。当接收或者拦截到对MSI API且请求开始新安装的调用并且调用进程被与特别的应用程序隔离范围相关联之时，在该调用被允许继续进行之前，把该MSI服务置入到该隔离范围的上下文中。随着该MSI服务执行它的通常的安装动作，安装继续，不过由MSI服务所请求的本机资源依照适用的隔离范围被虚拟化。当检测到该安装进程结束之时，就除去在该MSI服务和隔离范围之间的关联。尽管以上相对于MSI做出了描述，但是所描述的该技术也适用的其他安装安装。
等效性本发明可以作为在一个或者多个制造物品中的或者在其中所包括的一个或者多个计算机可读程序。该制造物品可以是软盘，硬盘，CD-ROM，闪存存储器卡，PROM，RAM，ROM，或者磁带。一般而言，该计算机可读取程序可以用任何编程语言来实现，所述编程语言是LISP，PERL，C，C++，PROLOG，或者任何字节码语言(诸如JAVA)。该软件程序可以作为对象代码而存储在一个或者多个制造物品上或者存储在制造物品中。
在已经描述了本发明的某些实施例之后，现在对于本领域技术人员而言变得非常清楚明白的是包括本发明的原理的其他实施例也可以被使用。因此，本发明不应该受限于某些实施例，而更确切地讲应该仅仅受到后附的权利要求的精神和范围的限制。
权利要求
1.一种用于由应用程序访问由操作系统所提供的资源的方法，所述方法包括步骤(a)由执行在应用程序隔离环境之内的进程接收对资源和与该资源相关联的标识符的请求；(b)确定所请求的资源驻留在应用程序隔离环境之外的位置；(c)把对该资源和与该资源相关联的标识符的请求重定向到所确定的位置；并且(d)使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
2.如权利要求1所述的方法，其中步骤(b)还包括由执行在应用程序隔离环境之外的进程确定所请求的资源驻留在应用程序隔离环境之外。
3.如权利要求1所述的方法，其中步骤(b)还包括由执行在应用程序隔离环境之内的进程确定所请求的资源驻留在应用程序隔离环境之外。
4.如权利要求1所述的方法，其中步骤(c)还包括由执行在应用程序隔离环境之外的进程把对该资源和与该资源相关联的标识符的请求重定向到所确定的位置。
5.如权利要求1所述的方法，其中步骤(c)还包括由执行在应用程序隔离环境之内的进程把对该资源和与该资源相关联的标识符的请求重定向到所确定的位置。
6.如权利要求1所述的方法，其中步骤(d)还包括由执行在应用程序隔离环境之外的进程使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
7.如权利要求1所述的方法，其中步骤(d)还包括由执行在应用程序隔离环境之内的进程使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
8.如权利要求1所述的方法，其中步骤(a)包括由执行在应用程序隔离环境之内的进程产生对资源的请求，该请求包括与资源相关联的标识符。
9.如权利要求1所述的方法，其中步骤(a)还包括接收对该资源和与该资源相关联的标识符的请求，该标识符包括标识至少一个COM服务器的类标识符。
10.如权利要求1所述的方法，其中步骤(d)还包括在由进程提供的接口上与资源通信。
11.一种用于由应用程序访问由操作系统所提供的资源的方法，所述方法包括步骤(a)接收对资源和与该资源相关联的标识符的请求；(b)由执行在应用程序隔离环境的之内进程确定所请求的资源驻留在应用程序隔离环境之外的位置；(c)把对该资源和与该资源相关联的标识符的请求重定向所到确定的位置；并且(d)使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
12.如权利要求11所述的方法，其中步骤(c)还包括由执行在应用程序隔离环境之外的进程把对该资源和与该资源相关联的标识符的请求重定向到所确定的位置。
13.如权利要求11所述的方法，其中步骤(c)还包括由执行在应用程序隔离环境之内的进程把对该资源和与该资源相关联的标识符的请求重定向到所确定的位置。
14.如权利要求11所述的方法，其中步骤(d)还包括由执行在应用程序隔离环境之外的进程使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
15.如权利要求11所述的方法，其中步骤(d)还包括由执行在应用程序隔离环境之内的进程使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
16.如权利要求11所述的方法，其中步骤(a)包括产生对资源的请求，该请求包括与该资源相关联的标识符。
17.如权利要求11所述的方法，其中步骤(a)还包括接收对资源和与该资源相关联的标识符的请求，该标识符包括标识至少一个COM服务器的类标识符。
18.如权利要求11所述的方法，其中步骤(d)还包括在由进程提供的接口上与资源通信。
19.一种用于由应用程序访问由操作系统所提供的资源的方法，所述方法包括步骤(a)接收对资源和与该资源相关联的标识符的请求；(b)确定所请求的资源驻留在应用程序隔离环境之外的位置；(c)由执行在应用程序隔离环境之内的进程把对该资源和与该资源相关联的标识符的请求重定向到所确定的位置；并且(d)使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
20.如权利要求19所述的方法，其中步骤(d)还包括由执行在应用程序隔离环境之外的进程使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
21.如权利要求19所述的方法，其中步骤(d)还包括由执行在应用程序隔离环境之内的进程使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
22.如权利要求19所述的方法，其中步骤(a)包括产生对资源的请求，该请求与该资源相关联的标识符。
23.如权利要求19所述的方法，其中步骤(a)还包括接收对资源和与该资源相关联的标识符的请求，该标识符包括标识至少一个COM服务器的类标识符。
24.如权利要求19所述的方法，其中步骤(d)还包括在接口上与资源通信。
25.一种用于由应用程序访问由操作系统所提供的资源的方法，所述方法包括步骤(a)接收对资源和与该资源相关联的标识符的请求；(b)确定所请求的资源驻留在应用程序隔离环境之外的位置；(c)把对该资源和与该资源相关联的标识符的请求重定向到所确定的位置；并且和(d)由执行在应用程序隔离环境之内的进程使用驻留在所确定的位置中的资源的实例，来应答对该资源的请求。
26.如权利要求25所述的方法，其中步骤(a)包括产生对资源的请求，该请求包括与资源相关联的标识符。
27.如权利要求25所述的方法，其中步骤(a)还包括接收对资源和与该资源相关联的标识符的请求，所述标识符包括类标识符，标识符标识至少一个COM服务器。该
28.如权利要求25所述的方法，其中步骤(d)还包括执行在应用程序隔离环境之内的进程通过接口与资源通信。
29.一种用于由应用程序访问由操作系统所提供的资源的系统，所述系统包括资源；第一进程，执行在应用程序隔离环境之内，接收对资源和与该资源相关联的标识符的请求；第二进程，确定资源驻留在应用程序隔离环境之外的位置；第三进程，把对该资源和与该资源相关联的标识符的请求重定向到所确定的位置；并且第四进程，使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
30.如权利要求29所述的系统，其中第二进程执行在应用程序隔离环境之内。
31.如权利要求29所述的系统，其中第二进程执行在应用程序隔离环境之外。
32.如权利要求29所述的系统，其中第三进程执行在应用程序隔离环境之内。
33.如权利要求29所述的系统，其中第三进程执行在应用程序隔离环境之外。
34.如权利要求29所述的系统，其中第四进程执行在应用程序隔离环境之内。
35.如权利要求29所述的系统，其中第四进程执行在应用程序隔离环境之外。
36.如权利要求29所述的系统，其中第一进程和第二进程包括相同的进程。
37.如权利要求29所述的系统，其中第一进程和第三进程包括相同的进程。
38.如权利要求29所述的系统，其中第一进程和第四进程包括相同的进程。
39.如权利要求29所述的系统，其中第一进程、第二进程和第三进程包括相同的进程。
40.如权利要求29所述的系统，其中第一进程、第二进程和第四进程包括相同的进程。
41.如权利要求29所述的系统，其中第一进程、第三进程和第四进程包括相同的进程。
42.如权利要求29所述的系统，其中第一进程、第二进程、第三进程和第四进程包括相同的进程。
43.如权利要求29所述的系统，其中所述资源还包括COM服务器。
44.如权利要求29所述的系统，其中所述资源还包括与驻留在应用程序隔离环境之内的第二资源具有不同版本的COM服务器。
45.如权利要求29所述的系统，其中所述标识符与第一资源和第二资源相关联。
46.如权利要求29所述的系统，其中所述资源在所述资源所驻留在的环境上还包括至少一个注册表条目。
47.如权利要求29所述的系统，其中所述资源驻留在第二应用程序隔离环境之内。
48.如权利要求29所述的系统，其中第一进程还包括产生对资源的请求，所述请求包括与所述资源相关联的标识符。
49.如权利要求29所述的系统，其中第一进程还包括与驻留在所确定的位置中的资源的实例相通信。
50.如权利要求29所述的系统，其中第一进程或者第二进程或者第三进程或者第四进程还包括COM服务控制管理器。
51.一种用于由应用程序访问由操作系统所提供的资源的系统，所述系统包括资源；第一进程，接收对资源和与该资源相关联的标识符的请求；第二进程，执行在应用程序隔离环境之内并且确定所述资源驻留在应用程序隔离环境之外的位置；第三进程，把对该资源和与该资源相关联的标识符的请求重定向到所确定的位置；并且和第四进程，使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
52.如权利要求51所述的系统，其中第一进程执行在应用程序隔离环境之内。
53.如权利要求51所述的系统，其中第一进程执行在应用程序隔离环境之外。
54.如权利要求51所述的系统，其中第三进程执行在应用程序隔离环境之内。
55.如权利要求51所述的系统，其中第三进程执行在应用程序隔离环境之外。
56.如权利要求51所述的系统，其中第四进程执行在应用程序隔离环境之内。
57.如权利要求51所述的系统，其中第四进程执行在应用程序隔离环境之外。
58.如权利要求51所述的系统，其中第二进程和第三进程包括相同的进程。
59.如权利要求51所述的系统，其中第二进程和第四进程包括相同的进程。
60.如权利要求51所述的系统，其中第一进程、第二进程和、第三进程和第四进程包括相同的进程。
61.如权利要求51所述的系统，其中所述资源还包括COM服务器。
62.如权利要求51所述的系统，其中所述资源还包括与驻留在应用程序隔离环境上的第二资源具有不同版本的COM服务器。
63.如权利要求51所述的系统，其中所述标识符与第一资源和第二资源相关联。
64.如权利要求51所述的系统，其中所述资源驻留在第二应用程序隔离环境之内。
65.如权利要求51所述的系统，其中所述资源在所述资源所驻留在的环境上还包括至少一个注册表条目。
66.如权利要求51所述的系统，其中第一进程还包括产生对所述资源的请求，所述请求包括与所述资源相关联的标识符。
67.如权利要求51所述的系统，其中第一进程还包括与驻留在所确定的位置中的资源实例相通信。
68.如权利要求51所述的系统，其中第一进程或者第二进程或者第三进程或者第四进程还包括COM服务控制管理器。
69.一种用于由应用程序访问由操作系统所提供的资源的系统，所述系统包括资源；第一进程，接收对资源和与该资源相关联的标识符的请求；第二进程，确定所述资源驻留在应用程序隔离环境之外的位置；第三进程，执行在应用程序隔离环境之内并且把对该资源和与该资源相关联的标识符的请求重定向把到所确定的位置；并且第四进程，使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
70.如权利要求69所述的系统，其中第一进程执行在应用程序隔离环境之内。
71.如权利要求69所述的系统，其中第一进程执行在应用程序隔离环境之外。
72.如权利要求69所述的系统，其中第二进程执行在应用程序隔离环境之内。
73.如权利要求69所述的系统，其中第二进程执行在应用程序隔离环境之外。
74.如权利要求69所述的系统，其中第四进程执行在应用程序隔离环境之内。
75.如权利要求69所述的系统，其中第四进程执行在应用程序隔离环境之外。
76.如权利要求69所述的系统，其中第一进程和第二进程以及第三进程和第四进程包括相同的进程。
77.如权利要求69所述的系统，其中所述资源还包括COM服务器。
78.如权利要求69所述的系统，其中所述资源还包括与驻留在应用程序隔离环境之内的第二资源具有不同版本的COM服务器。
79.如权利要求69所述的系统，其中所述标识符与第一资源和第二资源相关联。
80.如权利要求69所述的系统，其中所述资源驻留在第二应用程序隔离环境之内。
81.如权利要求69所述的系统，其中所述资源在所述资源所驻留在其内的应用程序隔离环境中还包括至少一个注册表条目。
82.如权利要求69所述的系统，其中第一进程还包括产生对资源的请求，所述请求包括与所述资源相关联的标识符。
83.如权利要求69所述的系统，其中第一进程还包括与驻留在所确定的位置中的资源的实例相通信。
84.如权利要求69所述的系统，其中第一进程或者第二进程或者第三进程或者第四进程还包括COM服务控制管理器。
85.一种用于由应用程序访问由操作系统所提供的资源的系统，所述系统包括资源；第一进程，接收对资源和与该资源相关联的标识符的请求；第二进程，确定所述资源驻留在应用程序隔离环境之外的位置；第三进程，把对该资源和与该资源相关联的标识符的请求重定向到所确定的位置；和第四进程，执行在应用程序隔离环境之内并且使用驻留在所确定的位置中的资源的实例来应答对该资源的请求。
86.如权利要求85所述的系统，其中第一进程执行在应用程序隔离环境之内。
87.如权利要求85所述的系统，其中第一进程执行在应用程序隔离环境之外。
88.如权利要求85所述的系统，其中第二进程执行在应用程序隔离环境之内。
89.如权利要求85所述的系统，其中第二进程执行在应用程序隔离环境之外。
90.如权利要求85所述的系统，其中第三进程执行在应用程序隔离环境之内。
91.如权利要求85所述的系统，其中第三进程执行在应用程序隔离环境之外。
92.如权利要求85所述的系统，其中所述资源还包括COM服务器。
93.如权利要求85所述的系统，其中所述资源还包括与驻留在应用程序隔离环境之内的第二资源具有不同版本的COM服务器。
94.如权利要求85所述的系统，其中所述标识符与第一资源和第二资源相关联。
95.如权利要求85所述的系统，其中所述资源驻留在第二应用程序隔离环境之内。
96.如权利要求85所述的系统，其中所述资源在所述资源驻留在其上的环境中还包括至少一个注册表条目。
97.如权利要求85所述的系统，其中第一进程还包括产生对资源的请求，所述请求包括与所述资源相关联的标识符。
98.如权利要求85所述的系统，其中第一进程还包括与驻留在所确定的位置中的资源的实例相通信。
99.如权利要求85所述的系统，其中第一进程或者第二进程或者第三进程或者第四进程还包括COM服务控制管理器。
100.一种用于由应用程序访问由操作系统所提供的资源的方法，所述方法包括步骤(a)由执行在应用程序隔离环境之外的进程接收对资源和与该资源相关联的标识符的请求；(b)确定所请求的资源驻留在应用程序隔离环境之内；(c)把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境；并且(d)使用驻留在应用程序隔离环境之内的资源的实例来应答对该资源的请求。
101.如权利要求100所述的方法，其中步骤(b)还包括由执行在应用程序隔离环境之外的进程确定所请求的资源驻留在应用程序隔离环境中。
102.如权利要求100所述的方法，其中步骤(c)还包括由执行在应用程序隔离环境之外的进程把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境。
103.如权利要求100所述的方法，其中步骤(d)还包括由执行在应用程序隔离环境之外的进程使用定位在应用程序隔离环境之内的资源的实例来应答对该资源的请求。
104.如权利要求100所述的方法，其中步骤(a)包括由执行在应用程序隔离环境之外的进程产生对资源的请求，所述请求包括与该资源相关联的标识符。
105.如权利要求100所述的方法，其中步骤(a)还包括接收对资源和与该资源相关联的标识符的请求，所述标识符包括标识至少一个进程外COM服务器的类标识符。
106.如权利要求100所述的方法，其中步骤(d)还包括在由进程所提供的接口上与资源相通信。
107.如权利要求100所述的方法，其中步骤(d)还包括由所请求的资源修改与执行在应用程序隔离环境之外的进程相关联的窗口。
108.一种用于由应用程序访问由操作系统所提供的资源的方法，所述方法包括步骤(a)接收对资源和与该资源相关联的标识符的请求；(b)由执行在应用程序隔离环境之外的进程确定所请求的资源驻留在应用程序隔离环境之内；(c)把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境；并且(d)使用驻留在应用程序隔离环境之内的资源的实例来应答对该资源的请求。
109.如权利要求108所述的方法，其中步骤(a)还包括由执行在应用程序隔离环境之外的进程接收对资源和与该资源相关联的标识符的请求。
110.如权利要求108所述的方法，其中步骤(c)还包括由执行在应用程序隔离环境之外的进程把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境。
111.如权利要求108所述的方法，其中步骤(d)还包括由执行在应用程序隔离环境之外的进程使用在应用程序隔离环境之内的资源的实例来应答对该资源的请求。
112.如权利要求108所述的方法，其中步骤(a)包括产生对资源的请求，所述请求包括与资源相关联的标识符。
113.如权利要求108所述的方法，其中步骤(a)还包括接收对资源和与该资源相关联的标识符的请求，所述标识符包括标识至少一个COM服务器的类标识符。
114.如权利要求108所述的方法，其中步骤(d)还包括在由进程提供的接口上与资源相通信。
115.一种用于由应用程序访问由操作系统所提供的资源的方法，所述方法包括步骤(a)接收对资源和与该资源相关联的标识符的请求；(b)确定所请求的资源驻留在应用程序隔离环境之内；(c)由执行在应用程序隔离环境之外的进程，把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境；和(d)使用驻留在应用程序隔离环境之内的资源的实例来应答对该资源的请求。
116.如权利要求115所述的方法，其中步骤(d)还包括由执行在应用程序隔离环境之外的进程，使用驻留在应用程序隔离环境之内的资源的实例来应答对资源的请求。
117.如权利要求115所述的方法，其中步骤(a)包括产生对资源的请求，所述请求包括与资源相关联的标识符。
118.如权利要求115所述的方法，其中步骤(a)还包括接收对资源和与该资源相关联的标识符的请求，所述标识符包括标识至少一个COM服务器的类标识符。
119.如权利要求115所述的方法，其中步骤(d)还包括在由进程所提供的接口上与所述资源相通信。
120.一种用于由应用程序访问由操作系统所提供的资源的方法，所述方法包括步骤(a)接收对资源和与该资源相关联的标识符的请求；(b)确定所请求的资源驻留在应用程序隔离环境之内；(c)把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境；并且和(d)由执行在应用程序隔离环境之外的进程使用驻留在应用程序隔离环境之内的资源的实例来应答对该资源的请求。
121.如权利要求120所述的方法，其中步骤(a)包括产生对资源的请求，所述请求包括与所述资源相关联的标识符。
122.如权利要求120所述的方法，其中步骤(a)还包括接收对资源和与该资源相关联的标识符的请求，所述标识符包括类标识符，所述标识符标识至少一个COM服务器。
123.如权利要求120所述的方法，其中步骤(d)还包括由执行在应用程序隔离环境之外的进程在接口上与资源相通信。
124.一种用于由应用程序访问由操作系统所提供的资源的系统，所述系统包括资源；第一进程，执行在应用程序隔离环境之外，接收对资源和与该资源相关联的标识符的请求；第二进程，确定资源驻留在应用程序隔离环境之内；第三进程，把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境；和第四进程，使用驻留在应用程序隔离环境中的资源的实例来应答对该资源的请求。
125.如权利要求124所述的系统，其中第二进程执行在应用程序隔离环境之内。
126.如权利要求124所述的系统，其中第二进程执行在应用程序隔离环境之外。
127.如权利要求124所述的系统，其中第三进程执行在应用程序隔离环境之内。
128.如权利要求124所述的系统，其中第三进程执行在应用程序隔离环境之外。
129.如权利要求124所述的系统，其中第四进程执行在应用程序隔离环境之内。
130.如权利要求124所述的系统，其中第四进程执行在应用程序隔离环境之外。
131.如权利要求124所述的系统，其中第一进程和第二进程包括相同的进程。
132.如权利要求124所述的系统，其中第一进程和第三进程包括相同的进程。
133.如权利要求124所述的系统，其中第一进程和第四进程包括相同的进程。
134.如权利要求124所述的系统，其中第一进程、第二进程以及第三进程包括相同的进程。
135.如权利要求124所述的系统，其中第一进程、第二进程以及第四进程包括相同的进程。
136.如权利要求124所述的系统，其中第一进程、第三进程以及第四进程包括相同的进程。
137.如权利要求124所述的系统，其中第一进程、第二进程、第三进程和第四进程包括相同的进程。
138.如权利要求124所述的系统，其中所述资源还包括COM服务器。
139.如权利要求124所述的系统，其中所述资源还包括与驻留在应用程序隔离环境之内的第二资源具有不同版本的COM服务器。
140.如权利要求124所述的系统，其中所述标识符与第一资源和第二资源相关联。
141.如权利要求124所述的系统，其中所述资源在所述资源所驻留在其上的应用程序隔离环境中还包括至少一个注册表条目。
142.如权利要求124所述的系统，其中第一进程还包括产生对资源的请求，所述请求包括与所述资源相关联的标识符。
143.如权利要求124所述的系统，其中第一进程还包括与驻留在应用程序隔离环境之内的资源的实例相通信。
144.如权利要求124所述的系统，其中第一进程或者第二进程或者第三进程或者第四进程还包括COM服务控制管理器。
145.一种用于由应用程序访问由操作系统所提供的资源的系统，所述系统包括资源；第一进程，接收对资源和与该资源相关联的标识符的请求；第二进程，执行在应用程序隔离环境之外，确定所述资源驻留在应用程序隔离环境之内；第三进程，把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境；并且第四进程，使用驻留在应用程序隔离环境中的资源的实例来应答对该资源的请求。
146.如权利要求145所述的系统，其中第一进程执行在应用程序隔离环境之内。
147.如权利要求145所述的系统，其中第一进程执行在应用程序隔离环境之外。
148.如权利要求145所述的系统，其中第三进程执行在应用程序隔离环境之内。
149.如权利要求145所述的系统，其中第三进程执行在应用程序隔离环境之外。
150.如权利要求145所述的系统，其中第四进程执行在应用程序隔离环境之内。
151.如权利要求145所述的系统，其中第四进程执行在应用程序隔离环境之外。
152.如权利要求145所述的系统，其中第一进程和第二进程包括相同的进程。
153.如权利要求145所述的系统，其中第一进程、第二进程和第三进程包括相同的进程。
154.如权利要求145所述的系统，其中第一进程、第二进程和第四进程包括相同的进程。
155.如权利要求145所述的系统，其中第一进程、第二进程、第三进程和第四进程包括相同的进程。
156.如权利要求145所述的系统，其中第二进程和第三进程包括相同的进程。
157.如权利要求145所述的系统，其中第二进程和第四进程包括相同的进程。
158.如权利要求145所述的系统，其中第二进程、第三进程和第四进程包括相同的进程。
159.如权利要求145所述的系统，其中所述资源还包括COM服务器。
160.如权利要求145所述的系统，其中所述资源还包括与驻留在应用程序隔离环境中的第二资源具有不同版本的COM服务器。
161.如权利要求145所述的系统，其中所述标识符与第一资源和第二资源相关联。
162.如权利要求145所述的系统，其中所述资源在所述资源所驻留在其上的应用程序隔离环境中还包括至少一个注册表条目。
163.如权利要求145所述的系统，其中第一进程还包括产生对资源的请求，所述请求包括与所述资源相关联的标识符。
164.如权利要求145所述的系统，其中第一进程还包括与定位在应用程序隔离环境之内的资源的实例相通信。
165.如权利要求145所述的系统，其中第一进程或者第二进程或者第三进程或者第四进程还包括COM服务控制管理器。
166.一种用于由应用程序访问由操作系统所提供的资源的系统，所述系统包括资源；第一进程，接收对资源和与该资源相关联的标识符的请求；第二进程，确定所述资源驻留在应用程序隔离环境之内；第三进程，执行在应用程序隔离环境之外，把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境；并且和第四进程，使用驻留在应用程序隔离环境中的资源的实例来应答对该资源的请求。
167.如权利要求166所述的系统，其中第一进程执行在应用程序隔离环境之内。
168.如权利要求166所述的系统，其中第一进程执行在应用程序隔离环境之外。
169.如权利要求166所述的系统，其中第二进程执行在应用程序隔离环境之内。
170.如权利要求166所述的系统，其中第二进程执行在该环境之外。
171.如权利要求166所述的系统，其中第四进程执行在应用程序隔离环境之内。
172.如权利要求166所述的系统，其中第四进程执行在该环境之外。
173.如权利要求166所述的系统，其中第一进程和第三进程包括相同的进程。
174.如权利要求166所述的系统，其中第一进程、第二进程以及第三进程包括相同的进程。
175.如权利要求166所述的系统，其中第一进程、第三进程以及第四进程包括相同的进程。
176.如权利要求166所述的系统，其中第一进程、第二进程、第三进程和第四进程包括相同的进程。
177.如权利要求166所述的系统，其中第二进程和第三进程包括相同的进程。
178.如权利要求166所述的系统，其中第二进程、第三进程以及第四进程包括相同的进程。
179.如权利要求166所述的系统，其中第三进程和第四进程包括相同的进程。
180.如权利要求166所述的系统，其中所述资源还包括COM服务器。
181.如权利要求166所述的系统，其中所述资源还包括与驻留在该环境上的第二资源具有不同版本的COM服务器。
182.如权利要求166所述的系统，其中所述标识符与第一资源和第二资源相关联。
183.如权利要求166所述的系统，其中所述资源在所述资源驻留在其上的应用程序隔离环境中还包括至少一个注册表条目。
184.如权利要求166所述的系统，其中第一进程还包括产生对资源的请求，所述请求包括与所述资源相关联的标识符。
185.如权利要求166所述的系统，其中第一进程还包括与驻留在应用程序隔离环境之内的资源的实例相通信。
186.如权利要求166所述的系统，其中第一进程或者第二进程或者第三进程或者第四进程还包括COM服务控制管理器。
187.一种用于由应用程序访问由操作系统所提供的资源的系统，所述系统包括资源；第一进程，接收对资源和与该资源相关联的标识符的请求；第二进程，确定所述资源驻留在应用程序隔离环境之内；第三进程，把对该资源和与该资源相关联的标识符的请求重定向到应用程序隔离环境；并且和第四进程，执行在应用程序隔离环境之外，使用驻留在应用程序隔离环境中的资源的实例来应答对该资源的请求。
188.如权利要求187所述的系统，其中第一进程执行在该环境之内。
189.如权利要求187所述的系统，其中第一进程执行在应用程序隔离环境之外。
190.如权利要求187所述的系统，其中第二进程执行在该环境之内。
191.如权利要求187所述的系统，其中第二进程执行在应用程序隔离环境之外。
192.如权利要求187所述的系统，其中第三进程执行在该环境之内。
193.如权利要求187所述的系统，其中第三进程执行在应用程序隔离环境之外。
194.如权利要求187所述的系统，其中第一进程和第四进程包括相同的进程。
195.如权利要求187所述的系统，其中第一进程、第二进程以及第四进程包括相同的进程。
196.如权利要求187所述的系统，其中第一进程、第三进程以及第四进程包括相同的进程。
197.如权利要求187所述的系统，其中第一进程、第二进程、第三进程和第四进程包括相同的进程。
198.如权利要求187所述的系统，其中第二进程和第四进程包括相同的进程。
199.如权利要求187所述的系统，其中第二进程、第三进程以及第四进程包括相同的进程。
200.如权利要求187所述的系统，其中第三进程和第四进程包括相同的进程。
201.如权利要求187所述的系统，其中所述资源还包括COM服务器。
202.如权利要求187所述的系统，其中所述资源还包括与驻留在该环境之内的第二资源具有不同版本的COM服务器。
203.如权利要求187所述的系统，其中所述标识符与第一资源和第二资源相关联。
204.如权利要求187所述的系统，其中所述资源在所述资源驻留在其上的应用程序隔离环境之内还包括至少一个注册表条目。
205.如权利要求187所述的系统，其中第一进程还包括产生对资源的请求，所述请求包括与所述资源相关联的标识符。
206.如权利要求187所述的系统，其中第一进程还包括与定位在该环境之内的资源的实例相通信。
207.如权利要求187所述的系统，其中第一进程或者第二进程或者第三进程或者第四进程还包括COM服务控制管理器。
208.一种用于把应用程序与隔离环境相关联的方法，所述方法包括步骤(a)获得所请求的应用程序的位置；(b)在所请求的应用程序和应用程序隔离环境之间创建关联；(c)存储关联；和(d)把所请求的应用程序启动到应用程序隔离环境中。
209.如权利要求208所述的方法，其中步骤(a)包括定位所请求的应用程序。
210.如权利要求208所述的方法，其中步骤(a)还包括定位驻留在操作系统的本机层中的请求的应用程序。
211.如权利要求208所述的方法，其中步骤(a)还包括定位驻留在第二应用程序隔离环境上的应用程序隔离范围中的请求的应用程序。
212.如权利要求208所述的方法，其中步骤(a)包括定位在第二应用程序隔离环境上的请求的应用程序。
213.如权利要求208所述的方法，其中步骤(b)包括把第二应用程序与应用程序隔离环境相关联。
214.如权利要求208所述的方法，其中步骤(b)包括把该应用程序与第二应用程序隔离环境相关联。
215.如权利要求208所述的方法，其中步骤(c)还包括把关联存储到应用程序隔离环境上。
216.如权利要求208所述的方法，其中步骤(c)包括把关联存储在文件中。
217.如权利要求208所述的方法，其中步骤(c)包括把关联存储在知识库中的配置条目中。
218.如权利要求208所述的方法，其中步骤(c)包括把关联存储在上下文菜单中。
219.一种用于把应用程序与隔离环境相关联的环境，所述环境包括应用程序隔离环境，包括应用程序隔离范围和用户隔离范围；重定向器，获得由代表用户执行的进程所产生的对应用程序的请求，获得所请求的应用程序所驻留在的位置，并且把来自于所确定的位置的所请求的应用程序启动到应用程序隔离环境中；并且在所请求的应用程序和应用程序隔离环境之间的关联，由重定向器维持。
220.如权利要求219所述的环境，其中所述重定向器驻留在应用程序隔离环境上。
221.如权利要求219所述的环境，其中所述重定向器定位在第二应用程序隔离环境上的所请求的应用程序。
222.如权利要求219所述的环境，其中所述重定向器定位在操作系统的本机层上的所请求的应用程序。
223.如权利要求219所述的环境，其中所述重定向器拦截对应用程序的请求。
224.如权利要求219所述的环境，其中所述重定向器查阅在所请求的应用程序和所请求的应用程序驻留在的位置之间的存储的关联，用以确定所请求的应用程序所驻留在的位置。
225.如权利要求219所述的环境，还包括规则引擎，用于规定重定向器的行为。
226.如权利要求225所述的环境，其中所述重定向器还包括响应于配置机制来配置规则引擎。
227.如权利要求219所述的环境，其中所述重定向器包括文件系统过滤器驱动器。
228.如权利要求219所述的环境，其中所述重定向器包括函数挂钩机制。
229.如权利要求228所述的环境，其中所述函数挂钩设备拦截选自多个进程创建操作、COM服务器操作以及窗口服务操作中的操作。
230.如权利要求219所述的环境，其中所述关联包括知识库中的配置条目。
231.如权利要求219所述的环境，其中所述关联包括由重定向器所存储的文件。
232.如权利要求219所述的环境，其中所述关联包括上下文菜单条目。
全文摘要
一种用于把执行着的进程从源隔离范围移动到目标隔离范围的方法，包括确定该进程处于适合于移动的状态中的步骤。该进程的关联从源隔离范围变化到目标隔离范围。一条规则与目标隔离范围相关联地加载。
文档编号G06F9/46GK101073059SQ200580041045
公开日2007年11月14日 申请日期2005年9月23日 优先权日2004年9月30日
发明者N·A·比塞特, A·罗伊乔德里, R·J·马扎费里 申请人:茨特里克斯系统公司