Machine A is the client machine with the following software configuration:
On this machine, we'll set up the Aberdeen & Wilshire Calendar ActiveX control. This will require the pre-installation of the Vccalc1.ocx control and required associated files on the client station.
To pre-install the Vccalc1.ocx file on machine A, you may use the following procedure:
Regsvr32.exe program over to \Windows\System directory if it's not already there.Vccalc1.ocx file to the \Windows\System directory.Vccalc1.ocx to the \Windows\System directory (these files can be determined by running DUMPBIN/IMPORTS VCCALC.OCX); you'll also need Mfc42d.dll, Mfco42d.dll, and Msvcrtd.dll.regsvr32 VCCALC1.OCX on the control.
The next thing that you need to do on machine A is set up DCOM class linkage. We know that Vccalc1.ocx will instantiate an ATLFinder object during its operation, therefore we'll need to pre-wire this class (through its class ID) to a remote machine. Recall that we could have indeed hard-coded this into ATLFinder.exe using CoCreateInstanceEx(), but we'll take advantage of DCOM support for legacy applications in our experiment.
The easiest way to do this, again, is with the assistance of the indispensable Oleview.exe utility. Follow these steps:
atl.dll, over to \Windows\System directory.regsvr32 atl.dll.ATLFinder.exe file over to a temporary directory.ATLFinder /RegServer to create the registry entries.ATLFinder.exe.
Running ATLFinder.exe will prepare the registry with information about the ATLFinder object. The actual ATLFinder.exe isn't required on this node, so we remove it after it's completed the job of setting up the registry entries. While ATLFinder adjusted the registry, it also inserted the location of the .EXE file under the \HKEY_CLASSES_ROOT\<clsid>\LocalServer32 key. We need to remove this and point it at the remote machine B. Start up Oleview.exe. Select All Objects on the left pane, and find the ATLFinder1 Class entry and select it. On the right pane, select the Implementation tab. Select the Local Server subtab, and clear out the Path to Implementation edit. This will clear up the associated registry key. Next, select the Activation tab. The pane will look like this:
Select the Launch as Interactive User check box and enter in the IP address of machine B in the Remote Machine Name edit. This tells the DCOM runtime to find a server for the ATLFinder1 class on the remote machine. When DCOM tries to launch the server remotely, the identity used will be that of the currently logged on user in Windows 95.
The Enable ‘At Storage’ Activation setting is specifically used in ActiveX document and/or Moniker binding scenarios where the desired operation is to 'start the object server on the node wherever the persistent data file of the object instance is stored'. This can be a powerful, albeit confusing, mechanism for starting object servers remotely. Essentially, it will allow for the activation of a DCOM object server remotely if the client has a pathname (e.g. \\System5\User\Doe\Mper.dat) to a file containing the persistent data used by the class (in this case, the server will be started on the \\System5 machine). The network filesystem is used as a type of persistent object instance store, and a UNC pathname is used to access and reactivate persisted object instances.
In actual deployment and production scenarios, performing the above setup on every client machine would be impossible. The ideal situation is to have the entire procedure automated when the user reaches a web page containing the Vccal1.ocx. Our earlier discussion of automated code download and installation is a perfect solution for this problem. Thankfully, Microsoft has built the call to the CoGetClassObjectFromURL() helper API into the Internet Explorer, saving us a tremendous amount pain. To deploy using automatic code download and installation, in this case, boils down to the creation of a .CAB file bundling everything together.
A .CAB file contains a compressed archive of one or more files. If the archives contains a .INF file, it will be used as the setup script to install the software component after it's downloaded. The WinVerifyTrust() facility is automatically called to allow the user to deny installation.
Bear in mind, however, even if a .CAB file is used, that DCOM for Windows 95 will still need to be installed at each client workstation before our Vccal1.ocx page would work properly.