 Chapter 27 -- ActiveX Controls Chapter 27 ActiveX Controls
CONTENTS
Wouldn't it be great if you could easily add new functionality to your Web site or even your standard hard-drive-bound programs? You see something new, you want it, poof... You add it into your word processor, your desktop shell, or anything else you feel like. Seamless, painless, and possible. ActiveX controls are the heart of Microsoft's new Internet strategy, proposing to give developers and users that kind of flexibility and functionality with that kind of ease of use. They're designed to be little add-on pieces that enhance things you already have so you don't have to start from scratch to build in every possible situation. These reusable objects even hang around on your system so that the next time you need them, you'll already have them and not waste time downloading them again. To introduce you to the realm of ActiveX, I'll do some digging into the following areas: - ActiveX concepts and background
- Why ActiveX controls matter to developers and users
- Getting down and dirty with design and implementation
- Where ActiveX is heading
- Resources you can turn to
Although knowing about ActiveX controls and how they can help you is one thing, knowing how to create them is a separate task altogether. Most of this chapter focuses on the usability side of the ActiveX controls rather than the creation side, but a good deal of the inner workings and concepts are explored as well. If you see enough to get interested in building your own, bear in mind that building ActiveX controls is programming at a high level, and you'll want to have some serious programming experience before experimenting on your own with a new type of control. If you've got the motivation, though, anything can happen. The old theory goes that you can't fit a square peg into a round hole unless you really pound it in there. In the same vein, it's always been hard to take good content and integrate it with a Web site or intranet unless you really beat on it to get it into the form that you need. Even then, it just can't be done sometimes-some of the things that exist just can't be forced to fit in the place you want to put them. Until now, anyway. Back some years ago, people in the Windows world began to get frustrated with the inability to take things created in one application and make easy use of them in another. In response to this frustration, object linking and embedding was born. Object linking and embedding, or OLE, was the answer to a number of problems because it allowed you to take a chunk of data from one program and easily attach it to another application that supported OLE. What was happening behind the scenes was that each OLE-capable application had some "hooks" in it that allowed other things to be attached to it later and talk to one another. Much like using building blocks, if you give everything a universal method of connecting, you can just keep adding new pieces as you need them. This universal method of connecting is the component object model, or COM. This is a standard that acts like the blueprints for plastic building blocks-it specifies what kind of connectors exist and what configurations are acceptable. Without it, two blocks designed by the same company just won't work together. OLE was built on top of COM for use in the Windows environment and proved very useful for both developers and end users. Now, instead of an image of a spreadsheet, the actual spreadsheet itself could be embedded within a document and manipulated. The basic premise was to add on to existing functionality in as seamless and efficient a manner as possible. In a sense, OLE components and OLE-enabled applications are all containers-they exist to hold special types of information that the other application may or may not be able to deal with. An application could essentially be nothing more than one big container to hold little containers, so that if you needed a component to take care of text, you brought it in. If you needed a component to take care of video, you brought it in, and so forth. It's the whole component object model theory at work; you start out with the pieces you need and put them together into the thing you want without too much work in between. ActiveX is the next generation of OLE controls and containers. More precisely, it's the next-generation name of OLE controls and components. For all intents and purposes, ActiveX controls are OLE controls, just with a cooler name, a new focus, and some new tricks. Microsoft defines an ActiveX control in a variety of different ways, but the most basic one that they give is, "An ActiveX Control is essentially a simple OLE object that supports the IUnknown interface." This doesn't preclude it from doing anything else, but the universal connector in this case is the IUnknown interface. Don't worry too much about the technical-sounding term. The IUnknown interface is just a way for an application to say, "I have no idea what to do with this; do you?" to something else. | Those Changing Names | In every product's life cycle, names end up changing around. Microsoft went through their own growing pains with ActiveX, but they finally seem to have made up their minds. After all, if "Oak" can evolve into "Java," why can't "OLE" move to "Sweeper" to "the Active Internet Platform" and come to a halt at "ActiveX"? There were talks about renaming the Internet Information Server just as they'd ended up renaming the Internet SDK (it's now the ActiveX SDK, for those who are keeping score), and if FrontPage didn't already have a nice name, it might have been next. Who knows what will end up with an ActiveX prefix before Microsoft is done... | The real changes of ActiveX are beneath the surface where it makes up for what OLE and OCXs (the next-to-last name used for ActiveX controls) lacked. When you use a control, you'd like to be able to identify whether it is what you think it is and does what you think it does. In the future, you might like the ability to look for something not necessarily by name, but by what it does. To handle both the present and future requests, Microsoft brought up a number of methods for categorizing all the controls and containers in the Windows registry. At a base level, categories are the types of questions that the control responds to. In the COM and ActiveX world, these are the interface signatures-the types of communications interfaces supported by the control. The interface signatures tell someone whether control A accepts type X of communication but not really what it can do with the information once it gets it. This information is a necessity for real intertwining of controls and their functionality because if control A supports a text-reading function, you might assume that it means you can do certain things once it reads the file. If it doesn't, and you jumped the gun, your program wouldn't be able to do much except sit there and complain that what it needed from the other control wasn't there. You really wanted to know not only that the control supported reading, but that it also did some other things as well. To organize all these possibilities, each unique control gets its own chain of things that it supports added on to it in the registry. If a registry identifier indicated, "This outputs RTF files," you could have that tagged on to the control. If a tag indicated, "This supports database access," you could tack that one on there as well until you've daisy-chained this huge and unwieldy string of unique identifiers onto the poor control and made it real apparent to other programs that your control supports certain things. | Tip | The definition and implementation for category keys is in a state of flux. The current method involves placing human-readable keys in the registry so that people can change classifications easily, but in the long run, that is a big mess with thousands of possible programs on one machine all putting long strings of data with arbitrary names inside your registry. If your role for ActiveX is a user and not a developer, you very rarely have to worry about how in the world these things are organized. If you're developing and need to worry about it, check the latest release of the ActiveX SDK for the most current details and methodology, just to make sure you don't do something that will become obsolete in the blink of an eye. | ActiveX controls, and the ActiveX technologies in general, matter to developers and to end users for a variety of reasons. Although it's impossible to cover every single reason, the major ones fall into two basic categories-functionality and financials. Creating your site so that it does everything you need is a tough job. It's even harder when you need to keep it innovative and up to speed with the latest trends and technologies. There's always something new you want to add or something you read about that clients and other end users really want to see in action. ActiveX controls allow you to get hold of the interactivity and "wow" factor without all the work. If you want to show a spreadsheet, you don't convert it to an HTML table; you just provide it in its native form and make an ActiveX control available for people to use. | Note | Not everyone meets this type of content delivery with anticipation and enthusiasm. The reason for this is cross-platform compatibility. If you decide to use a proprietary content format as a major portion of your site, you're counting on your primary target audience to have the control they'll need to view it. If the manufacturer only has an ActiveX control for Windows 95 and doesn't have any plans to move to UNIX or Mac, your Internet content is no longer platform-independent. See the section "ActiveX Viability and Directions" later in this chapter for more details. | Just because ActiveX controls are designed to be small for Internet use, it doesn't mean you have to use them that way. Just as the more traditional OLE controls functioned on the desktop machine level or over the network, ActiveX controls carry on the tradition. You can plug in an ActiveMovie control to an existing Visual Basic or C++ application with little or no difficulty because they've been ready for that kind of communication for quite some time now. How many developers out there have ever written OLE containers or controls? Visual Basic Extensions? OCXs, in the more recent past? If you add up the numbers of any estimate out there, you end up with a staggering total. By casual estimates, over a million developers out there have done these kinds of things as either individual efforts or corporate software initiatives. That's a heck of a user base to build on. Now think about the interchangability of it all. People who make one control sell it to a bunch of other people, and they might end up buying an extension that someone else made. It could be a compression algorithm, image display function, video or audio handling, or text display and modification; look through any software development magazine or newsgroup, and you'll see a small part of the potential development audience. The Migration Instinct People don't usually like to waste time or money. If you've spent a great deal of both in creating a piece of software, you're probably more inclined to make a few small changes than you are to start over from scratch. That's one of the things Microsoft is hoping for. With the huge base of existing customers who have created VBXs, OLE controls, OLE container applications, and OCXs, the possibilities opened by the ActiveX strategy are huge, and steps are in place to help people move from the old way to the new way, in somewhat of a software-upgrade path. The largest evidence of this is the large portion of the ActiveX Development Kit dedicated to Visual Basic migration to ActiveX components and controls. In fact, 14 lengthy chapters in the "Control Migration Pack" go into more details than you can easily shake a mouse cursor at. The Bandwagon Brigade Who has more money to spend on advertising: Microsoft or independent developers? Not a tough call. When Microsoft announces a new technology and puts lots of hype behind it, it drags plenty of attention in its wake even if the hype dies down after a while. This is great for people who are developing ActiveX controls and components because they just put the magic words "ActiveX enabled" in their advertisements and the mouths of their sales people, and they've grabbed onto some real big coattails at no real expense. Because ActiveX has such a large public presence, unlike some other object standards such as CORBA (which rings familiar to a select segment of developers and companies, but not the general population), it doesn't take much work to convince people it's a good thing. The more people that hop on the bandwagon, the more sheer momentum the wagon gets. Sure, it could eventually try to round a technological corner and go careening off a cliff into the depths of obscurity, but there's a pretty good stretch of open road in front of it right now. Knowing a little bit more about ActiveX, you might want to take a look at some of the stuff it can do before diving into the realm of just how it works. This is the opportunity to examine it from an end-user perspective and see more than just hype and promises. Microsoft started churning out controls like there was no tomorrow right after Internet Explorer (IE) 3.0's beta release, and other developers and software companies started to do the same. To start with, take a look at what's going on with two of the more popular Microsoft ActiveX Controls-ActiveMovie and the HTML Layout control. There are lots of video formats out there, such as MPEG, AVI, and QuickTime. Some you need special hardware for; some you don't. Some are well synchronized during playback; some aren't. Some can be played back over the Internet... Hey, why not just solve all the problems at once? ActiveMovie gives users the ability to view any format they'd like, all with better playback rates and synchronization and all without special hardware. This means that you can play back highly compressed MPEG video on a machine with no MPEG decoder board and get good results. It means the same control can play back QuickTime and AVI videos, as well as different forms of compressed audio. If that wasn't enough, you can create filters to modify the video and audio as it comes through. All of this is accomplished through Microsoft's DirectX method of providing direct access to audio and video hardware, so if there is anything on board that should make things faster, it will. All of this is accomplished through media streaming, where multimedia data streams get run through a series of filters. Some do the decoding, others do the drawing, and others do any modifications necessary in between. Developers can use the ActiveMovie SDK to create their own special filters for formats or effects, whereas end users take the compilation of filters (called a filter graph) and the ActiveX control and play back video or audio to their heart's content. Have you ever tried to position things in a nice organized manner using HTML? Let's see; you want the button to be in the top right of the screen, just under the logo, all the form elements should line up nicely, and that animated GIF needs to be positioned just so over a specific spot in the background graphic. If your answer to all the above issues is tables, good luck. It's frustrating to come up with what you think is a great design, only to be limited by not being able to position elements to your liking. The playing field is changing. One of the proposed extensions to HTML 2.0 is the ability to position HTML design elements on a 2-D XY-coordinate grid. If you want the graphic in the upper-left corner to be positioned precisely at 10,10, you can do it-assuming your browser has support for it, of course. The HTML Layout control gives you that ability now before worrying about what happens with the standards. This is good and bad. If you spend a long time designing something to be a specific way using Microsoft's idea of what the final 2-D layout specs will be, you might end up making changes later. If you want the functionality now, some changes later are usually more acceptable than just sitting around and waiting. What else is in the works? Pretty much anything you'd like to imagine, such as animation, audio, and business applications. If people are using it over the Internet (or want to), chances are it's going to get an ActiveX control before too long. If you want to see just what range of controls are out there, skim one of the Web sites mentioned in the section "Resources" later in this chapter, and you'll see everything from A to Z. You've heard about them, seen them in action, and now you might be wondering how in the heck they work. Before I dive into that, I want to reiterate one of the things I mentioned in the beginning-creating ActiveX components is advanced programming. It's not something you approach casually and expect to do something fantastic in an afternoon, having started from scratch. If it is and you're successful at it, a lot of companies would like to have a long talk with you about coming to work for them. If you're like the rest of us, though, you need to have a strong background in programming before you can really consider making a control of your own. This section isn't going to take you through the creation of an ActiveX control step-by-step. Microsoft has an ActiveX SDK for that, and it's huge. What I'm going to do is outline some of the more important starting points, and you can take the ball and run with it from there. If you're not familiar with COM or OLE, you have a lot of work ahead before you create your first original ActiveX control. If you've ever written VBXs, you're in much better shape. If you're familiar with COM and OLE and have written OLE controls, you probably won't even break a sweat. How difficult it will be is truly dependent on your experience because there are several layers of development concerns. The basic framework for ActiveX controls is supplied by Microsoft in an aptly named package called BASECTL, for "Base Controls." This is part of the ActiveX SDK, so you'll need a copy from Microsoft before you can do much with it. In that package are two basic but useful Internet-aware ActiveX controls and the C++ framework (named FRAMEWRK), which makes everything go. The fact that there are 15 C and C++ files in the initial FRAMEWRK component goes to show that building an ActiveX control isn't a walk in the park. Before you get too nervous, though, take a look through the code. It's well-commented (sometimes with a sense of humor...), and you can start to see just how it all fits together without too much pain and suffering. Although you can use any language to create ActiveX components, the primary language for creating controls is C++. More specifically, the initial tool is Visual C++ 4.0 on a 32-bit Windows platform, such as NT 3.51 or 4.0. The reason for this is that the calls and elements supplied in the first version of the framework are all specific to Visual C++, as would be expected in a Microsoft release. It takes time for these elements to be brought into other development environments on Windows, such as compilers from Borland and other vendors, and even longer for such pieces to reach other platforms such as the Macintosh and various flavors of UNIX. If things go as planned, Visual Basic 5.0 users will be able to turn their development environment into control-creating powerhouses as well. Currently existing VBX controls can be ported over already through judicious use of Visual C++, and as time goes on, other Rapid Application Development (RAD) tools such as Borland's Delphi will undoubtedly add the functionality as well, just to satisfy the growing developer audience. When and how are the key questions. Having created or otherwise obtained an ActiveX control, the next real step is setting up your documents to use the controls. Compared to understanding the mechanics behind it all, this is by far the easiest part of the whole operation. Until recently, the OBJECT tag was the INSERT tag. Although the name has evolved just as ActiveX's did, the purpose remains the same. It's a straightforward method of including a compiled object in the document, leaving it up to the browser on the other end to determine if it's going to do anything with it. The two primary components of the OBJECT tag are the ClassID and the optional parameters. ClassID The ClassID is a long Globally Unique Identifier (GUID) that allows the system to know for certain which piece of code you're talking about. No two components will (or at least should) have the same GUID in the registry, and when software developers create the ID for their function, they must follow basic guidelines for ensuring that this doesn't happen. Optional Parameters As with any application, you can attach a lot of possible elements to your OBJECT tag. You can indicate width, height, alignment, a nametag, and even the equivalent of command-line parameters by tagging them on the end with the expected PARAMETER tags. What the control accepts is up to its designers, but some of the more common things are filenames, filters, and other initialization parameters that can't be counted on from some INI file somewhere, so the control has to take all of it into account. What if the end user doesn't have the ActiveX control for the thing you want to show them? This has always been the bane of plug-in developers and the enemy of the end users. When you go to a cool site, the last thing you really want to do is see a message that says, essentially, "Oh, you'll need to be running the Foo plug-in for this to be interesting. Why don't you go to Foo.Com, download that 1+ meg beastie, get it set up and running, and then come back here. It'll be worth the effort. Well, we think it will, anyway..." Would all those who really want to do that a few dozen times please take one giant step backward in technology? Thank you. Traditionally, plug-in manufacturers had two choices to make that scenario less painful. First, they could make the plug-in small and easy to install, in the hopes that it wouldn't frustrate people too much. Otherwise, they could try to get big companies to bundle the plug-in with their software, hoping that everyone ends up with some version or another that may or may not be up to date with the sites people want to visit. In either case, that's a lot of hoping and jumping through hoops, and ActiveX doesn't make you go through any of it. Instead, everything gets automated. The Internet Component Download mechanism serves one purpose-if someone visits your site and he doesn't have the ActiveX component he needs, it starts sending it to him. The component doesn't come in a mail message or a file he has to muck around with but instead arrives as a new container that will deal with the data you want to send him. If you visit a site that has some cool 3-D stuff, but you have no 3-D ActiveX control, it recognizes that fact and says, "Hold on a sec; I'll start giving you what you need." Not only that, but it will install and configure it all for you without any work on your end. If the control is small enough, you might not even notice that it's all happening-you'll just get seamless access to the cool stuff. CODEBASE To make obtaining an ActiveX Control easy, the OBJECT tag has a CODEBASE parameter, which points to where the ActiveX control is stored on your server. If the client doesn't have the control, this is where it looks to get hold of it. Using the standard OBJECT tag, the following code segment shows what it looks like with a CODEBASE parameter added in: <object
classid="clsid:12345678-1234-1234-1234-123456789012"
CODEBASE="http://myhost.com/activex/mycontrol.ocx "
id=MyControl width=50 height=100 align=center>
| Note | If you've experimented with Java before, you might be thinking that the CODEBASE parameter looks suspiciously like the CODEBASE parameter that Java uses to help end users get Java classes that they don't have on their system. You'd be exactly right-both CODEBASE tags serve the same purpose and are used the same way. Isn't consistency great? | To ensure that end users are always running a current enough version of the ActiveX control, the CODEBASE parameter accepts an additional parameter: Version. This allows the developer to take different available versions of the control into account, so that no extra downloads are made if they're not needed, but no problems arise because of out-of-date code. The addition of the Version parameter makes a CODEBASE parameter look like this: CODEBASE=http://www.wherever.com/myfile.ocx#Version=a,b,c,d This causes the client's ActiveX container, such as Internet Explorer, to search the registry and find out what version already exists for an installed control. The CODEBASE parameter passes on the version number that it expects to be able to use, and if that version number is newer than any found in the registry, the download begins. Security Concerns and WinVerifyTrust When software starts downloading itself onto your system and setting itself up, you might begin to wonder how secure the whole process can possibly be. After all, what's to stop someone from specifying some ActiveX control with a really new version to make sure it gets downloaded and then does something nasty to your system? Well, it's all a matter of trust. Windows Trust Verification Services, to be exact. Microsoft's model for the Windows Trust Verification Services involves getting some assurance that the thing you're downloading from some specified person has been verified by someone who should logically do so. For example, when you buy food at a supermarket, you're putting your trust in the food, the store, and whatever organizations certify that the store meets health guidelines. It's the "What, Who, and Who Else?" mentality, and it is usually reasonably effective. The way that Internet Component Download takes care of these verifications is with the WinTrustVerify() procedure. This allows the client's software to perform the necessary steps to make sure everything's okay before going ahead and installing or running what's being referenced. Part of the method it uses to do that is through the existence of a digital signature, which makes sure the code hasn't been tampered with on its way from the original source. Somewhat like checksums in electronic file transmissions, digital signatures keep track of certain elements and combinations that end up being indicators of whether everything's as it should be. | Tip | You can learn more about the WinVerifyTrust() mechanism, as well as digital signatures, in the ActiveX Development Kit and from some of the resources listed later in this chapter. Both the Development Kit and the resources provide you with more information on just what places can be trusted, and why, to give you safe code. You can even find such places as VeriSign, and become a trusted vendor yourself. | The Mechanism-CoGetClassObjectFromURL() When a container, such as Internet Explorer, wants to go ahead and find, verify, download, and install a control, it makes one big call-CoGetClassObjectFromURL(). This one call does all the steps needed to get the code from one place to another and make sure nothing goes wrong in between. It involves the following steps: - Download the file specified in the CODE tag.
- Call the WinVerifyTrust mechanism, and make sure it's safe to go ahead and install.
- Self-register all the OLE components, using either regserver at the command line (for EXEs) or DLLRegisterServer() (for DLLs and OCXs).
- Update the registry.
This is the do-everything call, and it should be, considering that the function itself is defined as shown in Listing 27.1.
Listing 27.1. A definition listing for CoGetClassObjectFromURL().
CoGetClassObjectFromURL (
REFCLSID rclsid,
LpcWSTR szCodeURL,
DWORD dwFileVersionMS,
DWORD dwFileVersionLS,
LpcWSTR szContentTYPE,
LPBINDCTX pBindCtx,
DWORD dwClsContext,
LPVOID pvReserved,
REFIID riid,
VOID ***ppv );
The actual parameters used by CoGetClassObjectFromURL can be seen in Table 27.1, and they comprise a large number of details to make sure that what is downloaded is what's really wanted.
Table 27.1. The parameters used by CoGetClassObjectFromURL. | Parameter | Type | Description | | rclsid | REFCLSID | The ClassID (CLSID) of the object that needs to be installed. If nothing is specified, SzContentType is used to make the determination. | | SzCodeURL | LpcWSTR | The full URL to the object's code, á là the CODEBASE tag. | | DwFileVersionMS | DWORD | Major version number for the object. | | DwFileVersionLS | DWORD | Minor version number for the object. | | SzContentType | LpcWSTR | MIME type that must be understood by the object. | | PbindCtx | LPBINDCTX | A bind context, which should be used to register the client's IBindStatusCallback to receive callbacks during the download and installation process. | | dwClsContext | DWORD | Specifies the execution context for the object, based on its Class Context (CLSCTX). | | PvReserved | LPVOID | Reserved value, which must be set to NULL. | | Riid | REFIID | The interface to obtain on the factory object (typically IClassFactory). | | Ppv | VOID ** | Pointer in which to store the interface pointer upon return if the call is synchronous. | Table 27.2. Expected returns from CoGetClassObjectFromURL. | Return | Meaning | | S_OK | Success. Ppv contains the requested interface pointer. | | E_PENDING | Component code will be downloaded and installed asynchronously. If the client registered itself in pBindCtx, it will get notifications. | | E_NOINTERFACE | The desired interface pointer is not available. It's also possible that this return indicates other CoGetClassObject errors. | Within the call, a number of other components are executed to start the download, call out to the WinTrustVerify() 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, CoGetClassObjectFromURL() saves the effort for people who'd rather not be bothered. Permanent Storage 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. 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 "Don't get rid of me" 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. Component Packaging 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 CODE 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. Packaging Schemes and Methods 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. Cabinet (CAB) Files 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 DIAMOND.EXE, which is included in the Microsoft Internet SDK. | Tip | 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. | The text file that instructs DIAMOND.EXE 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 FOO.DDF.
Listing 27.2. A sample DDF file for use in creating CAB file packages.
; Directive file for FOO.OCX+FOO.INF
.OPTION EXPLICIT
.Set CabinetNameTemplate=FOO1.CAB
;** The files specified below are stored, compressed, in cabinet files
.Set Cabinet=on
.Set Compress=on
FOO.INF
FOO.OCX
Using the FOO.DDF file shown in Listing 27.2, the following command line creates a CAB file containing the compressed versions of FOO.INF and FOO.OCX: DIAMOND.EXE /f FOO.DDF
| Tip | 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 "Resources" point you to the most up-to-date information available. | 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. INF Files 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. 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.
Listing 27.3. Sample INF file for Internet Component Download.
;Sample INF file for FOO.OCX
[Add.Code]
foo.ocx=foo.ocx
mfc40.dll=mfc40.dll
[foo.ocx]
; Provides the version and ClassID (clsid) for FOO.OCX
; If the newer version is needed, specifies that it can
; be obtained from a specific location, in this case the
; CAB file created previously.
file=http://www.wherever.com/foo/foo1.cab
clsid={9DBAFccF-592F-101B-85CE-00608CEC297B}
FileVersion=1,0,0,111
[mfc40.dll]
; Since we'll assume our OCX needs the MFC40.DLL, for the
; Microsoft Foundation classes, we'll make sure it's on
; the system. If it's not, the component download will
; fail,because we've left the 'file=' line blank. This
; is because we don't want people to be downloading
; MFC40.DLL if they don't already have it... it's kind
; of big.
file=
FileVersion=4,0,0,5
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. 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.
Listing 27.4. Adding platform independence to INF file downloads.
[foo.ocx]
; Provides the version and ClassID (clsid) for FOO.OCX
; If the newer version is needed, specifies that it can
; be obtained from a specific location, in this case the
; CAB file created previously.
; Also specifies different Cab files, based on platform
file_win32_x86=http://www.wherever.com/x86/foo1.cab
file_win32_mips=http://www.wherever.com/mips/foo1.cab
file_mac_ppc=http://www.wherever.com/macppc/foo1.cab
clsid={9DBAFccF-592F-101B-85CE-00608CEC297B}
FileVersion=1,0,0,111
MIME and Other Identification 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. 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. 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? 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. Besides gaining the obvious Internet benefits, developers shouldn't be shy about pursuing ActiveX functionality for the desktop. After all, OLE containers and controls started there, and OCXs are already there. If things move the way Microsoft envisions, software could end up being much more component based, where you tailor one or two basic applications to do all your basic needs just by adding a component here or there. Because Visual Basic developers can treat ActiveX components like any other control or container, there's even more for them to build on as well. At the end of July 1996, Microsoft announced that it was putting plans in motion for moving control and appropriate trademark rights to an external industry-standards organization. Microsoft would be a participant and probably an extremely vocal one, but it would not be in direct control of decisions and directions chosen by the organization to facilitate ActiveX as an open and cross-platform standard. Just a few days later, Microsoft postponed that meeting indefinitely, sending a number of concerns shooting through the development world. Had they completely reconsidered? Did they decide that they wanted to keep more control over ActiveX, rather than become just a collaborator? Ostensibly, it was because Microsoft felt more time was needed to better define the process and the roles of those involved, but critics felt more on the skeptical side and said that the original announcement was rushed to beat Netscape's Open Network Environment (ONE) announcement that had arrived the beginning of the following week. Finally, after swaying to both sides, Microsoft announced that it would form its own standards group and would be positioning ActiveX as an open standard to challenge what it considered the closed nature of CORBA. Was this the best decision? The ActiveX technology is very persuasive, but whether it will be enough to persuade the early adopters of CORBA and OpenDoc to change over is something that only time will tell. Cross platform? That might startle a few anti-Microsoft-establishment folks out there, but it's true. Microsoft wants ActiveX to make it onto the major platforms, starting with the 32-bit Windows platforms (of course) but without a doubt including Macintosh and key UNIX operating systems. If there is one thing that developers, as a general group, have been less than thrilled about, it's all these neat and nifty ideas from Redmond that have always failed to take into account the significance of other major markets. Now that oversight is being rectified with a vengeance; Microsoft quickly announced partners for porting ActiveX to the Macintosh and to UNIX. They are intent on not wasting any time, and there are plenty of reasons why. The first, and most basic, reason is that they want the largest target audience possible. They realize that Mac and UNIX users constitute a significant portion of possible revenue, and leaving them out would be a fatal chink in the corporate armor. Very few "open standards" can hope to survive if their idea of open is "runs on the stuff we make." Another compelling reason is competition. If ActiveX was the only thing out there that could perform these kinds of functions (and, indeed, there are some functions that are currently unique because of its add-on nature), there wouldn't be too much danger of letting things progress as people saw fit. The biggest dangers of all, though, are competitive standards that do much of the same thing but do it differently. Everyone can coexist, but an industry full of multiple standards for the same type of thing would be very silly. Depending on who you talk to, ActiveX and Java are seen as either complements to one another, threats, or in completely separate ball parks. There's also OpenDoc, Netscape's Open Network Environment (ONE), CORBA, NEO, and other theories and implementations of independent objects and components that get reused based on requests, varying from platform to platform. How do they all fit together to cooperate or compete? The Component Object Request Brokerage Architecture (CORBA) is a well-respected, although in some cases little-known, standard that defines standards for Object Oriented Programming. Its primary home is UNIX, and it has quite the little empire there. Hard-core Java programmers who are looking at the long-term use and reuse of their code usually swear by it. Those just getting involved, of course, just swear at it. CORBA is administered by the Object Management Group (OMG) in Framingham, Massachusetts, an independent organization comprised of industry experts and corporate heavy hitters, including Microsoft. Even though they're part of the OMG, Microsoft didn't make ActiveX CORBA compliant. Both OpenDoc and Netscape's ONE embody the principles of CORBA, as do variations on Java's Object Model such as Joe and Sun's NEO. This could weigh heavily against Microsoft because they're essentially telling some very experienced developers (and the companies they work for) that ActiveX is better than what they're using, and their old investments in CORBA are now defunct. That wouldn't be a pleasant thing to hear, and it wouldn't be true. The problem is, that's almost the way it's presented. Speaking of competitive standards, let's not forget Netscape's place in this whole affair. With the initial hoopla of ActiveX coming about full force, Netscape actively dodged being part of it and announced that they had no plans to support the ActiveX model. Small wonder, considering their ONE (Open Network Environment) developments are aimed at CORBA compliance and would be undercut by such support. Where does that leave the countless number of Netscape Navigator users out there who want to make ActiveX part of their experience, no matter what Netscape thinks of the whole idea? It leaves them looking for developers who are more than up to the challenge of filling the void. ncompass Labs of Vancouver, British Columbia, grabbed the reins early with their ControlActive plug-in for Netscape, providing a one-stop solution to developers who couldn't afford to split their efforts in the direction of plug-ins or ActiveX. The difficulty, of course, is that this brings people back to the whole mandatory plug-in theory-it's not built into the software. Clever bundling by Netscape or Microsoft could easily shatter that problem and distribute it to a large audience. Should Netscape decide to move into the ActiveX arena, at least by embracing the ncompass initiative, they wouldn't lose much time. If you make it, will they buy? Some people sure seem to think so. As mentioned earlier, a lot of developers out there are already actively switching over to the ActiveX standard because it's so close to what they already had. As for end users, the increased seamless functionality is all the selling point they need, althou*gh if software manufacturers can cheaply transition controls and elements to ActiveX and pass those savings on, that would be even more compelling. At the end of July 1996, Microsoft announced estimates from the Giga Information Group stating that they expect the ActiveX component market will generate $240 million in revenues this year. As if that wasn't enough to entice people, the estimate swells to an enormous $2 billion by the year 2000. That's a significant pool of income, and most people will want to dive right in. The big hope, though, is that ActiveX won't stumble on cross-platform issues, leaving "whole Internet" developers hanging dry with promises they've made for future delivery and putting a big leak in that pool of interest and capital. There are endless piles of information on ActiveX available to everyone, and more sources pop up each day. With such a new and expanding technology, everyone's jumping on the bandwagon, and it's almost overwhelming. Where can you turn for more information on what's going on with ActiveX? Oh, where to begin... The authoritative guide to the world of ActiveX is Microsoft's ActiveX Software Development Kit (SDK). By programmers, for programmers, and not for the faint of heart, it's an extensive CD library of notes, specifications, examples, and errata. For quite some time, Microsoft has been making the general version of the SDK available to developers on its Web site to promote its use, and if ActiveX becomes a public open standard, the number of places you can get the most current SDK will increase exponentially. Right now, you can get hold of specs and samples at http://www.microsoft.com/activex/. Because ActiveX is really just some fancy additions to OLE controls, any and all resources out there on creating OLE or OCX controls will give you a great background into the more technical workings of the ActiveX world and how you can take advantage of it. Previous articles from technical journals, Web sites, and folks all over still hold valid information for the underlying mechanisms that make it all tick, and there's just a slight path to take you the rest of the way. When you design something for the Internet, it makes sense that the best sources of information are found there as well. Although a general search on ActiveX will turn up anywhere from one hundred to one million hits, the following sections describe a couple of top-notch spots to see what's going on, for either developers or people who are curious. ActiveXtra.com Two words sum up this site: Visit often. With news and views from the real world of developers and trade magazines, it offers a non-biased view of everything good and bad, as well as the technical information you need to survive. In addition, they plan to keep up a core list of ActiveX controls, tools, and vendors, which will give you everything you need in one well-organized package. The address is http://www.activextra.com. Microsoft Okay, so you'd expect to find Microsoft's Web site on this list, and I wouldn't want to disappoint you. Whether it's press releases, examples, conferences, bug lists, or technical help, Microsoft wouldn't dream of letting their brain child suffer for lack of stuff you can get hold of. Remember, though, that everything you find here will of course be from the viewpoint of the people who want it to succeed, and not all the help you might be looking for will be available. Advertising pitfalls is never a strong point in any company's strategy. That's what independent developers are there for. Find Microsoft at http://www.microsoft.com/activex. Individuals A number of individuals out there sprang up to take advantage of ActiveX technology and information very quickly. Although they don't have the time and effort to keep things up-to-the-minute, they're important because they're individuals who just want to see what the new stuff can do, like the rest of us. It would impossible to do justice to all of them in this short a span of space, so rather than single out any effort above the rest, I recommend that when you do your searches, you pick out a couple sites that don't look too commercial or biased, and you'll be pleasantly surprised at what you find. Last, but not least, don't forget the general community of active C++ and Visual Basic developers out there. Even if all of them aren't up to speed on ActiveX yet, a good number are, and even more have the background knowledge necessary to give you the advice you're looking for. ActiveX is coming. Don't be afraid. With a huge market to target and countless developers already drooling over what they could do with it, enthusiasm is high, as are expectations. Although failure of ActiveX is always a possibility, Microsoft stands in an excellent position to bring ActiveX to its full potential, if they can just clear the hurdles that they usually end up setting for themselves. ActiveX Controls push back the boundaries of what can and can't be done on the Internet. Instead of building new applications from the ground up, new controls can be added into existing programs to enhance their functionality, and even add Internet-awareness to otherwise locally-based programs. Dynamic download of these controls means that users can get what they want without pain and suffering, and developers can begin to aim their projects at users who will have increased functionality available.
   
|
