RTPatch Since Version 3.10

Over the last 20+ years, Pocket Soft has continued to improve the efficiency, flexibility, and reliability of RTPatch for Windows. With each release, we have striven to meet the changing needs of our customers, and our customers' customers. If you have an older version of RTPatch, then take a look at all of the functionality that an upgrade would provide. And don't forget to see the latest release offering on the What's New page.

New features and functionality have been added in:

Version 12.00

  1. Build command, PATCHFORMAT, enables you to build a patch file with the latest version of RTPatch Build, and apply the patch with any version of Patch Apply, back to version 3.20 (released in 1996). Previously, the Apply engine had to be of equal or greater version than the Build engine used to create the patch.
  2. Build command, DELDIRONMT, instructs RTPatch to delete a folder that is made empty by the patch apply process.
  3. Build command, SELFREGWARNINGS, enables you to turn on warnings, on a per-file basis, in the event that self-registration fails.
  4. Support for split patch files that is not disk-dependent. Support included in Apply API, EZPatch and Auto RTPatch.
  5. A generic utility is provided to “unsign” a code-signed file.
  6. Apply option, -ODISABLEWARNING:, enables you to disable specified warning numbers from being issued.
  7. New RTPatchApply32 callback Id, 0x23, provides percent complete on file commit operations when UNDO is used. When patching thousands of files, this operation can be time-consuming. The new callback permits greater user feedback during this step.
  8. DefaultToCancel option in EZPatch enables you to specify a list of warning numbers that will present to the user with “Cancel” as the default button selection.
  9. Auto RTPatch callback, 0x1020, indicates what the updated version number will be if the pending update succeeds.
  10. Auto RTPatch supports in-house “test” code-signing certificates
  11. Auto RTPatch supports https, and the ability to override the https port.
  12. Auto RTPatch includes a download-resume capability, when used with the new split patch file support.
  13. Auto RTPatch supports file:/// syntax
  14. Auto RTPatch includes a new setting, Mirror, that enables you to specify an alternate Url for your update in case the primary Url is unreachable.
  15. Auto RTPatch supports authenticated proxies.

Version 11.00

  1. Utilizing a technique described by Microsoft on MSDN, RTPatch 11 introduces a new Windows Service, called the "RTPatch File I/O Service," to assist in patching files under User Account Control. Once installed by a user with appropriate privileges (a member of the Administrator group), the RTPatch File I/O Service passively runs under the LocalSystem account, consuming no CPU cycles. When a patch is applied, patchw32.dll automatically detects if the process has Administrator level rights, and if not, and the RTPatch File I/O Service is installed and running, RTPatch will request that the patch file be applied by the Service. Under Windows Vista with UAC activated, for example, this will permit modification of the Program Files directory as well as the HKEY_LOCAL_MACHINE hive, without elevation of the calling process to Administrator.
  2. A new command, NOSEARCHROOT, disables RTPatch Apply's automatic search of the root of the Apply directory for any files to modify. Previously, RTPatch searching would default to the update directory, the "expected" subdirectory, and any directory listed on the user's PATH. The latter two (subdirectories and PATH) could be disabled, but searching the root of the update directory could not. NOSEARCHROOT disables this search when needed.
  3. The RTPatch Apply file I/O buffer size has been increased, which improves the speed of the Apply process by up to 20% in cases of numerous sequential file reads/writes.
  4. The Auto RTPatch client DLL API now generates a new callback ID of 0x1019 providing the path to the fully downloaded RTP file, in case the calling application would like to cache the file for later use.
  5. When applying an EXE-style MSP patch created by RTPatch for Windows Installer, new command line flag -w instructs the EXE to return the return code of the MSI API call (primarily MsiConfigureProductEx), rather than the internal RTPatch error code.
  6. New command ADDDEPTH instructs RTPatch to only add a file if a specified level of parent directories already exist for the intended add location of the file. This is used to conditionally add files to existing locations, but ignore the new file if its expected directory (or parent directory) is not already present on the user's machine.
  7. .The Auto RTPatch schedule now works with the HKEY_CURRENT_USER hive, in addition to the HKEY_LOCAL_MACHINE hive. Previously, only the HKEY_LOCAL_MACHINE hive was used, which caused no problems when the Auto RTPatch Scheduler was run as a service, but could fail if executed as a standard (non-service) process. Adding support for HKEY_CURRENT_USER enables the Auto RTPatch Scheduler to run as a normal process without the need for Administrator rights.
  8. The byte-handling commands (IGNOREBYTES, READBYTES, RETAINBYTES) now work with wildcard FILE specifications. Previously, a separate BEGINFILE/ENDFILE block was required for each file that used byte-handling features.

Version 10.50

  1. To expand on existing Windows Vista support added in version 10.00, version 10.50 adds application manifests to all RTPatch executables with the requestedExecutionLevel set to "AsInvoker." In most cases, this will result in non-admin rights, enabling RTPatch executables to run without requiring an Administrator password. In previous versions of RTPatch, the User Access Control (UAC) feature of Windows Vista would determine that any RTPatch or RTPatch-generated executable required Administrative rights, even if it did not perform Administrative actions. This is due to the "Installer Heuristic" feature of UAC. All RTPatch executables can still be granted Administrator rights using Windows Vista options. This change is by the request of the majority of RTPatch users.
  2. New EZPatch command, RequireAdmin enables the patch builder to indicate that a patch EXE should request Administrator rights at startup when executing under UAC on Windows Vista. By default, all RTPatch-generated executables will not request Administrator rights at startup. If, however, the RTPatch developer is creating a patch that will modify resources that require Administrator rights (e.g., the Windows, System or Program Files directories, or the HKEY_LOCAL_MACHINE registry hive), then the RequireAdmin command should be used.
  3. All RTPatch utilities are now digitally signed in anticipation of stricter requirements in upcoming releases of the Vista operating system. EZPatch executables have supported code signing since version 8.00.
  4. New error code 49, "This RTPatch upgrade requires Administrative rights. Please rerun with the 'Run as administrator' option," provides more meaningful feedback to Windows Vista end-users who encounter problems applying patches with UAC enabled.
  5. Since Windows Vista does not support Windows Help Format (HLP files), RTPatch documentation is now provided in compiled HTML format (CHM).

Version 10.00

  1. Version 10 of RTPatch expands 64-bit support in RTPatch for AMD64 and EM64T technology by introducing a native Win64 Build option. The new 64-bit Build option creates compatible patch files with the Win32 Build/Apply options. The only difference is the underlying hardware support. With version 10, RTPatch now offers native Win64 Build and Apply solutions. RTPatch's 64-bit support now includes:
    • Native Mode: Version 10 RTPatch introduces native 64-bit support for RTPatch Build (64-bit native mode for RTPatch Apply was introduced in RTPatch version 9). A new 64-bit EXE, pbld-v64.exe will only run on x64 Edition Windows operating systems, but will create patches that can be applied on any support Windows OS, including Windows 9x/Me, Windows NT/2000/XP, DOS, Windows (16-bit). (Enterprise Edition Only)
    • Legacy Mode: 32-bit RTPatch Build and Apply executes under a 32-bit Windows OS running on AMD64 or EM64T.
    • Compatibility Mode: 32-bit RTPatch Build and Apply executes under Windows x64 Editions, under the WOW64 architecture.
  2. New RTPatch Build commands, RFILE, RIGNORE, RNEWIGNORE and ROLDIGNORE greatly simplify the patch building process when trying to assign options to an entire directory tree, including subdirectories. Previously, it was necessary to include separate commands for each directory and subdirectory thereof. In cases of complex directory trees, this was a time consuming and tedious process. The new recursive file commands make it easy to replace all of those individual commands with a single command.
  3. History patch file can now be imported into new history patch files. Previously, you could only import version-to-version patches. The ability to import a history patch into another history patch makes it even easier for developers to maintain patch files and quickly support new versions.
  4. The RTPatch Build Wizard is now more integrated with the Build process, enabling Build Wizard users to have more interactive control of the Build process and more easily see the progress and operations undertaken by the Wizard.
  5. RTPatch for Windows Installer log files have been enhanced to provide more detail, including patch file size and percent reduction. This helps to spot possible inefficiencies and improve overall patch file size. (Enterprise Edition Only)
  6. The default algorithm settings have been changed so that the smallest possible patch files are attempted without special instructions.
  7. The Build Wizard now accepts options to create hidden EZPatch executables (no dialog shown to the end-user) as well as the ALLOWDUPLICATES command. This enables Build Wizard users to more easily set these options without having to type in "verbatim" commands, thereby simplifying the Build process.

Version 9.00

  1. Pocket Soft has tested and supports all 32-bit applications in version 9 running under the WOW64 architecture. Specifically, both 32-bit RTPatch Build and Apply are supported under legacy and compatibility mode:
    • Legacy Mode: 32-bit RTPatch build executes under a 32-bit Windows OS running on AMD64 or EM64T.
    • Compatibility Mode: 32-bit RTPatch Build executes under Windows x64 Editions, under the WOW64 architecture.
  2. 32-bit RTPatch Apply introduces "64-bit extensions" enabling access to the 64-bit registry from within the RTPatch registry scripting language. For example, assume that you are running 32-bit RTPatch in Compatibility Mode on Windows XP x64 Edition and you need to copy or access data from the 64-bit registry. Without 64-bit extensions, you would need to write a custom utility since only the 32-bit registry would be available to the 32-bit Engine. 64-bit Extensions make it easy to access both the 32-bit and 64-bit registries from RTPatch registry scripts, ROOTKEYs, SYSTEMKEYs, etc. Access to the 32-bit registry is also possible from the native 64-bit Apply engines.
  3. New macros for RTPatch Build command files and registry scripts compute the 64-bit and 32-bit System folders (e.g., the Windows and System folders, or the SysWow64 folder). This helps to enable the creation of patch files that can modify one or both of the System folder of a 64-bit system without complicated custom actions.
  4. A new RTPatch Build command, IGNORECKSUM, makes it possible to force a file delete regardless of the target file's checksum. For example, assume that you have an INI file that is customized for each end-user, but is now obsolete and needs to be deleted, IGNORECKSUM makes this possible without having to resort to custom actions. This command has no effect on MODIFY, RENAME and ADD patches.
  5. New EZPatch option, NoDelayCopy, makes it possible to disable delayed copy support with EZPatch self-applying patch executables. Previously, this command was only available for customers writing custom front-ends.
  6. Version 9 RTPatch introduces native 64-bit support for RTPatch Apply on Windows x64 Edition operating systems (AMD64 and EM64T). A new 64-bit DLL, patchw64.dll can be accessed from a custom application, from the supplied Win64 console front-end, or through the new native 64-bit EZPatch options (self-applying 64-bit EXE patch files). (Enterprise Edition Only)

Version 8.10

  1. New Build command, ADDONCHANGE, makes it easy to include full ADD patch entries for files whose new version is different than the supplied old version. Especially useful for files that are frequently modified by the end-user, but the Builder only wants to include ADD patches if the file has changed from the previous release. Prior to ADDONCHANGE, this was a tedious manual process.
  2. EZPatch executables now accept the command line parameter "-q" to suppress the display of Welcome/Success message boxes. This can be useful for testing in an interface restricted environment, for example.
  3. New Apply API Entry, RTPatchGetCost, returns the disk space requirements of a patch file as well as the number of patch file entries that the patch file includes. This can be especially useful for advanced users who have written their own front-end to the RTPatch Apply engine. RTPatchGetCost enables RTPatch developers to determine the needs of the patch file without having to apply the patch, so decisions such as using BACKUP and UNDO can be made on a space-available basis. (Enterprise Edition Only)
  4. New Entry Point in RTPatch Interface DLL, rtpcb32.dll, enables the caller to specify a password to minimize user interface requirements. Previously, there was no way to provide a password other than to have the end-user do it interactively. Password protection helps RTPatch developers make sure that patch files are only applied through the approved custom front-end they have provided. (Enterprise Edition Only)
  5. Executable-style updates created through the "RTPatch for Windows Installer" subsystem now accept some command-line options. Notable, the "-q" switch, which controls the amount of user interaction permissible, and the -r switch to control reboot behavior. (Enterprise Edition Only)

Version 8.00

  1. RTPatch Build command NOAUTOMATCH makes it easy to build patch files that will recreate the new system exactly. Previously, RTPatch would automatically match-up files that had moved location from the old system (OLDDIR) to the new system (NEWDIR). Usually this is the desired behavior since it results in the smallest possible patch file. Occasionally, it may be necessary to recreate the NEWDIR exactly. NOAUTOMATCH causes RTPatch to treat a moved file as a DELETE/ADD patch, rather than a MODIFY patch.
  2. Build command RECURSIVE causes RTPatch Apply to recursively apply a patch file entry until no valid target (old) files are located. This feature enables RTPatch developers to create minimal sized patch files when they need to patch multiple instances of an identical file.
  3. Registry scripting language now automatically supports the renaming of Volatile registry key entries.
  4. The ALLOWBIND command has been improved to better identify the automatic ignore regions of bound executables.
  5. Two new pbind.exe script commands, FileProgressColor and OverallProgressColor, allow the Patch Creator to specify the color of the Progress bars that display the overall and file-level progress of the patch process. Previously, there was no method to override the default progress colors (red).
  6. EZPatch supports enhanced color support for all Color-specific commands (including FileProgressColor and OverallProgressColor). Previously, only a handful of preset color codes were possible (e.g., red, blue, cyan, etc.). In addition to the preset format, you may now specify an RBG value in the form 0x######.
  7. EZPatch now supports code-signing of executables. Previously, the executable would be corrupted by code-signing (e.g., Authenticode). Code-signed executables are now supported automatically.
  8. The Auto RTPatch scheduler now accepts the "-a" switch. This switch causes Auto RTPatch to suppress the final "Finish" dialog box, which may be desirable if you are launching an executable after a forced upgrade (via the -e switch). Previously, the user had to click a "Finish" dialog box after the upgrade to dismiss the Auto RTPatch window. (Enterprise Edition Only)
  9. In RTPatch for Windows Installer, support for patching in the Global Assembly Cache has been added. Microsoft's Windows Installer 2.0 and less does not support patching the GAC. RTPatch now includes workarounds that enable seamless patching of the GAC. Support is automatic, so the patch builder does not have to do anything to utilize this feature. (Enterprise Edition Only)
  10. A new global log file option makes it even easier to create a log of the MSP patch apply process. Enhanced control of the log file creation makes it easy to specify the location of the log file (e.g., Windows folder, temporary MSI folder, application install folder).
  11. In RTPatch for Windows Installer, improved InstallScript workarounds enable the patching of MSI installs that were created with dependency on setup.exe. (Enterprise Edition Only)
  12. Improved error handling and documentation makes it easier for patch builders to isolate problems and identify solutions in the Windows Installer module. (Enterprise Edition Only)
  13. In RTPatch for Windows Installer, MSP GUIDs may now be specified by the patch builder. Automatic GUID generation is still available in cases where this is not needed. (Enterprise Edition Only)
  14. RTPatch for Windows Installer projects can now be easily transferred across machines. (Enterprise Edition Only)
  15. In RTPatch for Windows Installer, MSI installations that are part of a project may now be modified without having to delete and re-add the install. (Enterprise Edition Only)
  16. Any version of an RTPatch for Windows Installer project may now be removed. Previously only the oldest version of a project could be removed. (Enterprise Edition Only)
  17. Executable upgrades in the Windows Installer module (MSP delivered as an EXE) now accept a "/q" switch on the command line. The /q switch format is identical to msiexec's /q switch (see MSDN documentation for details). (Enterprise Edition Only)
  18. New Build command MEMBERSHIP allows RTPatch developers to assign membership groups to files and then conditionally apply groups of files at apply time. This can be particularly useful in cases where you need to distribute a single patch file that will be applied to two or more types of target installations. Previously, the only way to apply a piece of a patch file was to use the -file command line switch. MEMBERSHIP behaves similarly to the -file switch, but can be used to apply an entire group of files that were defined at Build time. (Enterprise Edition Only)
  19. The Visual Basic example has been enhanced to provide example code for more callback IDs. (Enterprise Edition Only)
  20. A new pbind.exe script command, InstallDLL, makes it easy to copy the RTPatch Apply Engine to the Windows directory of the target machine. This new pbind.exe command can be used to reduce the subsequent overhead of patch files by installing the RTPatch Apply DLL the first time an RTPatch is sent (or if you need to upgrade an existing engine). InstallDLL is version-safe - it will not overwrite a dll with a greater version number. Note: InstallDLL will only install the 32-bit RTPatch Apply Engine (patchw32.dll) that is included in the executable via the IncludeDLL command. (Enterprise Edition Only)

Version 7.00

  1. New BUILD command IGNOREDIRINFO makes it easier to organize files in the build directory without affecting the location used to locate/add files at apply time.
  2. Patch APPLY execution hooks (DOAFTER, DOAFTERALL, DOBEFORE, DOBEFOREALL), may [optionally] be configured to abort the patch process based on the return value of the hook.
  3. Windows Installer support module. This feature is a major addition to the existing RTPatch options available to patch builders. The technology added for RTPWI incorporates RTPatch BUILD into Windows Installer style patch files (MSP).

Version 6.5

  1. BUILD command, MAINTENANCE, gives patch creators a way to easily add and extract information on which patch files have been applied to a user's system.
  2. Registry Scripting macros give easy access to RTPatch values such as the Target Directory, Backup Directory, and more.
  3. Use the RecycleBin rather than deleting old files after patching.
  4. BUILD command, UPDATETIMESTAMP, gives patch creators greater control over the update of files' date and time stamps.
  5. Use TEMPDIR specification to control the location of temporary files during the application of a patch.
  6. Global pre and post execution hooks, DOBEFOREALL and DOAFTERALL, expand $ to the full path to the current patch file.
  7. Delayed patching support may be disabled.
  8. Expanded Registry hive support for ROOTKEY/SYSTEMKEY
  9. EZPatch includes a log file option.
  10. Main EZPatch window may be hidden.
  11. Expanded MSI Support
  12. Splash or background image (BMP) may be specified with EZPatch executables.
  13. Netscape 6 support added to Web RTPatch. (Enterprise Edition Only)
  14. Web RTPatch script parameters make it easy to redirect the web browser upon error, success or cancellation of the patch application. (Enterprise Edition Only)
  15. Web RTPatch supports multiple safe controls on a single page. (Enterprise Edition Only)
  16. Sample shows how to use patch apply DLL from VB.Net. (Enterprise Edition Only)
  17. Sample project allows developers to quickly build a working custom front-end for use with EZPatch's custom interface option. (Enterprise Edition Only)
  18. Cross-platform support in patch files allows Win32 patch applier to apply UNIX style patch files created with RTPatch Professional for UNIX. (Enterprise Edition Only)
  19. API callbacks give developers greater control over patching and delayed copy support. (Enterprise Edition Only)
  20. Interface module, rtp32cb.dll, accepts option for automatic creation of a patch apply log file. (Enterprise Edition Only)

Version 6

  1. Support added for patching software installed with Windows Installer (formerly MSI, Microsoft Installer).
  2. Improved patch creation wizard supports creation of EZPatch executables.
  3. Auto RTPatch offers self-updating software technology as a stand-alone, or built-in option for software updates. (Enterprise Edition Only)
  4. Web RTPatch included with all licenses (previously, it was a paid add-on). (Enterprise Edition Only)
  5. All interface strings moved to resources to facilitate easier customization and internationalization. (Enterprise Edition Only)
  6. Support files and sample projects introduced for applying patch files through PowerBuilder and Visual FoxPro. (Enterprise Edition Only)

Version 5.20

  1. New build command allows you to run a registry script before any patching is attempted. This allows you to make any modifications required prior to the evaluation of the ROOTKEY or any SYSTEMKEYS, which use the registry to identify file locations.
  2. New command SELFREG eases a common task on Win32 platforms. SELFREG may be used to identify that a file is self-registering and should be handled accordingly during the addition (register), deletion (unregister), or modification (unregister old, register new) of a file.
  3. New command SHAREDFILE adds support for shared files on Win32 platforms. When using the SHAREDFILE command with a DELETE patch, RTPatch will decrement the shared reference count and only delete the file if the count equals zero. When adding a file marked shared, RTPatch will increment the shared reference count (setting it to two if the file existed with no count prior to the ADD).
  4. Support for NEW Web RTPatch. (Enterprise Edition Only)

Version 5.10

  1. New system support enables easy, platform-independent location of the Windows and System directories. This simplifies the process of adding, deleting or modifying files that are located in these directories.
  2. Support for icon specification in compressed EZPatch executables.
  3. New patch apply console application added that operates solely with ANSI character set. (Enterprise Edition Only)

Version 5.00

  1. Open-file patching support introduced.
  2. Registry/INI specifications may now be used to identify an apply directory, or a system of files to patch. Any number of systems may be included in a single patch file.
  3. A flexible registry scripting language has been added. With this scripting language you may add, modify, delete, compare and manipulate the registry of the apply system.
  4. New searchall command instructs RTPatch Apply to search all local hard disks when looking for a system tag file. A system tag is a file whose location on the target machine indicates the apply directory for a system of files.
  5. New global pre and post apply execution hooks allow you to run external commands or executables before any patching is attempted, or after all patching is complete.
  6. New apply APIs add a No CallBack apply entry point as well as file handling impersonation calls. The former simplifies the incorporation of patching into scenarios where user feedback is not required. The latter allows patch appliers to work in environments where special file handling (e.g., for security purposes) is required. (Enterprise Edition Only)
  7. New example projects are provided for Delphi and Visual Basic. (Enterprise Edition Only)
  8. A new interface module simplifies incorporating RTPatch apply into an InstallShield setup. (Enterprise Edition Only)

Version 4.11

  1. Seamless support for files that have been "bound" on 32-bit Windows machines.
  2. Support for 16-bit (Unicode) filenames and paths.
  3. Support for 16-bit (Unicode) directives in a patch build command file
  4. New command INPLACE introduced. Used to identify a target directory system that should exactly mirror the development directory structure.
  5. New build command UNIQUE aids in the automation of patch building by producing a unique patch file each time patchbld.exe is executed.
  6. Universal Naming Convention (UNC) now supported in both patch build and patch apply.

Version 4.00

  1. The build and apply speed of RTPatch Professional has been dramatically improved with version 4.00 (Win32 executables only). Patches built with the Win32 executables are also significantly smaller than patches built with (or patches built with the DOS-based patch builders). The new patch building algorithm uses memory much more efficiently (and effectively) than the old algorithm.
  2. There are new SPEED and TYPE commands to control the patch-building process. The SPEED command allows the patch builder to tradeoff build time against patch file size. The SPEED command takes a numeric argument from 0 to 10 with 0 being the slowest (but producing the smallest patches) and 10 being the fastest (but producing the largest patches). The default is "SPEED 1" The TYPE command is used to control the type of patch building algorithm used. Separate algorithms are used for executable and non-executable files. The possible arguments for this command are E, N and A (for Executable, Normal and Auto).
  3. The apply-time execution hooks can now call Windows executables. To execute a Windows (or Win32) application, begin the hook command with an ampersand (&) immediately followed by a fully-qualified executable name. The remainder of the hook command will be passed to this file as a command line.
  4. There are six new pbind commands: OptionFromFile, OptionSet, FileFilters, TagFilters, FullPaths and Compress.
  5. The system tag locator now looks first in subdirectories of the update directory before it searches the entire disk (to improve performance in a particularly common case).
  6. There are NOPATCHWARNINGS and PATCHWARNINGS commands, which may be used inside file blocks, which turn off warnings at patch time.
  7. Windows NT security information may now be retained at patch time by issuing the ATTRIBUTE SECURITY command at build time.
  8. patchgui, pw32gui and the ezpatch executables now present a standard file browser to the user when unable to locate a system tag (rather than simply asking the user to type in the file location). There is a minor backward-compatible change in the DLL API to support this new feature. (Enterprise Edition Only)

Version 3.20

  1. The EZPatch GUIs have had a Cancel button added to the status window.
  2. A "Silent" option has been added to the pbind utility which forces the EZPatch interfaces not to ask the user for any information unless absolutely necessary.
  3. A "Color=System" command has been added to the pbind utility which causes the EZPatch GUI's to use whatever system color is set on the end-user's machine.
  4. An "IncludeDLL" command has been added to the pbind utility which binds the appropriate DLL into the bound patch file.
  5. The EZPatch Option handling has been enhanced. Option defaults and user permission to change options may be specified when a patch file is bound.
  6. The EZPatch DefaultFile handling has been enhanced. A default directory may be specified also which is where the file location dialog will begin (if the directory is found on the target machine).
  7. You now have the ability to build a custom GUI that includes the appropriate DLL and patch file in a single executable file.
  8. A "NOALLOWSPLIT" command has been added to the patch builders which prevents the resulting patch file from being split across multiple volumes. This was added at the request of several users who wanted patch to give an error when run on an inadvertently truncated patch file, rather than asking for additional disks when in fact there were none. The default is still to allow patch files to be split across multiple volumes, and there are corresponding /ALLOWSPLIT and /NOALLOWSPLIT options to patch which override this behavior.
  9. A "NOTZCHECK" command has been added to the patch builders which prevents patch from checking the hour on any file times that it checks. There have been occasional situations arise in which the user's files have their timestamps off by an integral number of hours as a result of being moved between platforms that maintain local time only and those that maintain GMT with a local time offset. This is especially pronounced just after a Daylight Savings Time change. This switch prevents any such problems from affecting the patch process. There are corresponding /TZCHECK and /NOTZCHECK options to patch which override this behavior.
  10. The Patch Apply GUI Options have been made more flexible. Now, all of the options are 3-state check boxes, allowing the options to be set, cleared or defaulted (that is, use the options set at patch build time). Any options that the user doesn't have the privilege level to change are now silently ignored.
  11. In Patch List mode, the DLLs now provide one callback for each file patch contained in the patch file (in addition to the previous listing text that was provided). (Enterprise Edition Only)
  12. The DLLs now send callback 6 (number of patch file entries). (Enterprise Edition Only)