CN1696910B - 用于对软件打补丁的方法和系统 - Google Patents

Abstract

本申请涉及一种对软件打补丁的方法和系统，以消除传统的应用为用户和系统增加的负担和负面效果。具体来说，这里描述了一个用于在目标计算机系统中扩充软件的工具程序。该工具程序在计算系统内接收扩充规格表。所述扩充规格表指定了(a)要扩充的函数(b)要测试的函数参数，(c)应用于所指定参数的测试，和(d)如果所指定的参数不满足于所指定的测试，就执行对函数行为的修改。当在目标计算机系统上调用所指定的函数时，如果所指定的参数不能满足所指定的测试，所述工具程序就对所指定函数的状态进行指定的修改。

Description

用于对软件打补丁的方法和系统

技术领域

本发明涉及到升级已安装的计算机程序的操作领域。

背景技术

打补丁是修改已经安装的程序，包括应用程序、实用程序、操作系统和操作系统部件、设备驱动程序等等的过程。打补丁对于出于各种目的来修改程序是有用的，这些目的包括纠正程序错误、减少或消除安全风险或者提高所修改程序使用的逻辑。打补丁一般是由最初提供要打补丁的程序的公司或其它组织发起的。

安装的程序主要是由可执行代码模块组成的。作为一个例子，许多设计成在来自Washington Redmond的Microsoft Corp.的WINDOWS XP操作系统上执行的程序主要是由叫做“DLL”的可执行代码模块组成的。一个打补丁的流行的传统方法是要在组成要打补丁的安装程序的可执行代码模块中标识出含有希望用补丁来修改的程序代码的可执行代码模块；创建一个新版本的已标识的可执行代码模块，在其中已作了需要的修改；并且将新版本的已标识的可执行代码模块与安装程序一起分配给希望应用该补丁的用户。然后每个用户确定她/他是否希望应用这个补丁，如果是，执行用新版本的已标识的可执行代码模块取代原来版本的已标识的可执行代码模块的安装程序。

传统的用于打补丁的方法有很多非常不利的地方。这些不利经常增加了与接收和应用补丁有关的负担。一些情况下，这种增加的负担延迟了一些用户对一些补丁的应用，而且甚至阻止了一些用户对一些补丁的应用。补丁应用中的这种延迟和阻碍在一些情况下可能对用户有严重的负面效果，对那些设计成减少或消除安全风险的补丁来说尤其如此。

传统的用于打补丁的方法的一个缺陷涉及到必须创建多个补丁进行分配以实现对单个程序的单独修改的常例。一些情况下，要打补丁的程序有几个不同的特定可执行代码模块的“环境(flavor)”，比如程序被设计成可在其上执行的每个操作系统或操作系统版本，和/或程序的每个自然语言版本的不同环境。这里标识的可执行代码模块是这样的一种可执行代码模块：以上描述的补丁的创建和分配过程必须为已标识的可执行代码模块的每个环境而重复。然后用户必须选择并应用已标识的可执行代码模块的适当环境的补丁。对大量结果补丁进行分类并选择在每个用户的计算机系统上适合的一组补丁来应用是非常繁重的，如此之多以至于这种情况有时被叫做“补丁地狱(patch hell)”。一些情况下，管理员必须维持一个标识了安装在每个目标系统上的一组可执行模块版本的目录数据库，它用于为每个目标系统选择适当的常规补丁。

传统的用于打补丁的方法的另一个缺陷涉及到分配的补丁的较大的尺寸。这对于有以兆比特级大小的可执行代码模块来说，并非罕见，这会导致单个补丁有一个可比较的大小，使得它对一些用户来说难以分配和存储，或者甚至不可能分配或存储。这个问题对具有多个环境的补丁来说更要加倍严重。进一步说，因为每个常规补丁一般包括一个完整的可替代的可执行模块，应用常规补丁会产生代码搅拌(code churn)的问题。

传统的打补丁的方法的一个进一步的缺陷涉及到一些用户在应用补丁到生产计算机系统之前要对其进行测试的需要。一些情况下，在计算机系统上安装一个补丁可能会有相反的结果，比如补丁中包含的新版本的标识的可执行代码模块产生一个新的程序错误的情况，或与在与补丁应用相对的计算机上运行的另一个程序之间产生新的、不可预料的相互作用的情况。因此，经常在生产系统上应用一个补丁之前，用户首先对一个测试系统应用该补丁以估计该补丁应用在生产系统中是否安全，该生产系统的数据和操作的维持是重要的。这种独立的补丁测试增加了与打补丁有关的负担。此外，在常规补丁产生问题的情况下——比如应用程序兼容性问题或新的开发弱点——在应用补丁充分长的时间后，这种问题很难追溯到该补丁。

传统的用于打补丁的方法的一个附加的缺陷涉及到补丁内包括的安装程序的运行。经常地，为了取代为执行程序的一部分的可执行代码模块，该安装程序必须首先终止那个程序的执行。同样地，一些情况下，这种取代在没有重新启动计算机系统的情况下不能完成。所有这些步骤会在打补丁的计算机系统的使用中导致实质的中断。

传统的用于打补丁的方法的另一个缺陷包括试图修补一个可执行模块，其中已经为那个可执行模块更早地发布“专用修补”，也叫做“热修补”给该可执行模块的适合的用户子集。这样的情况下，因为在向根据用户是否已经应用热修补的每个用户来分配取代不同新版本的可执行代码模块的常规补丁过程中遇到的困难，通常代之以分配一个取代单个新版本的可执行模块的简单的常规补丁，而不考虑用户是否已经应用热修补。如果那个新版本包含热修补，该补丁就向用户强加上热修补，而不是接收该热修补。另一方面，如果那个新版本没有包含热修补，它就剥夺了用户想要接收热修补的权利。

传统的用于打补丁的方法另一个缺陷包括对依靠特定可执行模块，比如一个特定动态链接库的软件产品的安装程序经常通过将该可执行模块存储在目标计算机系统的文件系统内的一个非标准位置来“隐藏”那个可执行模块这一事实。因此，有时候确定特定的目标系统是否包含一个需要打补丁的可执行模块的副本是困难的或不可能的，并且，同样，也很难确定它位于目标计算机系统的文件系统内的哪个位置。同样地，一些软件产品维持已经由安装程序安装的可执行模块版本的一个“目录”。软件产品可以依靠特定的可执行模块版本的目录中指示的正确性。常规补丁在没有更新该目录而用可执行模块的新版本取代标识的可执行模块版本的情况下，这种依靠就会失败了。

传统的用于打补丁的方法的另一个缺陷根源于在要打补丁的可执行模块被安装在目标计算机系统中之前的时间应用它们是不可能的这一事实。因此，如果要打补丁的可执行模块是在接收那个可执行模块的常规补丁之后才被安装到目标计算机系统中，该补丁被应用于该可执行模块是不可能的。

传统的用于打补丁的方法的另一个缺陷是它们典型地只能由使用具有自由的修改许可的管理账户登录到目标计算机系统的用户来应用。为此目的而登录一个管理账户会使该目标计算机系统易受存在于目标计算机系统上寻求修改该目标计算机系统并需要自由的修改许可的病毒的攻击。

传统的用于打补丁的方法的另一个缺陷是常规补丁很难或不可能失效，这需要比如倒转可执行模块的取代步骤，或者倒转一个或多个对系统注册表的修改的步骤。

因此，一个克服了以上讨论的传统的打补丁方法的一些或所有缺陷方面的新的打补丁的方法具有重要的实用性。

发明内容

本发明旨在提供一种改进的打补丁的方案，以克服传统的打补丁技术中的缺陷。

根据本发明的第一方面，提供了一种计算系统内用于扩充软件的方法，包括：在目标计算机系统中接收一个扩充规格表以指定(a)要扩充的函数，所指定的函数在计算系统中存在的软件中，(b)要测试的函数的参数，(c)应用于所指定参数的测试，和(d)如果所指定的参数不满足于所指定的测试，就执行对函数行为的修改；以及当在目标计算机系统上调用所指定的函数时，如果所指定的参数不能满足指定的测试时，就对所指定函数的行为进行指定的修改。

根据本发明的第二方面，提供了一种允许在计算系统中存在的软件进行扩充的计算系统，包括：含有该软件的存储设备；补丁接收程序，在所述计算系统中接收补丁，该补丁指定了(a)一个指针，在该指针处要扩充该软件，(b)与在指定指针处要测试的函数相关的一个值，(c)应用于所述指定值的测试，以及(d)如果指定的值不能满足所指定的测试，就执行对软件行为的修改；以及打补丁代理，在所指定指针处将代码注入软件，这样，当软件的执行到达目标计算机系统的所指定指针时，如果指定的值不能满足所指定的测试，就执行对软件行为的所指定修改。

根据本发明的第三方面，提供了一种计算系统内用于扩充软件的系统，包括：用于在所述计算系统中接收一个扩充规格表的装置，该规格表指定了(a)要添加值确认的函数，(b)在函数执行期间，在目标计算系统中存在的要进行测试的数据，(c)要应用于所指定数据的测试，以及(d)如果指定的数据不能满足所指定的测试，就执行对函数行为的所指定的修改；以及当在目标计算机系统上调用所指定的函数时，如果所指定的数据不能满足所指定的测试，用于对所指定函数的行为进行指定的修改的装置。

根据本发明的第四方面，提供了一种用于添加确认的方法，所述确认是确定目标计算系统中可用软件所访问的一个值是否有效，包括：在所述计算系统中接收一个扩充规格表，该规格表指定了(a)要添加软件所访问的一个值是否有效的确认的软件，(b)在所述扩充规格表的所指定软件中的指针，在所述指针处添加软件所访问的一个值是否有效的确认，(c)在所指定软件执行期间目标计算系统上存在的在所指定指针处要测试的数据，(d)要应用于所指定数据的测试，以及(e)如果指定的数据不能满足所指定的测试，就执行对软件行为的修改；允许用户配置用于所接收扩充规格表的操作模式；以及当在目标计算机系统上所指定指针处执行所指定的软件时，以与配置用于所接收的扩充规格表的操作模式相一致的方式来应用所接收的扩充规格表。

附图说明

图1说明了一个适合的工具程序(facility)可在其中实现的计算系统环境的一个例子。

图2是显示一个典型的参照该工具程序的计算机系统间数据交换的流程图。

图3是显示由该工具程序为接收并处理新补丁一般执行的步骤的流程图。

图4是显示由该工具程序使用的典型的样本补丁表格的数据结构图表。

图5是显示由该工具程序为更新一个为特定补丁的配置指令而一般执行的步骤的流程图。

图6是显示由该工具程序为完成一个由补丁指定的参数确认而一般执行的步骤的流程图。

具体实施方式

提供了一个用于为安装的计算机程序代码(“该工具程序”)打补丁的软件程序。一些实施例中，该工具程序增加了参数测试和对安装函数的测试结果处理。另一些实施例中，该工具程序为安装函数增加不同的其他类型的泛函性(functionality)，一些情况下是在安装函数的执行流程中的任意位置。

一些实施例中，对每个补丁而言，该工具程序向每个要打补丁的计算机系统——即每个“目标计算机系统”分配可以执行测试的一个点的说明、要执行测试的特性和怎样动作以回应一个或多个不同的测试结果。一些实施例中，该工具程序提供了一组标准的参数确认和可在补丁中被指定的其它测试。例如，补丁可以指定：对于一个特定的函数，如果该函数的特定参数没有一个确定的值，那该函数的调用应该在它实质的执行开始之前会失败。另一个补丁可以指定：对于一个特定的函数，如果特定的参数长度超过指定的最大长度值，那该参数应该在该函数的执行被允许继续进行之前被截短到指定的最大长度。许多依赖于调用带有参数值的函数的安全开发，当它们在没有原有函数代码的版本内被阻塞时，会导致该函数创建或利用不安全的环境。一些情况下，这种开发可通过使用这种补丁来阻止带有这种参数值的函数执行而被阻止。一些实施例中，补丁指定了例如从文件中读取或由用户输入的值的测试，而不是对函数参数进行测试。

一些实施例中，一个自动打补丁代理自动接收每个补丁，确认它，并将它们存储在补丁表格内用于可能的应用程序。一些实施例中，每个补丁被应用于要打补丁的可执行模块的任何情况下，当接收到补丁时，该模块已经被加载在目标计算机系统中上。这里该方法称作为“热修补”，并且使得补丁一被接收立刻就有效，并且不要求该工具程序能够确定要打补丁的可执行模块存储在磁盘的哪个地方。一些实施例中，每个接收的补丁应用于要打补丁的可执行模块的磁盘映像，这样，当磁盘映像在未来时间被加载时，加载的磁盘映像包括该补丁。这里该方法是指“冷修补”，允许补丁跨越多个会话的是持久的。一些实施例中，该工具程序执行热修补和冷修补。一些实施例中，每次要打补丁的可执行模块被操作系统加载者加载时，就将每个补丁应用于要打补丁的可执行模块。这里该方法是指“加载时间补丁”。一些实施例中，每次要打补丁的函数被调用时，就将每个补丁应用于要打补丁的可执行模块。这里该方法是指“调用截取补丁”。加载时间补丁和调用截取补丁都(1)不要求该工具程序能够确定要打补丁的可执行模块存储在磁盘的哪个地方，(2)方便了特定补丁的有准备的可逆性，并且(3)不要求对可执行模块的磁盘映像的修改。

一些实施例中，该工具程序允许用户或管理员配置已被应用的补丁的运行。作为例子，这种配置可以包括，对一个特定的已应用的补丁：由该补丁指定的测试在执行到达为该补丁指定的点时是否被执行；由该补丁指定的测试结果处理是被执行还是被忽略；和/或是否测试的性能和/或其结果被记录、显示在警告消息中等等。这些实施例中，该工具程序允许通过最初使登陆有效并使结果处理无效而在生产计算机系统上测试补丁。这些实施例中，该工具程序进一步允许在补丁结果处理之后，将该补丁记录在“详细(verbose)的模式”中来帮助标识该补丁产生问题的情况，比如应用程序兼容性问题或其它IT问题。如果发现补丁产生问题之后，这些实施例也允许该补丁在应用之后迅速失效。该工具程序的一些实施例也允许通过简单地从接收并存储在目标计算机系统中的一组补丁中删除该补丁而迅速失效。

一些实施例中，该工具程序使用“数据驱动”补丁方法，其中补丁不包含代码，而包含数据，比如指定了执行测试的点、要执行的测试的特性和怎样动作作为对一个或多个不同测试结果的响应的一段小的人类可读的文本或XML文档。这样的实施例中，打补丁代理接收数据驱动补丁，并且附加由补丁指定的测试和测试处理。一些实施例中，该工具程序使用“代码驱动”打补丁方法，其中每个补丁包含附加在要打补丁的可执行模块上的短程序，该短程序通过调用该工具程序的标准参数测试函数来自行执行测试，并且自行执行测试处理。使用数据驱动补丁或代码驱动补丁，用单个补丁来处理要打补丁的可执行模块的所有环境有时候是可能的。

一些实施例中，该工具程序标记每个补丁来证明(1)该补丁来源于一个批准的源头，并且(2)该补丁的内容从批准源头创建补丁开始就未被修改。

一些实施例中，该工具程序分配每个补丁给每个目标计算机系统，而且目标计算机系统上的打补丁代理基于目标计算机系统的特征自动确定哪个补丁将在目标计算机系统上应用和它们怎样被应用。这减轻了用户和管理员的许多传统的与选择和应用补丁有关的负担，以及维持一个正确的、当前的目录数据库的负担。例如，这些特征可以包括哪个版本的要打补丁的可执行模块被安装在目标计算机系统上。这些实施例中，该工具程序可以通过分配为特定可执行模块的热修补和未热修补的环境指定了不同处理的补丁、为那个可执行模块打补丁时消除为特定可执行模块牺牲热修补或使得热修补普遍存在的需要来克服由热修补所导致的该类型的问题。

一些实施例中，打补丁代理将每个接收的补丁存储在目标系统中，而不考虑当该补丁被接收时，要由特定补丁打补丁的可执行模块是否被安装在目标系统上。因为在许多情况下，该工具程序应用补丁作为对加载要打补丁的可执行模块或调用要打补丁的函数的响应，该工具程序可以对在接收补丁到目标系统之后安装在目标系统上的可执行模块应用一个补丁。同样地，补丁可以在要打补丁的可执行模块卸载和其后的重新安装中继续存在。

一些实施例中，打补丁代理在操作系统服务中实现。这些实施例中，工具程序符合打补丁代理应用补丁所需要的任何许可。这些实施例减少了当常规补丁被应用时通常强加的安全风险，因为它们消除了用户使用具有很宽修改许可的管理账户登录目标计算机系统的任何要求，上述要求会给目标计算机系统上存在的任何病毒修改目标计算机系统的敏感部分的较大机会。

这些由工具程序使用的补丁一般比较小，并因此提出了适度的对传输和存储的资源要求。同样地，因为工具程序使用的补丁易于以少数定义明确的方式来修改打补丁软件的行为(behavior)，故该工具程序帮助减少了代码搅拌的问题。

图1说明了适合的在其中可以实现该工具程序的计算机系统环境100的一个例子。该计算系统环境100只是一个适合的计算环境的例子并没有任何限制用户范围或程序功能性的意图。对涉及到示例性计算环境100中说明的任一部件或其结合而言，计算环境100被认为与其既无任何依赖性，也非必需。

该工具程序在大量其它的常用或专用计算系统环境或配置中也是可以操作的。适合使用该工具程序的熟知的计算系统、环境和/或配置的例子包括，但不限于：个人计算机、服务器计算机、手提或膝上设备、写字板设备、多处理器系统、基于微处理器的系统、机顶盒、可编程消费者电子设备、网络PC、微型机、大型机、包括任何以上系统或设备的分布式计算环境等等。

该工具程序可在计算机可读指令的普通上下文范围，比如由计算机执行的程序模块中进行描述。一般来说，程序模块包括基本例程、程序、对象、部件、数据结构等等，它们执行特定的任务或实现特定的抽象数据类型。该工具程序也可以在任务由通过通信网络链接的远端处理设备执行的分布式计算环境中施行。在分布式环境中，程序模块可被安置在包括存储器存储设备的本地和/或远程计算机存储介质。

关于图1，一个用于实现该工具程序的示例性系统包括以计算机110的形式的通用计算设备。计算机110的部件可以包括，但不限于处理单元120、系统存储器130和把包括系统存储器在内的不同部件耦合到处理单元120的系统总线121。系统总线121可以是许多类型的总线结构，包括存储器总线或存储器控制器、外围总线、和使用多种总线结构的任何一种的局部总线的任何一种。作为例子，而非限制，这种结构包括工业标准结构(ISA)总线、微通道结构(MCA)总线、增强型ISA(EISA)总线、视频电子标准协会(VESA)局部总线以及外围组件互联(PCI)总线，也称为Mezzanine总线。

计算机110典型地包括多种计算机可读的介质。计算机可读介质可以是由计算机110访问的任何可用介质并包括易失的和非易失的介质、可移动的和不可移动的介质。作为例子，而非限制，计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括易失的和非易失的介质、可移动的和不可移动的介质，这些介质以用于信息存储的任何方法或技术，比如计算机可读指令、数据结构、程序模块或其它数据来实现。计算机存储介质包括但不限于，RAM、ROM、EEPROM、闪存或其它存储技术、CDROM、数字化视频光盘(DVD)或其它的光盘存储器、磁性磁带、磁性录音带、磁性磁盘存储器或其它的磁性存储器设备，或可用于存储需要的信息并可由计算机110存取的任何其它介质。通信介质典型地包括计算机可读指令、数据结构、程序模块或在一个调制数据信号比如载波或其它传输装置中的其它数据并且包括任何信息传递介质。术语“调制数据信号”意思是具有一个或多个它的特征集或以信号中编码信息的方式变换的信号。作为例子，而非限制，通信介质包括比如有线网络或直接有线连接的有线介质和比如声频、RF、红外线和其它无线介质。以上的任何组合也应该包括在计算机可读介质的范围内。

系统存储器130包括以比如只读存储器(ROM)131和随机存取存储器(RAM)132的易失的和非易失的存储器形式的计算机存储介质。基本输入/输出系统133(BIOS)典型地存储在ROM 131内，它包括如启动时帮助在计算机110内的元件间传输信息的基本例程。RAM 132通常包含可由处理单元120即时存取和/或目前在操作的数据和/或程序模块。作为例子而非限制，图1说明了操作系统134、应用程序135、其它程序模块136以及程序数据13。

计算机110还包括其它可移动/不可移动、易失/非易失计算机存储介质。仅仅作为例子，图1显示了从不可移动的非易失磁性介质读取或向其中写入的硬盘驱动器141、从可移动的非易失磁性磁盘152读取或向其中写入的磁盘驱动器151、以及用于向诸如CD ROM或其它光学媒介这样的可移动非易失光学介质156读写的光盘驱动器155。其它能用于示例性操作环境的可移动/不可移动、易失/非易失计算机存储介质包括但不限于：磁性盒式磁带、闪存卡、数字多用途盘、数字视频磁带、固态RAM、固态ROM等等。硬盘驱动器141经常通过诸如接口140等不可移动存储器接口连接到系统总线121，而磁盘驱动器151通过诸如接口150等可移动存储器接口连接到系统总线121。

图1讨论并示出的驱动器及其关联的计算机存储介质为计算机110提供了计算机可读指令、数据结构、程序模块和其它数据的存储。例如，在图1中，示出硬盘驱动器141作为储存操作系统144、应用程序145、其它程序模块146和程序数据147。注意，这些组件可以与操作系统134、应用程序135、其它程序模块136和程序数据137相同，也可以与它们不同。这里对操作系统144、应用程序145、其它程序模块146和程序数据147给予不同的标号来说明至少它们是不同的副本。用户可以通过输入设备，如写字板、电子数字化仪164、麦克风163、键盘162和定位设备161(通常指鼠标、跟踪球或触摸板)向计算机110输入命令和信息。其它输入设备(图1中未示出)可包括操作杆、游戏手柄、圆盘式卫星天线、扫描仪等。这些和其它输入设备通常通过耦合至系统总线的用户输入接口160连接至处理单元120，但是也可以通过其它接口和总线结构相连，如并行端口、游戏端口或通用串行总线(USB)。监视器191或其它类型的显示设备也通过接口，如视频接口190连接至系统总线121。监视器191也可以与触摸屏面板等集成。注意，监视器和/或触摸屏面板可以物理连接到结合有计算设备110中的外壳，比如一个平板型的个人计算机。此外，比如计算设备110的计算机也可以包括其他外围输出设备，比如，扬声器195和打印机196，它们通过外围接口194等进行连接。

计算机110可能工作在使用一个或多个到诸如远程计算机180的远程计算机的逻辑连接的网络化环境内。远程计算机180可以是个人计算机、服务器、路由器、网络PC、对等设备或其他公共网络节点，并且一般包括与计算机110相关的许多或所有上述元件，虽然图1中仅说明了存储器存储设备181。图1所述的逻辑连接包括局域网(LAN)171以及广域网(WAN)173，但也可以包括其他网络。这种网络环境常见于办公室、企业范围的计算机网络、内联网以及因特网。例如，现在的工具程序中，计算机系统110可以包含数据移植于其中的源头装置，而远程计算机180可以包含目的装置。然而注意到，源头和目的装置不需要由网络或任何其他装置连接，代之以数据可通过任何能够由源头平台写入并由目的平台读取的任何装置进行转移。

当用于LAN网络环境时，计算机110通过网络接口或适配器170连接到局域网LAN 171。当用于WAN网络环境时，计算机110一般包括调制解调器172或其他装置，用于在诸如因特网的广域网173上建立通信。调制解调器172可能是内置或外置的，它通过用户输入接口160或其它适合的机制连接到系统总线121。在网络化环境内，所述与个人计算机110相关的程序模块或其中的一部分可能存储在远程存储设备内。作为例子，而非限制，图1说明了将远程应用程序185驻留在存储设备181上。应该认识到所示的网络连接是示例性的，在计算机间建立连接的其他装置也可以使用。

尽管图1显示了存在于特定计算机系统上以特定方式排列的各种功能性和数据，本领域的技术人员意识到这种功能性和数据可以通过不同排列的计算机系统以不同的其他方式分布。尽管以上述方式配置点计算机系统一般用于支持该工具程序的运行，然而本领域的一个普通技术人员意识到该工具程序可以用不同类型和配置并由不同部件的设备来实现。

图2是显示了参照本工具程序的计算机系统间一个典型的数据交换的数据流程图。图2显示的计算机系统(计算机系统210、220、221、222、230、231和232)一般有显示的一些或所有部件并且与图1结合进行讨论。在补丁分配服务器上，该工具程序产生一个或多个补丁。这些补丁201从补丁分配服务器发送到一个或多个管理服务器，比如管理服务器220和230。接着，每个管理服务器将补丁运送到一个或多个目标计算机系统，比如目标计算机系统221、222、231和232。一些实施例中(未显示)，补丁分配服务器直接，或通过一个比通过单个管理服务器更为间接的路径发送补丁到一个或多个目标计算机系统。在目标计算机系统接收到的补丁在目标计算机系统进行处理，下面将作更详细的描述。管理服务器也可以发送补丁配置命令202到一个或多个目标计算机系统，该系统应用补丁配置命令以重新配置特定补丁的运行。作为下面更为详细的描述，补丁可以完全失效；如果补丁没有失效，其运行通知和测试结果处理可以独立地生效或失效。当运行通知为生效时，通知可以显示或本地存储在目标计算机系统上，或可以作为通知203被发送到适当的管理服务器上。

图3是显示该工具程序为了接收和处理新补丁而一般执行的步骤的流程图。在步骤301，该工具程序接收一个补丁。在步骤301接收的补丁可以是一个数据驱动补丁或是一个代码驱动补丁。下面的表格1内显示了一个样本数据驱动补丁。

1   <Softpatch Patch＝″Q382429″>

2    <AffectedApplication AffectedExe＝″sqlservr.exe″>

3     <AffectedVersion Version＝″9.＊″>

4      <AffectedModules Name＝″SQLSORT.DLL″>

5       <Version  ″8.0.＊，9.＊″>

6              <Function Name＝″SsrpEnumCore″Address＝″0x0802E76B″

7                  Param＝″2″Paramtype＝″LPSTR″>

8                <Filter MaxByteLength＝″60″/>

9                <Resolution ActionType＝″BOOL″Action＝″FALSE″/>

10             </Function>

11      </Version>

12      <Version″10.＊，11.＊″>

13             <Function Name＝″SsrpEnumCore″Address＝″0x0802D283″

14                 Param＝″2″Paramtype＝″LPSTR″>

15              <Filter MaxByteLength＝″128″/>

16              <Resolution ActionType＝″BOOL″Action＝″FALSE″/>

17             </Function>

18      </Version>

19     </AffectedModules>

20    </AffectedVersion>

21   </AffectedApplication>

22

23   <Signature Hash＝″MD5″Signature＝″C509-64AA-9161-8C52-

249   F6D-BF5A-AEF2-ECE1-0038-34D1″/>

25   </Softpatch>

表格1

行1包含一个该补丁唯一的标识符。行2标识了受该补丁影响的应用程序。行3标识了受该补丁影响的应用程序版本。行4标识了受该补丁影响的可执行模块。行5标识了两个版本的受影响的可执行模块——版本8.0.^＊和9.^＊——它们提供了打补丁的方向。行6-10包含为这些两个版本的可执行模块打补丁的方向。行6-7标识了要打补丁的函数、它在可执行模块内的地址、由补丁测试的它的参数和要测试参数的类型。行8指示了在行6-7标识的参数应被测试以确定是否其长度超过60字节。行9指示了如果测试成功，该函数的调用应该失败。行12标示了两个更多版本的受影响的可执行模块——版本10.^＊和11.^＊——它们提供了打补丁的方向。行13-17包含为这些两个版本的可执行模块打补丁的方向。行13-14标识了要打补丁的函数、它在可执行模块内的地址、由补丁测试的它的参数和要测试参数的类型。可以看到，在行13-14内为版本10.^＊和11.^＊标识的可执行模块内要打补丁的函数地址不同于在行6-7内为版本8.0.^＊和9.^＊标识的的可执行模块内要打补丁的函数地址。行15指示了在行13-14内标识的参数应被测试以确定是否其长度超过128字节。行16指示了如果测试成功，该函数的调用应该失败。该补丁可以指定各种结果处理动作类型，包括补丁函数调用失败、出现异常、终止要打补丁的可执行模块正被执行的进程、或者纠正违规值(比如通过截短过长的串)。行23-25包含对该补丁的识别标志，该标志标识了补丁的源头并校验了从离开源头开始该补丁未被改变。

下面的表格2包含一个以上表格1中显示的补丁的代码驱动版本。

1    00411A7E   push    3Ch

2    00411A80   mov     eax，dword ptr[str]

3    00411A83   push    eax

4    00411A84   call    ValidateStringLength(411082h)

5    00411A89   add     esp，8

6    00411A8C   movzx   ecx，al

7    00411A8F   est     ecx，ecx

8    00411A91   je      411A9Ah

9    00411A93   jmp     foo+2(411AD2h)

10   00411A9A   xor     eax，eax

11   00411A9C   ret

表格2

行1-3将用于测试函数的参数推到堆栈上。行4调用测试函数。行5-8将用于测试函数的返回代码分支。如果测试函数成功，行9跳回开始执行打补丁函数主体部分。如果测试函数失败，行10-11推动失败的结果代码到堆栈上并从打补丁函数返回到要打补丁函数的本色(color)。为了易读，表格2忽略了显示在一些代码驱动补丁内的某些细节，包括用于测试补丁配置标记的当前值的可验证的标志、指令，和从打补丁函数的代码的开始重新定位的指令。

一些实施例中，所有类型的补丁可包含附加信息，包括，为要打补丁的可执行模块的一个或多个版本中每一个版本的可用于校验可执行模块的特定情况是适合的该版本的副本的文件签名。这种文件签名可以是，例如，为整个可执行模块版本的大小或校验和，或者可能发生在可执行模块内的特定点，比如在要打补丁的可执行模块的偏移量处，的代码。

在步骤302，如果补丁带有合法标志被标记，那么该工具程序继续到步骤303，否则该工具程序继续到步骤301以接收下一个补丁。在步骤303，该工具程序增加补丁到本地补丁表格。在步骤304，该工具程序使用补丁的初始配置，比如通过发送它到缺省配置。

图4是显示该工具程序使用的一个典型的样本补丁表格的数据结构图。补丁表格400包含行，比如行401和402，每个行分为以下列：包含从补丁中提取的补丁标识符的补丁标识符列411；包含标识要打补丁的可执行模块信息，比如其名字的可执行模块列412；标识了列412内标识的、要应用补丁的所有版本的可执行模块的可执行模块版本列413；包含当前配置值的测试性能有效列414，所述当前配置值用于确定打补丁函数被调用时是否每次都执行由补丁指定的测试；包含当前配置值的测试性能通知有效列415，所述当前配置值用于确定补丁测试执行时，是否每次都产生通知；包含当前配置值的测试结果通知有效列416，所述当前配置值用于确定当补丁测试成功时，是否每次都产生通知；包含当前配置值的测试结果处理有效列417，所述当前配置值用于确定当补丁测试失败时，是否要执行补丁结果处理；和包含到该补丁自身的指针、指定了测试失败时每次要执行的测试和测试结果处理的补丁列418。一些实施例中，不是如所示包含一个指针，而是该补丁列418直接包括每个补丁。一个特定的补丁表格可包括或指向各种不同类型的补丁，比如所有的代码驱动的补丁、所有数据驱动的补丁，或者代码驱动和数据驱动补丁的结合。

在步骤305，一旦该工具程序已经将接收的补丁增加到补丁表格并且初始化了它的配置，该补丁可由该工具程序自动应用于可执行模块。在步骤305，该工具程序可以使用许多不同的方法来应用该补丁，包括由参考结合的应用中描述的那些，也包括实时函数调用拦截、和/或(1)已经加载的可执行模块、(2)可执行模块的一个或多个磁盘映像、或者(3)由操作系统的加载程序加载的可执行模块的情况的代码重写。步骤305之后，该工具程序继续到步骤301以接收下一个补丁。

图5是显示该工具程序为了为特定补丁更新配置指令而一般执行的步骤的流程图。在步骤501，该工具程序为特定补丁接收配置指令，比如从一个管理员那里。一些实施例中，这种配置指令可由使用组方针的管理员产生。在步骤502，该工具程序参照接收的指令升级补丁表格内补丁的配置。步骤502之后，该工具程序继续到步骤501以接收下一个配置指令。

图6是显示该工具程序为执行由补丁指定的参数变量而一般执行的步骤的流程图。在步骤601，打补丁函数被调用。在步骤602，如果对影响被调用函数的补丁的测试是可行的，那么该工具程序继续到步骤603，否则该工具程序继续到步骤601以处理下一个对打补丁函数的调用。在步骤603，如果对该补丁的测试性能通知可以有效，那么该工具程序继续到步骤604，否则该工具程序继续到步骤605。在步骤604，该工具程序产生一个执行测试的通知。步骤604、608和610可以在该测试满意的目标计算机系统上显示或存储一个指示，和/或传送这种指示到一个远程计算机系统用于在那里显示或记录。

在步骤605，该工具程序执行由补丁指定的确认测试。一些实施例中，步骤605包括调用由该工具程序为测试所用的一组标准例程的其中一个。在步骤606，如果在步骤605执行的测试令人满意，那么该工具程序继续到步骤601，否则该工具程序继续到步骤607。在步骤607，如果为该补丁的测试结果通知无效，那么该工具程序继续到步骤608，否则该工具程序继续到步骤609。在步骤608，该工具程序产生一个测试不令人满意的通知。在步骤609，如果测试结果处理对于补丁有效，那么该工具程序继续到步骤610，否则，该工具程序继续到步骤601。在步骤610，该工具程序执行由补丁指定的测试结果处理。步骤610之后，该工具程序继续到步骤601。

本领域的技术人员应该意识到，以上描述的程序可以直接应用或以不同的方式扩展。例如，可以以不同方式在为不同目的的不同类型的可执行模块的不同位置使用该工具程序来应用各种不同类型的补丁。同样地，尽管这里描述的补丁是作为包含当值确认测试失败时来为其指示一个问题的，但该工具程序也可以用当值确认测试成功时来为其指示一个问题的值确认来实现。一些实施例中，每个测试伴随一个是成功还是失败指示问题的一个指示。尽管前面的描述作为首选的实施例而参考，然而本发明的范围仅仅以下面的权利要求和这里叙述的元件来定义。

Claims (32)

1.一种在目标计算系统内用于扩充软件的方法，包括：

在目标计算系统中接收一个扩充规格表以指定（a）要扩充的函数，所指定的函数在目标计算系统中存在的软件中，（b）要测试的函数的参数，（c）应用于所指定参数的测试，和（d）如果所指定的参数不满足于所指定的测试，就执行对函数行为的修改；以及

当在目标计算系统上调用所指定的函数时，如果所指定的参数不能满足指定的测试时，就对所指定函数的行为进行指定的修改；

其中，通过识别一参数测试函数以调用所述参数测试函数，所述扩充规格表指定将应用于所指定的参数的测试，所述参数测试函数的代码不包含在所述扩充规格表中。

2.如权利要求1所述的方法，其特征在于，由所述扩充规格表所指定的修改阻止了所指定函数的执行。

3.如权利要求1所述的方法，其特征在于，由所述扩充规格表所指定的修改是在所指定参数改变之后执行所指定的函数。

4.如权利要求1所述的方法，其特征在于，在所述目标计算系统中接收多个扩充规格表。

5.如权利要求1所述的方法，其特征在于，在接收所述扩充规格表后，并不要求用户干涉以执行对所指定函数行为的指定修改。

6.如权利要求1所述的方法，其特征在于，通过识别参数测试函数以调用所述参数测试函数，所述扩充规格表指定将应用于所指定的参数的测试，所述参数测试函数在接收所述扩充规格表之前就已安装。

7.如权利要求1所述的方法，其特征在于，所述扩充规格表包含代码。

8.如权利要求7所述的方法，其特征在于，由所述扩充规格表包含的代码包括调用参数测试函数的参数。

9.如权利要求1所述的方法，其特征在于，所述扩充规格表包含识别参数测试函数的文本。

10.如权利要求9所述的方法，其特征在于，所述参数测试函数的代码由所述扩充规格表含有的文本来识别。

11.如权利要求1所述的方法，其特征在于，进一步包括提供一个用于配置控制所述扩充规格表操作的状态的接口，并且仅当该状态为有效状态时，才对指定函数的行为进行指定修改。

12.如权利要求11所述的方法，其特征在于，所提供的接口允许所述扩充规格表的操作被本地配置。

13.如权利要求11所述的方法，其特征在于，所提供的接口允许所述扩充规格表的操作被远程配置。

14.如权利要求11所述的方法，其特征在于，所指定的测试是在执行所指定函数之前被执行。

15.如权利要求1所述的方法，其特征在于，进一步包括提供一个用于配置与所述扩充规格表相关警告的接口，并且如果所提供的接口用于使警告有效，就在由所述扩充规格表指定的测试每次失败时产生一个警告。

16.如权利要求1所述的方法，其特征在于，进一步包括提供一个用于配置与所述扩充规格表相关通知的接口，并且如果所提供的接口用于使通知有效，就在由所述扩充规格表指定的测试每次执行时产生一个通知。

17.如权利要求16所述的方法，其特征在于，进一步包括将所产生的通知合并到单个已经合并的通知中。

18.如权利要求1所述的方法，其特征在于，所接收的扩充规格表被标记，该方法进一步包括验证所述扩充规格表的签名，

并且，仅当对所述扩充规格表的签名的验证成功时，才执行对指定函数行为进行的指定修改。

19.如权利要求18所述的方法，其特征在于，仅当所述扩充规格表的签名的签名人与含有指定函数的软件的签名人匹配时，才执行对指定函数的行为进行的指定修改。

20.如权利要求1所述的方法，其特征在于，进一步包括当调用所指定函数时，改变所指定函数的代码以执行所指定的测试。

21.如权利要求1所述的方法，其特征在于，在已鉴别的可执行模块中提供所指定的函数，所述模块使用加载程序进行加载，而所述方法进一步包括在响应对所指定函数的每次调用而执行所指定函数之前来执行所指定的测试。

22.一种允许在目标计算系统中存在的软件进行扩充的方法，包括：

在所述目标计算系统中接收补丁，该补丁指定了（a）一个点，在该点处要扩充该软件，（b）与在指定的点处要测试的函数相关的一个值，（c）应用于所述指定值的测试，以及（d）如果指定的值不能满足所指定的测试，就执行对软件行为的修改；

通过打补丁代理，在所指定的点处将代码注入软件，这样，当软件的执行到达目标计算系统的所指定的点时，如果指定的值不能满足所指定的测试，就执行对软件行为的所指定修改；以及

其中所述补丁指定将应用于所指定的值的测试函数，所述测试函数的代码不包含在所述补丁中。

23.一种在目标计算系统内用于扩充软件的系统，包括：

用于在目标计算系统中接收一个扩充规格表的装置，所述扩充规格表指定了（a）要扩充的函数，所指定的函数在目标计算系统中存在的软件中，（b）要测试的函数的参数，（c）应用于所指定参数的测试，和（d）如果所指定的参数不满足于所指定的测试，就执行对函数行为的修改；以及

用于当在目标计算系统上调用所指定的函数时，如果所指定的参数不能满足指定的测试时，就对所指定函数的行为进行指定的修改的装置；

其中，通过识别一参数测试函数以调用所述参数测试函数，所述扩充规格表指定将应用于所指定的参数的测试，所述参数测试函数的代码不包含在所述扩充规格表中。

24.一种用于添加值确认的方法，所述确认是确定目标计算系统中的软件所访问的一个值是否有效，包括：

在所述目标计算系统中接收一个扩充规格表，该扩充规格表指定了（a）要添加一个值是否有效的确认的软件，（b）在所述扩充规格表的所指定软件中的点，在所述点处添加软件所访问的一个值是否有效的确认，（c）在所指定软件执行期间目标计算系统上存在的在所指定的点处要测试的数据，（d）要应用于所指定数据的测试，以及（e）如果指定的数据不能满足所指定的测试，就执行对软件的行为的修改；

允许用户配置用于所接收扩充规格表的操作模式；以及

当在目标计算系统上所指定的点处执行所指定的软件时，以与配置用于所接收的扩充规格表的操作模式相一致的方式来应用所接收的扩充规格表。

25.如权利要求24所述的方法，其特征在于，所述用户配置用于所述扩充规格表的有效操作模式，在所述有效操作模式下以与配置的所接收的扩充规格表的操作模式相一致的方式来应用所接收的扩充规格表的步骤包括：如果指定的数据不能满足所指定的测试，就执行对所指定软件行为的修改。

26.如权利要求24所述的方法，其特征在于，所述用户配置用于所述扩充规格表的有效诊断操作模式，在所述有效诊断操作模式下以与配置的所接收扩充规格表的操作模式相一致的方式来应用所接收的扩充规格表的步骤包括：如果指定的数据不能满足所指定的测试，就执行（1）执行对所指定软件行为的指定修改，以及（2）产生指定的数据不能满足所指定的测试的通知。

27.如权利要求24所述的方法，其特征在于，所述用户配置用于所述扩充规格表的详细有效操作模式，在所述详细有效操作模式下以与配置用于所接收的扩充规格表的操作模式相一致的方式来应用所接收的扩充规格表的步骤包括：

如果指定的数据不能满足所指定的测试，就执行对所指定软件行为的指定修改，以及

产生指定的测试被执行的通知。

28.如权利要求24所述的方法，其特征在于，所述用户配置用于所述扩充规格表的详细诊断操作模式，在所述详细诊断操作模式下以与配置用于所接收的扩充规格表的操作模式相一致的方式来应用所接收的扩充规格表的步骤包括：

如果指定的数据不能满足所指定的测试，就执行（1）执行对所指定软件行为的指定修改，以及（2）产生指定的数据不能满足所指定的测试的通知；以及

产生指定的测试被执行的通知。

29.如权利要求24所述的方法，其特征在于，所述用户配置用于所述扩充规格表的无效操作模式，在所述无效操作模式下以与配置用于所接收的扩充规格表的操作模式相一致的方式来应用所接收的扩充规格表的步骤包括：忽略对所指定软件的行为进行的指定修改，而不考虑所指定的数据是否能满足所指定的测试。

30.如权利要求24所述的方法，其特征在于，所述用户配置用于所述扩充规格表的无效诊断操作模式，在所述无效诊断操作模式下以与配置用于所接收的扩充规格表的操作模式相一致的方式来应用所接收的扩充规格表的步骤包括：

忽略对所指定软件的行为进行的指定修改，而不考虑所指定的数据是否能满足所指定的测试；

如果指定的数据不能满足所指定的测试，就产生指定的数据不能满足所指定测试的通知。

31.如权利要求24所述的方法，其特征在于，所述用户配置用于所述扩充规格表的无效诊断操作模式，在无效诊断操作模式下以与配置用于所接收的扩充规格表的操作模式相一致的方式来应用所接收的扩充规格表的步骤包括：

忽略对所指定软件的行为进行的指定修改，而不考虑所指定的数据是否能满足所指定的测试；以及

产生指定的测试被执行的通知。

32.如权利要求24所述的方法，其特征在于，所述用户配置用于所述扩充规格表的无效诊断操作模式，在所述无效诊断操作模式下以与配置用于所接收的扩充规格表的操作模式相一致的方式来应用所接收的扩充规格表的步骤包括：

将对所指定软件的行为进行的指定修改忽略，而不考虑所指定的数据是否能满足所指定的测试；

产生指定的测试被执行的通知；

如果指定的数据不能满足所指定的测试，就产生指定的数据不能满足所指定测试的通知。

Images