What is ActiveX? That's a good question that even Microsoft itself hasn't been able to answer easily. In one sentence: ActiveX is anything that Microsoft can give to the developer community that will bring about the integration of the computer desktop environment with the environment that makes up the Internet and its myriad resources and potential, all the while leveraging existing developer investments in Windows technology. That is a big sentence, but it's not so hard to digest.
ActiveX comprises a series of extensions and enhancements to two existing Microsoft technologies: the Windows 32-bit Application Programming Interface (Win32API), and the Component Object Model (COM), upon which Object Linking and Embedding (OLE) applications are built. To get these extensions into the mainstream developer community as rapidly as possible, Microsoft has made available the ActiveX Software Development Kit (SDK). The SDK can be downloaded via the Microsoft Web site (see Figure 1.1) at
Figure 1.1 : A page from Microsoft's Internet Development Web site.
http://www.microsoft.com/intdev/
The ActiveX SDK, in both the alpha and beta releases, includes a slew of programming tools, examples, and documents-more than enough for several books, in fact. This book will focus on the core of the ActiveX SDK, including the following:
This chapter briefly covers the topics necessary to get started working with the ActiveX SDK. You'll read a brief history of how Microsoft came to develop ActiveX; descriptions of the ActiveX Software Development Kit components; instructions for installing it; and a rundown of the other software necessary or useful for programming ActiveX applications. Let's start with the short history lesson.
Microsoft did not have a discernible Internet strategy until an important press conference in December 1995, when Bill Gates announced a broad vision for his company's plans for the future. Also in that month, Microsoft's Web site offered a new software development kit (SDK), code-named "Sweeper." This finally became a blip on the public's radar screen in March 1996, at the Professional Developer's Conference (PDC) in San Francisco, where Microsoft demonstrated the power of the new tools, renamed ActiveX.
The ActiveX demos were impressive despite occasional technical difficulties. Microsoft and other industry leaders presented VBScript, an implementation of OLE Scripting; ActiveX Controls, for embedding OLE Controls into HTML documents; ActiveX Conferencing, which enables sharing data as well as applications over TCP/IP; the Internet Control Pack, allowing developers to make their applications Internet aware; and numerous other ActiveX technologies.
The conference speakers described the ActiveX Tools as evolutionary rather than revolutionary, having been grown and nurtured over the years by Microsoft and other companies. An analog of VBScript, for example, has been seen on the Web in the form of JavaScript, and Visual Basic for Applications (VBA) has been a part of Microsoft applications for years. With ActiveX, scripting is enabled through the new OLE Scripting Service, which lets developers adapt a wide range of scripting languages for use in other environments besides a Web browser. In fact, the alpha version of Microsoft's Internet Explorer browser understood both VBScript and JavaScript; subsequently, the beta version released in July 1996 included full-blown Java support.
Similarly, the ActiveX Controls (formerly known as OLE Controls) are not new technology. What is new is that thousands of software developers can adapt their existing controls to work within a Web browser, such as Internet Explorer. Indeed, a major theme of the PDC was the leveraging of the existing technology of independent software vendors (ISVs)-without their having to rebuild their products from scratch.
The ActiveX controls are seamless on the Web client side, with automatic download and verification of the underlying code built into the specification. This is a major improvement over two existing Web technologies: Netscape plug-ins and Java applets. Netscape plug-ins must be downloaded and installed before using. Java applets (small pieces of network bytecode transmitted server-to-client across TCP/IP) must be rewritten by the ISV in the Java language, which is nearly as complex as C++. With ActiveX Controls, ISVs can adapt their existing products to work on the Web. This is a significant development not just for the look of the Web, but also for software vendors, who can expect to expand their market.
ActiveX Tools and ActiveX Controls exemplify another theme of the PDC: "activating the Internet." Currently, interactivity on the World Wide Web (WWW) is provided by two disparate technologies: increasingly complex Common Gateway Interface (CGI) scripts, which stretch server resources to the maximum; and client-based solutions such as Java and specialized plug-ins. ActiveX is a more coherent, integrated environment for adding interactive content to a Web site.
Underlying the ActiveX environment is the third and most significant theme of the Conference: Microsoft's integration of the Windows desktop and the WWW browsing model into one seamless "experience." The most striking example of this integration is the rebuilding of Internet Explorer into a simple document-container application, capable not only of browsing the Web, but also of hosting data from other Windows server applications such as Word or Excel. For the user, this means not having to open a window outside the Web browser when encountering a hyperlink to another application's document. By selecting the link, the document can be viewed or edited within the browser. This document doesn't even have to be located on the user's PC or local LAN, but can be anywhere on the Internet. The user's desktop/LAN are literally extended to seamlessly include the entire Internet, available via a click of the mouse.
Earlier we stated that ActiveX is not revolutionary but evolutionary technology. Let's review a bit of industry history and see how Microsoft has been following a path to ActiveX for many, many years.
In the early days of microcomputing (1980-1985), various companies attempted products that would "do everything" for the end user-Symphony, Jazz, and Framework are a few examples. These huge, monolithic programs were intended to provide, in one single package, all the functions a user would ever need to be productive. These superapplications all failed to one degree or another, mainly because they always lacked at least one other application or feature the user needed. To compound the inadequacy, the user either couldn't run the applications simultaneously, or data could not be easily shared between the monolith and the other applications.
Bill Gates publicly criticized the "do-everything" concept, insisting instead that integration should be at the operating system (OS) level, not at the application level. IBM attempted this sort of integration with its Systems Application Architecture (SAA), which would have integrated the various mainframe, mini-, and microcomputers that IBM built into a seamless user and developer interface. The SAA vision failed to be accepted; many of its concepts were never translated into working code on various platforms.
While Microsoft was building Windows into a robust and stable platform, the integration between desktop applications began. Object Linking and Embedding (OLE) version 1.0 was introduced in the early 1990s. OLE 1 allowed a user to place data from one application, such as an Excel spreadsheet, inside another application's data window, such as a Word document. This was the first step toward Gates's goal of OS-level integration.
OLE 1 became OLE 2, which introduced "visual editing," whereby a user could access the functionality of one Windows application within the frame of the currently active application. For example, by double-clicking on that Excel spreadsheet in the Word document, the user could edit the spreadsheet in place, without having to open a separate Excel window.
OLE 2 eventually became just OLE and was no longer merely an acronym for object linking and embedding. With today's OLE, applications can be programmed as "objects" (there are many definitions for that word), which can act as separate applications and be used by other applications as needed. OLE enables developers to create software "components," code modules usable by other applications or components. Entire applications can be constructed from these building blocks, much as one would assemble a model plane from a kit.
Microsoft has put out a significant amount of documentation on OLE, including the comprehensive Web site at
http://www.microsoft.com/oledev/
illustrated in Figure 1.2.
Figure 1.2 : Microsoft's OLE Development library begins here.
OLE is built upon the Component Object Model (COM), which is discussed more fully in Chapter 3 Rather than a programming tool in itself, COM is a specification for an extensible architecture in which services can be seamlessly added. In many respects, COM is the current manifestation of what Bill Gates talked about back in the early 1980s: integration at the OS level.
COM allows for growth even beyond desktop integration, to include the vast resources and power of the Internet. This is what ActiveX is truly all about. Of all the proposed definitions of ActiveX, perhaps the simplest and best is "a set of tools, conforming to the COM spec, that lets a developer use new or existing tools to integrate the computer desktop environment with the World Wide Web environment."
The base COM specification is fairly stable, because part of the spec allows for further extensibility. ActiveX is an emerging technology and will continue to grow.
This book's examination of current ActiveX tools will give you a firm foundation to begin using and exploring those tools. The starting point is, of course, the ActiveX SDK. In addition to the SDK itself, you'll also want to get familiar with a few other Microsoft tools introduced in this chapter and used throughout the book. These tools include Microsoft's Internet Information Server (IIS), the ODBC connectivity tools, Visual Basic, and Visual C++ (VC++).
Don't feel constrained to use Microsoft products exclusively. It is not necessary to use IIS, for example, to deliver HTML documents with embedded VBScript or OCXs. Nor is it necessary to use Microsoft's VC++ compiler to create applications. For the purposes of instruction, however, it is much simpler for us to focus on one set of tools. That said, let's look at the ActiveX SDK.
A Microsoft SDK is not a retail-style, nicely packaged product filled with easy-to-use manuals. You should definitely take the time to open up the SDK in either File Manager or Explorer and look at everything that is in the kit. Although the ActiveX installation program described below will set up critical files needed for developing applications in Visual C++, there are a number of directories that you should pay attention to after installing the SDK.
You should expect that the contents of an SDK can change significantly between releases. When we started to write this book, we had only the alpha version of the SDK. The first beta version included a number of new documents, and several documents and example applications from the alpha version had disappeared. The ISAPI material, for instance, was moved to the Win32 SDK. Meanwhile, several example programs from the alpha version vanished-SurfBear, for instance. The material in this book is based on the first beta version, not the alpha.
You'll want to carefully check the contents after installing a new version of the SDK, and we highly recommend keeping prior versions around for a while at least.
The ActiveX SDK is included on this book's CD-ROM. The SDK can also be retrieved from Microsoft's Web site via the link
http://www.microsoft.com/intdev/sdk/
Follow these steps to install the kit:
| NOTE |
You'll need to use a program such as WinZip, which understands long filenames. An eval copy of WinZip, recommended by Microsoft, can be downloaded from http://www.winzip.com/. |
SETUP.EXE will copy files appropriate to your platform (Win95 or NT). It adds a program group to the Start Bar containing links to a readme file with the latest updates to the SDK, and a couple of HTML files containing indexes to the \Help and \Specs subdirectories. These HTML files do not, however, list all of the documents in the SDK, so remember to look around in File Manager for additional readme or .txt files.
At this point, you can proceed to compile the sample ActiveX applications.
If any significant errors occur during compilation, consult the readme file in the \INetSDK directory. After that, each of the subdirectories have Makefiles that can be adapted as necessary.
In this section we will take a walk through the beta version of the SDK. This isn't meant to be a complete listing of every program in the SDK but will highlight a number of interesting example programs that will give you a taste of the possibilities opened up through the ActiveX extensions.
Our quick tour is organized around the six directories in the \INetSDK installation directory.
The \BIN directory contains a number of security-related utility programs for adding verification keys to code files for "safe downloading." In Chapter 8we'll talk about these files and a few other security issues.
Also in the \BIN directory are files for creating distribution versions of ActiveX programs; several registry edit (.reg) files to change the settings for Internet Explorer; a couple of utilities such as OLEView and the ODS Tool; and a couple of binaries for setting up a User Location Service.
The \HELP directory contains a somewhat diverse collection of HTML documents. The contents page for this directory is show in Figure 1.3. The files here are important and deserve your attention, but they don't really do justice to the core of ActiveX.
Figure 1.3 : Contents of the \HELP directory in the beta version of the SDK.
The \SPECS directory contains over 5MB of Word documents and HTML files. This is the place to really get into what's going on with ActiveX. The starting point is Overview.Htm, which contains links to the other .htm and .doc files in the directory. However, beware of relying on these files as the "final word"-here and there, the documentation is inaccurate or out of sync with the actual implementation.
The \INCLUDE directory contains header and other files needed for compile-time support. This directory holds the files that will become your best friends when you're developing ActiveX applications. The header, typelib, and object definition files in this directory represent the definitive documentation for the SDK in terms of creating programs in VC++. For us, the online documentation occasionally specified something that simply refused to work properly (such as a parameter type). By consulting the appropriate header file, we were able to resolve the difficulty.
The \LIB directory contains library files need for compile-time support. The setenv.bat file puts this directory before other directories in terms of search preference.
The abundant \SAMPLES directory contains source code for an assortment of Microsoft sample applications.
Figure 1.4 : The Framer application hosting a Word document.
Figure 1.5 : Sproids, as played by a beginner.
Figure 1.6 : The Progress dialog application.
Figure 1.7 : URLPad displaying the HTML for the Microsoft home page.
Figure 1.8 : Another Hangman winner.
Figure 1.9 : The AsyncFTP application.
| NOTE |
You'll also want to take a look at the SurfBear application on the Microsoft Web site at http://www.microsoft.com/intdev/prog-gen/inet-f.htm, which uses WinInet to retrieve raw HTML across the network. |
Now that we've looked at the ActiveX SDK itself, let's turn our attention to a few of the tools you might want to have on hand to develop ActiveX applications.
Not all of these programs are required to develop ActiveX applications. For example, the Internet Explorer installation program sets up the appropriate files necessary for it to understand VBScript and JavaScript. Web pages that contain such scripts do not need to be served by Microsoft's Internet Information Server-any Web server will do. Similarly, OLE controls can be developed in languages other than Microsoft's Visual C++. In general, however, you will find it easier to work with the Microsoft tools described below.
The first version of Internet Explorer, Microsoft's Web browsing tool, was an add-in to Word that allowed the user to (slowly!) browse the Web. Version 2, released as a standard, separate application, was a huge improvement. The final level-2 release, available on a variety of platforms, is compatible with the HTML 2 and 3 specs.
Now Internet Explorer 3.0, as shown in Figure 1.10, brings the browser closer to industry standards and incorporates features not readily available in other browsers. Beginning with the alpha version 3, Explorer has been rebuilt into a Windows document-container hosting application that also understands HTML. This key feature is what sets Internet Explorer apart from other browsers. The latest Explorer version also incorporates a few Microsoft-specific enhancements.
Figure 1.10: The Internet Explorer 3.0 home page.
| NOTE |
Explorer 3.0 generally conforms to the HTML 3.2 specification announced at the Fifth World Wide Web Conference, May 1996, in Paris. You can get full details about this conference at. |
http://www5conf.inria.fr/
Following are a few Explorer enhancements that are new to the browser playing field:
Internet Explorer 3.0 is still in beta form, but its popularity is growing as it incorporates features found in other browsers and adds the enhancements mentioned above. The code presented in this book assumes the reader has IE 3.0 beta or better. The alpha version of IE was included in the ActiveX SDK but is now a separate downloadable file, available at
http://www.microsoft.com/ie/
The Web server originally released by Microsoft was a repackaged version of the EMWACS server for NT. Today, the Internet Information Server (IIS) is all original Microsoft code, according to one Microsoft source. IIS offers the features expected of today's Web servers, including built-in security, support for virtual domains, directory aliasing, and the ability to manage other servers on a local network.
By the way, EMWACS, one of the original servers for NT, is still available at
http://emwac.ed.ac.uk/html/internet_toolchest/https/
By default, setup.exe will offer to install IIS in the following directories: \wwwroot, \ftproot, \gopherroot, and \scripts. As usual, it's a good idea to do a little planning for your installation. Consider the following:
The IIS Internet Service Manager (Figure 1.11) gives you control of most aspects of IIS administration.
Figure 1.11: The IIS Internet Service Manager's Report view.
Selecting a service to administer brings up the Service page of settings (Figure 1.12), where you can control various properties of the service. The Anonymous Logon and Password Authentication properties in this page are discussed in the upcoming section on NT Security. You can use the Comment field when users are working in a multiserver environment and you want to add some identifying information about your server, such as its function or purpose.
Figure 1.12: Service properties for a WWW server.
In the Directories page (Figure 1.13), you configure directory aliases for the server. In this example screen, three directories have been added: two that allow access to directories where the ActiveX toolkit is installed, and one for a \projects subdirectory where Visual C++ is installed. Also, note that the options for Enable Default Document and Directory Browsing Allowed are global options for the server, regardless of whether a directory on the screen is selected.
Figure 1.13: The Directories properties for a WWW server.
Figure 1.14 shows the specific Directory Properties dialog for setting a few other options specific to a particular directory. With this screen it is possible to add virtual host names when a multihomed host is being configured. In this case, there are additional network considerations, such as a properly configured domain name and IP number.
Figure 1.14: Directory Properties dialog for a virtual directory.
For HTML directories, set the Access option to Read. For script/program directories, allow only Execute access, particularly if directory browsing is allowed on the Directories property page.
The Logging page in Figure 1.15 shows the options for logging access to the WWW server. Here you specify logging server access to either a file or an SQL/ODBC database. If you aren't sure that it is wise to store the log data in an ODBC table, it's a good idea to choose Log to File. Later, the Bulk Copy program (bcp.exe) can be used to add the log file data to an SQL table, because the data is stored in a comma-delimited ASCII file. However, keeping log files is recommended.
Figure 1.15: The Logging properties for a service.
The Advanced page of service properties (Figure 1.16) allows the developer to limit access to the server by IP number and/or the amount of network traffic. Note that (like the directory options) these Advanced properties are global settings that will affect all Internet services and directories. Use these restrictions with care, particularly if the server is a multihomed host.
Figure 1.16: The Advanced properties for a service.
NT security has been described as "strange" by at least
one administrator we know. It is substantially different from
the simple UNIX user and group model. Handling security through
the Windows GUI may appear simple on the surface, but we advise
you to study how security works under NT.
| NOTE |
Windows NT 3.5 Guidelines for Security, Audit, and Control, published by Microsoft Press, is the definitive text on NT security. |
The IIS installation procedure by default adds to the host machine a user account with the name IUSR_[domain] (the domain name for the NT system on which IIS is running). A password is generated for the account, and the user ID and password are added to all of the service's property sheets, with Anonymous or Guest access. This user ID is what will show up in the access log.
Microsoft recommends that the password be changed in the User
Properties dialog (see the User Manager for Domains option in
the Administrative Tools menu).
| WARNING |
It is essential that the IUSR_ password not be blank! The IUSR_ account must have the right to "log on locally," as shown in the User Rights Policy dialog in Figure 1.10. If the password is left blank, anyone can log on to the overly trusting machine as the IUSR_ user. |
You can restrict directory access to only valid NT users having the privileges to access those directories. This works similarly to the NCSA scheme of protecting directories. Attempts to access the directory will be met with the familiar Userid/Password box. A user without both a valid account and the proper Read or Execute rights to the directory will receive an authorization failure.
Here are the steps we took to protect specific directories on our test NT workstation:
This notion can be extended to the file level. However, bear in mind that the further down into the directory tree you set privileges, the more administrative headaches you'll have in the future.
Also, it's important to note that some unspecified limitations exist on the number of users an NT system can support. Trade magazines report rumors that the machinery creaks a bit when the user load exceeds 1,000 or so.
Given the potential pitfalls of relying on NT for security, we recommend developing a custom authentication scheme for restricting access to Web pages-one that bypasses the built-in NT security system-and passing the Web user requests through an ISAPI filter.
The Internet Database Connector (IDC) is built in with IIS. Though not a part of the ActiveX SDK, it's worth mentioning as another "free" tool from Microsoft. (Well, almost free: If a Web site is using Microsoft SQL Server to publish public Web pages, an unlimited license must be purchased. The IDC itself is free, and if another data source such as Access or FoxPro is used, then there is no license fee for publishing data on the Web.)
The IDC allows the developer to query ODBC-compliant databases such as MS-SQL, Access, and FoxPro, and then pass the results back to the client in HTML format. This exchange is accomplished by first creating a Post method form, which calls an .idc file containing an SQL query. This file also contains the name of an output format (.htx) file that defines how the output will be displayed to the client.
Database interface tools such as IDC are almost as old as the Web itself, and Microsoft's version is not the first to hook into ODBC-compliant data. Among similar tools worth investigating are WebDBC from Nomad Development, available for evaluation at
http://www.ndev.com/
and Cold Fusion from Allaire, available at
http://www.allaire.com/
Both offer significantly more functionality than IDC at this time. Microsoft has indicated that IDC functionality will be enhanced in future releases.
The programming language BASIC, yesterday's stepchild, has seen a dramatic revival in recent years. In its new clothing as Visual Basic, it has been extended to be a GUI window painter and a code builder, and even sports a compiler to generate distributable *.exe executable modules. Who would have dreamed in the early 1980s that Microsoft would extend BASIC to support object-oriented notions of classes, methods, and inheritance? Yet that is precisely what has happened.
Today's enhanced version of Visual Basic is used by thousands of developers. In addition to the stand-alone version, there is an application-level version, Visual Basic for Applications (VBA), which facilitates automation of programs such as Word and Excel.
As you'll see in Chapter 3 C++ lends itself naturally to development of COM and OLE programs. This does not, however, invalidate the effectiveness of other languages, including Visual Basic, for such development. In the June 1996 issue of Microsoft Systems Journal, Joshua Trupin describes in three paragraphs how to write a "…simple, yet highly functional Web browser and ActiveX document shell…" using Visual Basic. No wonder VB is so popular!
Although this book focuses on using Visual C++ to develop ActiveX programs, Chapter 6also gives examples in Visual Basic. For "quick and dirty" applications, or in situations where performance is not necessarily an issue, there is often no reason not to use Visual Basic.
Visual Basic comes with a number of OLE controls that can be embedded into Web pages with the <OBJECT> tag. In Chapter 2you'll see an example of how to use the graph32.ocx to display data retrieved from an SQL query.
The VB help pages on a particular control will provide all of the proper <PARAM> field names and the type of data expected. The Class ID of the control can be found in the system registry.
Microsoft's Visual C++ is used to develop examples in this book. Beginning with the 4.1 Subscription Update, Microsoft has added ActiveX-related MFCs, project creation wizards, and sample applications to Visual C++ and the Developer Studio front-end. This book is not a tutorial on VC++ itself, but we will walk you through the steps necessary to create the sample applications in this book.
If you are studying the source code for the sample programs in the ActiveX SDK, it's a good idea to create project workspaces for the various samples. Here are the steps to create a workspace for the Progress example discussed in Chapter 3.
progress.exe: progress.obj progress.res
$(link) $(lflags) $(ldebug) -out:progress.exe progress.obj progress.res
$(olelibs) urlmon.lib
uuid3.lib
Figure 1.17 shows a ClassView screen for the Progress application workspace.
Figure 1.17: The ClassView screen for the Progress application.
The 4.1 Subscription Update to Visual C++ offers a number of new MFC classes, sample applications, and third-party OLE controls. Five new ActiveX-related classes have been added to support ISAPI: CHttpServer; CHttpFilter; CHttpServerContext; CHttpFilterContext; and ChtmlStream. These classes are discussed in Chapter 4 along with a new Setup Wizard for creating ISAPI applications.
To aid developers in creating Component Object Model (COM) objects, Microsoft has created the ActiveX Template Library. Installing this kit adds an AppWizard to the New Project Workspace menu. This allows the user to generate a skeleton COM applications. Chapter 3discusses COM, the AppWizard, and the template library.
The ActiveX Template Library is available on the Microsoft Visual C++ Web page at
http://www.microsoft.com/visualc/
The Win32 Software Development Kit, available via the Microsoft Developer Network, is a necessary item for developing some ActiveX applications. This includes applications using APIs such as WinInet, WebPost, and Hyperlinking. Aside from this, the Win32 SDK is an overall "must have" for any serious developer. In addition to the Win32 and other SDKs, it also includes a number of utility programs, reference material, and source code for developing applications in the Windows environment.
You can get information on subscribing to the Developer Network at
http://www.microsoft.com/msdn/
In addition, you should regularly take a look at Microsoft's Win32 Web page, shown in Figure 1.18. This site regularly contains updates and sample source code.
Figure 1.18: The Win32 Web site contains regularly updated articles and source code.
Since the December 1995 Bill Gates press conference, Microsoft has posted a steady stream of free and beta tools, utilities, and even graphic and sounds files to the Microsoft Web site. These include FrontPage, dbWeb, HTML viewers, and conversion programs for Word, Excel, PowerPoint, and other Microsoft programs. Descriptions of these tools are beyond the scope of this book, and we encourage you to investigate Microsoft's Web pages to learn more about them. For example:
http://www.microsoft.com/frontpage/
In addition, Front Page has Web server extensions that let you administer locally connected Web servers. These extensions are available for a variety of OS platforms, including NT and a variety of UNIX platforms.
http://www.microsoft.com/intdev/dbweb/