ch27.htm

CGI programming is the hottest stuff to look out for in this book

mechanism, and just generally take care of the little details
that always need to happen. Although it's easily possible to make
a meta-setup ActiveX control to exert more direct control over
code downloads, <TT><FONT FACE="Courier">CoGetClassObjectFromURL()</FONT></TT>
saves the effort for people who'd rather not be bothered.
<H4>Permanent Storage</H4>
<P>
One thing you probably noticed from the download mechanism is
that it specifically involves an installation phase. Unlike a
temporary memory or disk cache, as you are probably accustomed
to with browsers, downloaded ActiveX controls are placed into
permanent storage on the machine-from that point on, they are
permanently available elements. This is good and bad because if
there's a huge proliferation of controls out there that you keep
downloading, pretty soon you're going to fill up some serious
space. The good part is, of course, the fact that you now have
something that will kick in when you need it, and you didn't have
to work at all to get it there.
<P>
One of the things Microsoft has pondered is a cache-like tracking
of which things you use and which things you don't. If you download
a control from Company A and use it only that first time and never
again, the caching mechanism might ask if you want to get rid
of that old piece of junk. If you download one and you end up
using it every day, it'll sit right at the top of the &quot;Don't
get rid of me&quot; list. This cache system would definitely help
because the use of ActiveX controls is transparent to end users.
If several different controls from different sources do similar
things, such as animation or audio, you'd have to guess or otherwise
track down which control was used if you wanted to free up some
space. With an automated caching mechanism, the system knows what
control is called and can do the tracking work for you.
<H4>Component Packaging</H4>
<P>
Controls come in all shapes and sizes, and they are also stored
in different formats. Because it'd be silly to have a URL that
pointed to half a dozen different files, the URL in the <TT><FONT FACE="Courier">CODE</FONT></TT>
tag points to one specific file to be downloaded. This doesn't
mean that the one file it's getting is the entire control, however;
it might just be a starting point.
<H5>Packaging Schemes and Methods</H5>
<P>
The three supported methods for sending out controls to the world
at large are as a single file, in a cabinet (CAB) file, or as
a setup script (INF). With initial controls, it is very common
to see single files as the entire target for downloading, but
it won't be long before developers want to make really cool (and
therefore really complex) controls that require more than they
can reasonably fit in one single system file. As a result, they'll
move to packages.
<H6><FONT SIZE=2>Cabinet (CAB) Files</FONT></H6>
<P>
If you've installed Internet Explorer, you've seen cabinet files
in action. After all, IE is just one big ActiveX container, so
it seems like the logical thing to use in its own installation.
Cabinet files are compressed packages of files with a few headers
to define options. They're easy to construct, taking only a few
lines in a text file and requiring the use of a free compression
tool called <TT><FONT FACE="Courier">DIAMOND.EXE</FONT></TT>,
which is included in the Microsoft Internet SDK.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Tip</B></TD></TR>
<TR><TD><BLOCKQUOTE>
Because the CAB file format is non-proprietary, other popular compression and distribution tools could easily decide that they want to make CAB files as well as currently used formats. At the time of writing, the CAB file format had not been made publicly 
available, but you might want to look around to see if what you're using for compression has plans to integrate CAB file support, if it doesn't have it already.</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<P>
The text file that instructs <TT><FONT FACE="Courier">DIAMOND.EXE</FONT></TT>
to create a CAB file is called a directive file, and is specified
with the extension .DDF. The basic format is really quite straightforward
and consists of any option lines and basic settings, followed
by filenames on separate lines. Listing 27.2 shows a sample DDF
file, which would be saved as <TT><FONT FACE="Courier">FOO.DDF</FONT></TT>.
<HR>
<BLOCKQUOTE>
<B>Listing 27.2. A sample DDF file for use in creating CAB file
packages.<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier">; Directive file for FOO.OCX+FOO.INF
<BR>
.OPTION EXPLICIT<BR>
.Set CabinetNameTemplate=FOO1.CAB<BR>
;** The files specified below are stored, compressed, in cabinet
files<BR>
.Set Cabinet=on<BR>
.Set Compress=on<BR>
FOO.INF<BR>
FOO.OCX</FONT></TT>
</BLOCKQUOTE>
<HR>
<P>
Using the <TT><FONT FACE="Courier">FOO.DDF</FONT></TT> file shown
in Listing 27.2, the following command line creates a CAB file
containing the compressed versions of <TT><FONT FACE="Courier">FOO.INF</FONT></TT>
and <TT><FONT FACE="Courier">FOO.OCX</FONT></TT>:
<BLOCKQUOTE>
<TT><FONT FACE="Courier">DIAMOND.EXE /f FOO.DDF<BR>
</FONT></TT>
</BLOCKQUOTE>
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Tip</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
Because the CAB and DDF file formats can change without notice, check on the latest options offered to make sure you're taking advantage of the easiest and most effective way of packaging your controls. Either the ActiveX SDK or any of the sites listed in 
the section &quot;Resources&quot; point you to the most up-to-date information available.</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<P>
Recognizing that not everyone would want to build strangely formatted
files to create a CAB file, Microsoft recently released the CARBARC.EXE
program. This utility turns the creation of CAB files into as
easy a task as creating ZIP files, because all that is necessary
is a command line that specifies the name of the CAB file to be
created and the files to be added. This is just the first of the
myriad of utilities that will perform this function, but just
like PKZIP in MS-DOS preceded Windows-based ZIP utilities, CABARC
is the forerunner of the new compression technology.
<H6><FONT SIZE=2>INF Files</FONT></H6>
<P>
INF files are setup scripts. You've seen them on CDs from various
manufacturers of Windows software, and their purpose in Internet
Component Download is the same as it is for those other programs.
It provides a structured list of information that gives the system
all the information it needs to properly set up and initialize
the software in question.
<P>
Taking an example from the ActiveX SDK and modifying it to fit
the CAB file created previously, you can see what an INF file
might look like as shown in Listing 27.3.
<HR>
<BLOCKQUOTE>
<B>Listing 27.3. Sample INF file for Internet Component Download.
<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier">;Sample INF file for FOO.OCX<BR>
[Add.Code]<BR>
foo.ocx=foo.ocx<BR>
mfc40.dll=mfc40.dll<BR>
<BR>
[foo.ocx]<BR>
; Provides the version and ClassID (clsid) for FOO.OCX<BR>
; If the newer version is needed, specifies that it can<BR>
; be obtained from a specific location, in this case the<BR>
; CAB file created previously.<BR>
file=http://www.wherever.com/foo/foo1.cab<BR>
clsid={9DBAFccF-592F-101B-85CE-00608CEC297B}<BR>
FileVersion=1,0,0,111<BR>
<BR>
[mfc40.dll]<BR>
; Since we'll assume our OCX needs the MFC40.DLL, for the<BR>
; Microsoft Foundation classes, we'll make sure it's on<BR>
; the system. If it's not, the component download will<BR>
; fail,because we've left the 'file=' line blank. This<BR>
; is because we don't want people to be downloading<BR>
; MFC40.DLL if they don't already have it... it's kind<BR>
; of big.<BR>
file=<BR>
FileVersion=4,0,0,5</FONT></TT>
</BLOCKQUOTE>
<HR>
<P>
As you can tell from the INF file, it's possible to check for
file dependencies as part of the download. If you rely on people
having a specific DLL or OCX to get the most use out of your control,
you can make sure they don't end up getting the control if those
files are absent. This would be a quick-and-easy, although not
very secure, way of preventing the download of an update file
without the original on the system.
<P>
The other kind of dependencies that can be checked are system-level-what
happens if someone on a Macintosh downloads your OCX for Windows
NT? That's not going to help them too much. INF files let you
specify different files based on the MIME type that the client
system accepts. For example, you could set up three different
cases for a CAB file, based on whether the client was running
Intel-based Windows, MIPS-based Windows, or Macintosh, as shown
in Listing 27.4.
<HR>
<BLOCKQUOTE>
<B>Listing 27.4. Adding platform independence to INF file downloads.
<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier">[foo.ocx]<BR>
; Provides the version and ClassID (clsid) for FOO.OCX<BR>
; If the newer version is needed, specifies that it can<BR>
; be obtained from a specific location, in this case the<BR>
; CAB file created previously.<BR>
; Also specifies different Cab files, based on platform<BR>
file_win32_x86=http://www.wherever.com/x86/foo1.cab<BR>
file_win32_mips=http://www.wherever.com/mips/foo1.cab<BR>
file_mac_ppc=http://www.wherever.com/macppc/foo1.cab<BR>
clsid={9DBAFccF-592F-101B-85CE-00608CEC297B}<BR>
FileVersion=1,0,0,111</FONT></TT>
</BLOCKQUOTE>
<HR>
<H5>MIME and Other Identification</H5>
<P>
When considering all the file existence and version checking that's
going on and the fact that the Internet spans so many platforms,
it's logical to want a case where people on different platforms
or different machine types get different downloads. The two primary
identifiers used in the download of a component are the Globally
Unique Identifiers (GUIDs) that are associated with a control
in the registry and the MIME type that the HTTP server decides
to set the file to.
<P>
Currently, because the ActiveX specifications haven't been approved
or adopted as a standard by the folks in control of such things,
Microsoft has established some temporary MIME types for developers
to use on their servers to identify controls and their associated
platforms.
<H2><A NAME="ActiveXViabilityandDirections"><FONT SIZE=5 COLOR=#FF0000>ActiveX
Viability and Directions</FONT></A></H2>
<P>
How viable is ActiveX as a standard? Coming from Microsoft, it
certainly has an easy entrance into the Windows community, but
there's more to consider than just who spawned it. The biggest
initial hurdles to ActiveX implementation are its proprietary
nature, cross-platform capabilities, and who in the world is going
to develop, purchase, or integrate ActiveX controls for general
use. Fortunately, Microsoft seems ready to tackle those issues
head on... or are they?
<H3><A NAME="WhosGoingtoDevelop">Who's Going to Develop?</A></H3>
<P>
One of the big things in ActiveX's favor is that it's really just
a new name for something that thousands of developers have been
creating for years-OLE controls. Unlike some new thing where everyone
has to start over from scratch and learn a new language, existing
OLE controls can either be used as is or fine-tuned to provide
the performance and support needed to make them truly Internet-functional.
Companies have previously lined up to create OCX controls, which
are bigger versions of the streamlined ActiveX controls, and they
can transition that effort directly into the new standard without
much pain and suffering in the middle.
<P>