虚拟化窗口信息的方法和设备

admin管理员组

文章数量:1531695

2024年6月10日发(作者：)

如果与系统范围候选文件关联的许可数据指明文件不可修改，将错误条件返回给请

求者(步骤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”目录的请求可导致枚举名为

“Different_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_file_1”的真实文件。在一个实施例中，这是

通过调用挂钩函数的原始版本且将形成的真实文件名作为参数传递给该函数来完成

的(步骤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)。在一些实施例

中，合法的短文件名包含在文件名中的八个字符以及在可选扩展名中的三个字符。

在一些实施例中，合法的短文件名只包含合法字符，比如A-Z、a-z、0-9、｀、

~、！、@、#、$、％、^、&、*、(、)、-、_、’、{、和}。在一些实施例中，

前导空格或“.”或一个以上的“.”是非法的。如果所提供的文件名已经是合法的短文

件名，则返回将不生成短文件名的状态(步骤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”的真实注册表键。在一个实施例中，这

是通过调用挂钩函数的原始版本且将形成的真实名作为参数传递给该函数来完成的。

在其它实施例中，打开真实注册表键可通过应答打开虚拟键的原始请求来实现，所

述应答是通过向注册表过滤器管理器发信号以利用所确定的真实键名重新解析该请

求来进行的。

在一些实施例中，为了隔离所请求的虚拟注册表键所形成的真实名称可基于所接收

的虚拟注册表键名和范围特定标识符。范围特定标识符可以是与应用隔离范围、用

户隔离范围、会话隔离范围、应用隔离子范围、用户隔离子范围或上面范围的某些

组合关联的标识符。范围特定标识符用于“重整”在请求中接收的虚拟名称。

在其它实施例中，用户隔离范围或子范围可以是注册表键，在该注册表键之下存储

了用户隔离范围中存在的所有键。在这些实施例的一些中，在用户隔离键下的键层

次反应了所请求资源的路径。换句话说，通过将虚拟键路径映射到用户隔离范围来

形成真实键路径。例如，如果所请求的键是HKLMSoftwareCitrixMykey且用户

隔离范围键是HKCUSoftwareUserScope，则到用户范围真实键的路径可以是

HKCUSoftwareUserScopeHKLMSoftwareCitrixMykey。在其它实施例中，到用

户范围真实的路径可用本地命名约定来定义。例如，到用户真实键的路径可以是

HKCUSoftwareUserScopeRegistryMachineSoftwareCitrixMykey。在另外其它实

施例中，用户范围键可以都存储在单个键下，该单个键的名称被选择为是唯一的，

且数据库可用于存储所请求的键名与在用户隔离键中存储的对应实际键的名称之间

的映射。在另外其它的实施例中，真实键的内容可以存储在数据库或文件存储器中。

候选键存在的类别是通过检查用户隔离范围和任何与候选键关联的元数据来确定的

(步骤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”的键可具有可应用于“key1subkey_1”和“key1subkey_2”的孩子规则。在该

步骤中，试图虚拟化打开“key1subkey_1”和“key1subkey_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.2.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命名对象虚拟化

利用上述技术可虚拟化的系统范围资源的另一类是命名对象，其包括信号灯、互斥

体、变异体、可等待定时器、事件、作业对象、段、命名管道和mailslot。这些对

象的特征在于，它们通常只存在于创建它们的进程的持续期间。这些对象的命名空

间可在整个计算机上是有效的(全局范围)或者只在单个用户会话中有效(会话范围)。

现在参考图12，且在概观上，接收或截取创建或打开命名对象的请求(步骤1202)。

请求包含对象名，隔离环境将该对象名称当作虚拟名称。确定确定如何对待请求的

规则(步骤1204)。如果规则指明请求应当被忽略(步骤1206)，则真实对象名被确定

为虚拟名称(1207)，并且将创建或打开真实对象的请求发给操作系统(1214)。如果

所确定的规则不是忽略请求，而是指明请求应当被重定向(步骤1208)，则根据如重

定向规则规定的虚拟名称来确定真实对象名(步骤1210)，并且真实对象的创建或打

开请求被发给操作系统(步骤1214)。如果规则不指明请求应当被重定向(步骤1208)，

而是指明请求应当被隔离，则根据如隔离规则规定的虚拟名称来确定真实对象名

(步骤1212)，并且真实对象的创建或打开命令被发给操作系统(步骤1214)。响应于

所发出的创建或打开命令而由操作系统返回的真实对象的句柄被返回给请求创建或

打开虚拟对象的程序(步骤1216)。

仍然参考图12且更详细地，截取创建或打开命名对象的进程的请求(步骤1202)。

命名对象可属于会话范围或其可属于全局范围。在一些实施例中，通过替换操作系

统函数或用于创建或打开命名对象的函数的函数来钩住请求。在另一个实施例中，

挂钩动态链接库被用来截取请求。挂钩函数可在用户模式或内核模式中执行。对于

挂钩函数以用户模式执行的实施例，当创建进程时，挂钩函数可被加载到该进程的

地址空间。对于挂钩函数以内核模式执行的实施例，挂钩函数可与操作系统资源相

关联，该资源用于为系统对象分派请求。创建或打开命名对象的请求可指各种各样

系统范围资源中的任意一个，系统范围资源用于进程间通信和同步并且由唯一的标

识符来识别，包括信号灯、互斥体、变异体、可等待定时器、文件映射对象、事件、

作业对象、段、命名管道和mailslot。对于为每种类型的对象提供单独的操作系统

函数的实施例，每个函数可被分别钩住。可替换地，可提供为若干类型的对象截取

创建或打开调用的单个挂钩函数。

截取的请求包含对象名，隔离环境将该对象名当作虚拟名称。通过咨询规则引擎来

确定如何对待用于对象的请求的规则(步骤1204)。在一些实施例中，规则引擎可作

为关系数据库提供。在其它实施例中，规则引擎可以是树结构数据库、散列表或平

面文件数据库。在一些实施例中，为所请求对象提供的虚拟名称被用作在规则引擎

中定位应用于请求的规则。在这些实施例的特殊的一些中，多个规则可存在于用于

特殊对象的规则引擎中，并且在这些实施例中，具有与虚拟名称匹配的最长前缀的

规则是应用于请求的规则。在一些实施例中，进程标识符用于在规则引擎中定位应

用于请求的规则，如果其存在的话。与请求关联的规则可以是忽略请求、重定向请

求、或隔离请求。尽管在图12中作为一系列判定示出，但是规则查找可作为单个

数据库事务出现。

如果规则指明请求应当被忽略(步骤1206)，则真实对象名被确定为虚拟名称，并且

将创建或打开真实对象的请求发给操作系统(1214)。例如，创建或打开名为

“Object_1”命名对象的请求可导致创建名为“Object_1”的实际对象。在一个实施例

中，这是通过调用挂钩函数的原始版本且将形成的真实名称作为参数传递给该函数

来完成的。

如果通过访问规则引擎所确定的规则不是忽略请求，而是指明请求应当被重定向

(步骤1208)，则根据如重定向规则规定的虚拟名称来确定真实对象名(步骤1210)，

并且真实对象的创建或打开请求被发给操作系统(步骤1214)。例如，创建或打开名

为“Object_1”命名对象的请求可导致创建名为“Different_Object_1”的实际对象。在

一个实施例中，这是通过调用挂钩函数的原始版本且将形成的真实名称作为参数传

递给该函数来完成的。

如果规则不指明请求应当被重定向(步骤1208)，而是指明请求应当被隔离，则根据

如隔离规则规定的虚拟名称来确定真实对象名(步骤1212)，并且真实对象的创建或

打开命令被发给操作系统(步骤1214)。例如，创建或打开名为“Object_1”命名对象

的请求可导致创建名为“Isolated_Object_1”的实际对象。在一个实施例中，这是通

过调用挂钩函数的原始版本且将形成的真实名称作为参数传递给该函数来完成的。

为了隔离所请求的系统对象所形成的真实名称可基于所接收的虚拟名称和范围特定

标识符。范围特定标识符可以是与应用隔离范围、用户隔离范围、会话隔离范围、

或这三者的组合相关联的标识符。范围特定标识符用于“重整”在请求中接收的虚拟

名称。例如，如果对命名对象“Object_1”的请求对于关联标识符是“SA1”的应用隔

离范围是隔离的，则真实名称可以是“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)。在一些实施例中，

窗口名称和窗口类名可是原子(atom)，而不是字符串文字。通常，应用将串放置在

原子表中且接收16位整数，调用可用于访问串的原子。

如果在步骤1324和1326确定的真实窗口名称或真实窗口类名不同于对应的虚拟名

称，则窗口句柄的窗口映射表条目被更新以记录在请求中提供的虚拟窗口名称或虚

拟类名(步骤1330)。

如果来自操作系统的响应包括本地窗口名称或类的本地标识，则它们被在请求中提

供的虚拟窗口名称或虚拟类名替换(步骤1312)且将结果返回给请求者(步骤1314)。

现在参考图13A，如这里所示的来确定真实窗口名称或窗口类名。咨询规则引擎以

确定应用于请求的规则(步骤1352)。如果规则动作是“忽略”(步骤1354)，则真实名

称等于虚拟名称(步骤1356)。但是，如果规则动作不是“忽略”而是“重定向”(步骤

1358)，则如由重定向规则规定的根据虚拟名称来确定真实名称(步骤1360)。但是，

如果规则动作不是“重定向”而是“隔离”，则利用范围特定标识符根据虚拟名称确定

真实名称(步骤1362)。

在一些实施例中，特殊的范围特定标识符在规则中规定。在其它实施例中，所使用

的范围特定标识符与应用隔离范围关联，该应用隔离范围与请求进程关联。这允许

窗口或窗口类由任何其它与相同应用隔离范围关联的应用来使用。在诸如许多微软

WINDOWS操作系统家族的操作系统中，窗口名称和窗口类已经在会话中被隔离，

这意味着只有在与相同应用隔离范围关联的相同会话中执行的应用才能使用窗口名

称或窗口类。

在微软WINDOWS操作系统家族的一些中，窗口名称用作为标题栏中窗口的标题。

所期望的是，处理非客户区画图窗口消息以确保在窗口标题栏中显示的窗口标题反

应虚拟名称而不是特殊窗口的真实名称。当非客户区画图消息被截取时，从映射表

获取与窗口关联的虚拟名称，如果有的话。如果获取虚拟名称，则利用虚拟名称作

为窗口标题来画图非客户区，且指明已经处理了请求消息。如果没有获取虚拟名称，

则将请求指明为未被处理，利用窗口的真实名称将请求传递到画图标题栏的原始函

数。

4.5进程外COM服务器虚拟化

软件组件技术，比如COM、CORBA、.NET以及其它允许软件组件作为离散单元

被开发、部署、寄存、发现、激活或实例化及利用。在多数组件模型中，组件可以

在调用者的进程中或在相同计算机或分离计算机的分离进程中整体地执行，尽管一

些组件只支持这些情况的子集。

一个或多个唯一标识符识别这些组件。通常，组件基础结构提供代理激活请求的服

务或守护程序。希望利用组件启动的软件进程将请求传递给代理以便激活由组件标

识符规定的组件。代理激活所请求的组件，如果可能的话，且返回对所激活实例的

引用。在这些组件基础结构的一些中，相同组件的多个版本可能不共存，因为组件

标识符在版本之间仍然相同。

微软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 API CoRegisterClassObject()向CSCM注册其支持的所有COM服

务器的所有CLSID。如果所请求的CLSID被注册，CSCM返回对该COM服务器

的引用到调用者。COM客户端和COM服务器之间的所有后续交互独立于CSCM

发生。

先前描述的隔离环境允许具有相同CLSID的COM服务器的多个实例安装在计算

机上，每一个在不同的隔离范围中(其中是系统范围的不超过一个)。但是，仅此将

不会使那些COM服务器对于COM客户端可用。

图14描述为虚拟化对COM服务器访问所采取步骤的一个实施例。在概观上，为

每个在隔离范围中起动的进程外COM服务器创建新的CLSID，之后称作隔离

CLSID(或ICLSID)(步骤1402)。通过定义，这就是CLSID，且因此必须在所有其

它CLSID中是唯一的，换句话说，其必须具有GUID的属性。创建将所述对

(CLSID，应用隔离范围)映射到ICLSID的映射表。为ICLSID创建COM服务器注

册表条目，其描述如何用起动参数起动COM服务器，起动参数启动在适当应用隔

离范围中可执行的COM服务器(步骤1404)。由COM客户端对诸如

CoCreateInstance()或CoCreateInstanceEx()的COM API的调用被钩住或截取(步骤

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，

并且将其转换为适当的ICLSID，将该ICLSID传递到原始

CoRegisterClassObject()API(步骤1418)。当CSCM从具有所期望的ICLSID的

CoRegisterClassObject()调用接收响应时，其将对COM服务器实例的引用返回给调

用者(步骤1420)。

仍然参考图14且更详细地，为每个在隔离范围中起动的进程外COM服务器创建

ICLSID(步骤1402)。在一些实施例中，在安装COM服务器期间创建ICLSID。在

其它实施例中，在安装之后立即创建ICLSID。在又其它实施例中，在将COM服

务器起动到隔离范围中之前创建ICLSID。在所有这些实施例中，可通过钩住或截

取创建或询问注册表数据库中的CLSID条目的系统请求来创建ICLSID。可替换地，

可通过钩住或截取创建COM服务器实例的COM API调用，比如

CoCreateInstance()或CoCreateInstanceEx()来创建ICLSID。可替换地，可在已经进

行安装之后观察注册表数据库的CLSID特定部分的变化。

创建将所述对(CLSID，应用隔离范围)映射到ICLSID的映射表，以及具有该

ICLSID的COM服务器的适当注册表条目，ICLSID描述如何用起动参数来起动

COM服务器，起动参数启动在适当应用隔离范围中可执行的COM服务器(步骤

1404)。在许多实施例中，该表存储在永久存储器元件中，比如硬盘驱动器或固态

存储器元件。在其它实施例中，该表可存储在注册表、平面文件、数据库或易失性

存储器元件中。在又其它实施例中，例如通过将特定于该目的的新子键添加到由

CLSID识别的每个适当COM服务器条目，来在整个注册表数据库的COM特定部

分分布所述表。可在安装期间或在安装之后立即通过钩住或截取创建注册表数据库

中CLSID条目的调用、或者通过观察在安装进行之后注册表数据库的CLSID特定

部分的变化、或者通过钩住或截取创建COM服务器实例的COM API调用，比如

CoCreateInstance()或CoCreateInstanceEx()来创建该表中的条目。COM服务器到特

定隔离范围中的安装可以被永久地记录。可替换地，特殊COM服务器和隔离范围

到ICLSID的映射可被动态地创建且作为条目存储在非永久数据库中，或注册表数

据库中。

COM客户端对COM API的调用，诸如CoCreateInstance()或CoCreateInstanceEx()

被钩住或截取(步骤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)。在这些实

施例的一些中，可动态创建利用ICLSID的COM服务器的条目。

如果返回ICLSID，则将其传递到原始COM API以替换原始的CLSID。例如，所

确定的ICLSID可被传递到原始的CoCreateInstance()或CoCreateInstanceEx()函数，

该函数将请求传递给CSCM(步骤1414)。对于COM服务器在另一计算机上驻留的

实施例，CSCM将ICLSID传递给承载COM服务器的计算机，其中该计算机的

CSCM处理COM服务器的起动。

CSCM通过为确定起动参数在注册表中查找所请求的CLSID或ICLSID来寻找并且

起动可以正常方式执行的COM服务器。如果ICLSID被请求，则在步骤1404中描

述的ICLSID系统范围注册表条目被找到且在适当的应用隔离范围中起动COM服

务器(步骤1416)。

如果所起动的COM服务器实例在应用隔离范围中执行(无论是安装在该范围中还

是安装在系统范围中)，钩住或截取COM服务器实例的CoRegisterClassObject()的

COM API函数。利用如在步骤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呈现给应用实例的本地资源的聚集视图改变为不同

的聚集视图。这允许在特殊隔离范围内已经隔离的进程在进程运行同时被“移动”到

另一隔离范围。这对于一次只有一个实例被执行的系统服务或进程来说是尤其有用

的，比如WINDOWS操作系统中的MSI服务。本发明的这个方面还可用于允许用

户按顺序在若干隔离范围中工作。

参考图16，且在概观上，示出用于在一个隔离范围和第二个隔离范围之间，或者

在系统范围和隔离范围之间移动进程的过程的一个实施例。如本说明书中所使用的，

术语“目标隔离范围”将用于表示进程被移动到的隔离范围，包括系统范围，并且术

语“源隔离范围”将用于表示所移动进程来自的隔离范围，包括系统范围。如图16

所示，且在概观上，用于将进程移动到目标隔离范围的方法包括步骤：确保进程处

于安全状态(步骤1602)；在规则引擎中将进程的关联关系从其源隔离范围改变到目

标隔离范围(步骤1604)；对于任何过滤器驱动程序或挂钩将进程的关联关系从源隔

离范围改变到目标隔离范围(步骤1606)；且允许进程恢复执行(步骤1608)。

仍然参考图16，且更详细地，进程在向不同的隔离范围移动时可处于“安全”状态

(步骤1602)。在一些实施例中，监视进程以确定其何时不处理请求。在这些实施例

中，认为进程处于“安全”状态以便在进程没有处理请求时移动。在这些实施例的一

些中，一旦认为进程处于“安全”状态，到进程的新请求被延迟，直到进程被移动。

在其它实施例中，诸如在诊断应用方面，用户接口可被提供以触发隔离范围中的变

化。在这些实施例中，用户接口可运行将要移动的进程放置到“安全”状态下的代码。

在另外其它实施例中，管理程序可通过延迟到进程的所有进入的请求且等待进程完

成任何活动请求的执行来强迫进程进入“安全”状态。

如果与目标隔离范围关联的规则在规则引擎中已经不存在，则将它们加载到规则引

擎中(步骤1603)。

在规则引擎中改变进程与源隔离范围的关联关系(步骤1604)。如上所述，进程可与

任何隔离范围关联。该关联关系可由规则引擎用在对虚拟本地资源的每个请求上，

以确定要应用到该请求的规则。通过改变规则引擎中的适当数据结构可将应用实例

与目标隔离范围关联。在一些实施例中，写入将进程与新隔离范围相关联的新数据

库条目。在其它实施例中，存储与进程关联的隔离范围的标识符的树节点被改写，

以识别新的隔离范围。在另外其它实施例中，可做出操作系统请求以为进程分配附

加的存储，从而存储与目标隔离范围关联的规则，或在一些实施例中，存储规则的

标识符。

无论关联关系或规则存储在规则引擎的外侧，比如过滤器驱动程序、内核模式挂钩

或用户模式挂钩的任何之处，都可改变进程与源隔离范围的关联关系(步骤1606)。

对于进程和隔离范围规则之间的关联关系是基于PID维护的实施例，进程PID和

规则集合之间的关联关系被改变。对于PID不用于维护进程和可应用的隔离规则

集合之间关联关系的实施例，用户模式挂钩函数可被改变以访问与目标隔离范围关

联的规则集合。对于与隔离范围的规则集合关联的进程在规则引擎中维护的实施例，

在步骤1604中改变存储在规则引擎中的关联关系就足够了。

允许进程恢复在新隔离范围中的执行(步骤1610)。对于新请求被延迟或禁止作出新

请求的实施例，那些请求被发给进程且新的请求被允许。

在一个特别有用的方面中，上述的方法可用于虚拟化由微软提供且在微软

WINDOWS操作系统家族的一些中可用的MSI、安装打包和安装技术。由用于安

装的该技术打包的应用称为MSI插件。支持该技术的操作系统具有称为MSI服务

的WINDOWS服务，该服务帮助安装MSI插件。在系统上存在该服务的单个实例。

希望安装MSI插件的进程在它们的会话中运行MSI进程，它们的会话对MSI服务

作出COM调用。

MSI安装可被虚拟化以将MSI插件安装到应用隔离环境中。概念上，这是通过钩

住或截取在MSI服务的安装会话中对MSI API做出的调用来实现的。可使用互斥

体以确保一次只进行一个安装。当接收或截取请求启动新安装的对MSI API的调

用，且调用进程与特殊的应用隔离范围相关联时，在允许该调用进行之前，将

MSI服务放置在该隔离范围的上下文中。在MSI服务执行其正常安装动作时安装

进行，尽管根据可应用的隔离范围来虚拟化MSI服务作出的本地资源请求。当检

测到安装进程结束时，MSI服务与隔离范围之间的关联关系被移除。尽管上述参考

MSI来描述，所描述的技术可应用于其它安装技术。

等效性

本发明可作为在一个或多个制造物品中体现的一个或多个计算机可读程序来提供。

制造物品可以是软盘、硬盘、CD-ROM、闪速存储器卡、PROM、RAM、ROM或

磁带。一般地，计算机可读程序可用任何程序设计语言，LISP、PERL、C、C++、

PROLOG或任何字节码语言，比如JAVA来实现。软件程序可作为目标代码存储

在一个或多个制造物品之上或之中。

已经描述了本发明的某些实施例，现在对于本领域技术人员清楚的是，还可使用合

并了本发明概念的其它实施例。因此，本发明不应当限于某些实施例，而只应当由

随后权利要求的精神和范围来限定。

本文标签： 请求范围隔离