CN1696911A - 有效地打补丁 - Google Patents

Abstract

这里描述了一个用于自动处理软件补丁的工具程序。该工具程序在计算系统内接收鉴别的补丁包用于修改可编程实体的状态。该工具程序自动从所鉴别的补丁包中提取(1)标识要应用该补丁的已鉴别可编程实体的补丁应用信息，和(2)指定用于修改已鉴别的可编程实体状态方式的补丁状态信息。该工具程序自动将一个包含提取的补丁应用信息和补丁状态信息的已鉴别的条目增加到补丁表格。

Description

有效地打补丁

技术领域

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

背景技术

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

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

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

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

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

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

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

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

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

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

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

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

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

附图说明

图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-

24    9F6D-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  test   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 (38)

1.计算系统内的一种方法，包括：

在计算系统内接收一个鉴别的补丁包用于修改安装程序的状态；

自动从该鉴别的补丁包中提取(1)补丁应用信息，识别补丁要对其应用该补丁的已鉴别程序的鉴别部分，和(2)补丁状态信息，指定了一种修改已鉴别程序的鉴别部分的状态的方式；和

自动增加鉴别的条目到补丁表格，该鉴别的条目包含提取的补丁应用信息和补丁状态信息。

2.如权利要求1所述的方法，进一步包含使用鉴别条目的内容来修改已鉴别程序的鉴别部分的状态。

3.如权利要求2所述的方法，其特征在于，当没有管理用户登录计算系统时，鉴别条目的内容被用于修改已鉴别程序的鉴别部分的状态。

4.如权利要求2所述的方法，其特征在于，不基于任何用户许可，鉴别条目的内容被用于修改已鉴别程序的鉴别部分的状态。

5、如权利要求2所述的方法，其特征在于，无需确定已鉴别程序被持久存储的位置，鉴别条目的内容就被用于修改已鉴别程序的鉴别部分的状态。

6.如权利要求2所述的方法，其特征在于，鉴别条目的内容被用于修改已鉴别程序的鉴别部分来作为对已鉴别程序加载的响应。

7.如权利要求2所述的方法，其特征在于，鉴别条目的内容被用于修改已鉴别程序的鉴别部分来作为对已鉴别程序的鉴别部分的执行的响应。

8.如权利要求2所述的方法，其特征在于，被加载的已鉴别程序的两种情况，和鉴别条目的内容被用于修改已鉴别程序的所有情况的鉴别部分的状态。

9.如权利要求1所述的方法，进一步包括：

当补丁应用信息被提取时，确定已鉴别程序是否被加载在计算系统内；并且

如果已鉴别程序被加载在计算系统内，使用提取的补丁应用信息参照补丁状态信息来修改加载的已鉴别程序的状态。

10.如权利要求1所述的方法，进一步包括，从补丁表格中删除鉴别条目以阻止已鉴别程序的鉴别部分的状态被参照包含在鉴别条目中的补丁状态信息而被修改。

11.如权利要求1所述的方法，其特征在于，提取的补丁状态信息指定了修改已鉴别程序的鉴别部分来执行值确认。

12.如权利要求1所述的方法，其特征在于，提取的补丁状态信息指定了修改已鉴别程序的鉴别部分来执行参数确认。

13.如权利要求1所述的方法，其特征在于，提取的补丁状态信息指定了修改已鉴别程序的鉴别部分来执行从文件中读取的值的确认。

14.如权利要求1所述的方法，其特征在于，提取的补丁状态信息指定修改已鉴别程序的鉴别部分来执行由用户输入的值的确认。

15.如权利要求1所述的方法，其特征在于，提取的补丁状态信息指定修改已鉴别程序的鉴别部分来执行在一个或多个网络分组中接收的值的确认。

16.如权利要求1所述的方法，其特征在于，提取的补丁状态信息通过调用鉴别确认函数指定了修改已鉴别程序的鉴别部分的状态来执行参数确认。

17.如权利要求16所述的方法，其特征在于，补丁表格内的条目而非鉴别条目也包括通过调用鉴别确认函数来指定修改已鉴别程序的鉴别部分的状态来执行参数确认。

18.如权利要求16所述的方法，进一步包括，为鉴别确认函数的执行代码以修改已鉴别程序的鉴别部分的状态，已鉴别的代码不包括在鉴别的补丁包内。

19.一个计算机可读的介质，其内容导致计算系统执行一种方法，该方法包括：

在计算系统内接收一个鉴别的补丁包用于修改可编程实体的状态；

自动从鉴别的补丁包中提取(1)补丁应用信息，识别要对其应用该补丁的已鉴别可编程实体，和(2)补丁状态信息，确定一种修改已鉴别可编程实体的状态的方式；和

自动增加鉴别的条目到补丁表格，该鉴别的条目包含提取的补丁应用信息和补丁状态信息。

20.如权利要求19所述的计算机可读介质，其特征在于，鉴别的可编程实体有多个状态，其中只有补丁状态信息指定了的一个适合的状态子集才修改，并且其中接收的鉴别补丁包没有包含有关补丁状态信息未指定修改的已鉴别可编程实体的状态的信息。

21.一个或多个共同存储补丁表格数据结构的计算机存储器，包含多个补丁条目，每个补丁条目包括：

补丁应用信息，识别补丁要对其应用该补丁的已鉴别的可编程实体的鉴别部分；和

补丁状态信息，指定修改已鉴别可编程实体的鉴别部分的状态的一种方式，这样，对一个特定的补丁实体来说，该补丁实体的内容可以以所指定的方式用于修改已鉴别可编程实体的可鉴别部分的状态。

22.如权利要求21所述的计算机存储器，其特征在于，补丁应用信息识别了一个与可编程实体相关的可执行模块。

23.如权利要求22所述的计算机存储器，其特征在于，补丁应用信息识别了一个在识别的可执行模块中的位置。

24.如权利要求23所述的计算机存储器，其特征在于，补丁应用信息进一步识别希望在识别的可执行模块内识别的位置的内容。

25.如权利要求21所述的计算机存储器，其特征在于，选择的补丁条目包括多个补丁应用信息情况，每个情况识别不同版本的已鉴别可编程实体的鉴别部分。

26.如权利要求25所述的计算机存储器，其特征在于补丁应用信息情况的第一种情况是识别其中已经应用一个选择的热修补的一个已鉴别可编程实体的版本，而补丁应用信息情况的第二种情况是识别其中未应用所选择的热修补的一个已鉴别可编程实体的版本。

27.如权利要求26所述的方法，其特征在于，选择的补丁条目可以应用于(1)选择的热修补已经应用的已鉴别可编程实体的版本，(2)选择的热修补未应用的已鉴别可编程实体的版本，或(3)两者都有，但没有用选择的热修补未应用的已鉴别可编程实体的版本来取代选择的热修补已经应用的已鉴别可编程实体的版本，而且没有用选择的热修补已经应用的已鉴别可编程实体的版本来取代选择的热修补未应用的已鉴别可编程实体的版本。

28.如权利要求24所述的方法，其特征在于，选择的补丁条目可被管理员配置到一个目标计算机系统而无需考虑哪个版本的已鉴别可编程实体在目标计算机系统上执行。

29.如权利要求21所述的计算机存储器，其特征在于，选择的补丁条目的补丁状态信息包含对修改已鉴别的可编程实体的鉴别部分的状态有用的代码。

30.如权利要求21所述的计算机存储器，其特征在于，选择的补丁条目的补丁状态信息包含对修改已鉴别的可编程实体的鉴别部分的状态有用的数据。

31.如权利要求21所述的计算机存储器，其特征在于，选择的补丁条目的补丁状态信息指定了对应用于与已鉴别的可编程实体有关的指定参数的参数变量测试。

32.如权利要求21所述的计算机存储器，其特征在于，存储在补丁表格数据结构内的计算机存储器的特性是可配置的。

33.如权利要求21所述的计算机存储器，其特征在于，计算机存储器直接连接到应用一个或多个补丁条目的计算机系统。

34.如权利要求21所述的计算机存储器，其特征在于，计算机存储器直接连接到没有应用任何补丁条目的计算机系统。

35.一个自动实现接收的代码补丁的计算系统，包括：

一个预先安装的帮助函数的库；和

一个接收代码补丁的打补丁代理，每个代码补丁对应一组可执行模块并识别库中的帮助函数，并且，当接收代码补丁对应的一组中的一个可执行模块被执行时，调用由对应于包含该可执行模块的可执行模块组的代码补丁所识别的帮助函数以执行值确认呢。

36.如权利要求35所述的计算系统，其特征在于，打补丁代理包括一个库维持子系统，用于接收新参数确认函数并自动将接收的新参数确认函数增加到该库，这样这些新的主要的确认函数可参照识别它们的代码补丁被调用。

37.一种在计算系统内用于自动应用软件补丁的方法，包括：

在计算系统内接收用于修改可编程实体的状态的补丁，该补丁(1)指定一种修改可编程实体状态的方式，和(2)为多个版本的可编程实体的每一个版本，(a)识别可编程实体的版本，(b)在可编程实体的版本内确定一个位置以用指定的方式修改可编程实体的状态，和(c)在可编程实体的状态被修改之前，识别希望存在于可编程实体版本内指定位置的代码；

自动确定该补丁所识别的可编程实体的版本中的可编程实体的可鉴别版本是否安装在所述计算系统上；并且

仅当为可编程实体的可鉴别版本所指定的位置包含希望存在于指定位置的识别代码时，参照该补丁在为可编程实体的鉴别版本指定的位置上修改可编程实体的状态。

38.一种计算机可读介质，其内容导致计算系统为自动应用软件补丁而执行一种方法，所述方法包括：

在计算系统内存储一个补丁用于修改可编程实体的状态，该补丁(1)指定修改可编程实体状态的方式，并且(2)为多个版本的可编程实体的每个版本，(a)标识可编程实体的版本，(b)在可编程实体版本内指定一个位置以用指定的方式修改可编程实体的状态，并(c)在可编程实体的状态被修改之前，标识希望存储在可编程实体的版本内的指定位置上的代码；

自动确定该补丁所识别的可编程实体的版本中的可编程实体的可鉴别版本是否安装在所述计算系统上；和

仅当为可编程实体的鉴别版本指定的位置包含希望存储在指定位置的代码时，参照该补丁在为可编程实体的鉴别版本指定的位置修改可编程实体的状态。

Images