Setting up Machine A (the Client Machine)

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:

  1. Copy the 
    Regsvr32.exe
     program over to 
    \Windows\System
     directory if it's not already there.

  2. Copy the 
    Vccalc1.ocx
     file to the 
    \Windows\System
     directory.

  3. Copy the support files for 
    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
    .

  4. Run 
    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:

  1. Copy the ATL support DLL, 
    atl.dll
    , over to 
    \Windows\System
     directory.

  2. Run 
    regsvr32 atl.dll
    .

  3. Copy the 
    ATLFinder.exe
     file over to a temporary directory.

  4. Run 
    ATLFinder /RegServer
     to create the registry entries.

  5. Remove the 
    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.

© 1997 by Wrox Press. All rights reserved.