SocketTools Component Redistribution  
 

The SocketTools license permits the use of the ActiveX controls to build application software and redistribute that software to end-users. There are no restrictions on the number of products in which the controls may be used. However, if SocketTools has been installed with an evaluation license, any products created using its components cannot be redistributed to another system until a licensed copy of the toolkit has been purchased.

System Requirements

SocketTools is supported on Windows 32-bit and 64-bit desktop and server platforms. The minimum required desktop platform is Windows XP with Service Pack 3 (SP3) installed. The minimum required server platform is Windows Server 2003 with Service Pack 2 (SP2) installed. It is recommended that the current service pack be installed for the operating system, along with the latest Windows updates available from Microsoft. Some features may require Windows Vista or later versions of the platform. When this is the case, it will be noted in the documentation.

Earlier versions of the Windows operating system, including Windows 95, Windows 98, Windows Me, Windows NT 4.0 and Windows 2000 are no longer supported by Microsoft. The SocketTools components are designed to require Windows XP as the minimum operating system version and will not work correctly on earlier versions of Windows.

Control Redistribution

For those applications created using the SocketTools ActiveX controls, the control 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 provide 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 automatically register a control when your application is being installed, the installation program must be capable of loading the control and calling specific functions which will update the registry. Most modern installation tools are capable of registering ActiveX controls. For custom installation programs, refer to the article Installing and Registering ActiveX Controls on the Microsoft Developers Network site.

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, the following command would register the FTP control:

C:>regsvr32 c:\windows\system32\csftpax9.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.

User Account Control Warning COM registration requires account elevation under Windows Vista and later versions of the platform because it modifies the system registry. To register controls from the command prompt, you must run it with administrative privileges. From the Start menu, select All Programs > Accessories and right-click on the Command Prompt item. Select "Run as Administrator" from the context menu that is displayed.

If the ActiveX controls are installed on a 64-bit version of Windows, the 32-bit controls, which are used with Visual Basic 6.0 and other 32-bit development tools, are installed in the C:\Windows\Syswow64 folder and the 64-bit controls are installed in the C:\Windows\System32 folder. When redistributing the ActiveX controls, it is important to make sure that you are selecting the correct version, which is determined by the development tool used and the target platform. For example, if you are using Visual Basic 6.0, then you should only redistribute the 32-bit ActiveX controls, regardless if the target system is the 32-bit or 64-bit version of Windows. This is because Visual Basic 6.0 can only create 32-bit programs and therefore can only reference 32-bit controls and libraries. When the application is installed on 64-bit Windows, it will be executed by the WoW64 subsystem which provides a 32-bit environment for the application.

Version Information

The SocketTools controls have embedded information which provides version information to an installation utility. This information, called the version resource, specifies the 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 control, the setup program must determine if it has already been installed on the target system. If it has, it must compare the version resource information in the two files. It should only overwrite the control OCX file 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 file without checking the version number may cause other programs to fail unexpectedly on the end-user's system, which is obviously not desirable.

Installation Directory

The SocketTools ActiveX controls should typically be installed in the \Windows\System32 folder on the local machine. If you are deploying to a 64-bit system, then the 32-bit controls should be installed in the \Windows\Syswow64 folder. Some developers may prefer to install the control along with their application in a private directory. It is not recommended that developers take this approach unless COM redirection or registration-free activation is used 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.

COM redirection enables an application to isolate the controls that it uses, ensuring that the same version of the control which was used to build the application is loaded when the program is executed. To activate COM redirection, create an empty file named after the executable with a .local extension. For example, if the program is named MyProgram.exe then an empty file named MyProgram.exe.local should be created in the same directory as MyApp.exe. This binds the application to the local version of any controls which are installed in the same directory as the application. When an instance of the control is created, Windows will first search the application's directory, and then uses the standard search rules for locating the file.

If your installer package creates a 32-bit executable and you're deploying a 64-bit application, the installer must be capable of detecting that it is running on a 64-bit system and can disable filesystem redirection to ensure that the 64-bit controls are installed and registered in the correct location. Consult the documentation for your installer to determine if it is 64-bit compatible.