The ActivePatch license permits the use of the library and/or control to build and apply patches on both the development system and the end-user system. There are no restrictions on the number of patch or package files which may be created, nor are there any restrictions on the number of products in which the ActivePatch library or control may be used. However, if ActivePatch has been installed with an evaluation license, then patches may only be created and/or applied on the development system. Any products built using ActivePatch cannot be redistributed to another system until a licensed copy of the product has been purchased and registered.

ActivePatch is designed for the 32-bit Windows platform, and is supported on Windows 95, Windows 98, Windows ME, Windows NT 4.0, Windows 2000 and Windows XP. For Windows 95/98 and Windows ME, it is recommended that the system have at least 32 MB of physical memory. For Windows NT 4.0, it is recommended that the system have at least 64 MB of physical memory and it is required that the system have at least Service Pack 5 (SP5) installed. For Windows 2000, it is recommended that the system have at least 128 MB of physical memory and have at least Service Pack 1 (SP1) installed.

For those applications created using the ActivePatch library, the APATCH.DLL file must be distributed along with the application. The library has no external dependencies, other than standard Windows libraries that are part of the base operating system. In particular, the library does not use the Microsoft Foundation Classes library, nor does it use the Visual C Runtime library. If the ActivePatch C++ classes are used, then MFC support is required and must be linked into the application. Note that this is not a requirement for applications written in C or those applications written in C++ which do not use the ActivePatch classes.

For those applications created using the ActivePatch control, the APATCH.OCX file must be distributed along with the application and the control must be registered by the installation program. The process of registration means that specific entries must be created in the system registry which provides information about the control such as the location of the OCX file. Fortunately, ActiveX controls are self-registering which means that the control has the ability to create or update those registry entries itself. To take advantage of this, the installation program must be capable of loading the control and calling those functions inside the control which update the registry. Most modern installation tools are capable of registering ActiveX controls. For in-house setup programs, refer to the technical article on ActiveX Control Registration on the Microsoft Developers Network CD.

It is possible to register ActiveX controls manually without the use of an installation program. This may be desirable in those situations where an application is being deployed internally or the developer does not want to create a setup program for a limited distribution. The tool used to manually register a control is named regsvr32 and can be obtained from a number of places including the Visual Basic or Visual C++ CD-ROM. This utility accepts a command line argument which specifies the name of the control to register. For example:

C:>REGSVR32 C:\WINDOWS\SYSTEM\APATCH.OCX

A message box would be displayed indicating that the control was registered successfully. To prevent the message box from being displayed, use the /S option which tells the utility to function silently. If an error is reported, typically the reason is that a required system DLL is missing or out of date. Note that the above command should reference the system32 directory, instead of system, if being used under Windows NT.

The ActivePatch library and control have information embedded in them which provides version information to an installation utility. This information called the version resource, specifies the library or control's version number among other things. If you are using a third-party or in-house installation program, it is extremely important that the program knows how to use this information.

For example, if you are deploying an application which uses the ActivePatch library, the setup program must determine if that library has already been installed on the target system. If it has, it must compare the version resource information in the two libraries. It should only overwrite the library if the version that you have included with your application is later than the one installed on the system. An installation program which overwrites the library without checking the version number may cause other programs to fail unexpectedly on the end-user's system, which is obviously not desirable.

The ActivePatch library or control should be installed in the system directory on the local machine. Note that under Windows NT/2000/XP, the system32 directory should be used instead since that is where 32-bit controls and support libraries are installed. Some developers may prefer to install the library along with their application in a private directory. While this approach can be used with the ActivePatch library, it should not be used with the control. This is because the full pathname of the control file is stored in the system registry when it's registered. If multiple applications install the same control in different directories, the actual control that will be used is the one that was last registered. This means that it is possible that an application will load an earlier version of the control than it was built with, which may result in unexpected or fatal errors.