This is what a client-side <OBJECT> tag might look like in HTML:
<OBJECT CLASSID="clsid:79176FB0-B7F2-11CE-97EF-00AA006D2776" ID="spnTest"
CODEBASE="http://activex.microsoft.com/controls/mspert10.cab"></OBJECT>
</OBJECT>
A lot different from the Server.CreateObject method we're used to. It is, of course, the same basic format as the other way of creating objects on the server, using an <OBJECT> tag. Although it doesn't look exactly identical, it is doing the same thing. The string used with a call to CreateObject on the server is called a Programmatic ID or ProgID. This syntax isn't supported on the browser (yet), so the long ugly string making up the CLASSID attribute has to do the same job. It's known as a Class ID or CLSID. You may recall from Chapter 3, however, that we can also use the CLASSID method on the server if we're feeling particularly obtuse.
The second part of the tag, the ID="spnTest" attribute, is simply telling the browser that this object will be referred to in our code by the name spnTest. Finally, the CODEBASE attribute specifies a URL where the control can be downloaded from if it's not already present on our machine. This last attribute isn't supported in the server-side version of the <OBJECT> tag.
On the server, ProgIDs and CLSIDs are complementary—each ProgID has an associated CLSID and vice-versa. ProgIDs are generally easier for a human to read and understand, so they're commonly used when an ActiveX object needs to be identified. They have one problem though, especially in the Internet world. Suppose I create an object for a card game and give it the ProgID "CardServer.Hand". You visit my page, download the control and create the object, and play my card game. Everything is fine and dandy until you happen to visit someone else's page—for sake of argument let's say they live in Australia, mainly because I'd like to visit Australia.
My Australian colleague and I don't converse very often, and so we've unwittingly created two completely different objects with the same ProgID of "CardServer.Hand". What happens now? Your machine doesn't know whether it can use the object it already has, or if it needs to go out and get a new one. There is no way it can tell whether the control it already has is different from the one on the page in Australia. Either way, whether it keeps the existing one, or goes and gets the new object, one of the pages that uses the "CardServer.Hand" object won't work properly, because we'll only have one of the objects on our machine.
CLSIDs solve this problem. A special algorithm generates each CLSID number when the object is developed. This algorithm guarantees that the CLSID won't be ever duplicated, on this world or in this galaxy, for thousands of years. So we can be sure that an object we design or use in our pages won't ever conflict with another object somewhere else on this planet (or off it!). On the other hand, on the server we should be safe when using the ProgID, because we ought to know what objects we've got, and therefore be able to prevent conflicts.
One topic that concerns everyone, especially with the increasing reports of rogue components circulating on the 'Net, is particularly important: how does someone viewing our pages know that the objects we've included will be safe to run on their machine? The code is actually running on their machine, and it's not just a scripting language with a few buttons anymore—it's very powerful. With that power comes the ability to do damage. There are two commonly used methods for providing object safety, sandboxing and code signing. We'll look at both of them before wrapping up this section, by talking briefly about the way that the objects get from the server to the client in the first place.
The method of safety used by Java applets, and also by the VBScript and JavaScript scripting languages, is known as 'sandboxing'. This name refers to the practice of limiting the capabilities of these languages to actions that are defined to be safe to the machine. For example, since direct access to the hard drive of the machine could allow someone to erase files indiscriminately, sandboxed languages don't often support disk I/O. Disk access is 'outside the sandbox' and the language can't access it. While this method can ensure reasonably safe code, it can be tremendously limiting to the developer. How many applications at our local software store don't use our hard drive? Instead, applets often save information back across the network to the server that's supplying the pages.
An alternative that preserves access to the full capabilities of the machine is called 'code signing'. With this method, the code can do whatever it wants, but—if it does something bad—the user knows who caused the problem and can take appropriate actions. A digitally signed piece of software identifies the person who created and signed it, and that the code hasn't changed since it was signed. One common way to describe code signing has been to think of it as 'shrink-wrapping for the Internet.' The box of software you pick up at the local store isn't guaranteed to be safe to your computer—it could reformat your hard drive just as easily as it displays graphics on your screen. However, since you bought it in a box at the store, you know that whatever company distributed it vouches for its safety, and (in most cases!) feel confident enough to install and run it on your computer.
The mechanics of code signing are based on publicly known algorithms and cryptographic techniques, and are not owned by any company or organization. If you've used the PGP (Pretty Good Privacy) encryption system, you've used some of the same techniques that code signing does. We'll be covering code signing, cryptography, and digital certificates in more details in the next couple of chapters.
Finally, it's important to note that code signing is complementary to sandboxing, and not used in competition with it. Any string of 1's and 0's, including Java applets, can be digitally signed to provide authentication. In fact, both Microsoft and Netscape support, or have announced support for digitally signed Java applets. If the applet is signed, the browser can relax the security restrictions and let the code move outside of the 'sandbox' and do more with the computer.
On the server the objects we use are usually installed in the conventional way by a setup program. Imagine if we had to manually install each object that a certain web page used before we could view the page. We would probably be reticent about using objects unless we could be sure our users had already installed them, or they would be willing to go through the annoying process of location, download, and installation.
Not surprisingly, today's Java- and ActiveX-enabled web browsers have automatic methods for downloading and installing code. With Java applets, the only files that are needed are the .class file for the given applet and any dependent .class files it uses. When the browser sees an <APPLET> tag in the HTML, it knows to go to the server and retrieve these files in addition to any graphics or other objects embedded on a page. Both Netscape and Microsoft have different methods of packaging more than one class file into a compressed archive for quicker transmission over the network. Netscape uses ZIP files while Microsoft uses the same CAB and INF file formats that are used to distribute other applications.
The CAB file format is another compressed file format that has been used for some time by Microsoft to reduce file sizes. The part of Internet Explorer that performs the download and authentication process for software is called the Component Download Service. This element can use installation scripts to download one or more files depending on various factors, such as if the file is already installed on the machine, or if the version number of a currently present file is older than may be needed. Internet Explorer can also recognize another file with the .inf syntax used by some Windows setup programs. With files of this type, we specify a list of files and locations, and Internet Explorer downloads only those files it needs. This method can even be used to download different versions of controls for different operating systems or processor types.
If you are developing components for use with Navigator or Internet Explorer, you'll surely need to become more familiar with these issues. However, this introduction is appropriate for a book of this scope, and should be enough to give you an understanding of what actually happens when the browser sees an <OBJECT> or <APPLET> tag in our page.
To learn about creating ActiveX controls, look out for the Wrox Press book Instant VB5 ActiveX Control Creation.