Eric Tall and Mark Ginsburg
PLEASE NOTE-USE OF THE CD-ROM AND THE PROGRAMS INCLUDED ON THE CD-ROM PACKAGED WITH THIS BOOK AND THE PROGRAM LISTINGS INCLUDED IN THIS BOOK IS SUBJECT TO AN END-USER LICENSE AGREEMENT (THE "AGREEMENT") FOUND AT THE BACK OF THE BOOK. PLEASE READ THE AGREEMENT CAREFULLY BEFORE MAKING YOUR PURCHASE DECISION. PURCHASE OF THE BOOK AND USE OF THE CD-ROM, PROGRAMS, AND PROGRAM LISTINGS WILL CONSTITUTE ACCEPTANCE OF THE AGREEMENT.
HTML conversion by :
M/s. LeafWriters (India) Pvt. Ltd.
Website : http://leaf.stpn.soft.net
e-mail :
leafwriters@leaf.stpn.soft.net
| Publisher | Stacy Hiquet |
| Acquisitions Editor | Brett Bartow |
| Contributing Programmer | Aleksandr Bayevskiy |
| Development Editor | Carol Henry |
| Technical Reviewer | Ivor Fergus |
| Project Coordinator | Ami Knox |
| Proofreaders | Joe Sadusky and Jeff Barrash |
| Cover Illustration and Design | Megan Gandt |
| Book Design | Paper Crane Graphics, Berkeley |
| Page Layout | Janet Piercy |
| Indexer | Valerie Haynes Perry |
Copyright © 1996 by Macmillan Computer Publishing USA. All rights reserved.
PART OF A CONTINUING SERIES
All other product names and services identified throughout this book are trademarks or registered trademarks of their respective companies. They are used throughout this book in editorial fashion only and for the benefit of such companies. No such uses, or the use of any trade name, is intended to convey endorsement or other affiliation with the book.
No part of this publication may be reproduced in any form, or
stored in a database or retrieval system, or transmitted or distributed
in any form by any means, electronic, mechanical photocopying,
recording, or otherwise, without the prior written permission
of Macmillan Computer Publishing USA, except as permitted by the
Copyright Act of 1976, and the End-User License Agreement at the
back of this book, and except that program listings may be entered,
stored, and executed in a computer system.
EXCEPT FOR THE LIMITED WARRANTY COVERING THE PHYSICAL
CD-ROM PACKAGED WITH THIS BOOK AS PROVIDED IN THE END-USER LICENSE
AGREEMENT AT THE BACK OF THIS BOOK, THE INFORMATION AND MATERIAL
CONTAINED IN THIS BOOK ARE PROVIDED "AS IS," WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION
ANY WARRANTY CONCERNING THE ACCURACY, ADEQUACY, OR COMPLETENESS
OF SUCH INFORMATION OR MATERIAL OR THE RESULTS TO BE OBTAINED
FROM USING SUCH INFORMATION OR MATERIAL. NEITHER MACMILLAN COMPUTER
PUBLISHING USA NOR THE AUTHOR SHALL BE RESPONSIBLE FOR ANY CLAIMS
ATTRIBUTABLE TO ERRORS, OMISSIONS, OR OTHER INACCURACIES IN THE
INFORMATION OR MATERIAL CONTAINED IN THIS BOOK, AND IN NO EVENT
SHALL MACMILLAN COMPUTER PUBLISHING USA OR THE AUTHOR BE LIABLE
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THE USE OF SUCH INFORMATION OR MATERIAL.
ISBN 1-56276-448-9
The authors would like to thank the following:
ActiveX is the "hot" technology of 1996. This book is about the core technologies that make up the broad range of tools Microsoft has introduced under the name ActiveX.
Our focus is to present sample applications that use the major pieces of the ActiveX Software Development Kit (SDK), including Visual Basic Script (VBScript), WinInet, OLE controls, and the Internet Server API (ISAPI).
In this Introduction we'll first take a look at how Microsoft came to develop ActiveX. Following that is an overview of what is in each chapter, and a description of the environment in which we developed our sample applications.
Microsoft Windows has come a long way since the product was first announced in 1983. The original version didn't ship until 1985, didn't work too well, and didn't come with any truly valuable applications. Things are different today: Since the release of Windows 95, over 20 million units of that version have been sold, with expected sales of 50 million units by the end of 1996.
The Internet, too, has grown considerably since it evolved from its humble beginnings in the 1970s as the ARPAnet, a Department of Defense-funded 56K network intended primarily for academic institutions. In 1991, Tim Berners-Lee at the Geneva, Switzerland, High-Energy Physics Center(CERN) invented the Hypertext Transport Protocol (HTTP). This made possible The World Wide Web (WWW), and the popularity of the Internet exploded. Now, for the first time, hypermedia could be published quite readily using a simple PC or Mac, for the whole world to see.
The WWW is a distributed hypermedia system that conveniently makes use of existing network protocols (TCP/IP) for packet routing, and has a lightweight and inherently stateless protocol (HTTP) between client (the information requester) and server (the information provider). Network traffic on the WWW is growing exponentially. Going the way of the dinosaur are the old command-line network services-FTP, Telnet, and Gopher-which have all been subsumed by the HTTP protocol and therefore available transparently to the Web client.
Furthermore, the Web conveniently offers a flexible and extensible representation of data types. When a Web server passes data back to a Web client, a Multipart Internet Mail Extension (MIME) header identifies the medium type as ASCII text, HTML, audio, video, and so on. As third-party developers invent new media and the software to view it, the client MIME configuration files can be arbitrarily lengthened.
Also fading as the old Internet gave way to the new was Acceptable Use Policy (AUP), which precluded crass commercialism on the National Science Foundation (NSF) backbone pipes. In 1995 and 1996, as the NSF stopped subsidizing the infrastructure, AUP disappeared entirely, opening the floodgates for big and small firms alike to try their fortunes on the ëNet.
The flagship year for the World Wide Web was 1994. Graphical Web browsers were developed and released into the public domain, first by CERN, then by NCSA, making it a (relatively) simple matter to navigate the Internet. Support was soon added for VT-100 ("dumb terminal") browsing using the University of Kansas's Lynx package. On the server side, NCSA programmers such as Eric Bina and Marc Andreesen were soon hard at work improving the original HTTPd CERN software.
Windows, as well as Web browsers such as Mosaic, sport a graphical user interface (GUI) that has contributed significantly to making both the technologies popular. Both can be considered a single-platform environment: In the case of Windows, the platform is Intel-based PCs running MS-DOS; in the case of the Web client, the platform is, of course, the Internet. Both Windows and Web clients have evolved over time from the original hacked, prone-to-crash implementations into robust, usable, and productive technologies. In particular, Web clients are evolving into more than simply WWW browsers. They are also folding in advanced SMTP mail interfaces, collaborative workflow applications, and more. The client footprint is growing.
A GUI interface to computing, whether it be a Windows, Apple, Sun, or other version, has substantially increased the user's productivity. Likewise, a GUI interface to the Internet has enabled users to become significantly more communicative.
Until now, Windows and the Web existed in separate worlds-"bifurcated," to quote Microsoft. Accessing the Internet via a browser such as Mosaic was just another application running on your machine. Getting information off and on the Internet often required convoluted conversions between the source and target forms of data. Text is the most common type of data exchanged on the Internet, and all sorts of filters, macros, and programs have been developed to convert word-processed documents to or from HTML. Even with graphics, what looked good in print frequently needed adaptation for publishing on the Web.
Now Microsoft wants to bring Windows and the Web together. To nobody's surprise, Bill Gates admitted that Microsoft hadn't expected the Web to grow so rapidly. Fortunately, Microsoft has the resources to quickly redress this short-term tactical oversight. The company's new outlook is of a world where the user has just one interface to deal with. Rather than having two separate environments and two user interfaces existing on the user's desktop, Microsoft envisions an interface based largely on the Web browser model, integrated with the Windows interface. This is the first key idea behind the ActiveX SDK.
The second theme of ActiveX is "leveraging existing technology." Microsoft has grown rich and powerful selling its own products, mainly the operating systems. The popularity of Microsoft products is in part due to the huge amount of continuing independent software vendor (ISV) support for the various Microsoft operating systems.
Microsoft wants to retain that support. Indeed, the company regularly acquires ISVs whose technology they want. With this in mind, Microsoft does not want ISVs to have to develop everything from scratch. The developer should be able to adapt existing products to work within this vision of Web/desktop integration.
ActiveX was designed around this philosophy, building upon Microsoft's Component Object Model (COM), OLE technology (what used to be called Object Linking and Embedding), and APIs such as Win32. Instead of throwing a whole new model at the development community, ActiveX builds upon these well-established Microsoft models. For example, the developer can take an existing product such as an OLE control and adapt it with relatively minimal effort to work within a Web browser. This "leveraging" by Microsoft virtually ensures that ActiveX will bring about an important evolution of the Web environment.
The simplest-and broadest-definition, then, of ActiveX is "anything that Microsoft can give to the developer community that will foster this merging of Windows and the World Wide Web, all while allowing the developer to leverage existing technology."
In terms of leveraging a stable OS (NT and, to a lesser degree, Windows 95) with a distributed programming environment, the concepts put forth by Microsoft and embodied by the ActiveX SDK fit this goal very well.
The first and foremost of these concepts is, of course, standards. Indeed, standards helped make Microsoft what it is today. MS-DOS wasn't perfect; nor was the IBM PC. But once the computing population began to settle on MS-DOS (and a few others) as a de facto standard operating system, and the IBM PC as one of the standard PC hardware platforms, the microcomputer revolution began. Microsoft has long argued that the setting of preemptive standards by a regulatory body is often premature in the technology industry. One of the company's white papers speculates that if the government had intervened in the PC arena, we would now be standardized on TRS-80s.
There is something to this argument. If Microsoft can consistently be the first to demonstrate working, prototype standards, and if their user base reacts favorably, the result will be fantastic momentum toward extending the base architecture in even more innovative directions. Microsoft's commitment to drawing third-party support for ActiveX can be measured by its willingness to publish the necessary APIs, encouraging developers and users alike to jump on the Microsoft ëNet object bandwagon-instead of lining up with assorted UNIX-based rivals.
The Internet, too, is built upon standards: a core set of standard protocols including TCP/IP, SMTP, and others. While the Internet was steadily gaining popularity as a means of worldwide communication, the HTTP protocol was adopted as a standard. This ushered in another revolution in the computing world, beginning with the World Wide Web. The Internet's standards, however, are set by an Internet Engineering Task Force (IETF), and the interplay of research and commercial interests makes for a very interesting story here.
In reality, the technology is moving so fast that preemptive standards setting, or even ad-hoc industry agreements, are very hard to initiate or maintain. Major R&D players like Sun Microsystems and Microsoft have the resources to introduce first-mover innovations, and the smaller niche players usually follow suit by developing software to extend the vision. We see this playing out with Microsoft's embrace of Java at the OS level, while continuing unimpeded to develop competing technology revolving around DCOM and the ActiveX toolkit.
MS-DOS has been superseded in recent years by the 32-bit versions of Windows. Microsoft has been steadily developing standard technologies for programming 32-bit Windows applications, centered around COM, OLE , and the Win32 API. Today, Windows programmers can expect to use a coherent set of programming tools and methods that help them develop new applications relatively quickly and efficiently. They don't have to know, for example, all the details of the hardware they are writing for. These programming standards allow developers to reuse and share their efforts with other developers. As mentioned above, ActiveX takes advantage of these Windows programming standards and fits in with the Microsoft business plan of enabling developers to leverage existing technologies.
Microsoft has also embraced the concept of openness-that is, making the Windows platforms an open and extensible architecture. The traditional systems professional, grounded in UNIX, would think openness the antithesis of Microsoft and its strict adherence to proprietary solutions. But Microsoft does present an interesting interpretation of the word openness: that the operating system kernel should be considered a set of building blocks, not a monolithic application with which the developer or user has to interface.
A good example of this definition of openness is what Microsoft has done with its Internet Explorer browser. Microsoft techies are fond of saying that they "ripped it apart" and rebuilt it with the Windows building blocks, making the 3.x version of Explorer a document container application that also just happens to understand HTML tags. When a user opened a Word document with Explorer 2 (or with that "other" browser, for that matter), a pop-up box appeared announcing an "unknown file-type" or something similar. The user would then have to save the file to disk and open Word in another window to view the document. With Explorer 3 acting as a document container, and with Word available on the user's local PC acting as a server, a link to a Word document will launch Word within the browser frame, obviating the need for the user to run Word in a separate window.
OLE technology has been available within native Windows applications for some years, but the point here is that the user will eventually be able to execute quite a few applications within the context of a Web browser, without having to launch them in a separate frame.
This brings us to the present day, and the imminent release of new versions of Windows 95 and Windows NT. The new versions will achieve the unification of WWW and Windows desktop that Microsoft seeks. The ActiveX SDK comprises a set of tools provided by Microsoft that enable you to take advantage of this link between the desktop and the Web.
The material in this book is intended for Windows and Web developers who want to know what ActiveX is about, and want to begin using it immediately in their applications and/or Web sites.
If you develop commercial Windows applications, you will need to learn about ActiveX if only to stay competitive. Microsoft wants third-party developers to use this new technology to make their applications "Internet aware," so you can expect that your peers will be using the ActiveX tools.
Similarly, if you are a Web developer you'll want to read this book to learn how to incorporate ActiveX technologies into your current and future sites. The Web has become increasingly interactive and multimedia oriented. (1994 and 1995 saw CGI pushed to the limits and ushered in plug-ins as well as other technologies.) A static home page will before long be "old-fashioned." Incorporating even simple ActiveX technologies into a Web site will allow the developer to stay on the cutting edge of Web development.
This book is not meant to be, nor can it be a "comprehensive" document. The industry is moving too fast for that; Microsoft is moving too fast for that. What you will find here is help in getting a firm grasp on the programming principles and techniques needed for using and understanding the ActiveX tools. These principles will hold, even as ActiveX is extended and enhanced by Microsoft or third-party vendors.
We have attempted to produce a book as modular as possible. When you find a need to learn a particular set of tools, you can go directly to the appropriate chapter or section and find the information you want, without having to read preliminary material. For some subjects this was not possible, and in those cases we direct you to whatever additional sources you need to explore.
This book is organized into the following chapters:
In Chapter 1we define ActiveX and provide an overview of what is in the SDK. We'll also look at a couple of the tools you can use to develop ActiveX applications.
This chapter is about VBScript, with an overview of the language elements followed by several sample applications. We'll also look at a couple of other tools for managing HTML Content: the ActiveX Control Pad and Cascading Style Sheets.
Here we examine the Component Object Model, which is the underlying technology behind much of ActiveX. We will define COM and look at an example of a COM object and a client application that can access that object. We'll also discuss a couple of the low-level ActiveX enhancements to COM technology.
Here you'll find ActiveX extensions to the Win32 API, also known as the WinInet API. These extensions help you create programs that can add data from the Web into nonbrowser application windows, without the user having to cut and paste from a separate application. Examples of using the WinInet API are discussed, including embedding data from the an Internet source as objects into document windows.
Formerly known as OLE Controls, ActiveX controls are software components that the developer can plug into an application. In this chapter, sample controls appropriate for use in a Web page are built from the ground up using Visual C++. We'll also look at scripting these controls using VBScript.
The ICP is a handful of new ActiveX controls that can be used to make Windows applications "Internet aware." This chapter presents an overview of the major Internet protocols relating to the controls. Following that are Visual C++ and Visual Basic examples of using several of the controls, including the FTP, POP3, SMTP, NNTP, TCP, and UDP controls.
The Internet Server API can be used to create extensions to an http server-either replacing a traditional CGI application, or acting as a filter before sending the client request on to another filter, application, or the server itself. We'll examine the API and the ISAPI Microsoft Foundation Classes, and study some sample ISAPI applications.
This chapter covers the fundamental cryptographic principles underlying secure Internet communication. It then moves on to cover two important implementation examples: ActiveX services for the "safe" and automatic download of code (such as an ActiveX control) via trust verification; and the Microsoft CryptoAPI, which allows developers to add cryptography services to their applications. We also discuss Microsoft's Secure Electronic Transactions (SET) initiative in the exploding field of Internet-enabled electronic commerce.
The Conferencing SDK is a separate kit that was added to the Microsoft Web site shortly after the ActiveX SDK was put online. This chapter describes Microsoft's NetMeeting product, which uses the conferencing API. We'll also give an overview of a few other "Active" technologies from Microsoft.
Most of the programs described or developed in this book were developed using the following Microsoft products:
http://www.microsoft.com/intdev/
Most of the applications in this book were built with Visual C++
versions 4.1 and 4.2, on NT and Windows 95 systems. Chapter 6
on the Internet Control Pack, includes two examples using Visual
Basic. Chapter 7 covering the ISAPI, requires the Internet Information
Server to run the sample applications (IIS only runs on an NT
system).
| NOTE |
The CD included with this book contains the source code and project workspace files for the book's sample applications. (See the Appendix for a listing.) The subdirectories for these projects include either a debug or release version of the application that we built and tested on one of our machines. Be advised that you may need to rebuild an application when trying it out, because NT, the ActiveX SDK, the Win32 SDK, and Visual C++ are frequently updated. The versions of Microsoft software with which we built these applications may not exactly match the versions on your machine. |
Generally speaking, when developing applications with the Visual C++ compiler, you'll need 32ñ64MB of RAM, and a 75MHz or better Pentium system. Although Visual C++ will run on a slower system or a machine with less RAM, it tends to be painful.