ActivePatch Release Notes

ActivePatch 1.2 Build 1240

  • Because self-registering COM libraries and ActiveX controls can potentially be used to execute arbitrary code on the target system, the ApplyPackage function will no longer automatically register components included in the package. A new option named PACKAGE_OPTION_REGISTER_COMPONENTS has been added which instructs the ApplyPackage function to register any components after the package has been applied. Note that this option must be explicitly specified when applying the package; it cannot be used as a default option when the package is created.
  • Corrected a problem where CreatePackage would fail with an error that indicated there were no modified files if the Indexing Service was disabled on Windows XP.
  • Corrected a problem where ApplyPackage could fail if the the option PACKAGE_OPTION_FIND_FILE was specified and the target file was moved to a subdirectory of the target directory.
  • Corrected a problem where CreatePackage would fail with the error AP_ERROR_INVALID_CONTEXT if a password was specified. If no password was specified, the package would be created correctly.
  • Corrected a problem where an invalid package could be created if a reference directory was not specified.
  • Added the PACKAGE_FILE_PLATFORM_WIN2003 identifier for explicit support of patches and/or patch packages applied to the Windows Server 2003 platform.

Version 1.2 Build 1230

  • Corrected a problem where the header for a package file would be updated whenever it was closed, even though the package itself had not been modified. This could result in an error if the user applying the package did not have the appropriate permissions to modify the package file.
  • If the package file has the read-only attribute set, the package will be automatically opened in read-only mode. This prevents an unexpected error that can occur when an application attempts to modify a package file that is not writable.
  • Corrected a problem that could prevent the ActivePatch control from loading correctly in Access 97 or other ActiveX containers which required the implementation of the stock Enabled property.
  • Corrected a problem with Unicode versions of the ActivePatch API which could cause an application to terminate abnormally.
  • Corrected a problem where files with long file names were not replaced if they were in use (locked) at the time that a package was being installed. This only affected Windows 95/98/ME platforms.
  • When the CreatePackage or UpdatePackage functions were called without a reference directory being specified, the function would fail with AP_ERROR_INVALID_FILE_PATH instead of storing them in the package. This also affected the Create and Update methods in the ActiveX component.
  • When the PACKAGE_OPTION_OVERWRITE or PACKAGE_OPTION_IGNORE_READONLY options were specified when applying a package, and one or more of the target files had the read-only attribute set, the package application could either fail, or return a status indicating that the system needed to be rebooted in order to complete the update even though the file was not locked by another process.

Version 1.2 Build 1220

  • Corrected an error that would prevent a patch from being applied correctly under certain cases where the options to ignore the target file timestamp or attributes were specified.
  • Corrected a problem where specifying a password would prevent patch files from being applied; the error "The specified file contains an invalid header block" would be returned.
  • Corrected a problem that could occur when a package was created where files were only being stored and replaced, rather than patched
  • Corrected a problem when applying a package which could result in an error that the operation was canceled, even though the user had not actually canceled it.
  • Corrected several problems with the samples that would cause errors to be displayed when loading and/or compiling some of the projects.

Version 1.2 Build 1210

  • Added two new methods to the PatchFile and Package ActiveX controls called Initialize and Uninitialize. These methods are primarily designed for scripting languages such as VBScript and normally do not need to be called. The Initialize method is used to initialize the control with a runtime license key. The Uninitialize method will close any open patch files or packages, release memory that has been allocated and and resets the internal state of the control.
  • Closing a package inside the Progress event will now cancel the current operation, and an error will be returned to the caller. Note that this is not recommended; the Cancel method should be called, and when it returns to the caller with an error indicating the operation has been canceled, the package can be closed. Uninitializing or unloading the control in the middle of an operation, such as applying a package, may prevent the control from performing certain cleanup functions such as deleting temporary files.
  • Corrected a problem where the package file collection was not being released when the package was closed.
  • Corrected a problem when applying packages where the option to ignore missing files was specified.
  • Corrected a problem when applying packages that contained multiple versions of a target file.

Version 1.2 Build 1200

  • Modified patch generation and compression routines to reduce the overall size of patch files and packages. Implemented a new patch file format which reduces overhead for patches that contain a large number of change records. Existing patch files and packages can be used by the current version, but previous versions of the product will not be able to read the new format.
  • Corrected a problem where package options were not propagated to individual patch files created when building a package. This could potentially cause the application of a package to fail because the correct options were not being specified at the time the patch was being applied.
  • Corrected a problem where the Options property in the Package control was not being updated when a package was opened, and setting the property only worked when creating new packages. When a package is opened, the Options property is now set to that package's current options. Setting the property while a package is open will change the options for that package. Setting the property when there is no open package will change the default options used when a package is created.
  • The CreatePatchFile, CreatePackage and SetPackageOptions functions will now ignore the PACKAGE_OPTION_NOUPDATE option if it is specified. This option is only valid when applying a patch file or package.
  • Corrected a problem where PACKAGE_OPTION_NOUPDATE would indicate that the specific package could be applied successfully, but would fail when actually applied. This option now provides more extensive validation of the package and the patches that it contains.
  • Corrected a problem where the compression ratio for a patch file would be returned as a very large number. This affected both the values returned in the PATCH_FILE_INFORMATION structure as well as the Compression property for the PackageFile object.
  • Corrected a problem where temporary files could be left in the installation or system temporary directory when the application process failed or was canceled.
  • Corrected a problem where an error would be returned when attempting to access certain properties of the control in a scripting environment, such as the Windows Scripting Host.
  • The error AP_ERROR_INVALID_PATCH_LEVEL is returned if an invalid patch level is specified when creating a patch file. Patch levels must be between 1 and 9, defined as PATCH_LEVEL_MINIMUM and PATCH_LEVEL_MAXIMUM. Patch level 0 is a special value which specifies a default patch level that has the best balance between patch size and patch generation speed. This patch level is defined as PATCH_LEVEL_DEFAULT and corresponds to patch level 4.

Version 1.1 Build 1100

  • Corrects a problem with progress events not firing correctly, under some circumstances, or the percentage values being incorrect as a package is created or applied.
  • Corrects a problem with locked files on Windows 95/98, where in some cases the files would not be replaced after the system was restarted.
  • Corrects a problem where a locked file could cause the library or control to search for another matching file on the local system (as if the locked file did not exist).
  • Adds three new methods to the Package control. Open, which explicitly opens a package (rather than using the side-effect of setting the FileName and Password properties, although this can still be done); Close which explicitly closes a package; Flush which forces any changes to the package to be written to disk.
  • Adds a new property to the Package control called Applied; if this value is zero, the package has not been applied on the local system; if the value is non-zero, the package has been applied and the actual value specifies one or more bitfields (1=completed, 2=delayed). This allows your application to determine if any of the updates were delayed because a file was locked. The code would look like this:
    If Package1.Applied And apApplyDelayed Then     MsgBox "You must restart you system ...", vbInformation End If
  • The ApplyPackage syntax has been updated in the DLL so that the reserved parameter is now a pointer to an unsigned long integer which contains status bits that provide information about the package application; this is backwards compatible as long as developers followed the documentation and only specified a value of 0 for the reserved parameter.
  • The PACKAGE_OPTION_NOUPDATE and PATCH_OPTION_NOUPDATE option flags have been added for the ApplyPackage and ApplyPatchFile functions respectively. This allows an application to test the package or patch apply process without modifying any files on the target system. In the case of packages, it can be combined with the apply status to determine if applying a package would potentially require the user to reboot the system.
  • The PACKAGE_OPTION_IGNORE_MODIFIED option flag has been added for the ApplyPackage function. This specifies that ApplyPackage should not return an error if it determines that a target file has been modified. Instead, it ignores the file and processes the next update in the package. This option should be used with caution, since it explicitly bypasses the an integrity check that makes sure that each target file is identical to the original version of the file at the time that the package was created. Inappropriate use of this flag can potentially leave a target system in a "half-patched" state.
  • A new FlushPackage function has been added which corresponds to the control's Flush method.
  • A new error code AP_ERROR_FILE_LOCKED has been added which is more explicit than the more general access denied error; a problem where the AP_ERROR_FILE_NOT_FOUND error may be returned for a locked file has also been corrected.
  • A number of changes to declarations, error messages and other cosmetic modifications which do not affect the core functionality of the library or controls.