Microsoft Developer Network Start Page

MSDN Library
Visual Studio 6.0 release

The MSDN Library is the essential reference for developers, with more than a gigabyte of technical programming information, including sample code, documentation, technical articles, the Microsoft Developer Knowledge Base, and anything else you might need to develop solutions that implement Microsoft technology.

The MSDN Library is a member of the Visual Studio 6.0 family of development products, which includes:

  • Visual Basic
  • Visual C++
  • Visual FoxPro
  • Visual InterDev
  • Visual J++
  • Visual SourceSafe
  • MSDN Library
Jump to the Visual Studio 6.0 Start Page.

Copyright
Accessibility Information

Dr. GUI's Espresso Stand
Dr. GUI introduces the Visual Studio 6.0 release of the MSDN Library.

What's New on the Library
Click here for a comprehensive hotlinked list of new content in this release.

Writer's Corner
Read about and link to the MSDN writing team's new technical articles and samples.

MSDN Online
Find out what's new for MSDN Online members, read selected feature articles, and examine Dr. GUI's Online columns.

Locating Readme Files
Readme files provide you with valuable information on setup and other issues that affect this release.


Dr. GUI's Espresso Stand

Contents

Welcome to the Visual Studio 6.0 Edition of the MSDN Library
New Technical Articles in the Visual Studio 6.0 Edition of the MSDN Library
New Backgrounders in the Visual Studio 6.0 Edition of the MSDN Library

Welcome to the Visual Studio 6.0 Edition of the MSDN Library

MSDN, the Microsoft Developer Network, is Microsoft's broad program for providing developers with the tools, technologies, education, information, events, and other technical material they need.

The MSDN Library contains more than a gigabyte of developer information, documentation, sample code, technical articles, and much more. This edition has been refreshed and updated for the release of Microsoft Visual Studio 6.0 and the latest versions of Microsoft Visual tools (mid-1998). This information is always changing, growing, and—dare we say it—developing. In fact, the MSDN Library is updated every three months and can be accessed on the Web via the MSDN Online Membership http://www.microsoft.com/msdn/join/. To find out more about the MSDN Subscription program, read "MSDN Subscriptions."

Finding what's new in the MSDN Library

There are several ways to find the new content in this release:

  • From the MSDN Start Page, you can click on the What's New on the Library icon to view a complete, annotated, hotlinked list of all the new content in the MSDN Library.

Other icons from the MSDN Start Page will link you to subsets of new content:

  • Click on MSDN Online for an introduction to the MSDN Web site and a description of new offerings for MSDN Online members. Once you're there, take a look at the MSDN Online Feature Articles topic for a list of authors (including Dr. GUI) and their new articles.

  • Click on Writer's Corner for a roundup of new technical articles and samples written by MSDN's own Content Development Group.

Note The sources listed above do not include the new documentation for Microsoft visual tools released in this Visual Studio 6.0 edition of the MSDN Library. For introductions to new version 6.0 features, please go to the Visual Studio Start Page. From that page, you can link to What's New for Visual Studio 6.0. Plus, you can link to each of the Visual Studio product home pages and, from there, visit that product's corresponding What's New page.

New Technical Articles in the Visual Studio 6.0 Edition of the MSDN Library

New technical article topics in this section:

Microsoft SQL Server Developer's Resource Kit
Microsoft Index Server
Internet Explorer 4.0
The Component Object Model and DCOM
Other Technical Articles

Those of you familiar with previous MSDN Library releases will note that we have changed the way we organize content in the Technical Articles node and the Backgrounders node. Both of these nodes mirror each other's table of contents, and they in turn now mirror the basic structure of the Platform SDK. We have organized content to be task-based rather than product-specific. Therefore, whereas in the previous table of contents a major node was BackOffice, in this release of the MSDN Library you will see that many of the BackOffice components (Exchange Server, SQL Server) are in the new Database and Messaging Services node. Articles about Internet Information Server and Index Server, which previously were listed under the BackOffice node, are now in the Internet/Intranet/Web node.

Whether or not you are familiar with the organization of the Platform SDK, we're betting that our new table of contents for technical articles and backgrounders will make a lot more sense to you.

Now scroll down . . .

Below you will find summaries of and links to all the new technical articles that appear for the first time in this release of the MSDN Library. Note that the following technical article titles and summaries do not include the recent work of our in-house developers, also known as the MSDN Content Development Group. Our MSDN developers have finally brought work on their HelpDesk sample application to a conclusion. When all is said and done, the HelpDesk project is made up of twelve articles and a 24,000-line sample application. To read about the new HelpDesk technical articles and samples, together with a short summary of the entire project, go to Writer's Corner.

Microsoft SQL Server Developer's Resource Kit

Designing a Microsoft SQL Server application can seem a daunting challenge. There are many choices to make: development tools, database design, application structure, query design, and so on. Complicating things more, the right choices also depend on your unique application requirements and on the skills of your project team.

The good news is that there are many paths that lead to the development of high-performance SQL Server applications. While there may be different approaches to developing an application that performs as well as you need it to, knowing a few basic principles of SQL Server development will help you choose the right approach right away, saving precious development time.

The SQL Server Developer’s Resource Kit is a compilation of technical materials targeted at developers of large-scale SQL Server applications. The goal of the Resource Kit is to provide developers with the key technical information needed to design and to develop great applications on SQL Server. The following list summarizes the 12 articles in this Resource Kit.

  • "Microsoft ADO and SQL Server Developer's Guide"

    This article introduces ActiveX Data Objects (ADO) and the ADO programming model for developers who are building applications with Microsoft SQL Server. A sample application illustrates how to use the ADO object model with SQL Server.

  • "Designing Efficient Applications for Microsoft SQL Server"

    What developers need to know to design applications for optimal performance. This article explains basic principles and tradeoffs of SQL Server development.

  • "A Developer's Guide to Transaction Processing Systems"

    This article provides detailed information about transaction processing and explains how to build applications for Microsoft Transaction Server and Microsoft SQL Server.

  • "Developing Distributed Applications Using Microsoft SQL Server 6.5 Replication"

    This overview of replication architecture describes how to take advantage of the power of replication when you design databases.

  • "Developing International Database Applications Using Microsoft SQL Server"

    This article contains comprehensive information about building SQL Server 6.5 applications for international use. It is written for developers building Win32 client applications using Microsoft ODBC.

  • "Embedding Microsoft SQL Server in Your Application"

    Here is a blueprint for embedding SQL Server administration features in your application. As a result, you can deploy SQL Server in an unattended environment. Includes code samples.

  • "Migrating Btrieve Applications to Microsoft SQL Server"

    This article presents a strategy that enables Btrieve-based application vendors to convert applications to access Microsoft SQL Server. Includes code samples.

  • "Migrating Oracle Applications to Microsoft SQL Server"

    A description of the tools, processes, and techniques required to successfully migrate Oracle applications to SQL Server. This article also highlights essential design points for creating high-performance, high-concurrency SQL Server applications. Includes sample code.

  • "Migrating Sybase Applications to Microsoft SQL Server"

    This document provides information about migrating database applications from Sybase SQL Server to Microsoft SQL Server, including differences in TRANSACT-SQL statements and administrative procedures.

  • "OLE DB for the ODBC Programmer"

    What Open Database Connectivity (ODBC) programmers need to know to understand and use OLE DB. This paper discusses the relationship of ODBC calls to corresponding OLE DB methods and related programming issues.

  • "Upsizing Microsoft Access Applications to Microsoft SQL Server"

    How to smoothly migrate a Microsoft Access database to SQL Server and optimize your application for fast performance.

  • "Using ODBC with Microsoft SQL Server"

    How application programmers can optimize access to Microsoft SQL Server when using the SQL Server ODBC driver.

In addition to these SQL Server Resource Kit articles, we're also published the new technical article by William A. Vaughn, "Accessing SQL Procedures Using the UserConnection Object."

Return to technical article contents

Microsoft Index Server

Krishna Nareddy began his series of articles on Microsoft Index Server in the October Library with "Anatomy of a Search Solution." For the January MSDN Library release, the author contributed a follow-up article, "Introduction to Microsoft Index Server." This article describes features and capabilities of Microsoft Index Server, focusing on the recently released version 2.0. The third article in the series, "Indexing with Microsoft Index Server," appears for the first time in this release of the MSDN Library. This article is designed to help you understand, manage, and fine-tune the indexer. It also contains two utility programs that can help you troubleshoot Index Server.

Return to technical article contents

Internet Explorer 4.0

Ken Lassesen, cartographer extraordinaire, debuts yet another map (his twenty-second for the MSDN Library) with his new "An Extended Object Map of Internet Explorer 4.01." If you are creating applications that use Internet Explorer, this map will help you find your way.

For a discussion of using Cascading Style Sheets (CSS) in Internet Explorer 4.0, including samples and a reference table, read George Young's "Cascading Style Sheets in Internet Explorer 4.0." The article provides some usage guidelines for CSS in general, and points out CSS improvements and additions in Internet Explorer 4.0.

Michael Edwards and Matt Oshry contribute "Discardable Properties for Your Web Pages in Internet Explorer 4.0." This technical article explores a new Internet Explorer 4.0 property for temporarily saving data between Web pages. The IDiscardableBrowserProperty lets you easily save and recall pockets of data from different Web pages. Best of all, it requires little system overhead: The data is discarded if the browser is closed or the data is not accessed for ten minutes. Includes sample files.

Return to technical article contents

The Component Object Model and DCOM

The Distributed Component Object Model protocol is an application-level protocol for object-oriented remote procedure calls and is useful for distributed, component-based systems of all types. It has been revised. To see its latest incarnation, take a look at "Distributed Component Object Model Protocol (DCOM/1.0)."

Rajiv Delepet's "COM Security in Practice" describes how to make distributed applications secure. This article focuses on activation security and call security in detail, and then illustrates how COM security can be used in some common scenarios.

Return to technical article contents

Other New Technical Articles

  • "Developing with Microsoft English Query"

    English Query allows users to ask questions about your data in plain English. Great idea, hey? Adam Blum of the Microsoft English Query team steps back from the cutting edge of natural language development to show you how to incorporate it into your ASP Pages. English Query is easy to implement and provides a powerful searching capability for your SQL Server–based Web site or application.

  • "Building Dynamic Visual Basic Programs with DHTML"

    David Stutz, who calls himself the Visual Basic Architecture Wonk, tells you all about how to use Dynamic HTML as the basis for a broad new programming model. The author explains how DHTML augments and complements the capabilities of Visual Basic and Visual Basic for Applications.

  • Steven Pratschner, "Instrumenting Windows NT Applications with Performance Monitor"

    Using the Windows NT Performance Monitor to tune and debug an application helps to produce a better quality application. This paper describes a set of COM interfaces, C++ classes, and generic components that make the process of adding custom counters much easier. This article also contains sample files that illustrate how to implement performance counters in an application.

  • Nancy Cluts, "What's New in JScript 3.0"

    "If you're like me," the author writes, "you might have the impression that JavaScript or JScript is just some cut-down version of the Java language. It is not." The latest release of Microsoft JScript 3.0 provides a number of new features to help develop Web applications. This document details all the new features and provides examples.

Return to technical article contents

New Backgrounders in the Visual Studio 6.0 Edition of the MSDN Library

New backgrounder article topics in this section:

XML, or How to Deliver Data over the Web
Microsoft Transaction Server
New Microsoft Exchange 5.5 Articles
Internet Explorer 4.0 and Web Authoring
Universal Data Access
New Visual FoxPro Articles
Concerned About Security?
Folks, Some FAQs
And Finally . . .

XML, or How to Deliver Data over the Web

XML, or Extensible Markup Language, describes structured data and delivers the data the way you want it. You've heard about it, you've seen the abbreviation, but what's the fuss about? To help you answer that question, you may want to read John Swenson's series of articles on the subject, including "XML: One Hot Abbreviation, but What Does It Mean?" Another good entrée into XML is "XML: A Better Way to Move Data Across the Web." In his discussion of XML and its presence at the Web Tech·Ed conference, John Swenson focuses on "the technology's main benefit: XML's ability to describe and deliver data." In discussing the emergence of new file formats within Microsoft Office in "It's Not Just a .doc and .xls World Anymore," John explains how XML will create new opportunities for third-party developers. And finally, check out "The Distinction Is Fading Between Windows Applications and Web Applications," where John examines Microsoft's plan to make XML and HTML the "cornerstone of Office."

In addition to the XML articles previously published in the MSDN Library, we have the following new papers:

  • "Frequently Asked Questions About Extensible Markup Language (XML)"

    Answers to frequently asked questions about XML and its support by Microsoft and other companies.

  • "A Technical Perspective of XML"

    This is a thorough rewrite of the old XML white paper and includes new technical information about XML.

  • "XML: Data the Way You Want It"

    An explanation of how XML complements HTML and what XML markup looks like. You'll also learn how XML data formats are being used today, and about the tools and technologies available for authoring and working with XML.

  • "The XML Object Model in Microsoft Internet Explorer 4.0"

    This article shows you how to access the XML object model from script in Internet Explorer 4.0. It includes reference information on the XML Document, XML Element, and Element Collection objects, and a sample JScript program that uses the XML object model to display an XML document in a Web page.

  • "Going from HTML to XML"

    This article by Charles Heinemann explains the differences between HTML and XML, and provides instructions for authoring XML as well as converting HTML code to XML. Charles is a program manager for Microsoft's Weblications team.

We've also added to the Library the latest update to the "Specification for XML-Data."

Return to backgrounder contents

Microsoft Transaction Server

If you're interested in building COM-based applications, you'll want to know about Microsoft Transaction Server. This product combines the features of a transaction-processing monitor with an object request broker, letting you control communication among components and add mainframe-like functions, such as two-phase commit, to your applications. (Note: Version 2.0 of the Microsoft Transaction Server is available as part of the Windows NT 4.0 Option Pack.)

If you're a newcomer to Microsoft Transaction Server, or if you're curious about its capabilities, read "Microsoft Transaction Server FAQ: Databases and Transactions." It's an exhaustive list of what you can and can't do with the technology today. You may also want to take a look at "An Introduction to Microsoft Transaction Server."

If you want a quick summary of the benefits of Transaction Server, try "Microsoft Transaction Server: Why Care?" by David Vaskevitch, vice president of Microsoft's Database and Transaction Systems group.

Once you begin to set up distributed applications with MTS, you'll probably find yourself involved in security. "Securing a Web-based Microsoft Transaction Server Application," by Michael Morel, documents the security flow of an MTS-enabled application and explains how security works in a typical Web application using MTS and BackOffice.

For more extensive documentation, you can read "A Guide to Reviewing and Evaluating Microsoft Transaction Server." This article includes an overview of MTS features and how they benefit developers and business users.

Perhaps you want to integrate MTS with Active Server Pages (ASP)? Then you should read "Microsoft Transaction Server and Internet Information Server: Technology for the Web." This article talks about why MTS was integrated into the IIS architecture, describes the three major benefits of this integration, and shows how easy it is to develop server-side components that use MTS. Author James Utzschneider is the lead program manager for the Microsoft Transaction Server team.

And finally, if you're familiar with MTS and want to expand its functions by building custom resource dispensers, we have a new technical article by Walter Oliver, "Writing Microsoft Transaction Server Resource Dispensers."

Return to backgrounders contents

New Microsoft Exchange 5.5 Articles

  • "Active Directory Services Interface in the Microsoft Exchange 5.5 Environment"

    This paper helps application developers write directory-enabled applications using ADSI on top of the Exchange 5.5 directory service.

  • "Introduction to Collaboration Data Objects"

    This article details the differences between the Collaboration Data Objects (CDO) 1.2 library (which is shipping with Exchange 5.5) and its predecessor, Active Messaging 1.1. It also describes distinctions between CDO 1.2 and Collaboration Data Objects for Microsoft Windows NT Server, a subset library of CDO 1.2 that ships with Internet Information Server 4.0.

  • "The Microsoft Exchange Server 5.5 Connector for Lotus Notes"

    Through a product known as the Connector for Lotus Notes, Microsoft introduces comprehensive interoperability between Lotus Notes and Exchange.

  • "Windows NT Clusters and Microsoft Exchange 5.5"

    Do your applications require an environment of multiple server nodes to run at their best? This paper describes Microsoft Cluster Server and cluster architecture and implementation.

  • "Disaster and Recovery Planning with Microsoft Exchange Server"

    This paper covers Microsoft Exchange data, where it resides and how it is saved, and transaction logging and its application in disaster recovery.

Return to backgrounders contents

Internet Explorer 4.0 and Web Authoring

Michael Wallent, Microsoft's lead program manager for Dynamic HTML, has revised several articles that appear in this Library release. These include:

  • "Dynamic Control of HTML Attributes with Microsoft Internet Explorer 4.0"

    Read all about it: With Internet Explorer 4.0, page authors have total control over all attributes of all page elements at any time. Changes made to attributes that cause the page to change shape are handled automatically, with no additional script intervention by the author.

  • "Bubble Power: Event Handling in Microsoft Internet Explorer 4.0"

    Event bubbling is a powerful new way to handle such events as mouseovers, button clicks, and text selection.

  • "An Introduction to the Dynamic HTML Object Model"

    Four key innovations allow you to create dynamic pages in Internet Explorer 4.0.

Michael Wallent's articles first appeared on the Microsoft Site Builder Network (SBN) Web site (http://www.microsoft.com/sitebuilder/). Two other new articles on Internet Explorer 4.0 come from SBN:

  • Michael Edwards, "Web View: A New Look for Microsoft Internet Explorer 4.0 Folders"

    Internet Explorer 4.0 introduces a new viewing paradigm for Windows folders called Web View. "At first, I thought it was kind of lame," Michael Edwards writes. But on further consideration, the author finds that Web View folders are opening up a new realm of opportunities for customizing Windows Explorer folders and making things easier (and more fun) for your users. This article includes examples of Web View folders put to good use.

  • Bob Jervis, "Scriptlets: Reusable Objects for Web Authors"

    Dynamic HTML scriptlets combine the benefits of component programming with Dynamic HTML and scripting. DHTML scriptlets are a standard feature of Microsoft Internet Explorer 4.0.

Plus, check out Nancy Winnick Cluts' new article, "Handling Events in Dynamic HTML." This is a guide for HTML authors learning to handle events in Dynamic HTML.

Return to backgrounders contents

Universal Data Access

Universal Data Access is a platform, application, and tools initiative that defines and delivers both standards and technologies. It is a key element in Microsoft's foundation for application development, the Microsoft Windows Distributed interNet Applications (DNA) architecture.

To find out more, read David Lazar's "Microsoft Strategy for Universal Data Access." This is an in-depth look at Microsoft Universal Data Access, its components, its history, and its future. Then check out "What Are the Microsoft Data Access Components?" Microsoft Data Access Components (MDAC) is a set of redistributable technologies that implement Universal Data Objects. MDAC 1.5 consists of new, synchronized versions of ActiveX Data Objects (ADO), OLE DB, and Open Database Connectivity (ODBC). Another new Universal Data Access article, "OLE DB/ADO: Making Universal Data Access a Reality," focuses more specifically on ADO, which works in conjunction with OLE DB and its service component architecture.

Return to backgrounders contents

New Visual FoxPro Articles

If you are a Visual FoxPro developer, here are five new articles that should make your work easier:

  • "Data Design in Visual FoxPro"

    How to design a Visual FoxPro application.

  • "Using Toolbars in Visual FoxPro"

    How to use a global State Manager object to act as a mediator between menus, toolbars, forms, and any other service objects in your application.

  • "Using the Visual FoxPro Project Manager"

    This article outlines the benefits of using the Visual FoxPro Project Manager.

  • "The Visual FoxPro Data Dictionary"

    Visual FoxPro's data dictionary is based on a database container, a table that contains definitions for tables, persistent relationships between tables, connections to remote data sources such as Microsoft SQL Server, and views (both for local and remote data). This article takes a close look at the data dictionary and suggests ways to implement it in your applications.

  • "Multiuser and Data Buffering Issues in Visual FoxPro"

    This article discusses how data buffering works and explores strategies for selecting which buffering mechanism to use and how to handle multiuser conflicts.

Return to backgrounders contents

Concerned About Security?

We have two new backgrounders on the topic of security:

  • "Microsoft Product Security"

    This paper, written by Steve Sutton, president of Trusted Systems, Inc., and author of the popular book Windows NT Security Guide, offers a broad summary of basic security principles across all Microsoft products. The author emphasizes that the basis of Microsoft's security environment lies in Windows NT security features and enabling technologies, such as the CryptoAPI and smart cards.

  • "Implementing a Secure Site with ASP"

    This article helps you understand Windows NT Server security in areas relevant to Internet Information Server and Microsoft SQL Server and learn how these three products' mutual features can be used to implement security with Active Server Pages.

Return to backgrounders contents

Folks, Some FAQs

We suspect you secretly love FAQs. Who doesn't? Here are several that are new or have just been updated:

  • "Frequently Asked Questions About Dynamic HTML"

  • "Microsoft Visual J++ Frequently Asked Questions"

  • "Microsoft Visual InterDev Technical FAQ"

  • "Microsoft Visual Basic Scripting Edition: Frequently Asked Questions"

Return to backgrounders contents

And Finally . . .

  • "The Visual Modeling of Software Architecture for the Enterprise"

    This paper, from Grady Booch of Rational Software Corporation, describes the importance of modeling in software architecture and the software development process; includes a discussion of Unified Modeling Language (UML).

  • "The SAP DCOM Component Connector"

    With the DCOM Component Connector, SAP and Microsoft have provided for the seamless and tight technical interoperability of components on the basis of Microsoft's Distributed Component Object Model (DCOM). This paper discusses the benefits of using the DCOM Component Connector, which will be shipped by SAP in their R/3 4.0 product.

  • "Migrating to the Microsoft Project 98 VBA Object Model"

    This paper summarizes the key changes to Microsoft Visual Basic for Applications (VBA) in Microsoft Project 98 to assist in the migration of existing macros from previous versions of Microsoft Project and to aid developers of new macros and custom solutions.

  • "IP Telephony with TAPI 3.0"

    Now in its third major version, the Microsoft Telephony Application Programming Interface (TAPI) is suitable for quick and easy development of Internet Protocol (IP) Telephony applications. This article provides a thorough introduction to TAPI technologies and discusses the relationship between TAPI, Windows NT Active Directory, and Microsoft NetMeeting 2.0.

Return to backgrounders contents


What's New on the Library

New Content in the Visual Studio 6.0 Edition of the MSDN Library

Technical Articles
Backgrounders
Microsoft Knowledge Base
Books
Periodicals

Revised Content in the Visual Studio 6.0 Edition of the MSDN Library

Office Documentation
SDK Documentation
Platform SDK
Specifications

Note For the latest content updates and vital post-release information, including known problems and their fixes as well as answers to frequently asked questions (FAQs), be sure to check out the MSDN Release Notes Web page at http://www.microsoft.com/msdn/services/subscription/release.htm.

New Content in the Visual Studio 6.0 Edition of the MSDN Library

Here is an overview of the new documentation we have acquired for this edition of the MSDN Library.

Technical Articles

These are listed in two places here in the Welcome bin. For a list of all technical articles written specifically for MSDN by our team of MSDN writers, together with short summaries and links, please go to the Writer's Corner. For a list of all other technical articles (by company-wide Microsoft writers and third-party writers) that are new in this release of the MSDN Library, plus summaries and links, please go to Dr. GUI's Espresso Stand.

Backgrounders

Backgrounders include high-level overviews, case studies, frequently asked questions, and so on. For a list of new backgrounders in this release of the MSDN Library, plus summaries and links, please go to Dr. GUI's Espresso Stand.

Microsoft Knowledge Base

The Knowledge Base contains technical articles and samples that are created and maintained by Microsoft Technical Support. This comprehensive database contains more than 40,000 detailed articles with technical information about Microsoft products, fix lists, documentation errors, and answers to commonly asked technical support questions.

This version of the Microsoft Knowledge Base was acquired for this release of the MSDN Library on March 23, 1998. Click here to go to the top of the MSDN Knowledge Base node.

Books

Understanding Thin-Client/Server Computing by Joel Kanter

Understanding Thin-Client/Server Computing provides thorough coverage of the thin-client/server technology developed by Citrix Systems for Microsoft Windows and Microsoft Windows NT. The thin-client/server technology provides high performance at a lower cost, and this approach simplifies software updates, configuration, training, and maintenance. This book also provides an invaluable overview of issues such as:

  • The thin-client/server computing model

  • Ways of deploying applications

  • An architectural overview of the Citrix Independent Computing Architecture (ICA) Services and the relationship of WinFrame to Microsoft Windows NT Server

  • What hardware you can use

  • Planning the thin-client/server environment

  • Thin-client/server computing on the Web

Partial Books

By special arrangement with the publisher, MSDN has been allowed to reprint a portion of the following books in the MSDN Library. We have selected for inclusion specific chapters that we feel would most interest our readers and which discuss topics underrepresented in the Library.

Professional Active Server Pages (Chapters 5-8)

Every so often a book comes along that when you read it, you know you need to get a copy of it. Professional Active Server Pages is one of those books. The entire book contains information that is invaluable for developing good Active Server Pages, but we've chosen to focus on chapters 5 through 8.

Chapter 5, "Advanced Database Techniques," covers OLE DB/ADO/ASP, and would be useful for anyone developing and ASP-based system requiring database access.

Chapters 6, 7, and 8 define client/server environment and how it relates to Web-based ASP development.

Professional Visual C++ 5 ActiveX/COM Control Programming (Chapters 8-9)

Professional Visual C++ 5 ActiveX/COM Control Programming is an excellent book on ActiveX COM Control programming that covers much of what COM control developers should be considering today.

Chapter 8, "Distributed Objects with DCOM," discusses setting up machines on a network and configuring them correctly for Distributed COM.

Chapter 9, "Security," deals with security over an intranet and over the Internet. Addressing such topics as ISAPI (the Internet Services API), DCOM, and SIDs (security identifiers), this chapter is an excellent overview of the various components of network security.

Periodicals

Active Server Developer's Journal (Cobb Group)

February 1998
 Using ActiveX and Java Applets Together

January 1998
 Making #INCLUDE Files "Hackproof"

December 1997
 Using Active Messaging to Create and Send E-mail Messages

Exploring Windows NT (Cobb Group)

February 1998
 Implementing a Successful Registry Backup Strategy

January 1998
 Sharing Files with Services for Macintosh

December 1997
 Knowing What Hackers Know About Your Network

FoxTalk (Pinnacle Publishing)

January 1998
 Transactions: Take the ACID Test

Inside Visual Basic (Cobb Group)

February 1998
 User-friendly Field Advance

January 1998
 Building External Objects with Visual Basic

December 1997
 Extending Visual Basic to the Internet

MSDN News, March/April 1998

Contents

MSDN News, January/February 1998

Contents

Microsoft Interactive Developer Magazine

January 1998
 Scriptlets
Secure Logins
Using J/Direct to Call the Win32 API from Java

Microsoft Office and VBA Developer (Informant)

January 1998
 Agents Revealed: An Introduction to Microsoft Agents

December 1997
 Keyboard Class: From Windows-API Chaos to VBA Class-Module Calm

Microsoft Office Developer's Journal

February 1998
 An Introduction to Two Approaches: Dynamic Publishing over the Web

December 1997
 Publishing Access 97 Data on the Web

Microsoft Systems Journal

Volume 12, Number 12 (December 1997)
Bugslayer
C++ Q & A
The COM+ Programming Model Makes It Easy to Write Components in Any Language
Editor's Note
Under the Hood
A Programmer's Perspective on New System DLL Features in Windows NT 5.0, Part II
The Visual Programmer
Implementing the New Win32 Driver Model for Windows 98 and Windows NT 5.0

Volume 12, Number 11 November 1997)
 ActiveX/COM Q & A
C++ Q & A
Editor's Note
Under the Hood
A Programmer's Perspective on New System DLL Features in Windows NT 5.0, Part I
Surveying the New Win32 Driver Model for Windows 98 and Windows NT 5.0
Win32 Q & A

Volume 12, Number 10 (October 1997)
 A Preview of Active Channel and the Active Desktop for Internet Explorer 4.0
C++ Q & A
Editor's Note
Introducing the Bugslayer: Annihilating Bugs in an Application Near You
Under the Hood
The Visual Programmer
Wicked Code
Design a Windows NT Service to Exploit Special Operating System Facilities

Microsoft Visual J++ Informant (Informant)

February 1998
 Getting to Know Beans: JavaBeans in Visual J++
Java SDK 2.0: A Two-Way Bridge Between ActiveX and Java

January 1998
 From CAB to JAR: A Utility for Converting Cabinet Files into Java Archives

December 1997
 Unraveling Threads

Microsoft Web Builder (Cobb Group)

February 1998
 Creating an Expanding Menu

January 1998
 Scriptlets: A New and Powerful Way to Web Computing

December 1997
 Developing Active Desktop Items for IE 4.0

Visual J++ Developer's Journal

February 1998
 The Basics of ActiveX

January 1998
 Taming the GridBagLayout Class

December 1997
 Introducing the AFC

Windows 95 Professional

February 1998
 Coping with a Corrupt Registry

January 1998
 Freeing Hard Disk Space Automatically

December 1997
 How Secure Is Your Network?

Revised Content in the Visual Studio 6.0 Edition of the MSDN Library

Office Documentation

The Microsoft Office 97 Resource Kit has been updated with the latest new content.

SDK Documentation

SDK documentation location changes

Data Access Objects 3.5 SDK Documentation has been merged with the Platform SDK.

Microsoft SDK for Java Version 3.0 Pre-Release 2 has been merged with the Platform SDK.

The Windows CE Desktop Emulation SDK has been integrated into the Platform SDK documentation. You can now find this documentation under the title Windows CE Programmer's Guide.

Platform SDK

The following portions of the Platform SDK have been revised:

Introduction
Database and Messaging Services
Graphics and Multimedia Services
Internet, Intranet, and Extranet Services
Networking and Distributed Services
Reference
Setup and Systems
User Interface Services
Windows Base Services
Windows Programming Guidelines

Specifications

Specification for the Open Software Description (OSD) Format

This document provides an initial proposal for the Open Software Description (OSD) format. OSD, an application of the Extensible Markup Language (XML), is a vocabulary used for describing software packages and their dependencies for heterogeneous clients. We expect OSD to be useful in automated software distribution environments.

Specification for XML-Data

This document provides an initial proposal for a specification (XML-Data) for exchanging structured and networked data on the Web. This specification uses XML, the Extensible Markup Language, for describing data, as well as data about data. We expect XML-Data to be useful for a wide range of applications, such as describing database transfers, digital signatures, or remotely-located Web resources.


Writer's Corner

In this Visual Studio 6.0 edition of the MSDN Library, the MSDN Content Development team brings you the release of the full HelpDesk sample—a 24,000-line sample application that shows you how to build a scalable, distributed Web-based application.

The sample is an intranet application for reporting and resolving technical-support problems. It uses various Microsoft technologies, such as Microsoft Transaction Server, SQL Server, ActiveX Data Objects, Active Server Pages, and COM as parts of a complete package.

You may have been following this project through the articles published in the January 1998 MSDN Library release (listed at the bottom of this page). What's new for this release of the MSDN Library?

To get started with the sample right away, go to Kevin Marzec's "MSDN HelpDesk Installation and Deployment" for the HelpDesk setup files and installation instructions. The more hardcore out there may want to go straight to "The HelpDesk API Reference," compiled by Robert Coleridge. We've also collected the following new articles, which detail different client applications for the system:

  • "The HelpDesk Administration Explorer" by Robert Coleridge

    Robert discusses the HelpDesk client that allows an administrator to maintain the database and to control system parameters. He also teaches you how to create a Windows Explorer–style application in Visual Basic.

  • "DHTML, Data Binding, and the HelpDesk Technician Client" by Steve Kirk

    Steve uses his DHTML technician client for the HelpDesk sample as an opportunity to explore data binding, data source objects, and some pretty neat DHTML tricks.

  • "Viewing HelpDesk Activity: A DHTML System Monitor" by Steve Kirk

    This article, a nice compliment to "DHTML, Data Binding, and a HelpDesk Technician Client," finds Steve explaining how to build a browser-based statistical monitoring application for the HelpDesk system using DHTML, ActiveX Controls, and DirectAnimation.

  • "Visual Basic Clients for the HelpDesk Sample" by Venu Yerra

    Venu walks you through the functionality of the Visual Basic User and Technician clients for the HelpDesk sample.

  • HelpDesk Sample Development Issues

    In this collaborative article, the MSDN writing team holds a postmortem on the HelpDesk project as a whole, discussing obstacles, pitfalls, Trojan horses, and lessons that were learned.

For your convenience, here is a recap of the previously published HelpDesk articles:

  • "The HelpDesk Sample: Overview of an Automated Solution" by Robert Coleridge

  • "Designing the HelpDesk Transaction-Processing Object Model" by Fred Pace

  • "Task Distribution in a Customer Service System" by Steve Kirk

  • "The HelpDesk Sample Database Architecture" by Venu Yerra

  • "A Web Application for Handheld Transaction-Processing Clients" by Steve Kirk

The MSDN Online Web site (http://www.microsoft.com/msdn/) contains an up-to-date Known Issues page for the sample at http://www.microsoft.com/msdn/news/feature/020298/issues.htm. Look here if you have any problems setting up the sample.

Remember that this is an unsupported sample application. Please don't contact our tech-support line for answers to your questions about HelpDesk—they are not prepared to provide support for this sample application.


MSDN Online

Contents

What's New for MSDN Online Members
MSDN Online Feature Articles

What's New for MSDN Online Members

The MSDN Online Membership is your secret weapon—a free program that offers access to the MSDN Library Online, a subscription to MSDN Flash, third-party trial downloads, and a host of other benefits. Registration is quick and easy at http://www.microsoft.com/msdn/ and you get special access to additional content and ongoing benefits that are for members only!

Take a look at the New for MSDN Members and Subscribers column each week to learn what new third-party software downloads, Tips and Tricks, book and magazine content, Microsoft Mastering Series Training, and third-party discounts are in store for you!

Here is a sampling of the kinds of benefits that are waiting for you:

MSDN Library Online

The MSDN Library is the most comprehensive source of programming information available from Microsoft today. Used by developers around the globe, the MSDN Library is a centralized resource of up-to-date information that increases your productivity and helps you incorporate the latest technologies from Microsoft into your own solutions. The entire Library is now available for quick online access.

Tip of the week

We have a new Tip or Trick each week to help you navigate through Microsoft Access, Visual Basic, Visual C++, Visual J++, and more.

Microsoft Mastering Series training

Every month you'll have access to a new training module from the Microsoft Mastering Series. You can take advantage of this training online, or download the modules for offline use. This in-depth training is available online exclusively at MSDN Online!

Software downloads

We're always adding more and more evaluation copies of great third-party software to help you work smarter and faster. Try some—or all—and see how your efficiency grows!

MSDN Flash

Twice a month, you'll receive an e-mail message packed with tips and tricks, highlights of MSDN Online features, early notification of upcoming developer conferences, and new MSDN Online member benefits.

Great discounts

MSDN Online Members in the U.S. and Canada will be receiving our first-ever MSDN Online Membership Kit starting late February. It's packed with discounts and free stuff like the ComponentSource CD, which includes over 100 free trial downloads and 500 ActiveX controls worth $250. The Membership Kit also includes discounts on books and magazines, including PC Magazine, Microsoft Systems Journal, Inside Visual Basic, Computer Shopper, Visual J++ Developer's Journal, and featured books from Wrox Press and Microsoft Press.

What's the catch? We need your correct mailing address or the postal carrier can't deliver it to you. Members, please check your address in the Personal Information Center. Not a member? Sign up now at http://www.microsoft.com/msdn/join/ for our free program.

MSDN Online Feature Articles

If you have visited http://www.microsoft.com/msdn/ lately, no doubt you have noticed our weekly features by Dr. GUI, together with several other new voices at MSDN. These columns can be a relief from those technical articles you've been spilling your coffee on. They offer some strong opinions, some straight dope—and sometimes they can't help but be funny.

Dr. GUI Online

You know Dr. GUI. No need to introduce him to you. But did you know that he is now writing a weekly column exclusively for our MSDN Online Web site? If you haven't read these yet, or if you want to review them, here's your chance. Same practitioner, only more of him.

Dr. GUI on Components, COM, and ATL (Parts 1 through 4)
Performance Prescriptions for Microsoft Windows NT 5.0
Going Native with J/Direct

IMHO

This weekly column by MSDN Online writer John Swenson covers a broad range of developer topics, with a special emphasis on providing developers with an overview of key Microsoft technologies. Topics in recent months have included XML, ZAW, Windows DNA, Dynamic HTML, and other interesting acronyms. Before joining MSDN Online in 1997, John spent seven years as a reporter covering Microsoft and other software companies for Windows Watcher newsletter, Information Week magazine, and a local newspaper in the Seattle area. John uses his journalism background to zero in on important answers for developers, addressing such pressing questions as "Why should I care about this new technology?"

Windows 98 Has Something for Everyone, Even Developers
ADSL Is Almost Ready for Primetime
Common Sense Writing and Publishing for the Web
The Human Problems of Web Publishing
Server Scriptlets: Using Script to Create COM Components
XML: A Better Way to Move Data Across the Web
Windows CE Tools Are Flooding Forth
The Distinction Is Fading Between Windows Applications and Web Applications
It's Not Just a .doc and .xls World Anymore
XML: One Hot Abbreviation, but What Does It Mean?
Ease Your Work with Cascading Style Sheets
Internet Explorer: Surfing's Only the Beginning

Scope

This weekly column by MSDN Online editor Norvin Leach looks at a range of developer issues from the small (micro/scope), to the large (macro/scope), and even the distant future (tele/scope). Since beginning the column in the fall of 1997, Norvin has written about everything from data access and encryption to legacy DOS apps and what's happening at MSDN Online. Along the way, he raises such provocative questions as "Is ActiveX Dead?" Before joining Microsoft in 1997, Norvin spent more than four years as a reporter and editor at PC Week covering development tools, operating systems, and yes, even Microsoft.

ActiveX Revisted
Observations on the HelpDesk Sample
Consolidation and Decompilation at the SD West Show
Cryptic Controls
Titanic Failures
Thinking the Unthinkable About DOS Apps
Three Questions About Java
Your Letters


Dr. GUI on Components, COM, and ATL

Dr. GUI Online
Part 1: February 2, 1998
Part 2: February 9, 1998
Part 3: February 23, 1998
Part 4: March 2, 1998

Editor's Note Only parts 1 through 4 of this column were available at the time of release of Visual Studio version 6.0. This column will be reprinted in its entirety in the July 1998 release of the MSDN Library. You can also visit the weekly column, "Dr. GUI Online," at MSDN Online (http://www.microsoft.com/msdn/), and view the archives section for this and previous columns.

Contents

Part 1: You're gonna do COM? Hasn't it been done already?
Part 2: Basics of COM
Part 3: Getting Objects and Interfaces
Part 4: The Object Class and Object Library

Part 1: You're Gonna Do COM? Hasn't It Been Done Already?

The good doctor can hear you now: "You're gonna do what? Explain COM? Books have been written on that subject!"

Indeed they have. Dr. GUI can recommend a number of good ones. He really likes both Dale Rogerson's Inside COM (Microsoft Press, 1997) and Don Box's Essential COM (Addison-Wesley, 1998). Books like Adam Denning's ActiveX Controls Inside Out (Microsoft Press, 1996) and Professional Visual C++ 5 ActiveX/COM Control Programming by Sing Li and Panos Economopoulos (WROX Press, 1997) are good, too. And of course, you'll want Kraig Brockschmidt's Inside OLE, 2nd Edition (Microsoft Press, 1995)—the ultimate printed OLE reference. (MSDN is the ultimate reference, of course—not that the good doctor has an opinion.) And if you want a formal, nonpartisan explanation of component software, check out Clemens Szyperski's new book, Component Software: Beyond Object-Oriented Programming (Addison-Wesley, 1998).

"So what," you ask, "could Dr. GUI possibly add to all this?"

"Nothing," the good doctor would respond. These authors (and others) plus the documentation truly say it all. If you can find the time to read them, that is.

"So that's what you're up to!" you exclaim. "You're going to give us a gentle introduction to COM and ATL—just a few screenfuls each week!"

And Dr. GUI replies, "You're smart. This is going to be easier than I thought."

Components? Am I programming a stereo?

If you've used Visual Basic much, you're very familiar with using components to do your programming: you use both visual ActiveX controls (such as spin buttons) and nonvisual ActiveX components (such as database access objects). It's hard to find a significant Visual Basic program that doesn't make heavy use of premade reusable components. But although you reuse plenty of components, most folks don't yet write a whole lot of reusable components of their own.

If you're programming in C++, you likely have a different experience of reuse. C++ and object-oriented programming claim to make reuse easy, but what has your experience been? Have you been able to create a library of reusable objects? A few of you no doubt have, but most of us have not. And if we have such a library, do we routinely make good use of it? It's not just a lack of discipline that keeps us from reusing our code: the fact is that it's hard to reuse code (it never seems to do quite what we need) and it's even harder to write reusable code (it's very hard to be general enough yet useful enough).

On top of that, what C++ makes easy is not creation of reusable binary components; rather, C++ makes it relatively easy to reuse source code. Note that most major C++ libraries are shipped in source form, not compiled form. It's all too often necessary to look at that source in order to inherit correctly from an object—and it's all too easy (and often necessary) to rely on implementation details of the original library when you reuse it. As if that isn't bad enough, it's often tempting (or necessary) to modify the original source and do a private build of the library. (How many private builds of MFC are there? The world will never know . . . .)

So let's reuse binary objects, not source code

So how can you reuse binary objects? Well, the answer that first comes to a Windows programmer's mind is simple: use dynamic-link libraries (DLLs). Using DLLs does work—Windows is itself, after all, primarily a set of DLLs. But there are some problems.

First, DLLs are not necessarily programming-language independent. Even for DLLs written in C, it's all too easy to change the calling convention (which parameters are pushed in which order?) such that the DLL is only usable from C programs. Granted, the calling convention used by Windows is pretty well established as the standard for Windows systems, but the good doctor has seen DLLs fail because of mismatched calling conventions.

Writing a C-style interface for your DLL has some major limitations. First off, it restricts you from doing object-oriented programming because the object-oriented features of C++ require name decoration of function names. There is no standard for name decoration; in some cases, different versions of the same compiler decorate names differently. Second, implementing polymorphism is difficult. You can work around these problems by creating wrapper classes for both sides, but doing so is painful. And Dr. GUI's not into pain. (Not too much, anyway.)

Even if you did resolve the name decoration problems so you could link successfully to the DLL, other problems arise when it comes time to update your objects.

First off, you're hosed (that's a medical term) if you add any virtual functions to your object when you update it. You might think you're okay if you add the new functions to the end, but you're not: you've just shifted the vtable entries for all objects that inherit from you. And since a virtual function call needs a fixed offset into the vtable in order to call the correct function, you can't make any changes to the vtable—at least not without recompiling every program that uses your object or any object derived from it. Clearly, recompiling the world every time you update your object is not an option.

Second, if you're using new in your client to allocate objects, you won't be able to change the size of the object (that is, add any data) without recompiling the world.

Lastly (and most importantly), updating DLLs is a nightmare because you're stuck between a rock and a hard place with two unappetizing options: either try to update the DLL "in place" by overwriting it or rename the new version. Updating the DLL in place is very bad: the chances that even if you keep the interface consistent you'll break some user of your DLL are very high. Dr. GUI doesn't need to tell you of all the problems the industry, including Microsoft, has run into because of this issue.

The alternative—using a new DLL name—will at least keep your working systems working. But there's a cost in disk space (perhaps not a big deal when typical hard disks are 3 gigabytes or so), and a second cost: increased memory usage. If your user is using both versions of the DLL, there will be two copies of very similar code in the user's working set. It's not unusual when you examine a user's memory usage to find two or three versions of the Visual Basic runtime or the Microsoft Foundation Class (MFC) DLL, for instance. Given that almost all Windows systems typically use more virtual memory than they have physical memory, increasing the working set size has serious performance implications in the form of increased virtual memory swapping to disk. (That's why, to paraphrase a counter-example to Brook's law, adding more memory to a slow system makes it faster.)

Ideally, you'd like to allow your user (or application) to be able to choose what version to use. This is VERY hard with statically linked DLLs, but very easy if you dynamically load your DLL.

To be fair to C++, we should note that it was never intended to solve this set of problems. C++ was intended to allow you to reuse code in programs that reside in one file, so all of the objects are compiled at the same time. C++ was not intended to provide a way to build reusable binary components that can be mixed and matched over versions and years. By the way, the creators of Java noticed these problems—these deficiencies were a major motivation for developing Oak, which later became Java.

So what about Java?

Java does solve some of these problems, but it also adds some of its own. The biggest problem is that Java components (JavaBeans, usually) are only intended to be used by programs written in Java. Now it's true that the Microsoft virtual machine (VM) allows you to use JavaBeans as COM objects. You can therefore use them from any language. And it's true that Sun has a Java/ActiveX bridge. But in general, unless you're running on Windows, Java is a single-language system: Java components can only be used in Java programs. And, for the most part, you have to rewrite your systems from scratch to use Java. (Yes, you can make native calls—but it's a big hassle to do using Java Native Interface (JNI)—and your programs will no longer be at all portable.) Dr. GUI finds this pretty unacceptable, so he's glad that the Microsoft virtual machine (VM) is more flexible—for Windows, at least. No language, not even C++, Visual Basic, or Java, is right for every programmer and every problem.

Java also makes you decide when you write your program whether the component you're using is local (on your machine) or remote (on another machine)—and the methods for using local and remote components are quite different.

Java has a couple of other issues that make it a less-than-ideal answer for all component needs. First, it has no really solid way to deal with versioning. (The package manager in the Microsoft VM helps a lot with this issue.) Second, Java will be to one degree or another slower than C++. Dr. GUI notes that recent "it's as fast as C++" benchmarks published in an online Java magazine omitted tests where Java would do poorly. Two examples that come to mind are string and array manipulation (Java has to bounds-check each access), and initial method calls (Java has to look up the method by signature in a table in the class for the first call, although subsequent calls, which the magazine did test, can be fast). Finally, Java's "one-class-at-a-time" loading scheme can be considerably slower than loading all the code at once (even if there's less code!) because it requires so many more file or HTTP transactions, both of which have a high overhead.

Even if you're using Java in a way that gives good performance, your performance will suffer when you use Java components from another language because of the translation layer that needs to be there to link the dissimilar languages and object models.

Where Java shines is in the possibility that you can use your compiled components on dissimilar machines without needing to recompile for each machine's processor and operating system. But this often doesn't "just work"—you'll need to test and debug on every platform you intend to support.

So what's the alternative?

As it turns out, it is possible to use C++ to build DLLs and other binary components that are reusable. Both Dale Rogerson's book, Inside COM, and Don Box's book, Essential COM, start with a C++ class they want to reuse and solve each of the problems I've listed above (and a few more) with some slick tricks. And both of them end up with, not surprisingly, COM. In other words, each of the solutions to the problem of binary reuse is an important feature of COM. (If you'd like to check this progression out now, check out Markus Horstmann's article, "From CPP to COM".

While COM's "native language" is C++, it's relatively easy to use COM from C—the headers even support this. And, with a few language tweaks, it's possible to have two-way COM support from any language—Visual Basic, Java, Delphi, and so on. (By two-way COM support, I mean that it's possible both to use COM objects from that language, and to write COM objects in that language.) Implementing COM compatibility in your language run time isn't trivial, but the benefits are great: once you do, you open up a whole world of already written and debugged COM objects for your use. And there's a wide market for the COM components you write—the Giga Information Group estimates the current market at $400 million a year and expects it to be $3 billion in three years. (The COM-component market is growing faster than Microsoft!) Note that these market estimates are for third-party COM objects: they exclude COM components provided by Microsoft.

Another key feature of COM is that three types of objects are supported: in process (DLL), local (EXE in separate process on the same machine), and remote (DLL or EXE on a different machine via Distributed COM, or DCOM). You write code that uses COM components without worrying (or even knowing) what type of COM object you'll end up using, so you use the exact same code to hook up to an in-process, local, or remote object. How does COM hook you up to the right object? Well, it looks for the object's Class ID in the registry—and the registry entries tell COM which type or types of objects are available. COM does the rest, including starting processes and communicating over the network. (Note: there are performance differences between the different types of COM objects that you'll need to think about—but at least the code for connecting to and using the objects is exactly the same no matter what type of object you eventually use.)

COM doesn't solve all of the world's problems, however. For instance, it's still possible to break programs that use your component when you update a component. (Perhaps the fact that COM enforces a "black box" view of the component where it's not possible to find implementation details makes such breakage less common, but they still occur.) So you still have to choose between updating components in place and risking breakage, and using new Class IDs for new components. But COM does make it somewhat easier to write code that allows the user (or application) to choose what version it will use without recompilation.

Recall that COM components can be written in and used from most any language, and they can reside on any machine. That's nice. But what about cross-platform support?

Well, the cross-platform story is a good-news/bad-news story. The bad news is that there isn't very much COM on any platform besides Win32 right now. There are a couple of ports of COM to some non-Windows platforms, but not many. But that's not all the news.

The good news is that many more ports—to most common UNIX versions and to MVS—are coming, and soon. Further, Microsoft is doing some of the porting work itself. So it won't be long until COM and DCOM will be available on your favorite mainframes and UNIX boxes—availability for UNIX is scheduled to be announced in February. And think of how cool it'll be to have remote COM objects written in any language running on some fast mainframe that you can access from any language (Visual Basic, Java, Delphi, C++) on your machine. Check out the latest information on the Microsoft COM Web site (http://www.microsoft.com/com/).

So if you're developing for Windows, you'll certainly want to consider writing COM objects, no matter whether you develop in Visual Basic, Java, C++, Delphi, or some other COM-compatible language. The objects you write will be usable on the local machine or remotely without rebuilding your component or the component's clients, thanks to the magic of COM and DCOM. And if you need your solutions to run on platforms other than Windows, COM is looking better and better, so it's still certainly worth looking into and seriously considering.

Coming up next: Basic COM concepts you should know

Next week, we'll talk about the basics of COM: objects, interfaces, and modules. And we'll start to dig into the C++ code for a simple COM object, if we have time. (If not, we'll do it the week after next.)

Part 2: Basics of COM

Where we've been; where we're going

In Part 1, the good doctor talked about why a language like C++ doesn't solve the problem of allowing you to build software out of binary components. The gist of that discussion was that C++ wasn't intended to solve this problem; rather, it was intended to make reuse of source code easy for single-executable programs. C++ meets that goal quite well. But we want to be able to mix and match components from different vendors without rebuilding parts (or all) of the system each time a component changes. We went into a lot of reasons why the C++ model doesn't work in this scenario.

So then what? Do you have to abandon C++? Nope—but you have to use it in a way that's a little different than what you're used to. And that's what we'll discuss next—how to use COM from C++.

Does that mean that you should stop reading if you're not a C++ programmer? No, because whatever COM-compatible language you're using (Visual Basic, Visual J++, Delphi, and others) will be doing the things we discuss under the hood (or is that in the operating room?). So if you read on, you'll gain valuable insights as to how those ActiveX controls and COM components work.

Okay, so what is COM?

The Component Object Model (COM) is a way for software components to communicate with each other. It's a binary and network standard that allows any two components to communicate regardless of what machine they're running on (as long as the machines are connected), what operating systems the machines are running (as long as it supports COM), and what language the components are written in. COM further provides location transparency: it doesn't matter to you when you write your components whether the other components are in-process DLLs, local EXEs, or components located on some other machine. (There are performance implications, of course, but you don't have to rewrite a thing to change the other components' locations—that's key.)

Objects

COM is based on objects—but the objects aren't quite the objects you're used to in C++ or Visual Basic. (By the way, an object and a component are pretty much the same thing. Dr. GUI will tend to say "component" when he's talking about application architecture and "object" when he's talking about implementations.)

First off, COM objects are well encapsulated. You cannot gain access to the internal implementation of the object; you have no way of knowing what data structures the object might be using. In fact, the objects are so well encapsulated that COM objects are usually just drawn as boxes. Figure 1 is a drawing of an utterly encapsulated object. Note how the implementation details are hidden from you.

Figure 1. An utterly encapsulated, non-COM object.

That's all well and good for encapsulation, but what about communication? As it stands, we have no way to communicate with the component in that box. Clearly, this won't do.

Interfaces: Communications with an object

That's where interfaces come in. The only way to access a COM object is through an interface. We can draw an interface called IFoo on an object like the one shown in Figure 2.

Figure 2. Object with interface—still not COM.

The thing that looks like a lollipop sticking out of the side of our object is the interface—in this case, the IFoo interface. This interface is the only way to communicate with this object. The good doctor finds it more useful to think of an interface as being like a plug-in connector than a lollipop. It's how you plug into the functionality of the object. Think of it as being like the antenna input to your VCR or TV.

An interface is two things. First, it's a set of functions that you can call to get the object to do something. In C++, interfaces are represented as abstract base classes. For instance, the definition of IFoo might be:

class IFoo {
   virtual void Func1(void) = 0;
   virtual void Func2(int nCount) = 0;
};

We'll ignore the return types and inheritance for now . . . but do note that there can be more than one function in the interface and that all of the functions are pure virtual functions: they do not have implementations in class IFoo. We're not defining behavior here—we're only defining what functions are in the interface. (A real object has to have implementation, of course—more on that later.)

Second—and more importantly—an interface is a contract between the component and its clients. In other words, an interface not only defines what functions are available, it also defines what the object does when the functions are called. This semantic definition is not in terms of the specific implementation of the object, so there's no way to represent it in C++ code (although we can provide a specific implementation in C++). Rather, the definition is in terms of the object's behavior, so that revisions to the object and/or new objects that also implement the interface (contract) are possible. In fact, the object is free to implement the contract in any way it chooses (as long as it honors the contract). In other words, the contract has to be (gasp!) documented outside of the source code. This is especially important since clients won't get (and don't need) the source code.

This notion of a specific contract is crucial to COM and to component software in general. Without "ironclad" contracts, it would be impossible to interchange components.

Interface contracts, like diamonds, are forever

In COM, once you "publish" an interface contract by shipping a component, the contract is immutable—it cannot be changed in any way. You can not add. You can not delete. You can not modify. Why? Because other components are depending on the contract. If you change the contract, you'll break that software. You can improve your internal implementation as long as you still honor the contract.

What if you've forgotten something? What if requirements change? How does the world improve?

The answer's easy: you write a new contract. The standard OLE interface list has many of these: IClassFactory and IClassFactory2, IViewObject and IViewObject2, and so on. And you can, of course, provide an IFoo2. (I'm sure you've noticed by now that interface names, by convention, begin with an uppercase I.)

So if I write a new contract, how does software that only knows about the old contract still use my components? Won't that mess old components up?

COM objects can support multiple interfaces—they can implement multiple contracts

The answer to that is also no—and the reason is simple: in COM, an object can support multiple interfaces. In fact, all useful COM objects support at least two interfaces. (At least the standard IUnknown interface—more on this later—and an interface that does what you want the object to do.) Visual ActiveX controls support about a dozen interfaces, most of them standard interfaces. In order for a component to support an interface, it has to implement each and every method in that interface, so this is a very substantial task. That's why tools like the Active Template Library (ATL) and so forth are popular: they provide implementation for all of the interfaces.

So in order to support the new IFoo2 functionality, we add our IFoo2 to this object as well.

Figure 3. Version 2.0, which supports both IFoo and IFoo2—but still is not a COM object.

If you're still thinking of plugs, think of IFoo as the antenna input to your TV and IFoo2 as the composite video input. Note that you can't plug the antenna cable into the composite video input—or vice versa. In other words, each interface is logically unique.

On the other hand, these interfaces do have something in common. Do I have to rewrite the whole implementation just to add a new interface that's almost exactly the same as the old one? No, because COM supports inheritance of interfaces. As long as we don't change the functions already in IFoo, we can define IFoo2 as follows:

class IFoo2 : public IFoo {
   // Inherited Func1, Func2
   virtual void Func2Ex(double nCount) = 0;
};

Interface review

So let's review what we've seen. First off, COM is a binary standard for software object interaction. Since it's a binary standard, objects don't—and can't—know of the implementation details of the objects they use. Objects, therefore, are black boxes.

We manipulate these black box objects only through the interfaces the objects expose. Finally, a given object can expose as many interfaces as it chooses.

Simple, right?

Well, we've ignored a lot of details. How do those objects get created? How do you gain access to an interface? How do you call an interface's methods? And where's the implementation of these objects, anyway? And when will that pesky object finally be destroyed?

These are great questions—but unfortunately Dr. GUI's almost late for surgery, so we'll have to postpone the answers until Part 3. But the good doctor will deal with one issue now: How are interface methods called?

Calling interface methods

You may have seen this coming already, but this ends up being very simple: COM method calls are merely C++ virtual function calls. We will somehow (more on this in Part 3) get a pointer to an object that implements an interface, then we'll just call the methods of the interface.

First, let's assume that we have a C++ class called CFoo that implements the IFoo interface. Notice that we inherit from IFoo to insure that we implement the proper interface in the proper order.

class CFoo : public IFoo {
   void Func1() { /* ... */ }
   void Func2(int nCount) { /* ... */ }
};

The pointer we use will be called an interface pointer. Assuming we can get one, our code might look something like this:

#include <IFOO.H // Don't need CFoo, just the interface
void DoFoo() {
  IFoo *pFoo = Fn_That_Gets_An_IFoo_Pointer_To_A_CFoo_Object();

  // Call the methods.
  pFoo -> Func1();
  pFoo -> Func2(5);
};

It really is that simple.

But what really goes on underneath? Well, as it turns out, the COM binary standard applies to method calls, too—so COM defines what happens in order to call the function. Specifically, the same thing happens that happens for a virtual function call:

  1. pFoo is dereferenced to find the vtable pointer in the object.

  2. The vtable pointer is dereferenced and indexed to find the address of the function to be called.

  3. The function is called.

See Figure 4 for the numbered steps:

Figure 4. C++ virtual function calls through interface pointer

Remember that in C++ every time you have virtual functions you'll have a vtable that points to those functions—and that the calls are always done by indexing into the vtable.

"Aha!" you say. "I knew it. COM is really tied to C++! It's not a binary standard at all!"

To which Dr. GUI replies, "Nonsense." After all, you can implement this call in any language that supports arrays of function pointers. It's easy to do it in C, for instance—a call to Func2 through the pointer p would look like:

(*((*p)+1))(p, 5); // passing 5 to the 2nd function in the array

Note that we have to pass p as the first parameter—this simulates the C++ this pointer. (*p) is the first indirection (step 1), *((*p) + 1) is the index into the vtable (step 2), and then we call the function with p and 5 (step 3). It's easy, but it's ugly—Dr. GUI showed it so you'd know you could do it (and to make you appreciate C++). In x86 assembly language, it might look something like this:

MOV EAX, [pFoo]      ; step 1
MOV EAX, [EAX + 4]   ; step 2, indexed to 2nd pointer
CALL [EAX]          ; step 3

Dr. GUI is aware that the second and third instructions could be combined into CALL [EAX + 4] if you didn't need to keep the address of the function in EAX.

Why did the good doctor show all this detail? Well, if you can do it in assembly or C, you can do it in any language! Other languages (Visual Basic, Visual J++, Delphi) build the support for doing these calls into their run times or virtual machines—often by using assembly or C code similar to the above.

The point is that any COM method call must use the data structures shown in order to do a call, regardless of what the original language is—or regardless of where the COM object is. We'll discuss how COM achieves location transparency in a future column.

Where we've been; where we're going

Okay . . . so we've discussed interfaces, objects, and how interface methods are called.

An object is the basic unit of COM—it's the thing that COM creates. An object implements some set of interfaces. An interface is a set of methods and a contract for what those methods do. Interface methods are called in the same manner a C++ virtual function is called.

In Part 3, we'll talk about how to create these objects, how to get interface pointers, and how objects are destroyed.

Part 3: Getting Objects and Interfaces

In Part 2, we discussed two really basic concepts in COM: objects and interfaces. We also showed how an object could implement more than one interface. Finally, we discussed the nitty-gritty of how COM method calls are made—and noticed that they're the same as C++ virtual function calls. (But we also noted that you can do them in any language that supports—or can call assembly language to support—pointers to arrays of function pointers.)

More on COM: Creation and destruction of objects; getting interface pointers

But you might have found the discussion somewhat unsatisfying: we never talked about how to create an object, nor did we discuss how to get an interface pointer so we could call methods on the object's interface. And we never talked about how to get rid of objects you no longer need, or how to switch interfaces.

The good doctor will shed some light on these topics in this week's discussion. But first, we need to take care of a little housekeeping. You know how sometimes you go to explain something and you suddenly remember that you forgot a few important things? That's what's happened here—the good doctor forgot that in order to create objects, you've gotta be able to have a way to refer to them—and a way to clearly define your interfaces. So we'll talk about the forgotten pieces, then cover the real fun stuff. (And that's why this column is long—and late.)

Identifiers in COM

If you're thinking ahead, you've noticed that we're going to need some identifiers for various entities in the COM world. First, we're going to need an identifier for the object type (or class). Second, we'll need an identifier for each interface. But what should we use for an identifier? A 32-bit int? A 64-bit int? Well, perhaps we could. But there's a problem: the identifiers will have to be unique across all machines, since there's no way of knowing what machines you'll want to install a component on. Your objects and interfaces will need the same identifier on all machines so that any client can use your component. Further, no other object or interface may use that identifier, no matter where it came from. In other words, these identifiers must be globally unique.

Fortunately, algorithms and data formats exist for creating such identifiers. By using your machine's unique network card ID, the current time, and other data, these identifiers, called GUIDs (globally unique identifiers) are created by a program called GUIDGEN.EXE. GUIDs are stored in 16-byte (128 bit) structures, giving 2128 possible GUIDs. But don't worry about running out of GUIDs: although the good doctor was unable to find the exact number of atoms in the universe, even after searching the Web, he believes it's significantly less than 2128 So there's no shortage of GUIDs and no need for GUID conservation, despite the in-jokes of COM practitioners.

In C++, there are data types defined by COM header files for GUID, CLSID (class identifier GUID), and IID (interface identifier GUID). Since these 16-byte structures are kind of large to be passing around by value, you'll usually use REFCLSID and REFIID as the data types of parameters when passing GUIDs. You will have to create a CLSID for each object type you write and an IID for each custom interface you create.

Standard interfaces

COM defines a large set of standard interfaces and their associated IIDs. For instance, the mother of all interfaces, IUnknown, has an IID of "00000000-0000-0000-c000-000000000046" (the hyphens are part of the standard way of writing GUIDs). This IID is defined by COM and you need never refer to it directly; instead, use the symbol IID_IUnknown, which is defined for you in the headers.

The IUnknown interface has three functions:

HRESULT QueryInterface(REFIID riid, void **ppvObject);
ULONG AddRef();
ULONG Release();

We'll discuss exactly what these functions do later.

Much of your COM programming will be done using standard interfaces—a lot of it will be providing implementations for standard interfaces so that other COM clients and objects can use your object.

By the way, there are some macros used in COM to describe the return types and calling conventions of functions. Almost all COM methods return an HRESULT, so the macro STDMETHODIMP assumes that. The macro STDMETHODIMP_() takes a parameter—the return type of the method. (You only use the STDMETHOD macro when you're defining an interface with pure virtual functions—and the IDL compiler writes that code for you—more on that later.)

Using these macros, the declarations above would look like this:

STDMETHODIMP QueryInterface(REFIID riid, void **ppvObject);
STDMETHODIMP_(ULONG) AddRef();
STDMETHODIMP_(ULONG) Release();

We'll use these macros from now on out. Doing so makes it easy to port your code to different COM platforms (such as Macintosh and Solaris).

Custom interfaces

Custom interfaces are interfaces you create. You'll create your own IID for these interfaces, and define your own list of functions. Our IFoo interface is a custom interface. I've defined an IID called IID_IFoo (which has the value "13C0205C-A753-11d1-A52D-0000F8751BA7") by running the GUID generator on my machine.

Recall that the class declaration was originally:

class IFoo {
   virtual void Func1(void) = 0;
   virtual void Func2(int nCount) = 0;
};

We'll modify this to be COM-compliant by changing it around a bit:

interface IFoo : IUnknown {
virtual HRESULT STDMETHODCALLTYPE Func1(void) = 0;
virtual HRESULT STDMETHODCALLTYPE Func2(int nCount) = 0;
};

Using the macros as described above, this becomes:

interface IFoo : IUnknown {
STDMETHOD Func1(void) PURE;
STDMETHOD Func2(int nCount) PURE;
};

The word "interface" is not a keyword in C++, rather it is #defined in the appropriate COM header as "struct". (Recall that in C++ classes and structs are the same except that structs use public inheritance and access by default rather than private.) STDMETHOD uisesSTDMETHODCALLTYPE, which is defined as __stdcall, indicating that the compiler should generate the standard function calling sequence for these functions. Remember, we use these macros because the definitions of them will change as we port our code to different platforms.

All COM functions (with almost no exceptions) return an HRESULT error code. This HRESULT is a 32-bit number that uses the sign bit to represent success or failure and fields in the remaining 31 bits to indicate the "facility" and the error code (which is specific to the facility), and some reserved bits. Normally you'll want to return the success code S_OK, but you can return an error code—either a standard one or one you make up—if you encounter a problem in your method.

Finally, note that I'm deriving IFoo from the standard COM interface IUnknown. That means that any class that implements IFoo will also need to implement the three functions AddRef, Release, and QueryInterface. Also, the IFoo vtable will have pointers to these three functions before the pointers to Func1 and Func2. That's a total of five functions in the vtable, and five functions to implement. All COM interfaces are derived from IUnknown, so all COM interfaces contain these three functions in addition to any other functions.

What's that thing in the MIDL?

You won't actually write the declaration above yourself—it'll be generated for you by the MIDL compiler. Why? Well, as it turns out, C++ can't express everything that needs to be expressed in an interface. Recall that COM objects can be DLLs to be used in-process, meaning in the same address space. So if you pass a pointer to some data to an in-process server, the server can dereference the pointer directly.

But also recall that your COM object can be a local (out-of-process) server in separate EXE address spaces, or even accessed remotely. Any time you need to pass a pointer to a COM method in such an object, you're got a problem: the pointer is meaningless in any other address space. What's meaningful is the data to which the pointer points. This data has to be copied into the other address space—and perhaps back. This process of copying the right data is called marshalling. Thankfully, COM does the marshalling for you in most cases. But in order for it to do so, you need to tell it more than just the type the pointer points to—you need to tell COM how the pointer is used. For instance, does the pointer point to an array? A string? Is the parameter an input parameter only? An output parameter? Both? You can see that there's no way to express this in C++.

So we'll need another language, called IDL (Interface Definition Language) to define the interface. IDL looks a lot like C++, but it has "attributes" in square brackets added in to the C++-like code. MIDL.EXE compiles the IDL file you (or Visual Studio) write to produce a variety of outputs. For now, the only output we care about is the header file for our interface, which we'll include in our code.

In our example, it doesn't make any difference since we're only passing by value, so the IDL code looks very similar—the main difference is that the word "virtual" is missing. But if we created a new interface IFoo2 which adds a method Func3(int *) to the other two methods, the IDL would look something like this:

[ uuid(E312522F-A7B7-11D1-A52E-0000F8751BA7) ]
interface IFoo2 : IUnknown
{
   HRESULT Func1();
   HRESULT Func2(int in_only);
   HRESULT Func3([in, out] int *inout);
};

Note a few things. First, there are various attributes in the IDL, enclosed in square brackets. The attributes always apply to the thing immediately after, so the uuid attribute above applies to the interface—it's the IID for the interface. (UUID, or universally unique identifier, is a synonym for GUID.) The [in, out] attribute applies to the pointer and tells COM that it will have to marshal a single int both in and out when it calls Func3 (if marshalling is required). If the int pointer referred to an array, it would have an additional attribute (size_is with a parameter). There is IDL code to define the object as well. For instance, the code fragment to define our object might look like this:

[ uuid(E312522E-A7B7-11D1-A52E-0000F8751BA7) ]
coclass Foo
{
   [default] interface IFoo;
};

This is how the CLSID is associated with the class—and how the set of interfaces the class implements is defined. Note that although this looks a lot like C++ with a couple of additional attributes, it doesn't correspond exactly to C++ code like the interface definition does.

Creation of objects

Once our CLSID is associated with an object type (more on this later), we can create an object. As it turns out, this is very simple—just one function call:

IFoo *pFoo = NULL;
HRESULT hr = CoCreateInstance(CLSID_Foo, NULL, CLSCTX_ALL,
               IID_IFoo, (void **)&pFoo);

If CoCreateInstance succeeds, it creates an instance of the object identified by the CLSID GUID, CLSID_Foo. Note that there's no such thing as a "pointer to the object"; instead, we always refer to the object through an interface pointer. So we have to specify which interface we want (IID_IFoo) and pass a pointer to a place for CoCreateInstance to store the interface pointer.

The two parameters we've not discussed yet are not important at the moment.

Once we make the call, we check to make sure that the call succeeded and go ahead and use the object:

if (SUCCEEDED(hr)) {
   pFoo->Func1();   // Call methods.
   pFoo->Func2(5);
   pFoo->Release();   // MUST release interface when done.
}
else // Creation failed...

CoCreateInstance returns an HRESULT to indicate whether it succeeded or not. Always use the SUCCEEDED macro to check the result since nonnegative values mean success. In fact the most common success code, S_OK, is zero—so a check like "if (hr) // Success" won't work at all. Once the object has been created successfully, you can use the interface pointer to call the methods of the interface, as shown above.

It is vitally important that you release the interface pointer when you're done with it by calling Release. Note that since all interfaces are derived from IUnknown, all interfaces support Release. The COM object is responsible for freeing itself when you tell it you're done with it, but it relies on you to tell it when you're done. If we'd forgotten to call Release, the object would be leaked (and locked in memory at least until our application closed—and perhaps until the system is rebooted). Messing up object lifetime is a very common COM programming problem—and it's often difficult to find. So be careful, starting now. Note that we only release the interface if we were actually able to create it.

Figure 5 is a diagram of our newly created object. By convention, IUnknown is not labeled; it's always drawn attached to the upper right hand corner of the object. All of the other interfaces are drawn on the left.

Figure 5. Our first simple COM object, with unlabeled IUnknown.

Now that we have IUnknown implemented, we really have a COM object. (If only it was as simple as drawing a connector!)

If we'd added an IFoo2 interface to the object, we'd have a total of three interfaces, drawn as in Figure 6.

Figure 6. Theoretical version 2.0, which supports both IFoo and IFoo2.

GUIDs and the registry

So how did COM find the object's code in order to create it? Simple: it looked in the registry. When a COM component is installed, it has to have entries made in the registry. For our Foo class, the entry might look something like this:

HKEY_CLASSES_ROOT
  CLSID
    {E312522E-A7B7-11D1-A52E-0000F8751BA7}="Foo Class"
      InprocServer32="D:\\ATL Examples\Foo\\Debug\\Foo.dll"

Most objects will have some additional entries, but we can ignore these for now.

At HKEY_CLASSES_ROOT\CLSID, there's an entry for the CLSID of our class. That is how CoCreateInstance looks up the DLL name for the component. When you provide CoCreateInstance with the CLSID, finds the DLL name, loads the DLL, and creates the component (more on this later).

The registry entries would look somewhat different if the server was out-of-process or remote, but the main point is that the information would be there so that COM could start the server and create the object.

If you know the name (ProgID) of the object but not its CLSID, you can look up the CLSID in the registry. For our object, there's an entry at:

HKEY_CLASSES_ROOT
  Foo.Foo="Foo Class"
    CURVER="Foo.Foo.1"
    CLSID="{E312522E-A7B7-11D1-A52E-0000F8751BA7}"
  Foo.Foo.1="Foo Class"
    CLSID="{E312522E-A7B7-11D1-A52E-0000F8751BA7}"

"Foo.Foo" is the version-independent ProgID, and Foo.Foo.1 is the ProgID. If you create a Foo object from Visual Basic, the CLSID is looked up using one of these ProgIDs. (Note that the ATL wizards don't create the registry entries quite correctly in current versions: they leave out the first of the two CLSID keys shown above. Don't forget to make a copy of the CLSID for the version-independent ProgID.)

Modules, component classes, and interfaces

Note that it's possible—in fact common—for one module (DLL or EXE) to implement more than one COM component class. When this happens, there will be more than one CLSID entry that refers to the same module.

So now we can define the relationship between modules, classes, and interfaces. A module (the basic unit that you build and install) can implement one or more components. Each component will have its own CLSID and entry in the registry that points to the module's file name. And each component implements at least two interfaces: IUnknown, and an interface that exposes the component's functionality. Figure 7 shows this.

Figure 7. Module Oo.DLL contains implementations for three objects: Foo, Goo, and Hoo. Each object implements IUnknown and one or more additional interfaces.

Getting to the other interfaces with QueryInterface

Let's say that we have a new and improved Foo2 object that implements two custom interfaces: IFoo and IFoo2. We already know how to create such an object using CoCreateInstance and how to get a pointer to one of its three (don't forget IUnknown) interfaces.

Once we've got that interface pointer, how do we get an interface pointer to one of the object's other interfaces? We can't call CoCreateInstance again—that would create a new object. We don't want that—we only want a different interface on the existing object.

That's the problem that IUnknown::QueryInterface solves. Remember, because all interfaces inherit from IUnknown, all interfaces implement QueryInterface. So we'll just use the first interface pointer to call QueryInterface to get the second interface pointer:

IFoo *pFoo = NULL;
HRESULT hr = CoCreateInstance(CLSID_Foo2, NULL, CLSCTX_ALL,
               IID_IFoo, (void **)&pFoo);
if (SUCCEEDED(hr)) {
   pFoo->Func1();   // call IFoo::Func1
   IFoo2 *pFoo2 = NULL;
   hr = pFoo->QueryInterface(IID_IFoo2, (void **)&pFoo2);
   if (SUCCEEDED(hr)) {
      int inoutval = 5;
      pFoo2->Func3(&inoutval);   // IFoo2::Func3
      pFoo2->Release();
   }
   pFoo->Release();
}

We pass QueryInterface the IID of the interface we want and a pointer to the place for QueryInterface to store the new interface pointer. Once QueryInterface returns successfully, we can use the interface pointer to call that interface's function.

Note well that we must release both interface pointers when we're done with them. Failure to release either of them will leak the object. Since we never refer to the object except through interface pointers, we have to release each and every interface pointer we get in order for the object as a whole to be released.

IUnknown's other functions

IUnknown has two other functions, AddRef and Release. We've seen already that you use Release to tell an object that you're done with an interface pointer. So when do you use AddRef?

Reference counts and when an object can be freed

Most COM objects keep a reference count—in other words, they're required to keep track of how many interface pointers to the object are in use. When the reference counts on all of the object's interfaces goes to zero, it can be freed. We don't explicitly free the object; we just release all of the object's interface pointers and the object frees itself at the appropriate time.

AddRef increments the reference count, and Release decrements it. So if we didn't call AddRef, why did we have to call Release?

Whenever QueryInterface hands out a new pointer to an object, it's responsibility of QueryInterface to call AddRef before returning the pointer. That's why we didn't have to call AddRef for the pointers we got—QueryInterface did it for us. (Note that CoCreateInstance calls QueryInterface—which calls AddRef—so this is true even for our first interface pointer to an object.)

Note that you're required to call Release on the same interface pointer on which you called AddRef. Objects can, if they want, keep track of references on an interface-by-interface basis. The code above carefully did this, correctly pairing implicit AddRef calls with the appropriate Release calls—one Release call for each interface pointer.

You need to call AddRef if you're making a copy of an interface pointer so that the reference count for the interface is accurate. When you need to do this or not is a bit complex, but it's well covered by various COM references. Check them out for the details.

Various smart pointer classes can make dealing with the great IUnknown much easier (in fact, automatic). There are several such classes in ATL and Visual C++ 5.0. And if you're using another language such as Visual Basic or Java, the language's implementation of COM deals with the IUnknown methods correctly for you.

Where we've been; where we're going

So we've talked about how to create objects and destroy them (we don't—we just release all of our interface pointers to them), and how to call interface methods and switch interfaces. Along the way, we also introduced the concepts of various GUIDs used to identify the objects and interfaces and the registry entries needed so that COM can figure out how to create your object.

In Part 4, we'll talk more specifically about how in-process objects are created, and ways to make that creation more efficient. If there's time, we'll also talk about the guts of implementing an object, including the code you need for creating an object and IUnknown.

Part 4: The Class Object and Class Factory

In Part 3, we talked about how to create and destroy objects (we don't destroy them—we just release all interface pointers to them) and how to call interface methods and switch interfaces. Along the way, we also introduced the concepts of the various GUIDs used to identify the objects and interfaces and the registry entries needed so that COM can figure out how to create your object.

This time, we'll talk more specifically about how in-process objects are created, and ways of making that creation more efficient. We'll also talk about the class object (also known as class factory) and how to implement one. There's not time this week to talk about implementing your actual object, but that'll be at the top of the agenda next week.

What happens when you call CoCreateInstance?

We've talked already about how, when you call CoCreateInstance, COM searches the registry to find the CLSID so it can find the DLL (or EXE) that implements the object. But we didn't explain the details of how that happens. CoCreateInstance encapsulates the following functionality:

IClassFactory *pCF;
CoGetClassObject(rclsid, dwClsContext, NULL,
      IID_IClassFactory, (void **)&pCF);
hresult = pCF->CreateInstance(pUnkOuter, riid, ppvObj)
pCF->Release();

As we can see, there are three steps. The first step is to get a class object via its IID_IClassFactory interface. Next, we call IClassFactory::CreateInstance on this class object. (The parameters for this call are passed in from the CoCreateInstance call.) The parameter pUnkOuter is used for a reuse method called aggregation, which we'll talk about later. Assume that it's NULL for now. We now have a pointer to an instance of our object in *ppvObj. Finally, we release the class object.

So what is this class object? Why do we have to bother with it?

The class object

The class object is a special COM object whose main purpose is to implement the IClassFactory interface. (You'll often hear this object referred to as a "class factory" or even "class factory object," but it's more accurate to refer to it as the class object.)

If you've used Java extensively, you can think of the COM class object as being roughly like a Java object of class "Class." And you'll note that Java's Class.newInstance is analogous to IClassFactory::CreateInstance just as COM's CoGetClassObject is analogous to the Class.forName static method.

This object is special because it's not created by calling CoCreateInstance or IClassFactory::CreateInstance, as are most COM objects. Rather, it's always created by calling CoGetClassObject. We'll see other examples of special COM objects at the end of this article. (As it turns out, CoGetClassObject doesn't always create a class object. If COM has a class object for the right class available, it can just return an interface pointer to it.)

After the call to CoGetClassObject, note that the code doesn't have to worry about what kind of object it's creating—it doesn't matter whether it's an in-process or local server, for instance. The class object handles all those differences. CoGetClassObject, however, does need to do the work of digging through the registry (and list of existing registered class objects) in order to figure out how to create or find a class object for the CLSID requested.

The class object is a great example of the power of polymorphism. We call a COM API in order to get the object. But once we've got it, we can determine that it supports the standard interface we need (IClassFactory) and we can then call the methods of that interface—in this case, IClassFactory::CreateInstance. Note that we have no idea how the class object's CreateInstance works. All we know is that if it succeeds, it will return an interface pointer that refers to the object. We don't have to and don't want to know anything else (that's encapsulation) and we get the right behavior for the particular class object by making the exact same function call (that's polymorphism)—it's the identity of the class object that determines the exact behavior.

Each class object instance is associated with a particular CLSID—note that IClassFactory::CreateInstance does not have a CLSID as one of its parameters. Rather, the class object knows what CLSID it is to create. That means that you'll need at least one class object for each separate CLSID you want to be able to create.

In addition to IClassFactory, the class object can implement whatever interfaces it likes. For instance, you could define an interface that allows you to set defaults for object instances created from a particular class object. But note that you're not guaranteed that there is only one class object for a given CLSID, so if you call CoGetClassObject more than once, you may well get interface pointers to different class objects. (Since you control the creation of the class object, you can define this in your implementations.)

Why there's a class object

As we discussed, the most important reason for COM to require implementation of a class object is so that COM can have a standard polymorphic way of creating objects of any type without requiring the client to know the exact details of creation. The class object encapsulates that knowledge, so the client doesn't have to. This implies that the class object and the "real" object have a very close relationship—and often lot of knowledge of each other.

But why not a simpler scheme? For instance, you could imagine a function in your COM DLL called, say, DLLCreateInstance that would accept a CLSID and create a new instance. A function such as this is certainly simpler than a COM object and IClassFactory.

But it wouldn't work for EXEs. You don't just export functions from EXEs. And it certainly wouldn't work well for remote objects. So when we make the class object a COM object, COM takes care of all of the in-process and out-of-process issues for us. That's a good deal.

Since the class object is a COM object that knows how to "do the right thing" to create an instance of the target object, note that once the class object is created, COM is out of the picture in terms of creation of instances. So for the first object of a particular type that's created, COM has to do a lot of work. First, it has to look up the CLSID in the list of registered class objects (or in the registry if the class object doesn't exist). If the class object needs to be created, COM creates it, perhaps including loading a DLL or starting an EXE. Finally, COM calls IClassFactory::CreateInstance on the correct class object to create your instance. Phew!

But if you keep the class object around, you can skip most of the work for subsequent instances: just call IClassFactory::CreateInstance yourself to make additional objects. This can be almost as fast as calling operator new directly—and far faster than having COM create objects.

Important If you keep a class object around, you must call IClassFactory::LockServer to tell COM to keep the server in memory. The reference to the class object will not keep the server in memory automatically. This behavior is an exception to the normal COM behavior. If you fail to lock the server, you may cause a protection violation if you try to access the class object after the server's been unloaded. Don't forget to unlock the server when you're done with the class object.

Finally, the class object can support additional ways to create objects, such as the IClassFactory2 interface that's used instead of IClassFactory to create licensed controls. Licensed controls are controls that require the user to have the correct license ID before the control can be created.

Another way to create objects and when to use it

If you're creating only one instance of an object and if you can use IClassFactory to create the object, you may as well use CoCreateInstance (or CoCreateInstanceEx, which can create remote objects). But if you're creating more than one instance of an object, or if you need to use an interface besides IClassFactory to create the object, you'll need to get (and probably hold) a class object.

Getting the class object is easy—just do as CoCreateInstance does: call CoGetClassObject. Once you have the interface pointer to the class object, call IClassFactory::LockServer(TRUE) to lock the server in memory. Then you can hold on to the interface pointer to the class object and call IClassFactory::CreateInstance whenever you need a new instance. Finally, when you're done creating objects, release the server by calling IClassFactory::LockServer(FALSE) and release the interface pointer by calling Release on it. Remember that releasing the interface has to be the last thing you do to the interface.

Implementing the class object

So what does this class object look like? Well, it's a simple COM object. That means that it implements at least one interface: IUnknown. Almost all class objects also implement IClassFactory so they can create instances.

We might have a class object declared like this:

class CMyClassObject : public IClassFactory
{
protected:
   ULONG m_cRef;
public:
   CMyClassObject() : m_cRef(0) { };
      //IUnknown members
      STDMETHODIMP QueryInterface(REFIID, void **);
      STDMETHODIMP_(ULONG) AddRef(void);
      STDMETHODIMP_(ULONG) Release(void);

      //IClassFactory members
      STDMETHODIMP CreateInstance(IUnknown *, REFIID iid, void **ppv);
      STDMETHODIMP LockServer(BOOL);
};

Of course, this class contains declarations for each of the functions in IclassFactory::CreateInstance and LockServer. Plus (surprise!), there are the IUnknown functions. (Remember that IClassFactory is derived from IUnknown, as are all COM interfaces.) Note that we have a member that holds the reference count for this object and that we've initialized it to zero in the constructor. Note also that we're using the official COM macros for declaring method impmentations.

How this class object is created

There are a variety of ways to create a class object, none of which involve CoCreateInstance. Since we really only need one instance of this object and since it's a small object with no constructor, I decided to just declare a global object in my code:

CMyClassObject g_cfMyClassObject;

That means that this object will always exist when the DLL is loaded.

In order to implement IClassFactory::LockServer, we'll also need a global count of all of the nonclass object instances and the number of times LockServer was called:

LONG g_cObjectsAndLocks = 0;

How CoGetClassObject gets the class object

For in-process DLL servers, this is simple: COM calls a function called DllGetClassObject in your DLL. You must export this function if your DLL contains COM-creatable COM objects. DllGetClassObject has the following prototype:

STDAPI DllGetClassObject(const CLSID &rclsid, const IID &riid,
void ** ppv);

COM passes in a CLSID and an IID; DllGetClassObject returns a pointer to the requested interface in *ppv. If the class object can't be created or the requested interface doesn't exist, an error is returned in the HRESULT return value (note that STDAPI is #defined to return an HRESULT).

For EXE servers, the process is different: You register a class object for each class COM can create by calling CoRegisterClassObject for each class object. This puts the class objects in the list of registered class objects. When the EXE process ends, it calls CoRevokeClassObject once per class object to remove the objects from the registered list. If you need more details on this, check the COM docs or various COM books—I'd like to focus on in-process (DLL) servers here.

Note, then, that how COM actually gets the class object when you call CoGetClassObject depends on whether the object is implemented by a DLL or an EXE. If a DLL, it loads the DLL (if not already loaded) and calls DllGetClassObject. For an EXE, it loads the EXE (if not already loaded) and waits until the EXE registers the class object it's looking for or until a timeout occurs.

Our DllGetClassObject might look like this:

STDAPI DllGetClassObject(REFCLSID clsid, REFIID iid, void **ppv) {
   if (clsid != CLSID_MyObject) // Right CLSID?
      return CLASS_E_CLASSNOTAVAILABLE;

   // Get the interface from the global object.
   HRESULT hr = g_cfMyClassObject.QueryInterface(iid, ppv);
   if (FAILED(hr))
      *ppv = NULL;
   return hr;
}

We must check to see that the CLSID requested is the one we support. If not, we return E_FAIL. Next, we QueryInterface for the interface requested. If this fails, we set the output pointer to NULL and return E_NOINTERFACE. If it succeeds, we return S_OK and the interface pointer.

Implementing the methods of the class object

IUnknown::AddRef and IUnknown::Release

Our class object is global. It always exists and it can't be destroyed (at least not until the DLL is unloaded). Since we'll never delete this object and since references to class objects don't keep a server loaded, we almost don't need to implement reference counting. However, reference counting can be handy for debugging, so we'll implement it in this object anyway.

AddRef and Release are responsible for maintaining the reference count on the object. Note that we have an instance variable m_cRef that's been initialized to zero. AddRef and Release will just increment and decrement the reference counter and return the new value of the reference counter.

If the object was dynamically created, it would be the responsibility of Release to delete the object when the reference count went to zero. Since our object is globally allocated, we can't do that.

STDMETHODIMP_(ULONG) CMyClassObject::AddRef() {
   return InterlockedIncrement(&m_cRef);
}

STDMETHODIMP_(ULONG) CMyClassObject::Release() {
   return InterlockedDecrement(&m_cRef);
}

I used the thread-safe increment and decrement functions rather than just using ++m_cRef and --m_cRef to get into the habit of thinking about multithreaded operation.

If you wanted to make AddRef and Release real simple, you could simply have them return a nonzero value—you could also eliminate the member variable for the reference count for the class object (but not the objects and locks count global variable!).

IUnknown::QueryInterface

The QueryInterface implementation is 100 percent standard for this object—no special stuff because it's a class object. All we do is see whether the interface requested is one of the two interfaces (IUnknown and IClassFactory) that we support. If it is, we return an interface pointer, cast appropriately, to our object—and we call AddRef on that exact pointer to reference count. If not, we return the appropriate error code, E_NOINTERFACE.

STDMETHODIMP CMyClassObject::QueryInterface(REFIID iid, void ** ppv) {
   *ppv = NULL;
   if (iid == IID_IUnknown==iid || iid == IID_IClassFactory) {
      *ppv = static_castthis;
      (static_cast*ppv)->AddRef();
      return S_OK;
   else {
      *ppv = NULL; // COM Spec requires NULL if failure
      return E_NOINTERFACE;
   }
}

Note the funky new static_cast operator. In ANSI C++, you can distinguish between the three different semantic uses of casts by using different operators. The static_cast operator does the appropriate cast between pointers to different class types, changing the value of the pointer if necessary (it's not in this case because I'm not using multiple inheritance).

IClassFactory::CreateInstance

Here is the heart of our class object—the function that creates instances.

STDMETHODIMP CMyClassObject::CreateInstance (IUnknown *pUnkOuter,
   REFIID iid, void ** ppv)
{
   *ppv=NULL;

// Just say no to aggregation.
   if (pUnkOuter != NULL)
      return CLASS_E_NOAGGREGATION;

   //Create the object.
   CMyObject *pObj = new CMyObject();
   if (pObj == NULL)
      return E_OUTOFMEMORY;

   //Obtain the first interface pointer (which does an AddRef).
   HRESULT hr = pObj->QueryInterface(iid, ppv);

   // Delete the object if the interface is not available.
   //Assume the initial reference count was zero.
   if (FAILED(hr))
      delete pObj;

   return hr;
}

First off, we don't support aggregation, so if the pointer is non-NULL, we can't create the object because we're being asked to support aggregation. Next, we allocate the object and return E_OUTOFMEMORY if we can't allocate the object.

Next, we call QueryInterface on the newly created object to get an interface pointer to return. If this fails, we delete the object and return the error code. If it succeeds, we return the success code from QueryInterface. Note that QueryInterface will call AddRef if it succeeds, giving us a correct reference count for the object.

Note also that we did not increment the object and lock counter, g_cObjectsAndLocks. We could have done this if creation succeeded, but we would have to decrement it either in the instance object's Release or in its destructor. We'll put it in the destructor of the object itself—in Part 5. But if the decrement is in the destructor, then the increment should be in the constructor, not here.

There are a number of different patterns for doing the initial QueryInterface on the object, depending on how the object itself does its initial reference counting. An issue that comes up is that in some cases, an object will do something in the process of doing QueryInterface that causes the a pair of AddRef and Release calls to be executed. If the initial reference count of the object is zero, the call to Release will cause the object to free itself—even before CreateInstance returns. Not good.

One common technique is to set the object's initial reference count to one rather than zero. It's easy to do this in the object's constructor (see Part 5). If you do that, though, you have to modify CreateInstance to call Release after it calls QueryInterface so that the reference count will be set right.

If you do this, you omit deleting the object. If QueryInterface fails, it won't call AddRef—so the object's reference count will be one, not two. If you call Release at that point, the object's reference count will go to zero and the object will delete itself. If QueryInterface succeeds, it will increment the reference count to two and then the Release will decrement the reference count at one, where it should be for a healthy object.

If you assume that the initial reference count is one, you end up with CreateInstance code for the QueryInterface to the end that looks like this:

// ...

//Obtain the first interface pointer (which does an AddRef).
   HRESULT hr = pObj->QueryInterface(iid, ppv);

   // Delete object if interface not available.
   // Assume the initial referece count was one, not zero.
    pObj->Release(); // Back to one if QI OK, deletes if not

   return hr;
}

We'll use this code for our object in Part 5: it's simple, and it always works. The good doctor doesn't consider it a disadvantage that CreateInstance has to know implementation details about the object—after all, that's what CreateInstance is for: to encapsulate such details so the client doesn't have to worry about them.

IClassFactory::LockServer

LockServer merely increments and decrements the global lock and object count. It does not attempt to release the DLL when the count goes to zero. (If this was an EXE server, the server would be shut down when the count went to zero, provided there weren't any interactive users.)

STDMETHODIMP CMyClassObject::LockServer(BOOL fLock) {
   if (fLock)
      InterlockedIncrement(&g_cObjectsAndLocks);
   else
      InterlockedDecrement(&g_cObjectsAndLocks);
   return NOERROR;
}

Again, I've chosen to make this code thread safe. When the count goes to zero, the object can be deleted.

DllCanUnloadNow

COM will call DllCanUnloadNow to decide whether or not to unload a DLL. We simply return S_OK if it's okay to unload, S_FALSE if not. It's okay to unload if there are no objects or locks on the server.

STDAPI DllCanUnloadNow() {
   if (g_cObjectsAndLocks == 0)
     return S_OK;
   else
      return S_FALSE;
}

Where we've been; where we're going

So we've discussed part of how in-process objects are created and ways of making that creation more efficient. We also talked about the class object (also known as class factories) and how to implement one. But we didn't get around to actually implementing an object.

Next time, we'll talk about the guts of implementing an instance object, including the code you need for IUnknown and your own custom interfaces—and maybe even talk about special high-efficiency COM objects that don't use COM to be created.

A note: We've been using C++ to do these implementations, but you can also use C. The good doctor doesn't see any reason to (especially since mixed C and C++ programs are fine). But if you really want to for some reason, there are examples on MSDN, including the topic, "RectEnumerator in C: ENUMC.C," in Chapter Two of Inside OLE.

Your turn

Do you have any topics you'd like to see the good doctor address? You can write the Doc at drgui@microsoft.com. Although the good doctor's surgery schedule precludes individual replies, Dr. GUI does read and consider all mail.


Performance Prescriptions for Microsoft Windows NT 5.0

DR. GUI Online
December 15, 1997

Dr. GUI
MSDN Online

Tired of J/Direct yet? So's the doctor. It's wonderful stuff, but four (!) weeks of it (see "Going Native with J/Direct") is quite enough, huh? Dr. GUI must say, however, that he enjoyed greatly the opportunity to see how J/Direct bridges the sometimes nontrivial gaps between Java and Windows—even if you don't program in Java, studying it helps your understanding of Windows.

Anyway, Dr. GUI was reading his e-mail one day when he came across an interesting document from some folks on the Windows NT team. The document contains a set of guidelines for making applications load and execute more quickly under Microsoft Windows NT 5.0. While the tips are for Windows NT 5.0, many of them apply equally well to earlier versions of Windows NT and Windows 95.

Anyway, the good doctor thought that some of you could use these prescriptions, so he asked the folks at Windows NT if he could edit them up a bit and publish them. They gave permission, so here the list is.

This list isn't comprehensive; rather, the intent is to provide developers with a short list of "do's" and "don'ts." You'll certainly know other tricks for improving your program's performance.

Many of the tips attempt to reduce either your working set size or the number of pages your application touches. Reducing both of these makes your application faster (perhaps much faster in low-memory situations) because the operating system will have to do less swapping—if the applications are smaller, you don't need as much virtual memory.

  1. For best efficiency, do not statically link to the C Runtime Library

    This is kind of a hard-core recommendation, but if you spend some effort following it for your programs, you'll get some improvements in both speed and load time. If the effort needed to implement this for your program is high, be sure to do some quick tests to convince yourself that the performance gain is worth the pain.

    Instead of C Runtime Library routines, use routines exported by NTDLL instead. There is absolutely no hit in performance for using these routines since NTDLL is already in the address space of every process on the system anyway. Linking with MSVCRT.LIB is okay. However, for better efficiency, you shouldn't link with LIBC.LIB or LIBCMT.LIB.

    In general, using Win32 routines instead of C Runtime routines is a great idea for all Win32 platforms because it reduces your working set size, making your application faster because of reduced swapping. This is especially important if your application consists of more than one module since each module would get its own copy of each statically linked C Runtime routine it uses. (Using a common copy in a DLL is much more efficient in working space.) The only tradeoff is that such code is somewhat less portable than it might be otherwise.

  2. Use LoadLibrary() or the linker's new "Delay Load" facility where appropriate

    Loading and linking a DLL is expensive (time consuming). And DLLs that you use normally are loaded and linked to your program at the very worst possible time: before any of your code executes—in other words, while your user is sitting and waiting for your application to start.

    So if you link to a DLL in which you only use a few functions—or if you rarely actually use the DLL—then it makes sense to postpone loading and linking it. Today, on all Win32 systems, you can do this by loading it at runtime using LoadLibrary() and GetProcAddress(). Or if you're using Windows NT 5.0, note that the Windows NT 5.0 linker has a new "Delay Load" capability.

  3. Most DLLs should call DisableThreadLibraryCalls() during process attach

    For any Win32 DLL, the DllMain function in your DLL will be called numerous times with a "reason" parameter set to a value that indicates why it was called. First, it's called with DLL_PROCESS_ATTACH once for each process that attaches to the DLL. In this situation, you'll often want to initialize some of the DLL's data structures. It's also called with DLL_PROCESS_DETACH when the process detaches from the DLL. Although it's less common, it's possible to use this opportunity to do clean up such as freeing memory, file handles, or other system resources.

    However, DllMain is also called for each thread that attaches to (DLL_THREAD_ATTACH) or detaches from (DLL_THREAD_DETACH) the DLL.

    Most DLLs do not need to be notified for thread create/destroy operations. You could simply return for thread attaches/detaches, but that would mean paging in DllMain each time a thread attaches or detaches, thereby increasing your working set. And remember, a bigger working set means more disk thrashing, which means slow performance.

    So if your DLL doesn't need thread notifications, call DisableThreadLibraryCalls() during process attach (DLL_PROCESS_ATTACH). If you must do work during a thread attach/detach, take care to minimize the number of pages referenced to keep the working set as small as possible.

  4. Declare constants as CONST

    If you tell the compiler that a variable is const by using the const keyword, two things can happen. First, if the address of the constant is never referenced, it can be eliminated entirely from your variable space. Second, even if the variable's address is referenced, the compiler will put it in a read-only page of memory. Either of these mean that there will be fewer read/write (more properly, copy-on-write) pages—and that these pages will be more densely packed with memory that's actually changing over time. This can speed up paging tremendously because read-only pages don't have to be written to disk—they can simply be discarded and loaded from the original image file when they're needed.

    In DLLs, since every process gets its own set of read/write and copy on write pages, properly declaring constants saves the copy-on-write pages in proportion to the number of processes that use a DLL, literally multiplying your savings. (In a DLL, the read/write pages are initially marked read-only and are shared between all processes that use the DLL. It's only when you write to a page that a new copy of the page is made for the process that did the write. Copying the page is time-consuming, so it's best to minimize it.) This applies to all Win32 applications, but especially to DLLs.

  5. Statically initialize DLL global variables where possible—and don't set a global variable to the value to which it's been already initialized

    Many global variables are set during DLL initialization to values that could well have been set at compile time. Since your initialization writes to the pages, the pages will have to be copied on the first write—a rather expensive process. To avoid this, statically initialize the global variables to the correct values and be sure not to reinitialize them later on. Again, this applies to all Win32 DLLs.

  6. Each service should have exactly one RPC endpoint/protocol

    This tip applies only to Windows NT services. Each service should have no more then one remote procedure call (RPC) endpoint/protocol. If you're merging two services into one, use named pipe aliases to allow old clients to connect. Service start/stop code should simply register/unregister RPC interfaces.

  7. Restrict use of private heaps

    It's fairly common to set up your own private heaps for particular routines or data structures. While doing this can help you touch fewer pages as you access the data structure (since the data structure and nothing else will be on this heap), keep in mind that indiscriminant use of private heaps will result in many poorly utilized heap pages. Be sure to test different strategies before you commit to a design. This applies to all Win32 programs.

  8. Use well-behaved data structures that aren't spread across many pages

    This is a huge problem for all Win32 programs.

    By and large, most Win32 systems are memory-bound, meaning that the systems are often running in a state where the amount of memory needed by the programs running exceeds the amount of physical memory present on the machine. In other words, they use a lot of virtual (disk) memory.

    Each time the system needs a page of memory and none is available, it has to pick a page to swap out. If that page is a read/write page, it has to be written to disk so it can be restored later. So we'll have one disk operation to write the page, and one to read it in later.

    But even if the page can be discarded and loaded from the original file later, you have one disk operation to read the page when it's needed next.

    If you stop to consider that each disk operation takes thousands of times longer than a simple memory access, it becomes clear why it's so important to work so hard to avoid large working sets and swapping. It's also clear why the quickest and best performance improvement for most Windows machines is simply adding more RAM.

    By the way, when we have a paging system, we can't really call it RAM anymore, can we? RAM, as you'll recall, stands for "random access memory." Random access means that you can access any address in exactly the same amount of time. But that's not true for a paging system: the amount of time varies radically depending on whether the page is present or not. In fact, even systems that have caches are not really random access, since the access time depends on whether the data being accessed is in the cache or in RAM (or on disk, if you're using paging and caching, as most computers do).

    But it's not only the number of pages you access that makes a difference, it's also the pattern you use to access them. For instance, let's say that we have to write a value to four megabytes (1024 4K pages) of memory. And let's say that there are only 512 pages free.

    Compare what happens if we write each page completely before moving to the next to what happens if we write one DWORD in the first page, one DWORD in the second page, and so forth. In the first case, we'd generate 512 page faults. In the second, we'd generate about a million (nearly 1024 squared) page faults. If each page fault takes 10 milliseconds (ms) to service, the running time of the program goes from about five seconds (512 times 10 ms is 5120 ms) to about 2.75 HOURS (1,000,000 times 10 ms is 10,000,000 ms, or 10,000 seconds; that is, 167 minutes). Now Dr. GUI may not have used quite accurate numbers here, and this is the worst possible case, but you can see that minimizing how many times each page is accessed can make a huge difference in your program's running time. (Or you could have added more memory to avoid paging.) So the key to minimizing page swaps is to have good "locality of reference," meaning that accesses during a short time tend to be bunched on a small group of pages during rather than scattered over many pages.

    So what does this mean to you? Well, one thing: trees and linked lists tend to have very bad locality of reference, especially if they're not allocated carefully. For instance, let's say we allocate one node in a linked list, then a 4K string, then the next node, then a 4K string, and so on. Each node will be in a different page, so traversing the list will be very much like the bad case above. Again, this is a degenerate case, but it proves the point: the most efficient traversal of the list will be if the list is stored in order on pages that contain nothing but list nodes.

    With a little bit of planning, you can improve this situation. The simplest method is to allocate nodes in chunks (n elements at a time, perhaps with a scheme for suballocations). When you do this, at least each chunk will be in as few pages as possible—and doing this can give you considerable savings in page faults and therefore execution time.

Certainly there are many other methods for speeding up your applications, but these are important—and sometimes subtle. Try a few of these and see if you can't notice a big difference—particularly on a memory-starved system (like the 16-megabyte (16-MB) systems running Microsoft Internet Explorer version 4.0 that all your users are using).

Dr. GUI offers his thanks to: Michael Fortin, Mario Goertzel, Gurdeep Singh Pall, Jerry Shea, and Richard B. Ward.


Going Native with J/Direct

DR. GUI Online
Part 1: November 17, 1997
Part 2: November 24, 1997
Part 3: December 1, 1997
Part 4: December 8, 1997

Dr. GUI
MSDN Online

Contents

Part 1: Dr. GUI Goes Native with J/Direct
Part 2: Going Native with J/Direct
Part 3: Still Native after All This Time
Part 4: The Conclusion, Finally, of the Column That Wouldn't Die

Part 1: Dr. GUI Goes Native with J/Direct

Java . . . Again?

As regular readers of Dr. GUI's columns know, Dr. GUI has had his ups and downs with Java. While, like all good programmers, Dr. GUI would love to be able to port code with no effort to other platforms, the good doctor has noticed many, many reports of cross-platform incompatibilities, bugs, and performance problems—sometimes quite severe performance problems.

So, as a cross-platform API, Java isn't all that the hype machine says it is. As Dr. GUI's Polish grandmother used to say, "Fooled me once, shame on you. Fooled me twice, shame on me." And Dr. GUI doesn't intend to be shamed by being fooled again.

A good language . . .

As a language, Java's pretty cool: it gives you the tools you need to do serious object-oriented programming without all of the complication of C++'s "object-oriented assembly language" approach. Around the time Java came out, the good doctor was involved in a project to produce an interactive tutor for C++. Dr. GUI was quite envious of Java at that time: it would have been far simpler to teach Java than C++.

Many programmers like Java as a language—with good reason. In addition to being simpler than C++, Java also has cool features such as garbage collection. Not having to worry about when to free memory is a big relief to most C++ programmers, so garbage collection makes them more efficient.

. . . especially for Win32 programming

So if you're programming for Win32, Java can still be a great choice—especially for programs where performance isn't critical. (Make sure before you commit: at least one company was so disappointed in Java performance that they rewrote their program in Visual Basic—and reaped a performance improvement of about two orders of magnitude.)

Beyond Java: Getting Native

You've heard it before: "Java language, good. Java API, lacking." But what if you want to use Java for real work? What if your Java program needs to get access to Windows functionality not supported by Java?

As you well know, any language needs to be able to use the native capabilities provided by the operating system. With Java, this need is especially acute since the built-in functionality is so incomplete. Even Java's creators anticipated this need and added the capability of writing native methods to Java.

But don't forget that as soon as you use native methods of any sort, you kiss whatever cross-platform pipe dreams you had goodbye. If you isolate your native calls into a small set of classes, you might be able to port most of your classes, but native anything is never a cross-platform solution. Native methods are, however, a great way to get the speed and functionality your customers demand.

Java virtual machines (VMs) provide some form or another of native method interface. These native method interfaces are one of the least consistent parts of Java. Just on Win32, there have been four methods so far of calling native methods more or less directly. Sun's and Microsoft's VMs have always differed in how their native method interface works.

The method supported by the Microsoft VM is called RNI, for Raw Native Interface. (Not to be confused with RMI—Remote Method Invocation.) A quick look at the documentation for this confirms that RNI is indeed "raw"—you have to worry about locking pointers, turning garbage collection on and off, and many other problems. dynamic-link libraries (DLLs) you call through RNI need to be specially written to work with RNI—you can't use RNI to call arbitrary DLLs, although you can write wrapper DLLs.

In exchange for this complexity, you get full access to all of the fields in every object. And you get speed—RNI is very fast. But RNI is more complex than most programmers need, so it's better reserved for systems-level programming tasks such as extending the capabilities of the VM. So leave it alone unless you need to do brain surgery.

Native code for the rest of us

Thankfully, there are methods of accessing native code that don't require brain surgery: Java/COM integration and J/Direct.

Microsoft's Java VM added the ability to treat COM objects as special Java classes. Java/COM integration allows any Java Bean to be an ActiveX control and any ActiveX control to be a JavaBean—all nearly automatically. COM integration is best for calling APIs that are wrapped in COM objects—or for ActiveX controls. (We'll discuss using COM objects in Java and using Java to write COM objects in a later column.)

About the only disadvantage to this method is that there's a translation layer between Java and COM, so the performance won't be as fast as if you were using C++ (and therefore had one less translation layer).

This integration is very powerful, but if you just want to call into a C DLL (such as the Windows API), you'd still have to write a wrapper COM object just to call your DLL.

Direct to you!

That's where J/Direct comes in. J/Direct allows you to call most any DLL "directly"—in other words, without having to write an RNI or COM wrapper DLL. The VM takes care of thorny issues such as mapping of data types for you. J/Direct is best for calling APIs (in Windows or your own DLLs) that are not wrapped in COM objects. This allows you to access almost the entire Windows API, for instance—and enables a new class of Java programs: Windows programs written in Java.

So how do I get direct?

All you do is declare a static native method preceded by a special directive in a comment, then call the method you've declared. The VM takes care of translating parameters and adjusting calling sequences—all you do is call. Note that, unlike other methods, there's no reason to write a wrapper DLL or a wrapper COM object—just call the functions you need directly. Take a look at the code below for an example of how to use MessageBox from Java. (Can you believe that Java still doesn't have an easy equivalent to MessageBox? The good doctor can't.)

class ShowMsgBox {
  public static void main(String
   args[])
  {
    MessageBox(0, "It worked!",
        "This message box from Java", 0);
  }

   /** @dll.import("USER32") */
   private static native int
   MessageBox(int hwndOwner, String
     text, String title, int fuStyle);
}

This class has a declaration of a function (MessageBox) and a definition of a function (main). The main function is the standard entry point for Java applications (not applets). It calls the Windows API MessageBox directly and easily.

The declaration of MessageBox itself couldn't be simpler. It's just a standard Java native method declaration—preceded by a special comment called a "directive" that tells the compiler what DLL it'll find the MessageBox entry point in. In this case, the @dll.import directive just says that MessageBox can be found in USER32.DLL.

Note that now any method in any class can call ShowMsgBox.MessageBox, as does the code in main above. In general, it really is that easy.

As you see, J/Direct is a great way for Java programs to access the full power of Windows—you can call almost any Windows API. (There are some restrictions when the data types manipulated by the API can't be translated to the Java world—but those restrictions are surprisingly few. Even pointers and callbacks are supported!)

Note that since code that uses J/Direct can do anything, it's considered untrusted—so applications can run it, but not applets. However, it is possible to wrap code that calls J/Direct in a Java wrapper object that you sign as safe in one or more categories.

More on @dll.import

The main directive you need to know is the @dll.import directive. It's this directive that provides a way to tell the Java VM the DLL to which it needs to link.

You can specify the DLL to use for static native methods in a whole class by putting the directive immediately above the class declaration. Or you can specify which DLL to use on a method-by-method basis, as shown in the MessageBox example above.

@dll.import also has parameters to allow you to link to ordinals, use an alias for the function name, and modify the calling convention. The good doctor will share more on these next week.

Making it easy to access the Windows API

You're probably looking at this and saying, "Nice—but I don't want to have to write these funky comment directives for each Windows function I want to use." Fortunately, you don't have to declare the entire Windows API yourself—Microsoft provides handy classes that contain these declarations. All you have to do is import the correct class(es).

All of these classes are available in the "com.ms.win32" package. So the MessageBox sample above could be simplified to:

import com.ms.win32.*;

class ShowMsgBox {
  public static void main(String
   args[])
  {
    MessageBox(0, "It worked!",
        "This message box from Java", 0);
  }
}

The available APIs are declared in a set of classes—one for each Windows DLL:

Import | DLL Name | Contains
Kernel32.class | KERNEL32.DLL | (base API)
Gdi32.class | GDI32.DLL | (graphics)
User32.class | USER32.DLL | (user interface)
Advapi32.class | ADVAPI32.DLL | (crypto API, event logging)
Shell32.class | SHELL32.DLL | (interface to the Windows Explorer)
Winmm.class | WINMM.DLL | (multimedia)
Spoolss.class | SPOOLSS.DLL | (spooling)

For instance, MessageBox is contained in USER32.DLL and therefore declared in User32.class; just import this class (or the whole package) and you can call MessageBox directly.

Constants used in Windows are available in the "win" class. To access these, just import com.ms.win32.win and use win.CONSTANT_NAME, as shown below. Don't try to take a shortcut by extending or implementing com.ms.win32.win in your class; doing so will require that the entire class be loaded each time you load your class. (Talk about slow!) Write out "win.xxx" instead.

System.out.println("MAX_PATH = " + win.MAX_PATH);

Finally, the supported Windows structures are declared in a set of class files that have the structure name as the class name, such as RECT.class. Just import these and you can use the Windows structures as though they were Java classes.

Again, you get all of these classes when you import com.ms.win32.*. And note that the classes are an optional part of the Software Development Kit (SDK) for Java 2.0 install, so if you don't have them, just install again. (Since the classes contain only declarations, your users won't need to have them installed on their machines—but you'll need them in order to be able to compile.)

Try It Out!

Now you've got the basic knowledge you need to start playing with J/Direct. To get started, you'll need the <a href: "/java"> SDK for Java 2.0</A>. And having Internet Explorer 4.0 wouldn't hurt.

You won't be able to do everything just yet: we've not discussed how structures and callbacks work, so don't try to implement Petzold's GENERIC.C in Java—not just yet. There are a lot of APIs you can use to get experience in the meantime—or you can hop up to the Microsoft technologies for Java Web site (http://microsoft.com/java/sdk/20/jdirect/jdirect.htm) to read ahead. We'll talk about the remainder of the J/Direct topics in Part 2.

Part 2: Going Native with J/Direct

In Part 1, the good doctor shared some of the basics of using J/Direct to call into DLLs directly (including the DLLs that implement Windows). We broke off that conversation just before getting into some of the tricky and sticky parts of J/Direct.

The key issue is this: Java and Windows (primarily written in C and C++) don't deal with the world in exactly the same manner. The data types are sometimes different, the ways that memory is manipulated are different, and Windows has some concepts such as callbacks (requiring a pointer to a function) that Java just doesn't have. Also functions that are part of OLE have their own special rules.

As a result of these differences, J/Direct isn't really direct—it just looks direct. The VM has to do some level of translation (or marshalling) on just about every call. So while J/Direct will be far better than other methods for calling DLLs such as the Windows DLLs, it's still not going to be as fast as C++ because there's still a translation layer being used for each call and return; but we've already established that if you're using Java, performance isn't the most important issue for your application, anyway.

This time, Dr. GUI's going to discuss the issues of data marshalling. Next time, we'll discuss some of the odds 'n' ends, including callbacks and using dynamically loaded DLLs.

Translating Data with Data Marshalling

Although they're often close, the data types in Java don't map exactly to C/C++. Built-in data types map in a pretty natural manner, but there are some differences depending on whether the data element is a parameter to a function or a field embedded in a structure.

Strings, structures, and pointers all require special handling, as do callbacks and parameters that are polymorphic, or interpreted as different types in different situations.

Here is a table of the data mappings for parameters and return values:

Java | C/C++, Native | Notes/Restrictions
byte | BYTE or CHAR |
short | SHORT or WORD |
int | INT, UINT, LONG, ULONG, or DWORD |
char | TCHAR |
long | _int64 | Watch out for this one: long in C/C++ is only 32 bits, not 64 as in Java!
float | float |
double | double |
boolean | BOOL |
String | LPCTSTR | Not allowed as return value, except in OLE mode. In OLE mode, String maps to LPWSTR. The Microsoft VM frees the string by using CoTaskMemFree.
StringBuffer | LPTSTR | Not allowed as return value. Set the StringBuffer capacity large enough to hold the largest string that the DLL function can generate.
byte[] | BYTE* or CHAR* |
short[] | SHORT* or WORD* |
char[] | TCHAR* |
int[] | INT*, UINT*, LONG*, ULONG*, or DWORD* |
float[] | float* |
double[] | double* |
long[] | __int64* |
boolean[] | BOOL* |
Object | pointer to structure | In OLE mode, an IUnknown* is passed instead.
Interface | COM interface | Use JActivex or similar tool to generate interface file.
com.ms.com.SafeArray | SAFEARRAY* | Not allowed as return value
com.ms.com._Guid | GUID,IID,CLSID |
com.ms.com.Variant | VARIANT* |
@dll.struct classes | pointer to struct |
@com.struct classes | pointer to struct |
void | VOID | As return value only
com.ms.dll.Callback | function pointer | As parameter only

Most of the data type mappings are what you'd expect—byte to char, int to int, long to _int64, boolean to BOOL, and so on. But a few are surprising and some are different depending on whether the data is a parameter or a member of a structure (declared with @dll.struct—we'll discuss this in a bit).

There are no unsigned data types (except char) in Java, so be careful when operating on unsigned values. And don't forget that long is 64 bits in Java, not 32 as in C/C++.

When passed as parameters, arrays map to pointers to the element type. For instance, byte [] in Java maps to char* in C/C++. There are restrictions on return values, especially Strings and StringBuffers.

The Trouble with Structures

At first glance, you'd think that mapping structures from Java to C/C++ and back would be easy. After all, isn't a structure basically a class without member functions?

As it turns out, structures cause some special problems because they're stored very differently in C/C++ and in Java. In C/C++, a structure is stored in a contiguous block of memory, usually with some padding bytes between members to prevent unaligned accesses. (For instance, all members that are two bytes or longer would start at an even address, all members that are four bytes or longer would start at an address evenly divisible by four, and so on.)

In Java, the fields in a class are stored in some implementation-dependent fashion, but the fields are addressed (at least at first reference) by name, not by offset. This is required so that you can use updated versions of your class with old code, even if you add fields and methods.

In addition, the Java VM moves objects when it does garbage collection. This can cause a real problem if you pass the object by reference to a function in a DLL, so we have to insure that our special structures won't move.

The J/Direct solution to this problem is simple: you declare a class with a special "funky comment" @dll.struct directive and the VM creates an appropriate contiguous structure to hold the data memory (you can specify how to pack/pad the structure) and guarantees that the data won't move. For example:

/** @dll.struct() */
class SYSTEMTIME {
  public short wYear;
  public short wMonth;
  public short wDayOfWeek;
  public short wDay;
  public short wHour;
  public short wMinute;
  public short wSecond;
  public short wMilliseconds;
}

The following example uses the SYSTEMTIME structure in a DLL method call.

class ShowStruct {
    /** @dll.import("KERNEL32") */
    static native void GetSystemTime(SYSTEMTIME pst);
    public static void main(String args[])
    {
      SYSTEMTIME systemtime = new SYSTEMTIME();
      GetSystemTime(systemtime);
      System.out.println("Year is " + systemtime.wYear);
      System.out.println("Month is " + systemtime.wMonth);
      // etc.
    }
}

As we've seen before, the VM takes care of all of the sticky details.

Arrays, strings, and other objects (such as structures) in structures pose special problems. In Java, all objects (including arrays and strings) are allocated on the heap, so when you have a member of a structure that's an object, it really is just a reference to that object. So if you declared an array of five ints in a class in Java, your objects would contain a reference to the array of five ints on the heap, not the actual array of five ints.

In C/C++, if you declare an array of five ints in a structure, you get the five ints right there. If you want a pointer, you declare a pointer. Java doesn't have this flexibility. But when you pass a structure from Java to a C/C++ DLL, it needs to conform to the way that C/C++ does things.

First, if you want to embed a structure inside a structure, then both must use the @dll.struct directive. But you may want to embed the fields of the embedded structure directly to save the VM time in marshalling from a structure reference to an embedded structure.

For embedded arrays and strings, we need yet one more directive: @dll.structmap. This directive specifies the size and type of the array that maps to the Java reference. For example the Windows LOGFONT structure is defined as follows in C/C++:

   typedef struct {
     LONG lfHeight;
     LONG lfWidth;
     /* <many other fields deleted for brevity> */
     TCHAR lfFaceName[32];
   } LOGFONT;

This structure can be expressed in Java using a directive to specify the size.

   /** @dll.struct() */
   class LOGFONT {
     int lfHeight;
     int lfWidth;
     /* <many other fields deleted for brevity> */
     /** @dll.structmap([type=TCHAR[32]]) */
     String   lfFaceName;
   }

The @dll.structmap directive indicates the size of the fixed string as measured in characters (including space for the null terminator).

For embedded arrays, the directive is the same, but the syntax is a little different. To map from the C/C++ structure below:

struct EmbeddedArrays
{
  BYTE     b[4];
  __int64  l[4];
  doubl    d[4];
};

you would write:

/** @dll.struct() */
class EmbeddedArrays
{
    /** @dll.structmap([type=FIXEDARRAY, size=4]) */
    byte b[];
    /** @dll.structmap([type=FIXEDARRAY, size=4]) */
    long l[];
    /** @dll.structmap([type=FIXEDARRAY, size=4]) */
    double d[];
}

By the way, you specify the packing of structures using the "pack" modifier of the @dll.struct directive, as in /** @dll.struct(pack=4) */. The value can be 1, 2, 4, or 8; the default is 8. The effect of this modifier is the same as #pragma pack(4) in C/C++.

Strings

In general, you can just pass strings to DLL functions and the VM will do the necessary conversions automatically. For example:

class ShowCopyFile{
   public static void main(String args[]) {
      CopyFile("old.txt", "new.txt", true); }
   /** @dll.import("KERNEL32") */
   private native static boolean CopyFile(String existingFile,
      String newFile, boolean f);
}

Strings are read-only in Java, so the Microsoft VM will only convert the String object for input to the DLL function only. If the DLL function might modify the string, pass a StringBuffer object instead. Make sure that the capacity of the StringBuffer is large enough (s = new StringBuffer(capacity);). For example:

class ShowGetTempPath{
   static final int MAX_PATH = 260;
   public static void main(String args[]) {
      StringBuffer temppath = new StringBuffer(MAX_PATH);
      GetTempPath(temppath.capacity()+1, temppath);
      System.out.println("Temppath = " + temppath);
   }
   /** @dll.import("KERNEL32") */
   private static native int GetTempPath(int sizeofbuffer,
      StringBuffer buffer);
}

Do not use the default StringBuffer constructor; it will allocate space for only 16 characters. You may want to write a wrapper function to insure that a proper StringBuffer is always passed. For instance, you could write a new function:

public static String GetTempPath()
{
  StringBuffer temppath = new StringBuffer(MAX_PATH-1);
  int res = GetTempPath(MAX_PATH, temppath);
  if (res == 0 || res > MAX_PATH) {
    throw new RuntimeException("GetTempPath error!");
  }
  return temppath.toString(); // can't return a StringBuffer
}

This method offers both convenience and safety and it maps the error return value of the function to a Java exception. Notice that you cannot return StringBuffer objects.

Strings are converted to ANSI unless the "Unicode" or "OLE" modifier is used in the @dll.import directive, in which case the string is passed in Unicode format. For example, if our code was running on NT, we could avoid the Unicode-to-ANSI and ANSI-to-Unicode conversions by using:

/** @dll.import("KERNEL32.DLL, unicode) */

instead of the code above. Or, better yet, use:

/** @dll.import("KERNEL32.DLL, auto) */

The VM will pick the faster method depending on whether it's running under Win95 or NT. (Dr. GUI recommends using "auto" always when calling Windows API functions.)

J/Direct automatically takes care of calling the appropriate "...A" or "...W" variant of the functions (MessageBoxA vs. MessageBoxW, for instance) based on the conversion it decides to use. It first tries to use the function name without appending an "A" or "W"; if that fails, it appends the appropriate character and tries again.

Strings cannot be declared as return type of a DLL function except in "OLE" mode, where the native return type is assumed to be a LPWSTR allocated using the CoTaskMemAlloc function.

What's Next?

"My," sighs the good doctor, "this has stretched on a bit, hasn't it?" But we're still not quite done: we need to look at the fascinating issues of how J/Direct deals with pointers, callbacks, dynamically loaded DLLs, polymorphic parameters, calling OLE functions, and getting information on errors.

Even if you never program in Java or never use J/Direct, Dr. GUI hopes you're finding this series helpful in deepening your understanding of C/C++ and the Windows API—just as learning Latin deepens your understanding of how your native language works.

Part 3: Still Native after All This Time

Dr. GUI welcomes you back to the penultimate segment of our journey through one of the Seven Wonders of the Microsoft Virtual Machine for Java, J/Direct.

First, we discussed the basics of J/Direct. Then we talked about how J/Direct marshals garden-variety data, including structures and strings. Now Dr. GUI will operate on harder topics: pointers, polymorphic parameters, and callbacks. Next, we'll wrap it all up with dynamically loaded DLLs, calling OLE functions, getting information on errors, and a comparison between J/Direct and RNI.

Pointers

As any beginning Java programmer can tell you, Java does not support a pointer data type. So with pointers so common in Windows, Dr. GUI muses, how in the world are we going to do direct calls to Windows?

Well, the answer varies depending on exactly what we're doing. If we just need a pointer to a single data object, we can pass a one-element array of the correct type. For other uses, we can store pointers in Java integers and, if needed, use those integers (which really are pointers) to access the data they need by using various methods of DllLib such as ptrToStruct and ptrToString.

Simple pointers

So let's say you're calling a function that requires you to pass a pointer to an int in which the function will store a value. In Java, there's only one way to pass by reference: pass an array. So, to pass a pointer to a single object, just pass a one-element array instead—in this case, an array of int.

For instance, the DLL function:

void foo(int * piStatus); // C/C++ function, piStatus -> one int

would correspond with the following Java function:

/* Java with J/Direct */
/** @dll.import("foo") */
static native void foo(int [] piStatus);

and you would call it as:

/* Java with J/Direct */
int piStatus[1];
piStatus[0] = inValue;
foo(piStatus);
   int outValue = piStatus[0];

Pointers from the land of C/C++: Pointers as dumb handles

So now we know how to use pointers as additional return values. But what about when a DLL, such as a Windows DLL, passes us a pointer? What will we do with it?

When you're passed a pointer from a DLL, you have a couple of choices. First, if you don't need to manipulate it or dereference it, just store it in an int. You can then pass this int back to the DLL when needed. It's almost as if you're treating it as a handle or a cookie, rather than a pointer. For instance, the DLL functions:

/* C/C++ functions */
foo * RetPtr();
void TakePtr(foo *inPtr);

correspond to the Java functions:

/* Java with J/Direct */
/** @dll.import("foo") */
static native int RetPtr();
/** @dll.import("foo") */
static native void TakePtr(int inPtr);

and would be called as:

/* Java with J/Direct */
int thePtr = RetPtr();
TakePtr(thePtr);

In essence, you're treating the pointer as a handle or a cookie—you're not using its value at all but just passing it back to the DLL. Because Java data moves in memory when garbage collection is done, please note that attempting to get and use the address of a regular Java data structure is, according to the Surgeon General, dangerous to your program's health.

Pointers to data

But what if the pointer points to data you need to access?

If the pointer points to a structure, you can create a reference to the structure from the pointer, then use the reference as you normally would. Note that the structure must be declared with @dll.struct.

/* Java code with J/Direct */
/* RECT declaration from com.ms.win32.RECT.class */
/* import com.ms.win32.*; */
RECT rect = (RECT)DllLib.ptrToStruct(RECT.class, rawPtr);
rect.left = 0;

There are other DllLib methods you can use to convert a pointer to characters to a Java String object: ptrToString, ptrToStringAnsi, and ptrToStringUni.

There's also an overloaded DllLib.copy method you can use to copy memory pointed to by a raw pointer into a Java array of various types.

Finally, for the really hard-core hackers and systems programmers out there, you can allocate and free global and task memory, get the address of a data structure, and even read and write bytes at a specific memory address with various DllLib methods. (Aren't you glad you can only run J/Direct code with security permissions?)

Polymorphic Parameters

The good doctor hears you now: "Polymorphic parameters? Huh? Since when does Windows do inheritance?"

Well, this is a little different. You might have noticed that in some cases a parameter to Windows might be interpreted as a different type depending on the value of some other parameter passed. For instance, the final DWORD parameter to the WinHelp API can be interpreted as a pointer to a string, a pointer to a MULTIKEYHELP structure, a pointer to a HELPWININFO, or a plain integer, depending on the value of the next-to-last parameter.

So what do you do? Pass a pointer as an int?

As it turns out, it's much simpler than that: to call such a function, just provide a separate overload of the function for each possible type of parameter. When you call the function, Java will pick the correct overload based on the type of the parameter you pass and J/Direct will convert the parameter correctly. It really couldn't be easier.

If the return type is polymorphic, you'll need a separately named method for each overload (since neither Java nor C++ allows defining overloads based on return value). You can make all of these differently named methods map to the same DLL function by using the entrypoint modifier on your @dll.import directive (shown later).

Aliases

You may want to name the method in Java with a different name than is in the DLL. To do this, just add an entrypoint modifier to the @dll.import directive, specifying the name of the DLL function after the equal sign of the modifier. For instance:

/** @dll.import("USER32", entrypoint="GetSysColor") */
static native int getSysColor(int nIndex); // note "g", not "G"

Use this feature to deal with polymorphic return types. For example:

/** @dll.import("foo", entrypoint="Func") */
static native int intFunc();
/** @dll.import("foo", entrypoint="Func") */
static native long longFunc();
// Java name different, DLL name same

To link by ordinal, make the name of the entrypoint #<num> where <num> is the number of the ordinal—for instance, #24. For example:

/** @dll.import("foo", entrypoint="#24") */
static native int meanOldNum24(); // Linked by ordinal

Callbacks

You can't get very far in Windows programming without needing a callback function. In fact, you can't even create a window class, since one of the members of the WNDCLASS structure is a pointer to a callback function (your window procedure, or WndProc!). There are also other places where callbacks are necessary, from dialog boxes to window enumeration. Without a way to handle callbacks, J/Direct wouldn't be very useful: how could you use it if you couldn't even translate Petzold's GENERIC.C into Java?

So how do you make callbacks work in a language that doesn't have pointers at all, let alone method pointers? Well, it takes a little trickery.

First, you have to put your callback function (method) in its own class. This class must be derived from com.ms.dll.Callback. You then override a function called "callback" that returns void or int and takes any number of int parameters. You can use various DllLib methods to convert parameters if necessary. Note that since you'll create a new callback object for each callback, you can store data related to that callback in the object rather than passing it as the extra parameter that many callbacks take.

For instance, you could set up a call to EnumWindows as follows:

class EnumWindowsProc extends Callback {
    public boolean callback(int hwnd, int lparam) {
      StringBuffer text = new StringBuffer(50);
      GetWindowText(hwnd, text, text.capacity()+1);

      if (text.length() != 0) {
        System.out.println("hwnd = " +
                           Integer.toHexString(hwnd) +
                           "h: Text = " + text);
      }
      return true;  // return TRUE to continue enumeration.
    }

  /** @dll.import("USER32") */
  private static native int GetWindowText(int hwnd,
                                   StringBuffer text, int cch);
}

You can invoke EnumWindows with this callback in the following way:

  boolean result = EnumWindows(new EnumWindowsProc(), 0);

You must prevent garbage collection of the callback object until the function you call is done with it. If your callback is used by only one function, such as EnumWindows, you can just use the callback object directly, since garbage collection is turned off while you're in J/Direct functions.

But if the callback will be used after the function you pass it to returns (for example, timer callbacks) or you want to store the callback object in a native data structure (such as storing a WndProc callback in a WNDCLASS), you need to make sure that the callback object doesn't get garbage-collected. To do this, wrap the callback object in a root handle (com.ms.dll.Root) object.

In the case where you just want to store the callback across function calls, this can be quite simple:

EnumWindowsProc MyCallback = new EnumWindowsProc;
int rootHandle = Root.alloc(MyCallback);
// Use the Callback across function calls until you're done.
Root.free(rootHandle);

To store the address of the callback in a native structure, wrap the callback object in a root handle and use the DllLib.addrOf to get the address of the root object—then store that address in the structure. For instance, to set up the window procedure in a window class, you would write the WNDPROC class, overriding the callback method:

class WNDPROC extends Callback {
   public int callback(int hwnd, int msg, int wparam, int lparam)
   { ... }
}

and then write:

WNDCLASS wc = new WNDCLASS(); // com.ms.win32.WNDCLASS.class
int callbackroot = Root.alloc(new WNDPROC()); // your callback
wc.lpfnWndProc = DllLib.addrOf(callbackroot);

So Now What?

Well, now you've got a few more scalpels and forceps in your J/Direct doctor's bag—but in order to be able to fully operate, you need a few more tools. So in Part 4, we'll finish up this series by covering dynamically loaded DLLs, calling OLE functions, getting information on errors, and a comparison between J/Direct and RNI.

Part 4: The Conclusion, Finally, of the Column That Wouldn't Die

If you'd told the good doctor a couple of months ago that he'd end up spending four columns on J/Direct, he would have responded with utter disbelief. Perhaps Dr. GUI would have had you committed. (He can do that, you know. But only when he's really grumpy.)

But everything takes longer than expected, it seems. And the feedback you've been sending to the good doctor has been very good—many of you have found these columns useful and interesting. So, we'll continue on—at least for one more column. (Actually, we're done as of Part 4.)

In Part 1, we dissected the basics of J/Direct. In Part 2, we sliced into how J/Direct marshals garden variety data, including structures and strings. In Part 3, Dr. GUI operated on harder topics: pointers, polymorphic parameters, and callbacks. In Part 4, we'll suture it all up by dealing with calling OLE functions, dynamically loaded DLLs, getting information on errors, and a comparison between J/Direct and RNI.

So, without further ado (or doodoo), let's start!

OLE APIs

The world of OLE APIs brings a whole new set of conventions to function calls.

Because it's important to get error status information, especially in a remote server setting, OLE functions (in OLE32.DLL and OLEAUT32.DLL) almost always return an HRESULT that indicates whether the function succeeded or not. Since the single return value is used for error status, the "real" return value is passed by reference as the last parameter, by convention. This will cause us problems in Java because passing by reference is difficult (you have to use a one-element array).

In addition, all OLE strings use Unicode character encoding. Finally, OLE functions return strings by allocating the string using CoTaskMemAlloc; they expect the caller to free the string using CoTaskMemFree. J/Direct has to deal with all these things in order to make calling OLE APIs as easy as possible.

To illustrate the contrast, the code for a simple Add function would look like this in the Win32 style of coding:

  int sum;
  sum = Add(10, 20);

In OLE style, the Add function would be written in the following way:

  HRESULT hr;
  int sum;
  hr = Add(10, 20, &sum);
  if (FAILED(hr)) {
    ...handle error..
  }

When you use the "OLE" modifier on the @dll.import directive, J/Direct takes care of all these differences in a way that's natural for Java. The return of the Java function is the actual return value. J/Direct takes care of checking the HRESULT for you. If the HRESULT indicates an error, J/Direct throws a ComFailException. So instead of checking the HRESULT, you handle an exception to deal with errors.

So in Java, using J/Direct, our OLE example above would be declared as follows:

/** dll.import("OLELIKEMATHDLL", ole) */
private native static int Add(int x, int y);
// Equivalent to HRESULT Add(int x, int y, int * sum); in OLE

and called like this:

int sum = Add(10, 20);
// if we got here, Add succeeded—otherwise exception

Note, however, if the HRESULT is some nonfailure value other than S_OK (such as S_FALSE), J/Direct does not throw a ComSuccessException—this is different from how Java/COM integration works. If you need to check different success codes, such as S_FALSE, you'll have to call the OLE function as a regular DLL function (without the "OLE" modifier).

J/Direct also takes care of the differences in the way strings are handled. Strings are passed to and from OLE functions as LPCOLESTRs. When you return a string from an OLE function to Java, the VM passes a pointer to an uninitialized LPCOLESTR. The VM takes care of freeing the return value string after it converts it to a Java string.

GUIDs and VARIANTs are passed using the com.ms.com._Guid and com.ms.com.Variant classes. (Note the underscore on _Guid.) The style of passing is similar to strings except that no memory allocation occurs.

For example, OLE32 exports the functions CLSIDFromProgID and ProgIDFromCLSID to map between CLSIDs and the human-readable names used by the Visual Basic function CreateObject. These functions have these prototypes:

HRESULT CLSIDFromProgID(LPCOLESTR szProgID, LPCLSID pclsid);
HRESULT ProgIDFromCLSID(REFCLSID clsid, LPOLESTR *lpszProgId);

In Java, you would declare these methods in the following way:

  import com.ms.com._Guid;
  class OLE {
    /** @dll.import("OLE32", ole) */
    public static native _Guid CLSIDFromProgID(String szProgID);

    /** @dll.import("OLE32", ole) */
    public static native String ProgIDFromCLSID(_Guid clsid);
  }

To pass a COM interface pointer, you must generate a Java/COM interface class using a tool such as jactivex.exe. You can then pass or receive COM interfaces by declaring a parameter to be of that interface type.

For example, the system class com.ms.com.IStream is a Java/COM interface that represents the Structured Storage IStream* interface. The OLE32 function CreateStreamOnHGlobal could be declared as follows:

import com.ms.com.*;
/** @dll.import("OLE32", ole) */
public static native IStream CreateStreamOnHGlobal(int hGlobal,
                                     boolean fDeleteOnRelease);

Run-Time Loading and Linking

Windows includes the ability to specify that DLLs load at run time, rather than at load time. In other words, you can ask Windows to load any arbitrary DLL by name. This is handy because you sometimes can't specify the exact DLL at compile time—you may need to calculate the name of the DLL at run time, for instance. Perhaps the DLL is different for Windows 95 and Windows NT. Or perhaps you have different DLLs for a family of similar devices.

Windows supports this with LoadLibrary and GetProcAddress. You use these functions via J/Direct to load the DLL and find the function you want to call.

Calling the function, however, is a problem: Java does not support method references. Instead, we'll use an int to hold the function pointer and then we'll call the function by using the call method exported by msjava.dll. It takes an int that contains the address of the function as the first parameter, and passes any number of parameters after that to the function it calls.

For example, to call a function prototyped in C as:

BOOL AFunction(LPCSTR argument);

you'd write (after declaring the Win32 API functions):

/** @dll.import("msjava") */
static native boolean call(int funcptr, String argument);

int hmod = LoadLibrary("...");
int funcaddr = GetProcAddress(hmod, "AFunction");
boolean result = call(funcaddr, "Hello");
FreeLibrary(hmod);

It almost couldn't be easier.

Finding out about Errors

Normally in Windows, you find out about errors by using the Windows API GetLastError to obtain an error code set by the previous API call. Because the Microsoft Win32 VM for Java may execute function calls of its own in the process of executing Java code, the error code may have been overwritten by the time you get to it. Because of this, J/Direct code should not call GetLastError directly.

To reliably access the error code set by a DLL function, you must do two things. First, use the SetLastError modifier to instruct the Microsoft VM to capture the error code immediately after invoking that method. (For performance reasons, this is not done by default.) Second, call the com.ms.dll.DllLib.getLastWin32Error method to retrieve the error code. Each Java thread maintains separate storage for this value.

For example, the FindNextFile function returns status information through the error code. FindNextFile would be declared as follows:

/** @dll.import("KERNEL32",SetLastError) */
static native boolean FindNextFile(int hFindFile,
    WIN32_FIND_DATA wfd);

A typical call would look like this:

import com.ms.dll.DllLib;
boolean f = FindNextFile(hFindFile, wfd);
if (!f) {
  int errorcode = DllLib.getLastWin32Error();
}

J/Direct vs. RNI

J/Direct and Raw Native Interface (RNI) are complementary technologies you can use to call native code. (The third method is calling COM objects using Java/COM integration.)

Using RNI requires that DLL functions adhere to a strict naming convention and it requires that the DLL functions work harmoniously with the Java garbage collector. RNI functions must be sure to call GCEnable and GCDisable around code that is time-consuming, code that could yield, code that could block on another thread, and code that blocks while waiting for user input. RNI functions must be specially designed to operate in the Java environment. In return, RNI functions benefit from fast access to Java object internals and the Java class loader. A good use for RNI would be extensions to the Java VM and API.

J/Direct links Java with existing code such as the Win32 API functions and/or DLLs that were written to be called from C/C++ or Visual Basic. These DLLs were not designed to deal with the Java garbage collector and the other subtleties of the Java runtime environment. So J/Direct automatically calls GCEnable on your behalf so that you can call functions that block or perform UI without having a detrimental effect on the garbage collector. In addition, J/Direct automatically translates common data types such as strings and structures to the forms that C functions normally expect. As a result, you don't need to write glue code and wrapper DLLs.

The tradeoff is that DLL functions called via J/Direct cannot access fields and methods of arbitrary Java objects. In this release, they can only access fields and methods of objects that are declared using the @dll.struct directive. Another limitation of J/Direct is that RNI functions cannot be invoked from DLL functions that have been called using J/Direct. The reason for this restriction is that garbage collection can run concurrently with your DLL functions. Therefore, any object handles returned by RNI functions or manipulated by DLL functions are inherently unstable.

So if you need more power than you can get by sticking with "100% Pure" Java, you can use RNI, J/Direct, Java/COM integration, or any combination thereof. The compiler and the Microsoft Win32 VM for Java allow you to mix and match J/Direct and RNI, even within the same class, as your needs dictate. And it's easy to generate Java classes that wrap most any COM class or ActiveX control using the jactivex tool.

Phew! That's Done!

Thanks for reading this far! Dr. GUI hopes you've found this as fun and instructive to read as it was to write. And the good doctor needs to thank the authors of the "About J/Direct" article in the SDK for Java 2.0. (See the Microsoft Technologies for Java Web site at [http://www.microsoft.com/java/]) for inspiration (and some leveraged code and text).


Should Your Next UI Be Written in Dynamic HTML?

Dr. GUI

November 3, 1997

Dynamic HTML: Not Just for the Web Anymore . . .

Many of you, Dr. GUI is sure, have noticed that Microsoft has released Internet Explorer 4.0.

Many of you, Dr. GUI hopes, have downloaded it and are using it every day. The good doctor installed it, and he sure ain't goin' back: it makes his Web browsing experience much easier and faster.

You may have even found some cool pages that take advantage of the best that Internet Explorer 4.0 has to offer. You'll be seeing more and more of those: the new features are so compelling that you almost can't not use 'em. Sure, you'll still have to offer a version of your pages for down-level browsers, but the new features are so cool that it will, for the first time, be worth it. These features are far cooler than frames, and look at the number of sites that offer frames and non-frames versions.

Here's an example: check out the Dynamic HTML virtual jack-o-lantern at http://www.microsoft.com/ie/ie40/demos/pumpkin/pumpkin.htm. Then check out the rest of the demos there, including Asteroids at http://www.microsoft.com/ie/ie40/demos/asteroids.htm. Go ahead and play a game or two! And be sure to take a look at the source code—just select View Source from the Context (right-click) menu.

So, you're saying, "Uh, Doc—I'm not a Web developer. I don't run a Web site. I can barely spell HTML. What's all this coolness got to do with me?" Or maybe you're thinking, "Actually, I'm kinda jealous that I can't take advantage of all this coolness and ease-of-writing in <insert the name of your favorite programming language here>."

Jealousy begone . . .

Be ye jealous no more: you can take advantage of Dynamic HTML in your Visual C++, Visual Basic, and Java applications. All you have to do is embed Internet Explorer 4.0 into your application as an ActiveX control, load up the control, and you're in business.

"So what?" you say. "I've been able to embed a web browser since Internet Explorer 3.0. And I've done it, when I wanted to embed Web browsing in my application. So what's so special about Dynamic HTML?"

Not your grandmother's HTML

Dynamic HTML is not your grandmother's HTML. Now it's certainly true that, up until now, HTML hasn't given you a lot to be jealous over. Why, you couldn't even position images, text, and objects accurately! In terms of making a UI really good, the dialog editor makes old HTML look bad. (That is, unless you got a Ph.D. in HTML tables—then you might be able to do what you want. So it was pretty well unthinkable to do your UI in HTML: who'd want their app to look as bad as a Web page?

Dynamic HTML is different. First, it supports to-the-pixel positioning and even layering of every element on the page. (Even better than the dialog box editor!) And it supports transparency. In short, if you can do it in Publisher or another desktop publishing program, you can do it in Dynamic HTML.

So even if all you were doing was a static layout of a dialog box, you'd benefit from using Dynamic HTML.

But wait! There's more! Download before midnight tonight, and Dynamic HTML will include even more: it will make julienne fries! It'll slice through a tin can, then cut a slightly over-ripe tomato into paper-thin slices.

Okay, you've guessed it: the good doctor is joking. Dr. GUI's just trying to boost Internet Explorer sales so he can get paid more. (Remember that the good doctor gets a cut of Internet Explorer profits. But he's starting to be concerned that he's not seen even the first check.)

It's dynamic! (Duh!)

Anyway, here's what's special about Dynamic HTML: it's dynamic. "Duh!," you say? Well, let the good doctor explain: you can change the style and/or content of any element of a Dynamic HTML page at any time with script. You can add 'em. You can remove 'em. You can hide 'em. You can change 'em. (Even the text on the page!) You can move 'em. You can change the font, change the color, apply filters and transition transitions (shades of PowerPoint!), rotate 'em, layer 'em, and even make virtual julienne fries out of 'em. (Your cholesterol count may vary.) And, of course, you can embed images, Java applets, ActiveX controls, and scriptlets (a new technology for making software components out of Dynamic HTML—see Bob Jervis's article, "Dynamic HTML Scriptlets: Reusable Objects for Web Authors,".

Want a demo of using Dynamic HTML from inside an application? Fire up Internet Explorer 4.0 (if you're not using it to read this) and select About from the Help Menu.

C'mon, do it!

When was the last time you saw an About dialog box like that? This wasn't hard to do—the programming was much simpler than if you'd tried to do this. Be sure to click on the Copyright Information link and play with it some.

A new way of conceptualizing HTML pages

So you've probably already figured out (or at least guessed) that what's dynamic about Dynamic HTML is that you can change anything at any time. But that's not nearly as important as the fact that Dynamic HTML represents a new way of conceptualizing HTML pages. Please let the good doctor explain.

In old HTML, HTML page authors and even the browser conceptualized the HTML page as a stream of text that described text, images, and objects. It also described, in a very limited fashion, how those elements were to be laid out on the page. The page was a very sequential kind of thing. And, as we've mentioned before, once it was loaded into the browser it couldn't change much (aside from animated GIFs).

Dynamic HTML reads the same sort of HTML code as old HTML did. So all of your old HTML pages still work. And, in fact, Dynamic HTML adds no new tags to previous versions of HTML.

So what's different? Well, Dynamic HTML makes major additions to the old HTML object model. In fact, it now makes sense to think of a Dynamic HTML page as a collection of objects and collections, since that's exactly what it is when it's in the browser. In other words, the browser parses the still-linear Dynamic HTML text stream and creates an in-memory representation of a set of collections of objects.

Old HTML also had some collections. What's new is that everything is now a part of the object model, and everything can have its style and/or content modified. The relationships between the objects are described by the document object model (or DOM). See it at http://www.microsoft.com/msdn/sdk/inetsdk/help/default.htm.

So although a Dynamic HTML page is still a stream of text, once it's inside the browser it's really a collection of objects! So if you've ever programmed for any object model, you'll have a leg up on the Dynamic HTML object model.

So I've got objects: Now what?

Now that you've got access to all the objects, you can manipulate them (as described above) using script in your Dynamic HTML page.

But if I'm an application using the browser control, what do I do? Here's the good news: the document object model is exposed to the container of the browser. That means that you can do anything from your container application that you can from script! In addition, your container can extend the document object model. I don't want to go into the details here, but there are excellent papers and samples in the Internet Client SDK. Be especially sure to check out "Programming the Document Object Model from C/C++" and "Reusing the WebBrowser and MSHTML." You can get to both of these from the Internet Tools and Technologies section at http://www.microsoft.com/msdn/sdk/inetsdk/help/itt/internet.htm#set_internet_tools. Note that there's even a way to easily do HTML dialog boxes.

Other advantages

There are two other key advantages to using Dynamic HTML for user interfaces.

First, Dynamic HTML makes a great UI prototyping language—perhaps more powerful and easy-to-use than Visual Basic, for instance. And if you prototype and implement in Dynamic HTML, that means that you can use your prototyping code without rewriting. Dr. GUI calls it "write once, use everywhere."

Second, you may already have UI designers, Web page designers, or Web development engineers who already know HTML or maybe even Dynamic HTML. If so, they can perhaps be added to your development team, specializing in the UI of your product.

Note that Dynamic HTML is even more powerful when you use it with data binding—binding HTML elements to fields in a database. For an excellent demo, check out the Dynamic HTML Reference at http://rapid.wrox.co.uk/books/0707/WroxRefDB/wroxdhtm.htm.

So how do I get started?

If you'd like your applications to look and work better with less effort, here's what Dr. GUI prescribes:

  • First, if you've been putting off learning HTML and a scripting language, now's the time to learn. The good doctor can certainly understand why you put it off: with as little functionality as old HTML gave you, why learn something that looks something like assembly language? But Dynamic HTML gives you so much power that it's well worthwhile (and not all that hard, truth be told) to learn Dynamic HTML.

    In addition to the information in the Internet Client SDK, there are good books from WROX and Microsoft Press. Also, check out the really cool demos at http://rapid.wrox.co.uk/books/0685. Be sure to try out the Tetris-like game and the Jigsaw puzzle—all in HTML.

  • Learn the document object model. It's far easier to use scripting languages for prototyping since they're interpreted and since there's a good Internet Explorer script debugger. The sources described above will also teach you about the DOM.

  • Learn to host a Web Browser control and how to manipulate it, using the resources described above.

  • Check out the Visual C++ Technology Preview at http://www.microsoft.com/visualc/. It provides even better MFC support for using the WebBrowser control, including a CHtmlView class, support for the new Internet Explorer 4.0 common controls, and support for hosting ActiveX documents.

  • Have fun! You'll be learning a set of very powerful and easy-to-use tools. If you do so, Dr. GUI's prognosis for your projects is excellent!


Scripting Your Options

Dr. GUI

November 10, 1997

Last week, Dr. GUI explained how to use Dynamic HTML to create user interfaces in applications—even applications that aren't Web-based. The good doctor spoke of how flexible Dynamic HTML is (you can change anything, even the text, on the fly), and how to manipulate a document by manipulating the object model—changing, adding, and deleting objects.

This week, Dr. GUI would like to continue by telling you about the various options that you have to take advantage of scripting. You can do this in your Dynamic HTML pages and in new Dynamic HTML objects called "scriptlets." You can even take advantage of scripting engines in your applications—an easy way to provide your users with a scripting language.

Scripting in Web Wages

If you've used the Web much at all, you've run into Web pages that contain script. Script is used to validate your input, change the behavior of buttons and other HTML form controls, and to link HTML form controls, ActiveX controls, and Java applets. With the combination of ActiveX controls, Java applets, and script, Web pages can do quite a bit.

Before Dynamic HTML, though, scripting was quite limited: in general, you could not change the appearance or contents of the document once it was rendered. That means that it was not possible to do most mouse-over effects, let alone wholesale changes to the style and content of the page on the fly. Now that Dynamic HTML exposes an object model that allows you to change anything on the page, scripting is much more powerful than it was before.

Client-side scripting

Most of the script you've looked at (and perhaps written) has probably been client-side script. Client-side script is part of the HTML document—so it's downloaded into the client's browser. The client's browser interprets and executes the script. Note that the good doctor said "interprets"—the script is sent as source text, so the browser actually has to parse the source code before it can execute the script.

It's easy to find examples of client-side scripting—just note any Web page that says it requires VBScript, JavaScript, JScript, or ECMAScript. Once you're viewing such a page (go to http://www.microsoft.com/scripting/, then click on the Samples link), use the View Source command in your browser to view the HTML source for the page—including all of the script source code. As you all well know, you can learn a lot about programming by looking at other people's code.

Unfortunately, there is no way to hide the script source code—so you probably want to use some other technology, such as ActiveX controls, to hide your proprietary logic. (Every silver lining has its cloud, it seems.)

Check out http://www.microsoft.com/scripting/ for more information on client-side scripting. And note that since client-side script is embedded in the HTML page, you can use it even in applications that aren't Web-based (but which use Dynamic HTML, as discussed last week).

Server-side scripting

Even more common is server-side scripting. In server-side scripting, the server interprets and executes the script in the .ASP page (ASP stands for "Active Server Page") before it delivers the HTML page to the browser. Like client-side scripting, the script source code is coded in the ASP page. However, this code is never sent across the wire to the browser; instead, the server interprets and executes the code and sends the resulting stream to the browser.

Microsoft's Web sites use server-side scripting all over the place. Perhaps the coolest use of server-side scripting (not to mention database/Web integration) is sidewalk.com, at http://www.sidewalk.com/. But even the Microsoft home page (http://www.microsoft.com/) uses server-side scripting extensively.

One key advantage of server-side scripting is that you can deliver very customized pages without requiring any scripting intelligence on the client side. In fact, the server-side script can even deliver different custom pages to each user based on browser capabilities, user preferences, server-side includes of text, and current contents of a server-side database. It's even easy to build pages and/or sets of pages that contain repeating rows of database data. But server-side scripting doesn't make any sense unless you're delivering the pages from a Web server, such as Internet Information Server (for Windows NT Server) or Personal Web Server (for Windows NT Workstation and Windows 95).

Check out http://www.microsoft.com/iis/default.asp for more information on Active Server Pages and server-side scripting.

Scripting languages

Dr. GUI's terminology has been quite generic in referring to scripting above. Of course, you well know that all script has to be coded in some specific scripting language. Scripting languages are a key area in HTML where Microsoft offers a true choice: whereas "the other browser" supports only one scripting language (JavaScript—and not the most up-to-date, standardized version at that), Internet Explorer's ActiveX Scripting supports both VBScript and JScript. In addition to supporting two scripting languages, Microsoft's scripting architecture is modular and open, so that other scripting languages can be used. Internet Explorer supports both scripting languages on all platforms where Internet Explorer runs, including Windows 3.1x, Macintosh, and UNIX. (Note that Internet Explorer 4.0 is in prerelease for all these platforms now—see the Microsoft Internet Explorer Web site [http://www.microsoft.com/ie/]).

Because both client-side and server-side scripting use ActiveX Scripting, all scripting languages are supported on both the client and server sides when you're using Microsoft client and server software. If you'd like to write your own scripting engine to work with any ActiveX Scripting Host (such as Internet Explorer and Internet Information Server), check out http://www.microsoft.com/msdn/sdk/inetsdk/help/compdev/engines/engines.htm#ch_script_engine.

VBScript

VBScript is the simpler of the two scripting languages currently offered. It looks a lot like Visual Basic and it's about as easy-to-learn as Visual Basic. So it's the obvious choice for beginners to scripting.

The downside of VBScript is that it's not supported at all on the other browser—so HTML pages that use client-side VBScript are for Internet Explorer only. However, on the server side the limitations of down-level browsers don't matter—so VBScript is a great choice for server-side script no matter what browsers your users have.

Check out http://www.microsoft.com/vbscript/ for more information on VBScript.

JScript/JavaScript/ECMAScript

First off, let's get these names right. JScript is the name for the Microsoft implementation of the scripting language that's also known as JavaScript and ECMAScript. As you probably know, JavaScript is not Java—its roots are much closer to C/C++ than to Java. However, for marketing reasons, Netscape chose the name JavaScript rather than LiveScript, which is what it had been called before.

ECMAScript is the new name for the scripting language that meets the ECMA-262 standard. (ECMA stands for the European Computer Manufacturers' Association.) The standard is based on JavaScript with additional input from both Netscape and Microsoft.

Microsoft's JScript 3.0 is the most up-to-date implementation of ECMAScript available—as of this writing, it's the only implementation that is 100% ECMA-262–compliant. It's the most advanced implementation available—and it has a few features, such as conditional compilations and some language extensions, that go beyond ECMA-262. These new features have been submitted to ECMA for consideration for a future version of the standard.

Writing your client-side script in ECMAScript/JScript is a good idea because if you're careful about how you write the script source code (and if you test a lot), you can probably get the same script to run under both Internet Explorer and down-level browsers. If you do this, you will want to make sure you don't use new features. JScript offers several features that VBScript doesn't yet offer, so it's the more powerful of the two. But it's a bit harder to learn than VBScript.

Check out http://www.microsoft.com/jscript/ for more information on JScript and ECMAScript.

Scriptlets

Perhaps the most exciting component news for both Web and non-Web developers in Internet Explorer 4.0 is that Internet Explorer now supports what Microsoft calls "scriptlets."

A scriptlet is very simple: it's just a Web page that you can embed in another Web page—or, for that matter, in any Windows application that can host an ActiveX control. Scriptlets expose a public interface of methods, properties, and events just like any ActiveX control—the difference is that any Dynamic HTML programmer who can write script can also write scriptlets, and thereby participate in the creation of reusable components.

Only the variables, procedures, and functions that have "public_" prepended to their names can be accessed by the scriptlet's container. (In JScript, you can gather all of the interface declarations into one "public_description" section.) Events are thrown using a single onscriptletevent event that passes parameters to the container. And, of course, it's possible to have functions implement properties by prepending "public_get_" and "public_put_" to the function names.

Scriptlets are incredibly powerful for building components. These components can be used in Web pages, saving a lot of the cutting and pasting (or server-side includes) that Web programmers do today. Since scriptlets are cached by the browser, they give much better performance by reducing the download size and bandwidth requirements—once a scriptlet is downloaded, it stays in the user's cache, eliminating the need to download that functionality over and over. And because scriptlets use the power of Dynamic HTML, they tend to be considerably smaller than either ActiveX controls or Java applets.

But scriptlets aren't just for Web pages: under Windows, any scriptlet is considered an ActiveX control (just as Java Beans are ActiveX controls). That means that you can use scriptlets any place you could use any other ActiveX control—in Visual Basic, Visual J++, Visual C++, even in Microsoft Word and Microsoft Excel. Any application that can host an ActiveX control can host a scriptlet. What a great way to take advantage of the power of Dynamic HTML and scripting in your Windows applications, huh?

Check out http://www.microsoft.com/msdn/sdk/inetsdk/help/scriptlets/scrlt.htm for more information on scriptlets. And be sure to check out the scriptlet gallery at http://www.microsoft.com/sitebuilder/gallery/files/scriptlets/default.htm.

Using scripting to automate your applications

Dr. GUI has noticed that a number of you seem to have a psychological condition he calls "VBA Envy." The cause is looking at the wonderful capabilities in Word, Excel, PowerPoint, Access, and Visual Basic that VBA (Visual Basic for Applications) gives you.

Now, it is possible to license Visual Basic for Applications for your applications—and many companies do this. There are even companies that will help you integrate VBA into your application. For more information, check out http://www.microsoft.com/vba/.

But if your scripting needs are simpler, you may be better off simply making your application an ActiveX scripting host so that you can host VBScript, JScript, and any other ActiveX scripting engine. The very modular design of Internet Explorer comes to the rescue again—it's not only possible to write your own scripting engines, but you can also write your own scripting hosts!

It's not trivial to do this (you have to develop and expose an object model, for one thing—but you might have an object model already developed for automation purposes), but it's not the hardest programming task in the world, either. And it can give your application extremely powerful scripting capabilities with reasonable effort on your part.

The Windows Scripting Host uses this technique today to allow you to use any ActiveX scripting engine to automate Windows operations, either from the command line or from a Windows-based host. The Windows Scripting Host will be included in Windows 98 and in Windows NT 5.0.

Check out http://www.microsoft.com/msdn/sdk/inetsdk/help/compdev/scripting/hosts.htm#ch_script_host for more information on making your application a scripting host.

This Week's Prescription . . .

So, what should you do about scripting?

First, play around a bit with client-side scripting. It's a powerful tool to help you develop user interfaces in Dynamic HTML. And even if you decide to implement the scripting code in your application by directly manipulating the document object model instead, scripting is great for developing and testing prototypes.

Second, if you do Web-based applications, get familiar with server-side scripting and Active Server Pages. These technologies—especially when they generate Dynamic HTML pages for Internet Explorer 4.0—will really revolutionize the way you do Web programming. Visual InterDev (http://www.microsoft.com/vinterdev/) is a great tool for helping you write Active Server Pages—and it's a standard part of Visual Studio.

Third, check out scriptlets. Scriptlets are a great way to develop low-cost, small, powerful components you can use everywhere: in Web pages and in ActiveX control containers. They give you all the ease of development of a Web page combined with the power of Dynamic HTML and ActiveX. It's darn hard to find folks who can develop ActiveX controls in C++, so if you have some controls that could reasonably be implemented as scriptlets, that can be a big win in terms of getting your products to market faster.

Lastly, consider whether your application would benefit from having scripting capabilities—and if it would, whether implementing Visual Basic for Applications or just implementing the COM interfaces and object model necessary to be an ActiveX scripting host is the way to go.

And for more information, check out some of the great articles on the SiteBuilder Network, especially Bob Jervis's "Scriptlets: Reusable Objects for Web Authors" and the Internet Client SDK (http://www.microsoft.com/workshop/prog/inetsdk/). Don't forget the Microsoft Script Library at http://www.microsoft.com/scripting/ (then click on the Microsoft Script Library link), and be sure to take a look at Nancy Winnick Cluts's "All About Scripting," on the MSDN Library.


Dr. GUI Gets Embedded

Dr. GUI

October 27, 1997

Not just for handheld PC's any more

Pssst . . . Dr. GUI's got a hot tip for you. No, it's not about the stock market. It's about programming. And opportunity. Here's the deal: If you've seen the first generation of handheld PC's, you might think that Windows CE is just for cute little handheld computers that replace your paper organizer. And you might not consider that a real exciting or profitable platform to program for.

But, with the release of Windows CE 2.0 (http://www.microsoft.com/windowsce/), Windows CE isn't just for handheld PC's anymore. Now, don't misunderstand: the good doctor dearly loves his handheld PC (between Dr. GUI and his partner, the GUI family has two of them). But as much as he loves it, he has to admit that it's a bit of a compromise. It's too big to carry effortlessly (although the good doctor now wears his on his belt, like he wore his scientific calculator in high school), and the keyboard's too small to type on easily. Dr. GUI's hoping lots of folks get Internet Explorer so he can afford the upcoming smaller devices—and maybe even the larger devices that have already been announced. (Remember that the good doctor gets paid with the profits from Internet Explorer—but he's not seen the first check yet, for some reason.)

Even today, there are a wide variety of apps available (http://www.microsoft.com/windowsce/hpc/partners/showcase.htm), ranging from games to specialized applications to Pocket Streets (http://microsoft.com/expedia/streets/pocket.htm), which allows you to download and view street maps of anywhere in the U.S. from Microsoft Expedia Streets 98. (It was handy to have a map of San Diego on my H/PC while there for the PDC last month.)

But what's really exciting is the release of Windows CE 2.0 as a modern, modular operating system for any embedded system you can imagine.

That means that you'll see it popping up everywhere—set-top boxes (WebTV will be using it in a future version), DVD players, game consoles (DirectX will be supported in a future version of Windows CE), and more. And many companies are working with Microsoft to support Windows CE development (http://microsoft.com/windowsce/developer/announce.htm).

So what's the opportunity?

Well, it's simple, really: with a lot of machines coming, there's a lot of opportunity to write killer applications for Windows CE devices of various types.

The add-ons for Visual C++ and Visual Basic are available in beta form for download today. (See http://www.microsoft.com/windowsce/developer/download/betainfo.htm) The beta of the add-on for Visual J++ is coming soon. The Visual C++ add-on supports Windows CE SDK programming in C/C++, MFC for Windows CE, and ATL for Windows CE. The Visual Basic add-on includes many of the standard Visual Basic ActiveX controls plus some special controls especially for Windows CE. And the Visual J++ add-on will support JDK 1.1 features plus special classes written specifically for Windows CE.

If that's not enough, MetroWerks has announced CodeWarrior for Windows CE (http://www.metrowerks.com/embedded/wince.html), to ship early next year. It will support both C/C++ and Java.

So there are gonna be lots of tools available—and probably at least one using your favorite programming language.

The best thing, of course, is that since Windows CE is part of the Windows family, you already know how to program it. Sure, there are some API differences, but they're minor compared with all of the conceptual knowledge of how Windows works that you already possess!

Roll your own!

But if you'd rather create your own Windows CE device, you can get a beta of the embedded system add-on today at a nominal charge for shipping and handling of the CD (http://www.microsoft.com/windowsce/developer/download/betainfo.htm). With this add-on, you can create custom versions of Windows CE for your own devices, and even prepare images so you can burn them into ROM and/or download into one of several hardware development platforms for testing. (Remember that Windows CE is modular—that means you can include only the modules you need for your hardware and applications—which lets you tune RAM and ROM requirements to your situation.)

If you're new to hardware and embedded systems, there's a huge list of technology partners who stand ready to help you create your system (http://www.microsoft.com/windowsce/developer/resources/techpart.htm).

By the way, Dr. GUI noticed that Windows CE isn't the only Microsoft operating system that you can use in embedded and dedicated systems: every Microsoft operating system from DOS to Windows 3.1x to Windows 95 to Windows NT is available! (See http://www.microsoft.com/embedded/) DOS and Windows 3.1 can even run from ROM, as can Windows CE. But Windows CE is the only 32-bit multitasking operating system that you can run from ROM so it's the operating system of choice for embedded systems. And its modular design and support for many types of processors makes it even more attractive.

Why CE 2.0 is cool

So why is the good doctor so hot on CE? Well, it's because it's cool—like NT, it was designed from the ground up to be a great 32-bit, multi-threaded, multitasking operating system. No 16-bit anything. No DOS nothing. No segment registers. Just a great operating system. With features like Unicode support, pre-emptive multitasking, memory protection, and a small footprint, it's the lightweight fun operating system you'd write if you had the time.

And, because it's simple yet powerful, it's just plain old fun to program for. Just like in the old days with DOS and Windows . . . except you don't have to muck with segment registers and TSRs any more. And you can distribute your first efforts as shareware on the Web nowadays rather than having to use floppy disks.

Where do I sign up?

That's easy: just download the add-on betas you'd like from Microsoft (http://www.microsoft.com/windowsce/developer/download/betainfo.htm).

Although the add-ons include an H/PC emulator that runs on your PC, you'll want to get at least one H/PC just so you see how your applications really run. (Low-power processors are a lot slower than the Pentium Pro on your desk is.) And you're in luck there: with new devices on the way, H/PC manufacturers have been selling first-generation H/PCs at fire-sale prices—Dr. GUI's seen them offered for as little as $69.95 (refurbished, and no, there aren't any left), although most have been in the $200–$400 range. All of these machines can be upgraded to Windows CE 2.0 later this year—sometimes at no charge. (Check to see what the deal is before you buy.) Casio's announced an especially cool deal in that their Windows CE 2.0 upgrade will come with an additional 2 MB of RAM—all for less than $100, and free if you bought a machine between September 8 and the end of the year.

Dr. GUI's noted only one gotcha: the tools require Windows NT 4.0 and 32 MB of memory. But haven't you wanted to upgrade anyway? I know it's time to add another 64 MB of memory to the desktop machines in the GUI household.

So will Windows CE be the next big thing? It might well be—and if it is, Windows programmers are well positioned to catch the wave. By getting a start on Windows CE now, you'll be even better positioned for success—and you'll have fun while you're at it.


Dr. GUI Does Data with XML

Dr. GUI

October 20, 1997

Last week the good doctor explained how to modify your ActiveX controls so they'll run great under Internet Explorer 4.0. This week, Dr. GUI would like to tackle something a bit more theoretical and future-oriented: XML.

If you're like the doc, you've been reading about XML for a couple of months now and are thoroughly confused about what it might be. Is it a replacement for HTML? A format for indexing Web sites? A way to specify push channels on the Web? A floor polish? A dessert topping? Or all of these?

Simply put, XML is a language that allows you to mark up data. So it's not a floor polish, nor a dessert topping, nor a replacement for HTML. But you can use XML to do the other things, and more.

While HTML and Dynamic HTML are getting better and better at being able to describe layouts and define user interfaces, there has not been a standard way to describe structured data on the Web until XML, formally known as eXtensible Markup Language. Although HTML and XML look fairly similar to one another, there is one crucial difference: while HTML is intended to describe how the document should look, XML describes the relationships among the data. For instance, tags in HTML control positioning, layout, fonts, and color. Tags in XML represent the type of the data enclosed in them. So a "typical" HTML tag might be <B> for bold, while a "typical" XML tag might be <CITY> to indicated that the tagged text is the name of a city.

Dr. GUI knows you're probably asking, "So if you can't control layout with it, why is XML interesting?"

The Network Today vs. the Network with XML (in Internet Explorer 4.0)

Today on the Internet (and other networks), there is a standard way of formatting presentation and UI (HTML) and for clients to send small amounts of data to a server (URLs), but no general standard format for data, especially not for rich data. XML provides a standard format language for rich data that complements HTML formatting for presentation and UI. This format can be used between any pair of computers, not just between server and browser. So, for instance, once a standard <APPOINTMENT> or <INVOICE> is defined in XML, any computer can understand a standard data record generated by any other, giving your data not only cross-platform compatibility but also cross-application compatibility. Dr. GUI is especially excited about exchanging patient records among his various medical practice management programs using XML.

Data and the XML data format

What are the characteristics of data that is moved from site to site or from server to client? First, let's assume that data has been "assembled" into complex structures such as a P.O. or a Bug Report or a Portfolio. This assembly is expensive and is typically done by middle-tier servers. In other words, we don't want to re-do this assembly at each stop the data makes. Next, any data format needs to support extensible annotation for common agreement, personalization, and search support in a Web community.

XML is an ideal standard for meeting these requirements, because:

  • It is standards based and fully extensible.

  • It supports rich, hierarchical, structured and semistructured data.

  • It supports flexible application programming interfaces (APIs). For instance, an XML parser might expose a data object as a tree which can be traversed by your application, or it might expose it as a set of tables.

  • It is supported by Internet Explorer 4.0.

So What Is XML?

XML, then, is just a standard for encoding data. Like HTML, XML is based on SGML. But XML is far simpler than SGML; as a result, you can build an XML parser in days, not months (whew!). Syntactically, it's like HTML, but with two key exceptions:

The set of tags is unlimited.

Containing tags may not overlap each other.

Here's an example of legal XML. Note that each tag is completely contained within its container; none of the tags overlap. This is technically a requirement of HTML as well, but since in practice most HTML is written with overlapping tags, no browser parsers enforce this requirement.

<Person>
<Name>Adam Bosworth</Name> <Title>General Manager</Title> <Age>42</Age>
</Person>

XML can intermix tags and text:

<Person><Name>Adam Bosworth</Name> is an <role>advocate</role> for <technology>XML</technology>

</Person>

Tags can't overlap. The following is illegal in XML because the <Person> and <KeyPoint> tags overlap:

<Person><Name>Adam</Name>
<Key Point><Heading>XML provides a data bus</Heading> </Person><More> . . . </More></KeyPoint>

Tags may be ended in one of three ways. As in HTML, <TAG> is ended by </TAG>. Since XML is strict about proper nesting, you can also end the innermost tag with </>, which is much simpler. Finally, <TAG></> can be shortened into <TAG/>. This is especially handy when the primary purpose of the tag is to set attributes, not enclose text or other tags, as in <NAME VALUE="Adam" />.

XML is normally encoded in Unicode or UTF-8. But you can encode it in any character set you like if you include a first line specifying the character encoding. For instance:

   <?XML Encoding="Windows-1250"?>

would support Eastern Europe.

If no such tag is encountered, the parser assumes UTF-8, but will recognize Unicode data if it's preceded by Unicode byte-order mark.

Namespaces

As of the last submission to the W3C, the semantics of tags can be qualified uniquely by using a namespace.

<?XML::Namespace href = "http://ofs/PO.dtd" as = "po"?>
<Order><ShipTo>Adam</ShipTo> <Amount>100</Amount>
<Items> <Item><Qty>6</Qty><Prod>E13</Prod></>
<Item><Qty>9</Qty><Prod>J14</Prod></> </Items>
</Order>

Tags from multiple namespaces may be mixed. This is essential if data for one grammar is being annotated.

Example

<?XML::Namespace href = "http://acme/stocks.dtd" as = "acme"?>
<?XML::Namespace href = "http://www/types.dtd" as = "types"?>
<acme::Stock> <Ticker>MSFT</Ticker><Price>
<types::Double>110.5</types::Double></Price></Ticker></Stock>

XML and validation

XML supports validating data formats by specifying a grammar for the entity. There are two ways to define rules for the document: DTDs and schemas.

A DTD is used to define a grammar for the tags and attributes. This syntax is going to be supported, but deprecated by Microsoft. It uses a special non-XML–based grammar that looks like the following:

<!doctype RootElement System "URL"[]> or if an internal DTD then
<!doctype RootElement [
<!ELEMENT author (#PCDATA)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT book (title?, author+)>
]>

A schema is a much richer and more extensible way to describe the rules for the content of a document. It uses XML itself as a grammar. A schema is defined using a particular XML syntax, as follows:

<elementType id="author"> <cdata/>
</elementType>
<elementType id="title"> <cdata/>
</elementType>
<elementType id="book">
<elt href="#title" occurs="OPTIONAL"/>
<elt href="#author" occurs="ONEORMORE"/>
</elementType>

XML and Internet Explorer 4.0

XML can be treated as a data source in Internet Explorer 4.0. To do this, first include an applet or ActiveX control that functions as a data source object:

<Applet Class=com.ms.xml.dso.xmldso.class id="mystocks"> <Param name="url" value="http://..."> </Applet>

Then bind to this like any other DSO:

<TABLE DataSrc="#mystocks">
<TR> <TD DataFld="Ticker">
<TD DataFld="Price"></TR>
</TABLE>

XML data also can be provided inline to any applet or object. Example:

<Applet …> <?XML version="1.0"?>
<Stocks>
<Stock><Price>10</Price>   <Ticker>MSFT</Ticker></Stock>
<Stock><Ticker>ORCL</Ticker>   <Price>?</Price></Stock>
</Stocks>
</Applet>

You would use a set of Java classes to access the tree.

Finally, you can use the lightweight C++ parser object from JavaScript:

Document = new ActiveXObject("msxml");
Document.url = "http://…";
tree = Document.getRoot();
...

XML API

The W3C Document Object Model (DOM) controls the standard Object Model (also known as an API) to XML data.

Microsoft has shipped an interim parser on the Web that allows you to load the data into your own data structures or directly use the DOM API as it was when Microsoft cut the code. Microsoft will track the object model as it progresses at http://www.microsoft.com/standards/xml.

Current object model

The root object is the Document. It contains a tree of element objects.

Document.getRoot()

Returns the tree of element objects

Document.load(url)

Points to a new XML document

Document.createElement(type,tagname)

Returns an element of the appropriate type and tagname

Element.getchildren()

Returns the children of that element as collection

Element.getParent()

Returns a parent element

Element.getTagName()

Returns the tag type (that is, on <foo>7</foo> would return "foo")

Element.getText()

Returns the combined unmarked-up text of all children

Element.getType()

Returns the category (Element, Comment, PI, or Text)

Element.addChild(newchildelement, childbefore)

Warning   This has changed in the DOM to Element.append(newchildelement), Element.prepend(newchildelement), Element.insert(newchildelement,index).

Element.removeChild(childtoberemoved)

Returns the removed element

Warning   this is renamed in the DOM to Element.remove(childtoberemoved)

Element.setAttribute(name,value)

Sets the value of the attribute as a string or list of strings (the DTD can specify that the attribute value is a list of tokens)

Element.getAttribute(name)

Returns the value of the attribute as a string or list of strings (the DTD can specify that the attribute value is a list of tokens)

Element.removeAttribute(name)

Removes the specified attribute

Element.getAttributes()

Returns all the attributes in a collection (only works in Java currently)

What's Next?

The good doctor notes that XML is very much a work in progress. Microsoft is working with the W3C XML committee to standardize extensions to support standard namespaces for data and types, updates and synchronization, schemas, and queries. But even though it's changing, you can start getting experience with it now—you can, for instance, format data to be moved around the Web as XML by using the Java source Microsoft has provided free on the Web and provide us with feedback and bug reports. (Microsoft will be working on a C++ implementation of this parser as well.)

Dr. GUI would like to thank Adam Bosworth for giving the PDC talk on which this column is based.


Dr. GUI Cooks Active Eggs

Dr. GUI

October 13, 1997

Welcome . . .

. . . to Dr. GUI's not-quite-first not-quite-real nonquestion column. (The question and answer columns will continue to appear in Developer Network News, printed and online.) Now that his patients will have even more appointments with the good doctor, he promises to travel far and wide—sometimes even to Building 7—in hopes of finding interesting tidbits to share.

For the next few weeks, Dr. GUI would like to share information he learned in a place beyond even Building 7—specifically, at the recent Microsoft Professional Developers Conference in San Diego.

There are many topics the good doctor is thinking of addressing—Dynamic HMTL, Windows CE, data access, and so on—but it seems that the most important for this week is how to tweak your ActiveX controls so they work great with the latest release of Internet Explorer.

Optimizing ActiveX Controls for Internet Explorer 4.0—da rulz have changed, but not a lot

Internet Explorer 4.0 brings some new rules for writing controls so that they'll run optimally. Older controls will still work, but you will find that a few changes will help your controls—and your user's system—run much better. Two of the changes are particularly important: using at least apartment-model threading, and supporting windowless operation.

Huh? Why should I target Internet Explorer 4.0?

Why should you bother optimizing your control for Internet Explorer 4.0? Two reasons: First, Internet Explorer 4.0 is likely to be one of the most popular browsers ever. Second, the Internet Explorer 4.0 Dynamic HTML control will be used on the Active Desktop and in a wide variety of applications, including e-mail, HTML Help, the Visual Studio IDE, and many third-party applications. In other words, a lot of users will feel the improvements you make.

If that isn't enough, Microsoft is encouraging developers to take advantage of the Dynamic HTML control to provide UI for many applications, both traditional and Web-based. The easy programmability and rich display capabilities of Dynamic HTML make using the control very attractive. Dr. GUI's looking forward to using DHTML for everything from dialog boxes to full-blown applications.

So if you want the widest possible market for your controls, you'll want to make sure they work well with Internet Explorer 4.0. Luckily, doing so requires only minor surgery. Your controls won't even need general anesthesia—just a shot of Novocaine.

Symptoms of unoptimized controls

Does your control show symptoms of needing Internet Explorer 4.0 optimization? Check your control against Dr. GUI's symptom list for symptoms of gotta-optimize-itis:

  • Slow system performance when Internet Explorer is running more than one instance of your control (also known as apartment envy)

  • Utter lack of attention to Internet Explorer4.0's multimedia filtering and transition effects (a.k.a. window-itis)

  • Using imaginary window handles (a.k.a. activation window disorder)

  • Lack of persistence and readiness (a.k.a. property disorder)

  • Lack of interaction with the surrounding Internet Explorer4.0 document object model (a.k.a. DOM deficiency)

  • Inability to function in a secure environment (a.k.a. signing/marking deficiency)

  • Slow or absent delivery and installation (a.k.a. breech delivery)

  • Interrupting the current application (a.k.a. activation and focus kleptomania)

  • Inability to make its needs known (a.k.a. event firing disorder)

If your control shows one or more of these symptoms, it has gotta-optimize-itis. Fortunately, this disease is never fatal and relatively easily cured by using one or more of the techniques below.

Ways to write controls

As you know, there are three major ways to write ActiveX controls: you can use C++ with MFC, C++ with ATL, or Visual Basic. What you may not know is that in Internet Explorer 4.0 any Java Bean is automatically an ActiveX control, so you can use Java as well—even for visual controls. (Other tools, such as Delphi, support the writing of ActiveX controls, too.)

For the best control over your controls and the fastest controls, Dr. GUI prescribes ATL 2.0, the Active Template Library that ships with Visual C++ 5.0. For easier, slightly smaller controls, you can use MFC (but your control will require that the MFC DLL be installed on the user's machine). Visual Basic is easy to write, but also requires a large DLL and doesn't give the fine-grained control of the C++ technologies. Java controls require the Java VM (included with Internet Explorer), are somewhat slow, and don't provide fine-grained control. (It's hard to write good-looking controls with AWT, but between AFC and J/Direct you can write anything you want in Java.)

Since this article is about optimization, we'll focus on ATL and MFC controls.

Avoid apartment envy: Use apartment model multithreading

This is a biggie, because you can really degrade your user's performance if you ignore it. So it's very important to make sure that your control uses apartment model multi-threading. Many older controls are single-threaded; such controls cause huge performance problems when multiple instances of the control are run through multiple instances of the Internet Explorer 4.0 Web browser control, which is most of the time nowadays. (This was also an issue with Internet Explorer 3.0, but it wasn't as noticeable because it wasn't as common to run multiple copies of the browser.)

By default, controls created with MFC (version 4.2 and later) and with the latest Visual Basic 5.0 update are automatically apartment-model multithreaded. If you're using ATL, you're really in luck: you get a choice when creating your control. (Dr. GUI likes to be able to control his controls.) If you have controls built with older versions of MFC or Visual Basic, it's an easy matter to update to the latest version and to rebuild the controls—that should be the majority of the work you'll need to do to update your control. And don't forget to mark your control as apartment-model multithreaded in the registry.

But Dr. GUI has to warn you about one very important other issue: while the MFC, ATL, and Visual Basic run times are protected against the re-entrancy problems caused by multithreaded access, you have to protect your global and static data. To do this, the good doctor prescribes appropriate synchronization techniques (semaphores and the like) to protect all global and static data by insuring that it can only be operated on by one thread's scalpel at a time.

Be cool: Make it windowless

The next change you should make to MFC and ATL controls is to make them windowless—so they do their drawing on the container's device context rather than on their own. Unfortunately, in the current release, Visual Basic controls cannot be windowless. So to create a windowless control, you'll have to use MFC or ATL.

Making the control windowless has several advantages besides the fact that windowless controls are faster. The most important for Internet Explorer 4.0 is that windowless controls can have multimedia filter and transition effects applied to them. If your control has its own window, Internet Explorer 4.0 cannot apply the cool multimedia effects to the control—this ties the hands of folks who use your controls. The good doctor knows you don't want to do that.

In addition to all that, windowless controls can be non-rectangular and transparent—and Internet Explorer 4.0 can manipulate their z-order (which control is on top). If you remember the "Mr. ActiveX Eggplant Head" demo using transparent, irregularly shaped controls, you'll have some idea of the power of windowless controls. In addition to being efficient, they're cool!

If you need a window, make your own

Internet Explorer 4.0 also changes how controls are activated: they're not made in-place active unless they're visible. This means that if you need a window to be a message target, you'll need to create your own; you won't get the normal in-place active window unless you're visible. If you try to access the window when it doesn't exist, you'll end up getting egg on your face as you use a NULL handle.

Let Internet Explorer know when you're ready

In Internet Explorer 3.0, there wasn't a really clean way for a control to tell the browser whether the control was ready to be scripted or not. Programmers came up with a number of kludges to work around this, but none was AMA-approved.

In Internet Explorer 4.0, there's a standard way to give detailed information about when your control is ready: just implement the DISPID_READYSTATE automation property and call the container's IPropertyNotifySink::OnChanged when the ready state changes. Note that if you implement ready state you must be sure to properly notify the container. If you don't, the window.onLoad script method will never be called. It's not called until all objects that implement ready state have indicated that they're completely ready.

Don't lose your memory: Use IPersistHistory

In Internet Explorer 3.0, there was a "page cache" of four pages. That means that your ActiveX controls (and Java applets) would be kept alive as the user navigated up to three pages away. This was handy because it allowed the user to navigate back and still have the control present in the same state it was when the user navigated away. For instance, if the control contained something the user was editing, the contents of the control would be the same when the user came back.

This caching caused performance problems, however, so it was eliminated in Internet Explorer 4.0. That means that controls suffer amnesia—they lose their memory—if you navigate even one page away. But Dr. GUI does have a prescription that will take minimal work on your part and work even better than before.

When your control starts, call IPersistHistory::LoadHistory to see if the browser control has any data for you to load. If successful, it returns an IStream interface from which you can read.

When your control is about to be destroyed because the browser is moving to a different page, call IPersistHistory::SaveHistory to get an IStream interface to which you can write the data you need to save.

The data written by IPersistHistory will be kept for the same browser session only, regardless of how many pages away the user navigates. (This is a big advantage over an arbitrary page limit.) But don't write huge amounts of data using this mechanism: the total system limit for all pages in all instances of the browser is only 2 MB. For large data, such as images and database query results, use the cache API to put the data file in the cache and write only the identifier of the object using IPersistHistory.

Change your environment: Take advantage of Dynamic HTML

It's easy for your control to access the Dynamic HTML objects on the Web page: just call IOleClientSite::GetContainer to get access to your container object, then use QueryInterface to get a pointer to the IHTMLDocument2 interface. At that point, you can access and even modify every object on your Web page.

This can be an attractive alternative to exposing your source code as script. (If you ship script, you're exposing yourself to examination by any code doctor.) Note that it's easier to prototype and debug your code in script, then translate the script into interface calls.

Be safe! Sign your work!

It's very important to sign your controls, even if they aren't safe. (Don't mark them as safe if they're not safe, though!) Signing and marking are two different things: signing is just saying that you wrote a control, marking it is further asserting that the control is safe to use in any Web page. Think of writing a control as like painting a fine painting: what artist wouldn't sign their work? Browsers can be set to simply ignore unsigned controls, so it's doubly important to sign yours. (In fact, both high and medium security settings ignore unsigned controls entirely.)

Before you mark your control as safe (by implementing IObjectSafety), make sure it really is safe. (Dr. GUI knows you know how important being safe is nowadays.) There are two types of safety: safe for initialization and safe for scripting. Safe for initialization means that there is no possible initialization input stream that would cause the control to damage a user's machine. (Could an input value, for instance, cause an array to be over indexed?) Safe for scripting means that there's no possible script command or combination of script commands that would cause the control to damage a user's machine. (You especially have to watch out for invalid parameter values.)

Although this is not a complete list, here are some behaviors that are almost always unsafe:

  • Reading, and especially writing, the disk or registry

  • Reading, and especially writing, outside of its memory allocation

  • Cross-frame access of anything

If you can't mark your control as safe, sign it anyway so the user can use it from a proper security zone.

Be smart about delivering your control

The best way to deliver controls and other programs to the user's machine will be using the OSD (Open Software Description) standard. OSD is an XML vocabulary designed by Marimba and Microsoft and supported by Netscape, Lotus, BackWeb, and more.) You can deliver OSD content as a separate file or as a part of a set of Content Definition Format (CDF) tags. OSD will support either push or pull for distribution.

For Internet Explorer 3.0, you'll need to author <OBJECT> tags that point to a .CAB file that has an embedded .INF file. For Internet Explorer 4.0, you can embed the OSD file (and the INF) in the CAB, or reference a CDF file. Note that this new method automatically provides uninstall functionality, as well. (The good doctor wonders if that was enough TLAs for you.)

It's important that you not rely on the user's machine having DLLs (such as MFC, the C run time, the Visual Basic run time, or the ATL run time) available. It's a simple matter to add a few lines of code to your INF file to cause the right CAB file to be downloaded from Microsoft if the user's machine doesn't have the DLL they need. In this way, only users who don't already have the DLL will have to spend time getting it.

Cure kleptomania: Don't steal activation/focus from the active app

Dr. GUI notes with regret (and no small amount of anger and frustration) that it's increasingly common for extraordinarily rude programs to pop up a dialog in your face while you're in the midst of doing something else. What's worse, these programs even steal the keyboard focus, meaning that the characters you're typing into your application end up being processed by the dialog. Dr. GUI joins Miss Manners in denouncing such caddish behavior on the part of programs (or, for that matter, on the part of people).

In an environment where any page can be used as the desktop, you may find that your control is actually placed on the user's desktop. Because of this, it's very important that you never bring up a dialog asynchronously. Only bring up dialogs in response to user actions. This is good design anyway (ask Dr. Manners), but it's especially important for controls on the desktop.

Instead of bringing up a dialog, change the visible state of the control or even of the taskbar. For instance, if the server is unavailable for your stock ticker control, just put a message that says "Server unavailable" in the control rather than interrupting the user with an unnecessary and annoying dialog. If the condition is very important, you can play a sound to alert the user. But don't just pop up a dialog box and steal activation and focus from the application the user is using.

Other guidelines and common problems

One of Dr. GUI's favorite underused Internet-related interfaces is the IBindHost interface, which is very handy when you need to get data from somewhere else on the Web. Check out this powerful interface the next time you're writing a control that needs to get data over the Web.

The good doctor has also noticed a number of common problems that show up when using Internet Explorer version 3.0 controls with version 4.0. Double-check these common problems:

  • Remember that controls are not activated until they're actually visible.

  • Avoid names that are used by XObject.

  • Don't call the container (fire events) from any thread other than the thread on which the control was created. If your control is apartment-model and doesn't start any threads of its own, this won't be an issue since you'll only be called on "your" thread. But if you're free-threaded or if you start threads of your own, be careful of this. If you fire an event on a different thread, the container will never see the event.

  • Don't fire events when the container has asked you to FreezeEvents. If you do, they'll be ignored. (Just as in conversation.) Note that you have to keep track of how often you've been asked to freeze events and only fire events when that count is zero.

Debugging with the Active Desktop

Dr. GUI finds that debugging controls when the Active Desktop is enabled is a special challenge since the IDE debugger doesn't get to load the browser—it's already loaded. This makes it difficult to set breakpoints in controls. The simplest option is just to disable the Active Desktop when you're debugging. If you'd rather not do that, you can attempt to attach to the Active Desktop process or use Task Manager to kill the Active Desktop (Explorer shell) process. If you kill the Active Desktop, there are a number of ways to restart it, including double-clicking on the desktop, pressing Ctrl+Shift+Esc, and starting it with the task manager.

The prognosis

Dr. GUI notices that there are some great benefits to be gained by writing your ActiveX controls in a way that's optimal for Internet Explorer 4.0. First, your control will be a good Internet Explorer 4.0 control. Second, it'll work well in new user interfaces constructed using the Dynamic HTML control, so it'll get use far beyond the Web.

Of the optimizations, the most important to implement are apartment-model awareness and windowlessness (trying saying that five times fast!). You also need to think about security issues all the time—when you're designing, coding, testing, and preparing to sign your control. Don't put off thinking about security until the end.

If you do these optimizations, Dr. GUI promises that you'll take maximum advantage of all your containers, including Internet Explorer.

In closing

Thanks to Dave Massy for the useful talk at PDC that provided material for this column. If you have questions, be sure to see the Internet Client SDK for more information.

Your Turn Whaddya think? Any comments? Do you have any topics you'd like to see the good doctor address? You can write the Doc at drgui@microsoft.com. Although the good doctor's surgery schedule precludes individual replies, Dr. GUI does read and consider all mail, even Java flames.


Dr. GUI's PDC Wrap-Up

Dr. GUI

October 6, 1997

What a full week it was—with too many sessions, too much food (the good doctor put on about five pounds), too much writing (the good doctor was doing other MSDN reporting as well), and a whole lot of puns. Dr. GUI thanks all the folks he met and especially those who pun-ished him in such a pun-ny manner in Dr. GUI's first (and hopefully not last) pun contest. (The good doctor's so into pun-ishment that he's been thinking of checking into a pun-itentiary. And after that string, perhaps he should.)

Enough of that. [Editor's note: It's about time!] Another part of what the good doctor has been up to is getting his head to stop spinning over all of the new technology he saw. (Stopping your head from spinning is like decompressing after you've been deep underwater: you have to do it gradually or you can get the bends.) There was indeed a lot of information on a lot of new technologies, and Dr. GUI's still trying to make it all make sense. ("Making it all make sense." Hmmm, we could make a tag line out of that phrase . . . naw, it's probably been done.)

It's Windows NT 5.0, stupid

So the good doctor's trying to come up with unifying themes to help. In almost all of the presentations, there was one primary unifying theme: Windows NT 5.0. Several speakers, including Bill Gates, referred to Windows NT 5.0 as a product that Microsoft is betting the company on. The new technologies for distributed computing are exciting and powerful—and they'll make your development easier as well as making your applications and systems more powerful and robust in addition to enabling new types of applications that just weren't possible before.

Windows DNA architecture

The name we've come up with to try to describe this is "Windows DNA Architecture," where DNA stands for "Distributed interNet Applications." (Dr. GUI didn't come up with the capitalization, OK?) Windows DNA is a renaming of some old names, especially the old "Active Platform" name. The technologies that fell under the "Active Platform" umbrella are still there and in fact improved—better than ever. But the name "Windows DNA Architecture" really describes the key new features that are designed to enable distributed computing as never before.

Windows DNA: "both-and," not "either-or"

There are many dualisms in computing today: Applications can be designed as client-server or Web applications (among others), UI can be generated as documents or code, storage can be structured or unstructured, computers can be mobile or connected, and resources can be centralized or distributed.

None of these design choices is "right" or "wrong"—they're just more useful or less useful in certain situations. Some applications lend themselves to client-server or three-tier design, and some are best done with Web servers. There are good reasons to do UI as HTML pages sometimes, and good reasons to use the Win32 UI API including DirectX. (Or is that DirectEggs? Oops, pun-ish me again.) Some applications need to store data in a database, others need less structured storage, such as text files. Some applications run only on an individual PC or LAN. Some need to be able to work with unreliable network connections (such as phone lines to connect to the Internet—or, given the traffic on the Internet nowadays, any connection to the Internet) and intermittent connections, such as laptop and handheld PCs. And there are compelling reasons to both centralize and distribute resources.

But the fact that these different technologies for writing applications grew up independently means that they're often not compatible with each other. So today, you often have to make a dualistic "either-or" decision about which technologies to use. If the technology you didn't choose has some features you could use to make your life easier, that's too bad. Do without or implement it yourself.

A key theme of Windows DNA is bridging these dualisms—enabling you to make "both-and" rather than "either-or" decisions, and use the best of both worlds.

Web UI and Windows UI

Since the Dynamic HTML control is an ActiveX control, you can embed it in programs built in any language that supports ActiveX controls: Visual Basic, Visual C++, Visual J++, and so on. That means that you can use the Dynamic HTML control as part of your program—not only to browse the Web, but also as your user interface. Since the Dynamic HTML control exposes then entire Document Object Model and since everything in a Dynamic HTML page can be changed on the fly, you have complete programmatic control of all aspects of your UI. And if you don't enjoy writing UI code, you can probably, with some luck, find folks who can not only prototype your UI in Dynamic HTML but can also write the final code from the prototype. Using Dynamic HTML will give you rich, easy-to-write interfaces.

But what if you really need access to Win32, OpenGL, or DirectX? Well, remember that Dynamic HTML can host ActiveX controls: just write a component that uses the technology you need and embed it in your Dynamic HTML UI. With this component approach, you have total flexibility.

"Auto-everything" with COM+

The second key theme of Windows DNA is moving commonly used functionality into the operating system so that you don't have to write it over—and over, and over—again. We call this "auto-everything." Dr. GUI's friends at Microsoft are painfully aware of the chasm-like distinction between great tools and frameworks and horribly complex APIs. On one hand, we have tools and frameworks such as Visual Basic and MFC that take much of the drudgery and tedium out of writing applications, making you more productive. On the other hand, we have the incredible complexity of some raw APIs—such as the dozen or so multi-function interfaces you have to implement in order to build a visual ActiveX control from scratch.

The part of Windows DNA that provides a powerful, easy-to-use API for building component applications is called "COM+." COM+ includes services for transactions, resource management, dynamic and asynchronous invocation, data management, and server services. The emphasis in COM+ is on making sophisticated, complicated functionality such as transactions (that can be rolled back if not completed) and resource management (including reference counting) an "automatic" (or at least easy-to-use) part of the operating system so that the services can be used from any language. Just as MFC made writing Windows applications—even OLE servers—a snap, so too will COM+ (and visual tools) make sophisticated functionality all but automatic. The idea is that, just like a framework, COM+ will do all of the tedious stuff for you. All you have to do is write the code that's specific to the problem you're solving.

For instance, when you write a server component, all you'll have to write is the service logic and the shared data. COM+ will deal with queuing, connections, security, thread pools, and synchronization. When you write a client, you only have to deal with the UI, shared data, business rules, and interaction logic. COM+ will deal with protocols, caching, queues, drawing and multimedia, events, data binding, rendering, and UI interactions. And for components, all you need to deal with is meta-data and methods—COM+ will deal with data-binding, interception, versioning, the class factor, registration, IUnknown, reference counting, IDispatch, connection points, and persistence.

COM+ is not a replacement for COM; rather, it's an extension of COM. Although COM+ will do many things for you correctly and accurately, older programs or programs that just need to do things a different way can still use COM as they always have.

Integrated storage with OLE-DB and ADO

OLE-DB is an API that allows you to access all types of data—whether from a SQL database or a text file—in a consistent fashion. OLE-DB relies on OLE-DB providers—objects that expose particular data stores using a consistent object model. So if you expose your custom data formats to OLE-DB by writing an OLE-DB provider object, anyone will be able to access the data in a consistent, simple manner. By the same token, when you access data through an OLE-DB consumer object, you're able to access not only databases but also any data for which an OLE-DB provider has been written. It's not hard to imagine how powerful this is.

For easy access to OLE-DB data, you can use ADO (Active Data Object). ADO is an automation interface to OLE-DB data that can be used by any languages. Since it's so much more powerful than the former objects (DAO and RDO), it makes sense to use ADO exclusively.

Messaging, transactioning, Intellimirror, and caching enable distributed computing even without continuous connections

Networks are great, but what happens when the network goes down? Or when you undock your laptop or handheld PC? Windows DNA has several technologies to allow your programs to work even though the machines aren't connected all the time.

Transactioning is the ability to roll back changes if the entire transaction can't be finished. For instance, let's say you lost your Internet connection between updating your inbound and outbound flights in a travel reservations database. You would not want to have your flight record half updated—it's either all or nothing. Transactioning allows you to define what constitutes a complete transaction and to have the system automatically cancel incomplete transactions, thus ensuring data integrity. COM+ will have support for automatic transactioning.

Messaging is the ability to send a command to another computer and have it queued for later automatic execution. An example today is what happens when you use a mail program to reply to mail off-line. The response is queued in the Outbox until you reconnect to the network, at which time it is sent. (Mail and mailboxes are a good model for messaging.) Now generalize this to any function call—for instance, a transaction to update a database record. When you use messaging to do such calls, the calls can be queued at many places along the way, thereby giving you support for disconnected networks and robust behavior in the event of interruptions of network service. COM+ also provides automatic messaging.

Windows NT 5.0 supports two types of caching of user data and settings. First, it supports Intellimirror, which stores a copy of the user's settings and files on a server. This means that a user can walk up to any machine on the network and restore their settings and files—you can even replace a failed machine with a new one and have the new one set the same as the old one automatically. User-side caching is also important to allow users to download data to a mobile computer and to do work while not connected to the network.

Distributed services enables logical centralization even though physically distributed

For a number of reasons—bandwidth, geography, and so on—you want to distribute various computing resources all over the network rather than centralizing them on one machine. But if you have to manage that distributed system or have to try to find something on it, you soon wish that all the resources were on one huge central machine.

Active Directory enables you to find resources and users no matter where they are. Active Directory, which scales to millions of objects, allows you to store information on users, resources, configurations, credentials, policies, and so forth. Active Directory supports LDAP protocol, meaning that it can be accessed from any LDAP client. Since this directory is integrated into the OS, it's secure—and your programs can easily take advantage of it to find information on users.

NT 5.0 also supports a distributed file system, which allows replication including to disconnected clients.

New Windows NT 5.0 Features

There are a number of features in Windows NT 5.0 that don't fit neatly into Windows DNA—but they're things you should know about so you can take advantage of them as appropriate.

Base services

Windows NT 5.0 supports a number of features designed to make better use of PC hardware including Plug and Play, power management (including OnNow), a common driver model for Windows 98 and Windows NT (including signed drivers), and much more device support. It also supports 64-bit VLM (very large memory) address spaces and scales to more processors better than before. The file system supports disk quotas, file attributes, and real-time indexing.

Windows NT 5.0 also supports multilingual UI so that the same NT binary can run anywhere, regardless of languages. That also means that there's only one Windows NT 5.0 API for the whole world.

Network and Distributed Services

Much of the work of supporting networks better has gone into simplifying installation and configuring of networks (with Plug and Play-style easy installation) and extending the network infrastructure via new protocols. Distributed services include directory and security services, discussed above.

Application services

Windows NT 5.0 should be the last time you ever install an OS. After the initial install, NT will update itself with "self everything." It will be able to install patches and enhancement automatically, as well as detect and repair damaged or missing program files. Application installation will now be handled by the OS, which results in two advantages: the OS can do it right (and keep the OS files secure) and then it also has the information it needs to automatically uninstall.

User/Presentation services

In addition to the Dynamic HTML features, Windows NT 5.0 supports DirectX 5.0 to parity with Windows 98, including video hardware acceleration, audio, and even force feedback joysticks. For Alpha users, note that Fx!32 allows you to run Intel Win32 binaries on Alpha NT machines.

What can I do today?

Some of the features we've discussed aren't available now—but you still can write Windows DNA applications today using the following ideas:

First, use COM to componentize your applications. This will make it easier to modify your applications to work with COM+ later on and, more importantly, it will give you great mix-and-match flexibility and component reuse.

Use Dynamic HTML data binding to display data and ASP pages to create transactions. And use ADO to access data, since ADO works with OLE-DB.

Use ActiveX controls, Java with AFC, Dynamic HTML, and channels to provide rich UI for your users.

For maximum cross-platform client compatibility, author your UI in basic HTML. You can also use Dynamic HTML features that degrade gracefully—or even check the browser in your ASP page and download the right page. And remember that Dynamic HTML will be supported cross-platform as soon as Internet Explorer 4.0 is available for Macintosh and UNIX. (It should be even more widespread when it's a standard.)

Be sure to understand and integrate with Windows NT 5.0 and zero-administration installation.


Windows 98 Has Something for Everyone, Even Developers

IMHO
February 25, 1998

John Swenson
MSDN Online

If you're a developer, you might be wondering what Windows 98 has to interest you. With the new operating system now in the release candidate stage, it's time to examine the successor to Windows 95, if you haven't done so already.

Even if your main interest is Windows NT 5.0, Windows 98 can teach you a lot about what's coming in that operating system. New features such as the Win 32 Driver Model, multimonitor support, and ACPI and OnNow power management technologies are all appearing in Windows 98 before they arrive in Windows NT 5.0.

Writing so-called "clean" applications for Windows 98 is also good preparation for designing clean applications for Windows NT 5.0. For details on how to do this, see the Microsoft Designed for Windows NT 5.0 and Windows 98 Logo Handbook (see the Microsoft Windows Family Web site at http://www.microsoft.com/windows/thirdparty/winlogo/logo/default.htm). Pay special attention to the "Best Practices" section.

Dig beneath the surface

With Windows 98, you don't have to worry about the backward compatibility of your Windows applications. All your apps written for Windows 95 should run fine under Windows 98. But if you look closely at the new operating system, you might find some new features your apps can take advantage of.

The first time experienced Windows 95 users fire up Windows 98, most won't notice much new, since Microsoft hasn't made any significant changes in the user interface for Windows 98. But if you're a developer, start digging. You'll soon discover there's a lot of new technology in Windows 98, most of it hidden under the covers. If someone has told you the only big new feature in Windows 98 is an integrated version of the Internet Explorer 4.0 browser, don't believe them.

I've been running Windows 98 beta software for nearly a year, so I've had plenty of time to try out most of the new features in Windows 98. Yet even after months of tinkering, there are still several major new features I haven't got around to trying, such as Windows 98's support for hot-plug-enabled Universal Serial Bus devices and multiple monitors (the ability to drive more than one monitor at once using multiple video cards).

Many of the new items in Windows 98 aren't features that end users will ever notice—they're new technologies that only developers will appreciate. For example, Windows 98 supports the new Win32 Driver Model (WDM). WDM is a unified driver model that will allow developers to write drivers that work on both Windows 98 and Windows NT 5.0. This is possible because Microsoft added selected NT Kernel services into Windows 98 via a virtual device driver (ntkern.vxd). This allows Windows 98 to maintain full support for legacy device drivers while adding support for new WDM drivers. For more information about WDM see the Microsoft Hardware Development Web site at http://www.microsoft.com/hwdev/desinit/wdm.htm.

Much more than just an integrated browser

For a complete summary of all the new technologies and features in Windows 98, read the feature overview on the Microsoft Windows 98 Beta 3 Web site (http://www.microsoft.com/windows98/info/feat.htm). Rather than try to list all of the features here, I'll pick one sample most likely to interest developers, skipping the many new entertainment features such as WebTV for Windows.

If you write Windows applications, you're probably most interested in system-level features such as Windows 98's new Dr. Watson utility. Dr. Watson can generate a system snapshot that gives Windows 98 users a comprehensive picture of their software environment. If a software fault occurs in your application (general protection fault, hang, and so forth), Dr. Watson will intercept it and indicate which software faulted and why. The utility also saves detailed information about the state of a system at the moment the fault occurred. Technical support personnel can gather this information from users, making it much easier to diagnose why applications crash.

There are many uses for the new features in Windows 98 that developers will discover on their own. For example, if you set up two displays on one PC using the multimonitor feature, you could write code in one window and view some sample code in another window on your second monitor. You can display code today on two monitors with Windows 95 or Windows NT 4.0, but only if they are connected to two separate PCs. It's much harder to cut and paste code between two PCs than it is between multiple Windows on a single PC.

Figure 1. The new System Monitor in Windows 98 is similar to the Performance Monitor in Windows NT 4.0.

Networking and administration improvements

Windows 98 contains many new features aimed at corporate developers, IS managers, and network administrators. The Windows 98 Resource Kit will contain numerous administration tools, as well as detailed technical information about networking, setup, and related topics.

One key feature is the ability to automate Windows 98 setup using custom setup script files. These easy-to-create scripts can contain predefined settings for every option available during a standard Windows 98 setup and installation. They can also contain instructions for installing additional software, incorporating the setup scripts that come with many applications.

Windows 98 will also ship with a hyperlink on the Start menu that takes users directly to a new Windows Update Web Site. Registered users who visit the site can download the latest Windows 98 drivers and operating system files there, ensuring that their copy of Windows 98 stays up to date. The Web site launches software that automatically scans each system to determine what it needs, and then prompts users to download the appropriate updates. Network administrators who don't want employees updating their own systems can remove this link to the site.

In the area of networking, Windows 98 will support non-Microsoft networking technologies such as Novell NetWare Directory Services (NDS). The Client Services for NetWare protocol enables Windows 98 users to log on to Novell NetWare 4.x servers running NDS to access files and print resources.

More stable, more robust

No discussion of Windows 98 would be complete without mentioning all the work that went into improving the overall performance of the operating system. Veteran Windows 95 users will quickly notice that Windows 98 is a faster, more stable, and more reliable operating system. Not as stable as Windows NT, but more crash-proof than Windows 95, thanks to the new fully 32-bit kernel in Windows 98.

The 32-bit kernel in Windows 98 provides improved memory management and process scheduling, improved system-wide robustness, and better cleanup after an application closes or fails.

Windows 98 is also a fully integrated 32-bit, protected mode operating system. It introduces the new FAT32 file system, which first appeared in the OSR 2.1 version of Windows 95 but hasn't made its widespread debut until now. The new file system uses smaller clusters to do a much more efficient job than the old FAT16 file system of storing information on today's multi-gigabyte hard drives. Windows 98 will have a tool to let users upgrading from Windows 95 safely convert their drives from FAT16 to FAT32. Users will no longer have to divide their 2GB or larger hard drives into multiple partitions.

Other under-the-hood improvements that speed system performance and make Windows 98 more stable and reliable include:

  • Preemptive multitasking and multithreading support. This allows multiple applications and system tasks to run well concurrently.

  • 32-bit device drivers for all system components, ensuring better resource management.

An application launch accelerator that uses Disk Defragmenter to optimize disks for faster-starting applications.

End users who don't understand these technologies will simply notice that Windows 98 crashes less often than Windows 95 and has a smoother look and feel.

New hardware galore

Every Windows 95 user who tries Windows 98 will come up with their own opinion about which changes are most significant. To me, the most sweeping change is Windows 98's vast support for new hardware. This built-in support may not become obvious until next year, when many of the hundreds of new devices supported by Windows 98 reach market. This includes many types of PC peripherals that didn't exist when Windows 95 was released, such as AGP graphics cards, DVD drives, and USB devices of every class. Windows 98 will also support yet-to-be-released devices that will connect through an IEEE 1394 high-speed bus. Finally, the new operating system will provide users with the latest drivers for many of their existing cards and peripherals.

Figure 2. The Add New Hardware Wizard lists some of the new types of devices supported in Windows 98.

The best way to understand Windows 98 is simply to try it yourself. With Windows 98 already at Release Candidate 0 as of this writing, the final version will soon be out.

Comments? Send us e-mail.


ADSL Is Almost Ready for Prime Time

IMHO
February 18, 1998

John Swenson
MSDN Online

Every once in a while a new technology comes along that is so interesting I feel compelled to write about it, even if it isn't directly related to software development, the usual topic here at MSDN Online. Today's irresistible cool technology is ADSL, or Asymmetric Digital Subscriber Line. As you've probably read by now, this high-speed telecommunications technology allows users to download information over normal copper phone lines at speeds ranging from 1.5 to 8 megabits per second (Mbps). Upload speeds are a bit slower, peaking out at 1 Mbps, but that's still 34 times faster than a 28.8K modem.

ADSL and cable modems are supposed to be the technologies that will finally break the bandwidth barrier, allowing millions of home PC users to throw away their 28.8K or 56K modems and download Web pages at least 50 times faster. Both services are still in scarce supply, however, and have yet to see widespread deployment by phone companies or cable companies.

Aside from this rather major hurdle, which time should solve, I can vouch from personal experience that ADSL is not some blue-sky technology. It's real, and it works great.

Launch dates approaching

Please pardon the sales pitch. I have no reason to sell anyone on ADSL; I'm just an enthusiastic convert. I'm one of 1,000 Microsoft employees participating in an ADSL trial that Microsoft has been running in the Redmond area in collaboration with GTE, the local phone company around here. When the trial started two years ago, only a couple of dozen GTE and Microsoft employees tested ADSL at home. At the time, ADSL was one of those cutting-edge technologies that was cool, but so far from public availability that it was hardly worth writing about.

Today, ADSL is much more interesting to write about because soon you won't have to work at a company like Microsoft to be able to try it. GTE and several other phone companies plan to begin offering the service to the public in numerous cities around the country by the end of this year. The ADSL Forum (see their Web site at http://www.adsl.com/), a trade group that promotes ADSL, keeps a list of ADSL rollouts around the world, where you can check to see if the service is due to arrive soon in your area.

GTE plans to end its trial and begin offering ADSL service to the public within three months, beginning in such towns as Redmond where the company already has installed ADSL equipment in its switching stations. Prices reportedly will start at around $50 per month for home users. That's surprisingly affordable when you consider that it's likely to include a leased ADSL modem, and is only 2 ½ times more expensive than the $20 per month that most people already pay for a personal Internet account. It seems reasonable to predict that many PC users will decide 50 times the speed is worth 2 ½ times the monthly cost, especially when they consider the other benefits of ADSL.

More than just speed

What I like best about ADSL is that the service is always on (no more dialing an Internet connection) and works over the same voice line you can talk on. Even while you're surfing the Web with ADSL, your phone can ring (or you can dial out) and your conversation sounds totally normal. ADSL eliminates the need for an extra line reserved for your modem, saving at least $20 a month.

If you're like most developers, you probably work at home occasionally, perhaps just on nights or weekends. The hassles of dialing into the office to check your e-mail and access your files may keep you from working at home more often.

Developers don't need a high-speed line to write code from home, but a technology like ADSL sure helps when you're transferring files to a remote server, checking e-mail, dialing into the corporate network, or surfing the Web. ADSL also lets you download any software application in minutes.

Faster uploads, too

When I joined the Microsoft-GTE trial last spring, GTE gave me an early ADSL modem from Westell (http://www.westell.com/) that could download data at 1.5 Mbps, but upload only at a paltry 56K. I recently moved, and this week GTE visited my new home to reinstall ADSL. The installer brought a new Westell modem that downloads data at the same 1.5Mbps, but uploads data at speeds approaching 1 Mbps. Like my older Westell modem, this external modem connects to my PC through a standard Ethernet card.

Setting up ADSL on my Windows PC was a snap. All I did was type in an IP address, a gateway address, and a handful of other entries in my Network settings, and then ping the addresses in a DOS box to make sure they worked.

Modems maturing

My new ADSL modem uses rate adaptive technology to automatically adapt its speed to line conditions and distance, so it performs optimally at all times. Instead of a clunky gray box, this Westell FlexCap modem is housed in a sleek black case. This attention to how the product looks is a good sign. It tells me Westell must be gearing up to begin marketing ADSL modems to the consumer public, instead of just to telephone company engineers.

The biggest difference between my new and old ADSL modems is that the new upload speed lets me host a Web site at home. This is a lot easier than transferring all of my Web files via FTP to a remote server at my Internet Service Provider. The 1 Mbps upload speed is plenty fast for dishing out Web pages on a small personal Web site. As long as I leave my home PC turned on, my Web site is always up and running.

Easing rollout costs

From an end-user perspective, ADSL doesn't have any drawbacks I can see other than the potential cost issue if phone companies price the service too high. The biggest issues face the phone companies, which must bear the cost of rolling out ADSL to tens of thousands of customers in each market.

The GTE installer who visited my house told me ADSL is far easier to install and set up than ISDN, yet he still had to spend three hours solving an installation problem that turned out to be at the GTE switching center. Most home ADSL installations only take about an hour, he said. Still, the time and cost of dispatching an installer for every new ADSL customer adds up fast, no matter how quick the installation.

Next up: Universal ADSL

To solve this installation cost hurdle, Microsoft, Intel, and Compaq recently announced they are teaming up with GTE and a bunch of other telecommunications companies and equipment makers to develop a mass-market version of ADSL called Universal ADSL. (Read more about this announcement on the GTE Web site at http://www.gte.com/g/news/fastadsl.html.) This so-called "DSL Lite" technology is supposed to be a lot easier to install when it rolls out at the end of this year, since installation won't require a visit from the phone company. There will no longer be a need to install a splitter on each user's phone jack. Nor will users have to open their PCs to install a network card, since DSL Lite modems will connect through the Universal Serial Bus.

DSL Lite won't be as fast as regular ADSL, but it will cost less. Phone companies may limit download speeds to well under 1 Mbps to keep prices low. Not much public information is available yet about DSL Lite, but you can check the Universal ADSL Working Group Web site (http://www.uawg.org/index.html) for updates.

An end to bandwidth suffering

No matter how the phone companies configure ADSL, every home user who tries it a will experience a quantum leap in performance over today's pokey analog modems. Working from home will get a lot easier, and developers will be able to download software to their heart's content. Slowly but surely, today's bandwidth crunch will fade away.

Comments? Send us e-mail.


Common Sense Writing and Publishing for the Web

IMHO
February 9, 1998

John Swenson
MSDN Online

If you've ever written an article for a Web site, or if you plan to write one someday, then Jakob Nielsen has a message for you. The Web usability specialist—a distinguished scientist at Sun Microsystems who has written several books on usability—is an expert on how people read and view information on the Web. He argues that almost no one actually reads on the Web. According to his research, practically everyone just scans information on the Web. If true, this has major implications for how Web sites should be designed and articles structured. Most Web sites today present information terribly, he says.

Nielsen visited Microsoft recently as a guest of Microsoft Research. While he was in Redmond, he delivered a lecture to Microsoft employees, advising them how to make their Web sites more usable and articles more readable. His messages hit home with MSDN Online Editor Norvin Leach and myself, since we've been thinking hard lately about how we structure articles and other information on the MSDN Web site.

Before you stop reading at this point and say, "I'm a software developer, not a writer or site builder, I don't need to know how to publish information on the Web," consider this. Sooner or later, almost every developer has to write a technical article or describe an application they built. Chances are that information will be posted on an internal or external Web site. If you want people to actually read what you write, pay attention to what Nielsen has to day.

A shorter attention span

According to Nielsen, any article written for the Web should differ in several important ways from an article on the same topic written for print (paper). To begin with, Web articles should only be about half the length of print articles. In his research, Nielsen has found that people have a much shorter attention span on the Web than when they are reading something on paper.

The main reason for this short attention span is because it's so easy to shoot off to a different Web site with a simple mouse click, Nielsen says. Web users always carry this thought in the back of their minds, knowing there are countless other Web sites they could jump to at any moment. Ever noticed how many people read Web sites with their finger poised over the mouse button? A physical piece of reading material like a magazine or paper report tends to hold a person's attention better because the user has to move the magazine or paper away from their face and pick up something else when they want to switch what they're reading.

Web writing is a new skill

If you really want people to absorb the information you post on the Web, it's essential to teach yourself to write in a new way, according to Nielsen. "The natural way you write is wrong," he says.

Since most people have spent years writing for print, they find it hard to break old habits. But Nielsen argues that change is essential when switching to writing for the Web. Everything written for the Web should be extremely concise, presented in outline format, and stripped of all marketing verbiage, he advises.

To demonstrate what he means, I'll switch to a writing style Nielsen recommends as I list some of his other tips for creating Web sites and articles that people will actually read:

  • Make everything easy to scan

    Use highlighted words, limit your paragraphs to a single thought, and put everything into bullets and lists.

  • Add more content, cut the fluff

    Devote more of your Web site to the actual articles and other content you want to publish, and less space to navigational menus, ads, and graphics. Many sites use only 20 percent of the pixels on each screen to display actual site content, he says.

  • Establish credibility

    Research has shown that people judge information to be more credible on Web sites that look like they are professionally designed. It also boosts credibility to carefully edit out all typographical errors and frequently update information on your site, since most people find fresh information more credible. Adding links to other Web sites helps credibility, too, since it makes your site appear more connected to the rest of the Web.

  • Kill the marketingese

    Web users dislike gratuitous, self-inflating, marketing information. "They really want the hard facts," Nielsen says. "They don't want self-promoting information. Yet if you look around the Web, this is how all sites seem to be done." If you strip out the marketing talk, people won't have to do that editing in their own heads and they'll be more likely to keep reading.

  • Use an inverted pyramid style

    When writing for the Web, always write in an inverted pyramid style. Put your conclusion at the top and list the most important information first, assuming that most people will quit reading before they reach the end.

  • Cut length with hyperlinks

    Since it's important to be concise, use hyperlinks to shorten your text. Rather than explain every nonessential thought to your readers, fill your text with hyperlinks to sidebars, related articles, and other sites where readers who are interested can get more information. Hyperlinks are a particularly useful way to shorten white papers and other long technical articles. To see how Nielsen uses hyperlinks in his articles, see his essay about Writing for the Web (http://www.useit.com/papers/webwriting/).

  • Kill all nonessential graphics

    Since download times rule the Web, don't make your readers wait for graphics and big pages to download. Most people start feeling anxious if they have to wait more than one second for a page to appear, Nielsen says, and most won't wait more than 10 seconds unless the information is very important to them. A detailed explanation of Nielsen's research on this topic is available at his Web site (http://www.useit.com/papers/responsetime.html).

  • More information is not better

    Always remember that what really matters is not giving your Web readers more information, but giving them more concise information. How much is too much? It varies depending on subject, but as a general guideline, you shouldn't make readers click down more than three screens to reach the end of any article, Nielsen cautions.

For more advice from Nielsen and details of his usability research, visit useit.com: Jakob Nielsen's Website (http://www.useit.com/).

Comments? Send us e-mail.


The Human Problems of Web Publishing

IMHO
January 30, 1998

John Swenson
MSDN Online

Microsoft's first Web TechEd conference featured an amazing range of technical presentations on everything from linking Web sites to databases to putting the latest user interfaces on top of your Web applications. If anyone still doubts that Web development has become as technical as other forms of software development, here was the evidence. More than 3,000 developers—many of them from Fortune 500 companies—spent three days attending presentations on 82 different Web-development topics.

After so much hard-core technical talk, imagine my surprise when I had lunch with a group of Web developers on the final day of the conference and asked about their biggest concerns and issues. Did they mention any of the technical topics covered at conference? No, they started discussing the human problems associated with publishing big corporate Web sites. They talked about the difficulty of getting their managers to adopt the new development ideas they learned at conferences like Web TechEd, and they talked about the difficulty of establishing simple procedures to let more people inside their companies contribute to the corporate Web site.

Two Web developers who work for a large chip manufacturer brought up this latter issue, which has more to do with people than technology. They talked about the problems associated with having hundreds of employees publish information to their company's intranet and extranet. It turns out that approximately 400 people at this company post information directly to the Web.

This number wouldn't seem so high, except that all these employees must not only create the content (text, graphics, and layout) they want to post online, but they also have to do all the work of preparing their content for the Web. They have to add the HTML tags and whatever else is necessary and then post the files in the proper location on the correct Web server.

A barrier to publishing

This method of Web publishing—requiring every employee who creates information for a company's Web sites to understand HTML—isn't that uncommon. Many companies require their employees to understand Web publishing in order to get their material on the Web.

The more I think about this, the more absurd this seems. Is there any other type of publishing where people who write articles or create graphics also have to learn the technical skills of publishing? Can you imagine a newspaper reporter or magazine writer running the presses at the printing plant? There are some examples of this, but they're few and far between. The editors of some small weekly newspapers, for example, handle all their writing, editing, and publishing tasks (sometimes even advertising, too). But you'd never find anyone who handles more than one of these tasks at a large newspaper.

When desktop publishing took off in the early 1980s, many people discovered how easy this new technology made it to publish newsletters, brochures, and other documents. They found that desktop publishing software allowed them manage all the tasks of layout, editing, writing, and publishing.

When the Web took off a couple of years ago, the same thing happened. A lot of people started publishing their own Web sites, handling all the tasks of layout, design, and content creation.

Division of labor

Does it make sense for employees in all but the smallest companies to learn all these Web publishing skills? Why should employees who want to post information on their corporate intranet or Web site have to understand the technical details of Web publishing? As corporate Web sites grow bigger and more complex, it makes sense to separate the people who create the content from the people who understand the technical details of Web publishing.

Many companies do separate these two functions. When I write an article for MSDN Online, for example, I don't add the HTML tags or post the article to our Web server (although some writers here do like to add their own HTML tags). We have employees who specialize in those tasks. It's not that I don't want to understand how to perform those tasks, it's just not an efficient use of my time to stay up to date on all the technical procedures.

There's an interesting parallel here to application development. At Web TechEd, developers heard a lot about the benefits of separating their Web applications into multiple tiers. They also heard a lot about the benefits of separating their Web content from their application's user interface.

If separation is good when you're developing Web applications and Web sites, why not apply that same strategy to people and separate the process of Web publishing from the process of creating Web content? If it takes special knowledge to understand how to publish information on the Web, why not concentrate that task in the hands of a few specialists?

Easing the Web publishing process

New tools and applications are arriving that may eliminate this issue altogether, by making it easy for employees without any technical knowledge to publish their information on the Web. At Web TechEd, Microsoft demonstrated the capabilities of its new Site Server 3.0 BackOffice application (see the Microsoft Site Server Web site at http://www.microsoft.com/siteserver/default.asp for more about Site Server). Microsoft senior Vice-President Bob Muglia showed how a company could set up pages on their intranet using Site Server, where employees without any technical skills could publish information.

In the example he used, Muglia showed how a company could set up an internal Web site where employees could list job openings. Using drop-down menus, they could select the job category, department name, and other information. Then they could type the job description into a window and click Send to post the opening. In this example, the Web administrator had set Site Server to prevent the job postings from actually getting published until someone had reviewed each submission, to make sure the submitter had permission to post job openings. It would be easy, however, to set up sites where employees could publish directly to the Web, without any technical Webmaster standing between them and the Web.

Web publishing for everyone

With better tools such as Site Server 3.0, employees won't have to possess as much technical knowledge in order to participate in their company's Web publishing process. But until more companies simplify their publishing processes, many individuals will still be prevented from contributing.

The other way to let employees publish information—forcing them to send every submission through a Webmaster—only creates bottlenecks. When every submission has to go through Web specialists, information can take days or weeks to make it onto the Web site. Still, this approach may be better than requiring employees to learn the technical skills to publish information themselves. In this age of specialization, employees shouldn't have to know HTML to get their information published.

Comments? Send us e-mail.


Server Scriptlets: Using Script to Create COM Components

John Swenson
MSDN Online

January 28, 1998

On January 28, Microsoft quietly previewed the beta release of a new component technology at the Web TechEd conference—reusable COM components written in script, called server scriptlets.

I've heard about scriptlets before. What's new here?

The Dynamic HTML scriptlets we introduced last year with Internet Explorer 4.0 are built from HTML and script, run on the client, and are primarily used for user interfaces. Server scriptlets are written in script, and don't use any Dynamic HTML or HTML.

In addition, they don't have a user interface, because they run on the server. Adding a user interface just slows down these small, efficient components.

What can you use server scriptlets for?

Lots of common scripting tasks, such as running middle-tier business logic, accessing and manipulating databases, and adding transaction processing to applications.

Developers can use server scriptlets anywhere they use COM, says Andrew Clinick, Microsoft's program manager for scripting technologies.

How do you build server scriptlets?

Developers can create server scriptlets by componentizing any of their script. They can pull script out of their Active Server Pages (ASP), for example, and package it into a server scriptlet, which can be reused over and over again.

What languages can you use?

Until now, developers have had to build their server-level COM components in Visual Basic, Visual C++, or Java, says Clinick, who introduced server scriptlets to several hundred developers at Web TechEd in Palm Springs, California.

Now, authors and developers who know script can create components using any scripting language that supports the Microsoft ActiveX Scripting interfaces. These include JScript, Visual Basic Scripting Edition (VBScript), PERLScript, PScript, and Python.

How do I get started with server scriptlets?

You can download the beta version of this technology on the server scriptlets page of the Microsoft Scripting Web site (http://www.microsoft.com/scripting/scriptlets/server/default.htm).

The download includes the server scriptlet run-time component, documentation, and examples. There's also a Scripting Wizard designed to simplify the process of creating either Dynamic HTML or server scriptlets.

The wizard asks you whether you want to create a Dynamic HTML or server scriptlet, and then walks you through a series of other steps. It creates a template that developers can use as a starting point to add their own script or Dynamic HTML. (Although the wizard simplifies the creation of Dynamic HTML scriptlets, you don't need to download anything to create Dynamic HTML scriptlets, which run in Internet Explorer 4.0.)

Can I debug the scriptlets?

You can debug your scriptlets with the Microsoft Script Debugger version 1.0, which is also available for download from the Microsoft scripting Web Site (http://www.microsoft.com/scripting/debugger/dbgdown40.htm). The next version of Visual InterDev will also work nicely as a scripting debugger, Clinick says. For information about Visual InterDev see the Microsoft Visual InterDev Web site at http://www.microsoft.com/vinterdev/. Microsoft introduced the upgrade to this professional Web-development tool at Web TechEd. It should enter beta testing in March.

What are the benefits of running server scriptlets?

Server scriptlets let you take advantage of the power of the server without having to write any new client code. By using remote scripting, you can even call server scriptlets without refreshing your Web page on the client. For more information on that technology, check the Microsoft Scripting Library at http://www.microsoft.com/scripting/docs/msl/msl.htm.

Also, since server scriptlets are full-fledged COM components, they can be "completely transactionally aware," Clinick says. "You can create server scriptlet components that work really well with Microsoft Transaction Server."

Are there any differences between using scriptlets and using other COM components?

After you have created a server scriptlet, you can use it in your applications. Using server scriptlets is similar to using other COM components, but there are small differences in how you register server scriptlets. Clinick demonstrated how easy it is to register a new server scriptlet, simply by right clicking on the component's icon and then choosing "register" from a drop-down menu.


XML: A Better Way to Move Data Across the Web

IMHO
January 21, 1998

John Swenson
MSDN Online

One of the hottest topics at Microsoft's Web TechEd conference in January was Extensible Markup Language (XML), a technology that many believe is destined to become the universal language for describing and transferring data on the Web. The last time we wrote about XML at MSDN Online in early December, we focused on how developers can tag documents with XML (see the article "XML: One Hot Abbreviation, but What Does It Mean?"). Once tagged, these documents are capable of describing themselves and the data they contain to Microsoft Internet Explorer 4.0 or another XML-enabled application.

It's a mistake to focus too heavily on XML's role as a document markup language, however—you could miss the technology's main benefit: XML's ability to describe and deliver data. "Everyone in the universe, it seems, regards XML as a way of marking up documents," explains Adam Denning, group program manager of Microsoft's XML team. "That is certainly useful . . . but we also believe in XML as data. In other words, as a way of moving data from one place to another."

A new data transfer mechanism

XML could become a universal technology for transferring data between applications, Denning predicts, just as Hypertext Markup Language (HTML) has become a universal technology for displaying information on the Web. "The key message we want to get across is that XML is to data what HTML is to display," he says. "XML is by no means a competitor to HTML."

Said another way, XML complements, not replaces, HTML. While HTML is all about defining how information is displayed, XML has nothing to do with display. XML is all about describing information. For example, an HTML tag might define the color or font size of a word, but it says nothing about the actual meaning of the word. An XML tag can describe the meaning of any word or term—identifying it as a person's name, a product name, date, or whatever. The descriptions can be as specific as a developer chooses to make them.

Users can even build their own XML vocabularies (hence the "Extensible" in XML). An automotive trade group, for example, could build a specialized XML vocabulary of automotive terms, and then tag its data with those terms. Microsoft is working with various industries to help them create their own XML vocabularies, Denning says.

After a set of data has been described with XML, Internet Explorer 4.0 can parse the information and display it as HTML. An XSL (Extensible Stylesheet Language) processor handles the translation to HTML. (Microsoft recently posted a technology preview version of the Microsoft XSL processor on the XML Web site at http://www.microsoft.com/xml/xsl/msxsl-f.htm.)

Pour on the XML

It's important to understand that XML data is handled completely apart from the user interface, says Tom Johnston, a group product manager at Microsoft. An easy way to visualize this is to think of pouring XML data into your HTML forms, he explains. The forms may change for different users, but they all access the same set of XML data, allowing users to process and display that data in many different ways.

Developers who want to create the most sophisticated and powerful Web applications should consider using XML in conjunction with Dynamic HTML, Johnston advises. Dynamic HTML provides a state-of-the-art technology to design the user interface of a Web application, while XML provides a state-of-the-art way to access data.

W3C standardizing XML

There are still technical challenges to be solved before XML is ready for everyone, Denning says, such as how to let users locate and use XML information published on the Web. Microsoft and other members of the World Wide Web Consortium (W3C) are working to develop solutions to these problems and implement them in the group's final XML specification. (The W3C issued an early proposed recommendation on December 8, 1997 for XML 1.0; see the W3C Web site at http://w3c.org/Press/XML-PR.)

Developers who want to learn more about XML can visit the Microsoft XML Web page (http://www.microsoft.com/xml/) or the W3C XML Web page (http://www.w3.org/XML/). Denning's team has created a downloadable demo of a Web site that uses XML to host an online auction, complete with live bids viewable by all the Web participants. There's also an extensive description of how Microsoft's developers built the XML demo.

Educate yourself on XML

Despite XML's newness, the technology is rapidly gathering momentum. "XML is big," Denning says. "Everyone's talking about it. There's so much to it, and so many ways it can be used." Because so many developers are interested in XML and yet so few really understand it yet, there's a big opportunity for XML education—books, seminars, and articles—to take off the way HTML education did, he says.

He encourages developers who want to get an early start with XML to take their existing information, whether stored in documents or databases, and begin to mark it up using XML tags. If you don't want to do this all by hand, consider using some of the first XML tools, which were announced at Internet World in December. (See the Microsoft Press Pass Web site http://www.microsoft.com/corpinfo/press/1997/Dec97/xmlmompr.htm for more information.)

More meaningful information

Although the XML specification is still not complete and there is a need for many more XML tools, developers have enough information to get started today with this new technology. As you do, think about XML as a way to move data around the Web, between different Web-enabled applications.

The ultimate promise of XML, Denning says, is that it will allow Web publishers to provide users with information they find more meaningful. Once the technology has matured and Web publishers have created rich sets of data described by XML, users will find it easier to extract the information they want.

Comments? Send us e-mail.


Windows CE Tools Are Flooding Forth

IMHO
January 16, 1998

John Swenson
MSDN Online

If you're a Windows developer who has yet to try creating software for Windows CE, you probably haven't kept up with all the news pouring out of Microsoft about this new platform. There's been a lot to follow in the past month and it's going to get even busier. Here's a summary of the news most likely to interest Windows developers.

The biggest news came in early January at the Consumer Electronics Show, when Microsoft unveiled the Palm-sized PC (http://www.microsoft.com/windowsce/palmpc/) and Auto PC (http://www.microsoft.com/windowsce/autopc/), and announced that 55 Independent Software Vendors (ISVs) are developing 260 applications for the three different types of PC Companion products (the Handheld PC [http://www.microsoft.com/windowsce/hpc/], Palm-sized PC, and Auto PC.)

New toolkits are on the way

If you're like most Windows developers, you're probably more interested in what tools are available for this new platform than you are in new hardware devices. To learn what's happening on the tools front, I talked to Randy Kath, group manager for Windows CE tools. The timing was good, since I learned that Kath's team has just completed three major new Windows CE toolkits and sent them to manufacturing (see the Microsoft Windows CE Web site at http://www.microsoft.com/windowsce/developer/ for more information, or check out the toolkit documentation in the MSDN Library, Tools and Technologies bin):

  • The first Microsoft Windows CE Toolkit for Visual Basic 5.0

  • A new, upgraded version of the Microsoft Windows CE Toolkit for Visual C++ 5.0

  • A new, upgraded version of the Microsoft Windows CE Embedded Toolkit for Visual C++ 5.0

All are add-ons to the full desktop version of the corresponding member of the Microsoft Visual Tools family. (A Microsoft Windows CE Toolkit for Visual J++ 1.1 is still under development and due out later this quarter.)

The Windows CE tools team isn't ready to divulge all the features in each of these new products, since the marketing folks want to save some surprises for the product launch. But the toolkits will be available for anyone to use in just a few weeks. Microsoft plans to launch the new Windows CE toolkits and provide full details at the Software Development '98 trade show (see the Software Development '98 Conference Expo Web site at http://www.sd98.com/) in San Francisco, February 10–12.

Visual Basic toolkit for the masses

The new Windows CE Toolkit for Visual Basic 5.0 should appeal to the largest number of Windows developers, Kath says. Now the legions of Visual Basic developers can use their knowledge of Visual Basic and Win32 to create new applications for Windows CE, with a minimum of learning required. The Visual Basic toolkit is able to shield developers from the complexities of the new platform, such as the dozen different processors that power various CE hardware products. (Developers who use the Windows CE Toolkits for Visual Basic or Visual J++ don't have to tailor their applications for different processors.)

Developers who want to dig into Windows CE a bit more deeply can use the Windows CE Toolkit for Visual C++. This toolkit lets them tackle more ambitious projects, such as creating ActiveX controls optimized for specific embedded CPUs or processors. (You can't build ActiveX controls for Windows CE using the Visual Basic toolkit, since that toolkit doesn't support compiling.)

Processors galore

It's Microsoft's job to support the growing family of CE processors and test CE applications, making sure they are able to run on every processor, Kath says. He goes on to say that Microsoft accepts this responsibility because it wants to minimize the amount of development CE developers must do for the different CE processor types.

As the CE platform expands, shielding application developers from the different processor types will become even more important. "We've got at least a dozen processors we now support. By the end of this year, it's likely to be about 30," Kath predicts.

Only a small number of these processors will be used in the PC Companion devices that most Windows CE developers are targeting. The other processors will go into a wide range of other embedded systems, showing up in everything from computerized VCRs to industrial washing machines. (See the article, "Windows CE for Washing Machines? Well, Not Yet.") These are of concern mainly to developers using the Windows CE Embedded Toolkit for Visual C++.

Technologies you already know

Windows CE allows Microsoft to reach out to a whole new base of developers, since the operating system is designed for embedded developers who don't come from the PC software world.

The biggest target for Windows CE, however, remains the estimated 4.6 million developers creating desktop and server Windows applications today. Microsoft is relying on them to create the bulk of the applications required to fill out the Windows CE platform and stimulate new hardware and software markets. To entice Windows developers to try Windows CE, Microsoft is offering them modified subsets of the tools and technologies they already know, such as Microsoft Win32, Visual Basic, and Visual C++.

"What we've really done is enable developers to start writing software beyond the desktop and still use Win32," Kath says. He and his team hope the new round of Windows CE toolkits due out this month will spark an explosion of new software for H/PCs, Palm-sized PCs, and Auto PCs. "I'd like to challenge developers," he says, "by asking them 'What kinds of new applications can you build?'"

Comments? Send us e-mail.


The Distinction Is Fading Between Windows Applications and Web Applications

IMHO
January 8, 1998

John Swenson
MSDN Online

Are you a Web developer or a Windows developer? Since you're visiting MSDN, chances are you develop Windows applications and probably consider yourself a Windows developer. But as the lines rapidly blur between Web applications and Windows applications, how much longer will you bother to make such a distinction?

It's still possible to classify most Microsoft developers into one of these camps, although it's easy to see the distinction between Web developers and Windows developers disappearing almost completely over the next year or two.

Everyone who follows the software industry knows the Web is having a major impact on applications development. But the extent to which Web standards are about to affect Windows applications is greater than many developers realize. I'm surprised at what I've seen here at Microsoft.

The decision to completely integrate Microsoft Internet Explorer with Windows gets the most attention in the press. But in the three months since I joined MSDN, I've discovered how hard Microsoft is working to integrate Web technologies across its entire line of applications and development tools. The work extends far beyond Internet Explorer. Much of it is taking place on a core technology level, with Microsoft helping the World Wide Web Consortium (W3C) and other standards groups develop the basic technologies for creating Web-enabled applications.

Web standards leading the way

This extent to which Windows development is merging with Web development hit me while I was researching articles on Microsoft Office, Hypertext Markup Language (HTML), and Extensible Markup Language (XML). HTML and XML—a hot new Web technology that complements HTML—are both Web standards under the guidance of the W3C. The fact that Microsoft will make these Web technologies a cornerstone of Office—the company's most important set of applications—says a lot about the growing importance of Web standards in Windows applications.

Microsoft recently announced that it plans to elevate HTML to a standard file format for the next version of Office. This will essentially turn Office into a giant tool for creating Web content. What is the proprietary technology that will allow Microsoft to make this radical change? There is none. Thanks to some clever use of standard XML and HTML, Office users will be able to automatically save all of their Microsoft Excel, Word, PowerPoint, and other Office documents as HTML, without sacrificing any document formatting. (Office 97 users can save documents as HTML today, but those HTML files can't preserve all of the rich formatting in native Office 97 files, such as Excel pivot tables or Office Art.)

Windows + Web = Weblications

Office is just the beginning of this trend toward thoroughly Web-enabled applications, or so-called "weblications." Some of the newest Microsoft applications, such as Microsoft Money 98, have user interfaces constructed almost entirely from HTML. These applications look and feel like Web sites, using hyperlinks in place of some pull-down menus, for example. To push this trend further, there's even a new weblications team within Microsoft (headed by general manager Adam Bosworth, one of the company's XML experts).

What struck me the most about Windows applications becoming Web applications was not so much Money 98, the next version of Office, or even the creation of a weblications team within Microsoft. The realization came from observing which developer technologies Microsoft is working the hardest to promote. If you've paid attention to the company's message in recent months, you've probably noticed that Microsoft is putting a lot of effort into evangelizing Web technologies backed by the W3C and other Internet standards groups.

HTML 4.0, Dynamic HTML, XML, Extensible Style Language (XSL), Cascading Style Sheets (CSS), and other Web standards or soon-to-be Web standards are all central to Microsoft's plan to make Windows and Internet Explorer the best computing platform for the Web. If you've visited the MSDN Web site (http://www.microsoft.com/msdn/) or Microsoft Site Builder Network (http://www.microsoft.com/sitebuilder/) recently, you may have noticed that we're spending as much time writing about these new Web technologies as about Microsoft's own products and technologies.

Weblications everywhere

Most Windows developers probably underestimate how deeply Microsoft is planning to integrate Web standards into future Windows applications. Based on what I've seen and heard since joining Microsoft three months ago, the company is moving toward a world of weblications that will replace today's desktop Windows applications.

Weblications will create many changes, such as reducing the need to focus on documents and file locations, thereby freeing users to think more about the information they are viewing or authoring. Weblications also promise to eliminate today's concept of applications, by letting users perform tasks without consciously launching an application tailored to each task.

Windows applications will become more Web-enabled and Web-centric than Money 98 and the next version of Office. As more of these Web applications appear, prepare to start hearing the term weblication all the time. And prepare to start seeing a lot of Windows applications that use HTML, Dynamic HTML, and a host of other Web technologies.

As 1998 unfolds, MSDN will bring you lots more information on the tools and technologies for building applications that blend the networked capabilities of the Web with traditional desktop Windows applications.

To prepare for this emerging world of weblications, start by eliminating from your thinking any distinctions you may believe exist between Web applications and Windows applications, or between Web developers and Windows developers. In a world full of weblications, every Windows developer eventually will be a Web developer.

Comments? Send us e-mail.


It's Not Just a .doc and .xls World Anymore

IMHO
December 18, 1997

John Swenson
MSDN Online

With all the announcements Microsoft makes these days, it's easy for important news to slip by without notice. It would have been easy, for example, to miss the relatively quiet December 15 announcement that the next version of Office will feature HTML as a companion file format to Microsoft's proprietary Office file formats.

When I read the December 15, 1997 Microsoft press release, "Microsoft Office Breaks Ground by Adopting HTML Standard as File Format," (http://www.microsoft.com/corpinfo/press/1997/Dec97/htmlpr.htm) on this, I did a double take. You mean after all these years of working with Word documents, Excel spreadsheets, and other Office file formats, Microsoft is suddenly going to let millions of Office users start working with a single, standard .htm Web file format? Wow.

Reading further, I saw that the next version of Office will continue to let users open, save, and create .doc files, .xls files, .ppt files, and other native Office file formats. But Office users who want to switch to a native Web format will be able to work with all their Office documents as .htm files, or convert any native Office file to HTML.

But can't you already make this HTML conversion in Office 97, I wondered, simply by choosing Save as HTML . . . in the File menu of each Office application? The press release was short on details, so I called Andrew Dixon, a product manager on the Office team.

Separate but equal

"The best way to describe this is that we're elevating HTML to the same level as our own proprietary Office file formats," Dixon explained.

This improved HTML support in Office will enable seamless "round-tripping" between HTML file formats and native Office file formats. In other words, users will be able to switch their Office documents back and forth between HTML and native Office file formats at any time, without losing any formatting.

Office users will be able to save a Word document in HTML, for example, and open it back up in Word (or a browser) while preserving all important data such as PivotTable dynamic views and complex charts and tables. Even long documents filled with editing marks and Word Art will look exactly the same whether they're saved as Word documents or HTML files.

The same goes for documents created in any Office application, including Excel, PowerPoint, Access, and Outlook. Excel users will be able to switch their Excel spreadsheets to HTML, for example, and still preserve their Excel pivot tables.

Today when users save Office documents in HTML, they look very similar to the way they appear in the Office file formats, but not identical. In the future, such documents will look identical. This means anyone using a Web browser on any platform will be able to open Office documents and see them exactly as they should look, even if they don't have Office installed on their PC.

How'd they do that?

This seamless back-and-forth switching between file formats is possible because some clever developers on the Office team figured out how to save Office documents in HTML without losing any of the rich document formatting possible with Excel, Word, or the other Office applications.

Microsoft couldn't accomplish this file-format conversion trick by using straight HTML though. The next version of Office will also rely on XML (Extensible Markup Language) to preserve richly formatted Office documents in the .htm format.

In case you're unfamiliar with XML, this is the new Web technology that made a big splash at the December Internet World 1997 trade show in New York City. See the "XML: One Hot Abbreviation, but What Does It Mean?" article I wrote on the topic for more information.

XML complements, not replaces, HTML. It provides a standard format to describe different types of data, so that the information can be decoded, manipulated, and displayed consistently and correctly. Like HTML, XML is an industry standard, or at least in the process of becoming one. (Microsoft is working closely with the W3C to develop the XML 1.0 specification, which is now in the "proposed recommendation" stage.)

Rather than get bogged down in a technical explanation of how Office will use XML, I'll stick to the topic of the file-format change.

The decision to make HTML a companion file format to the native Office file formats was "an incredibly important design decision for the next version of Office," Dixon says.

The chief reason for making this big file-format switch is—you guessed it—the rising importance of the Web. Letting Office users save their documents as HTML will make it a snap for companies and other organizations to post documents on their intranet and Internet Web sites. If Office users save their original documents as HTML files, there won't even be any conversion process. Documents will be able to go straight onto the Web.

Making HTML a standard Office file format also promises to eliminate the file-exchange headache for organizations trying to share their documents with the outside world. Users will be able to send Office documents via e-mail and know the person at the other end of the line can open the documents with all their formatting intact.

The developer opportunity

So what is this file-format change likely to mean for developers? A lot. Since HTML and XML are industry-standard file formats, the next version of Office should open the door to all sorts of new third-party and custom applications, Dixon says. Any application that supports HTML will be able to open Office documents and edit them, allowing developers to create new applications linked to Office. "That opens all kinds of doors," Dixon says.

It's still too early to discuss what the new opportunities might be for third-party developers, he says. (Microsoft isn't talking release dates yet for the next version of Office, in case you were wondering.) But forward-thinking developers can use their imaginations and start thinking now about how their applications might be able to take advantage of an Office that uses HTML as a standard file format.

With the rapid rise of the Web, it's inevitable the Office team would tie the suite even more tightly to HTML. But until now, who would have predicted they'd find a way to create Word, Excel, PowerPoint, and Access documents in HTML—without sacrificing any formatting?

Comments? Send us e-mail.


XML: One Hot Abbreviation, but What Does It Mean?

IMHO
December 12, 1997

John Swenson
MSDN Online

Even if you're an experienced software developer, important new technologies always come along that you know nothing about. Such seems to be the case with XML, which garnered a lot of attention at this fall's Internet World 97 because of its newness. Based on many of the questions XML vendors were asked at their Internet World booths, few of the 50,000-plus people attending Internet World had a clue about what XML (eXtensible Markup Language) actually does.

"They don't understand it," said Denise Graves, an account manager staffing the Internet World booth for ArborText, a Michigan software company that is one of the first vendors to offer an XML tool. "I've had lots of people come up to me and say 'I know I need to learn XML, I know it's next thing for the Web, can you tell me about it?'" Many people incorrectly assume XML is a replacement for HTML, and don't understand that XML actually complements HTML, she says.

It's still early

If you're among those who don't know XML from HTML, don't worry. The W3C is still working on the first XML specification, so there's still time to get up to speed on this new technology before it arrives in full force. Microsoft is touting the fact that Internet Explorer 4.0 is the first browser to support XML, but even Microsoft product managers admit there really isn't any XML on the Web yet. Just wait, they promise, and you'll see how important XML will become.

Unless you already know what a parser does and understand acronyms such as DTD (Document Type Definition), XSL (Extensible Style Language), and RDF (Resource Description Format), you have some learning to do. The best place to start is probably the W3C Web Site's XML page (http://www.w3.org/XML/). Two days before the start of Internet World, the W3C kick-started XML by releasing the initial proposal for the XML 1.0 specification. Developers who are serious about learning XML should read through the proposed specification (http://www.w3.org/TR/PR-xml-971208/), one Microsoft XML expert advised.

In search of XML

I spent most of my second day at Internet World talking to people about XML. Everyone seemed to explain it in a different way, and most recommended seeing a demo to help understand what XML can do. You may have trouble catching a demo, but you can point your browser to the new Extensible Markup Language (XML) pages of the Microsoft Site Builder Network Web site (http://www.microsoft.com/xml/). There's an XML demo (http://www.microsoft.com/workshop/author/xml/parser/) on the site you can download, and lots of information about XML. Be sure to also take a look at "Frequently Asked Questions About Extensible Markup Language (XML)" document, available on the MSDN Library.

Here's how Microsoft defines XML:

A simplified subset of the Standard Generalized Markup Language (SGML) specifically designed for Web applications. XML provides a standard format to describe different types of data—for example, an appointment record, a purchase order, a database record—so that the information can be decoded, manipulated, and displayed consistently and correctly. XML provides a file format for representing data, a schema for describing data structure, and a mechanism for extending and annotating HTML with semantic information.

Don't be confused

Okay, so what does that really mean? It's really not so complicated, said Adam Bosworth, Microsoft's chief XML expert. "It's simple—XML is just an unlimited set of tags. It's like HTML, but XML lets you build your own tags," he says.

Another good explanation came from Rick Shaw, a senior systems engineer at Poet Software, one of several companies shipping the first XML tools. "XML allows self-describing documents," he told me during a stop at Poet's booth in the Microsoft Partners Pavilion. "If you look the tags in HTML, they're really just formatting tags. They don't really say anything about what's in the text. An HTML tag would just say 'this is bold' or 'this is blue.'"

XML tags go much further than HTML by letting you define the actual content within a set of tags. For example, an XML tag might define a word or series of words as the name of a person (<person>Rick Shaw</person>) or technology (<technology>XML</technology>). If you had a long document or series of documents you wanted to search for names, you could easily pull out all of them. With straight HTML you couldn't do that, since the search engine would have no way to know which words represented names. If you searched for "name" in HTML, you'd just find every instance of the word "name."

What XML can do

When a document is fully tagged with XML, you can do amazing things with it, said Kari Johnson of Chrystal Software, a Xerox spin-off and one of the other XML tools vendors in the Microsoft Partners Pavilion. XML lets you view a document in whatever form you want to see it, rearranging its structure on the fly, or just pulling out sections that contain the information you're looking for. You can break a document into as many fragments of text as you want and tag them all, she said. In an extreme case, you could apply an XML tag to every word, although that probably wouldn't make sense. You can even define your own new XML tags, allowing for infinite tagging possibilities.

XML is not just another nifty new technology in search of a market, Johnson said. Although most Internet World attendees who stopped by the Chrystal Software booth didn't understand XML, they did understand the problems it can solve, she said. "That's a good sign, because it means not only is this a good technology, but there's also a market behind XML, a need for this," she said.

Large companies will be among the first to use XML, Johnson predicts, since it can help them catalog, search, and retrieve information from their vast stores of documents. Because XML is extensible, it can describe data contained in a wide variety of applications, from entire collections of Web pages to individual database records.

Microsoft is betting most people will want to display XML information in a Web browser. That's why the company is building support for XML into Internet Explorer, and in the future plans to add it to other Microsoft products as well. To push XML along, Microsoft is working closely with the W3C to develop the XML 1.0 specification.

A lot more to come

Since XML is just getting started, we'll be sure to give you a lot more information on MSDN Online as this new technology develops. Be sure to check the XML pages of the Microsoft Site Builder Network Web site (http://www.microsoft.com/xml/) too. In the meantime, think how much better off your users would be if you could give them a better way to organize, search, and view information in your applications.

Comments? Send us e-mail.


Ease Your Work with Cascading Style Sheets

IMHO
December 8, 1997

John Swenson
MSDN Online

If you haven't taken a look at cascading style sheets (CSS) since Internet Explorer 3.0, it's time to reexamine this technology, which has improved with Internet Explorer 4.0. The new CSS support in Internet Explorer 4.0 allows developers even more control over the design and appearance of their Web sites and Web applications.

Internet Explorer 3.0 was Microsoft's first browser to support CSS. Internet Explorer 4.0 goes beyond the World Wide Web Consortium's (W3C) original CSS Level 1 specification by supporting new features proposed in the working draft for CSS Level 2. As one developer put it: "Same story, except now you can do a lot more cool things."

In a nutshell, CSS improvements in Internet Explorer 4.0 make it easier to print Web pages and position elements more precisely on the page.

But does it matter?

Rather than delve into the technical details of CSS in this column, I asked one of Microsoft's CSS experts to explain to Web applications developers why they should care about CSS. (If you're looking for technical details about CSS, see the links at the bottom of this column. Plenty of CSS information is available on the Web from the W3C, Microsoft, and other reliable sources.)

With Dynamic HTML bursting onto the scene this year and gaining a large following among Web application developers trying to make their sites look better, some developers might wonder if CSS even matters anymore. CSS does matter, explains Scott Isaacs, a lead program manager on the Internet Explorer team, because it is one of the technologies that make up Dynamic HTML. (Other parts of Dynamic HTML are HTML 4.0, data binding, and the Document Object Model.)

"Dynamic HTML covers all our client-side standards in Internet Explorer 4.0, including CSS," explains Isaacs, the author of Inside Dynamic HTML, a new book from Microsoft Press. He's worked with the W3C on CSS and other specifications that fall under the Dynamic HTML umbrella.

Separation is the key

CSS is important because it allows developers to separate content from the way that content is presented in a Web site, Isaacs says. The W3C endorsed this separation long ago. By separating presentation from content, developers can save time by making it much easier to update their content. CSS can automatically format all that content so it is displayed properly.

With CSS, it's a lot less work to update a huge Web site or Web application site. "You can define the look of your entire Web site with one file," Isaacs says. CSS lets you describe the attributes of any element on a page, including fonts, indentation, colors, alignment, and spacing.

In this day of political battles over software standards, CSS is refreshing because it's a straightforward and noncontroversial technology. CSS is simply about making your pages look better, and saving developers work, Isaacs says.

The bottom line is that CSS decreases site maintenance work. Whether you just write Web applications for a site or maintain the site yourself, that's an undeniable benefit. "If you have 500 Web pages and you want to change the background color all of on them, you can either change it once (in CSS) or you can change it on 500 pages," Isaacs says. If talk of Style Sheets makes your eye start to glaze over, just think about all the work style sheets can save you in terms of designing and maintaining a Web site.

Here today, here tomorrow

If you're going to be doing any sort of Web development in the future, it makes sense to learn about CSS, Isaacs adds. Your knowledge of CSS won't become obsolete any time soon, since the W3C has declared that all future presentation extensions are going to be done through CSS, not new HTML tags. There will be more HTML tags added in future, but they'll be context tags, not content tags. These tags will do more than just make a page look different—they'll add meaning to the tags themselves.

CSS is designed to degrade gracefully, which means if a browser doesn't recognize a Style Sheet or Style Sheet attribute, the browser will simply ignore it. No error will occur.

There are tools that let you add CSS to your Web pages without hand coding. As a somewhat loyal Microsoft employee, I have to mention FrontPage 98. Microsoft's new Web-authoring tool has a style button (in the page properties dialog box) that opens a Style dialog box. The Style box lets you assign CSS attributes to any page element, simply by entering page-design information in the dialog box.

A lot of developers write their style sheets in Notepad, but new Web tools are making it easier and more intuitive to author CSS according to Isaacs.

CSS is programmable

Once developers learn the basics of CSS, they can keep going. The Document Object Model (DOM) in Internet Explorer 4.0 makes CSS programmable as an object, Isaacs says, just as it makes HTML programmable in the same way. This programmability is what makes Dynamic HTML dynamic, allowing developers to create Web pages that automatically change and tailor themselves to the user.

As more developers learn to add Dynamic HTML to their Web applications, expect to hear much more about CSS. This component of Dynamic HTML should grow in popularity as Web sites grow ever larger, more sophisticated, and more difficult to maintain.

For more information

For technical details on CSS, the W3C Web site (http://www.w3.org/Style/) has information on CSS Level 1 and Level 2 specifications. Microsoft Site Builder Network columnist Nadja Vol Ochs also has written extensively on CSS (see http://microsoft.com/sitebuilder/columnists/default.asp for appropriate links). Finally, Scott Isaacs has a section devoted to CSS coding on his Inside Dynamic HTML Web site (http://www.insidedhtml.com/css/tutor.htm).

Comments? Send us e-mail.


Internet Explorer: Surfing's Only the Beginning

IMHO
December 4, 1997

John Swenson
MSDN Online

If you're like most PC users, you probably think of Internet Explorer as an application for surfing the Web and viewing Web sites, not as a platform for running other applications. But an applications platform is exactly what Internet Explorer is becoming, in more ways than one.

As Web sites mature, many are providing their content through Web applications. Take a look at sites such as Amazon.com (the online bookstore) or Microsoft Expedia (Microsoft's travel site). To say sites like these simply display content is a gross understatement. They let visitors tap into vast databases using sophisticated Web applications. Web sites like these are blurring the distinction between Web content and Web applications.

Web applications that require both a Web server and a Web client are the most obvious kinds of applications that run on Internet Explorer. But there's another kind of application extending Internet Explorer's role as an applications platform.

Incognito Browser

A new breed of standalone Windows applications rely on an integrated version of Internet Explorer to display the user interface and content in HTML, while using Windows for other tasks. You might not even realize you're using Internet Explorer when you fire up one of these applications since you usually can't spot the Web browser in them. You won't see any telltale browser signs, either, such as forward or back arrows. Some of the indications that you're in a Windows application might also be missing, such as dialog boxes and pull-down menus.

There are already dozens of these hybrid Windows applications on the market that use integrated components of Internet Explorer. Examples include the latest version of the Lotus Notes client, Quicken 98, and Microsoft Money 98. All use the HTML control in Internet Explorer 4.0 to display HTML content inside the application.

Game developers are helping to lead the way toward Internet Explorer integration. Many have created games for Windows 95 that use Internet Explorer as a component to enable online gaming, or to call up Web sites where users can download patches and add-ons.

A Web Interface on a Windows Application

The first time I saw Money 98 demonstrated several months ago, I immediately noticed something different about the application, but it took me awhile to figure out what was different. All of the screens in Money 98 look like Web pages and the program lacks the pull-down menus typical of a Windows application. But without the forward and back arrows, Favorites list, and other features of a browser, I didn't realize I was seeing an integrated version of Internet Explorer.

Clicking on application buttons in Money 98 is like clicking on a hyperlink. Instead of pulling down a menu, the buttons usually jump you to another screen. That's because most of Money 98's user interface is built with HTML. The application's rich interface is possible thanks to its integrated Internet Explorer components.

The latest trend

Developers who want to create applications that take advantage of the Web and the rich display capabilities of HTML and Dynamic HTML should try integrating Internet Explorer into their Windows applications, says Hadi Partovi, a group program manager on the Internet Explorer team. At Microsoft, "We're definitely moving more toward using more HTML for the user interface," says Partovi, whose job is to make Internet Explorer a better platform for running applications.

If you integrate Internet Explorer into your application, Microsoft can save you the work of tracking the ever-changing standards of the Web, Partovi says. "If HTML changes, you won't need to worry about changing your application. We'll update it for you by updating the HTML component. You won't need to track the HTML standard for every new tag," he explains.

Since the HTML component in Internet Explorer 4.0 supports advanced capabilities such as Dynamic HTML, Microsoft's browser lets developers display richer content and a richer interface for their Windows applications than HTML alone would allow.

Adding New Features

Internet Explorer also lets developers add new features to their applications, such as the ability to link users directly to a Web site. The HTML component in Internet Explorer lets you display a Web site inside your application, rather than forcing users out to a separate Web browser.

So what happens if you create an application that uses Internet Explorer, but all your customers don't have Internet Explorer installed on their PCs? That's not a problem, Partovi says, since Microsoft allows developers to freely distribute Internet Explorer as an integrated part of their applications.

One hidden benefit to integrating Internet Explorer 4.0 is that it's a way to ensure your users have the latest Web technology on their PCs. When a user installs an application that includes Internet Explorer 4.0, it upgrades the common controls installed with Windows 95 or Windows NT 4.0. With the new controls in Internet Explorer 4.0, you can add new visual effects to your application, such as the sliding directory trees.

A dash of Internet Explorer

The Web isn't the only force pushing Internet Explorer into its growing role as an application platform. There are also an increasing number of Windows applications that use the HTML component and other technologies provided by Internet Explorer. As more of these applications filter onto the market, even Windows developers who never imagined their stand-alone applications running inside a Web browser may soon discover reasons to add a dash of Internet Explorer to their software.

For More Information

For technical details on how to use the services and technologies of Internet Explorer 4.0 in your applications, visit the Microsoft Internet Tools & Technologies Web site (http://www.microsoft.com/msdn/sdk/inetsdk/help/itt/internet.htm). Web developers might also want to look at Microsoft's Internet Client SDK Web site (http://www.microsoft.com/msdn/sdk/inetsdk/help/default.htm).

Comments? Please send us e-mail.


ECMAScript and JScript: Two of a Kind

John Swenson
MSDN Online

November 19, 1997

I stayed home from the madness of COMDEX this week for the first time since 1990. With MSDN Online editor Norvin Leach covering all the speeches, presentations, and parties in Vegas, I'm free to roam the halls of Microsoft and write about exciting topics such as . . . scripting!

Scripting isn't a topic you're likely to hear much about at COMDEX, where most of the attention is focused on flashy products that are able to grab attention on the noisy, crowded show floor. Microsoft has an important story to tell about its scripting technology, however. The story has to do with standards, and how Microsoft came to support a strange-sounding specification called ECMAScript-262.

Because of the odd name, and because Microsoft and Netscape each offer their own scripting languages similar to ECMAScript, developers face a confusing picture of which scripting language to use in their Web applications.

A new standard

ECMAScript is important because it's the Web's only standard scripting language. The committee that developed it this year was comprised of scripting experts from Microsoft, Netscape, IBM, Sun Microsystems, Borland International, and other software companies. The group started work on the specification in January 1997 and managed to get the final version completed and ratified just 10 months later, in October. Microsoft's representative on the ECMAScript committee, Andrew Clinick, says it's surprising that the group was able to complete its work so quickly considering the many differences between the member companies.

"Initially it was tough," he says. "You'd think Microsoft and Netscape wouldn't talk to each other. But despite the marketing rhetoric, Microsoft and Netscape did work together quite well on this. Once the marketing people left, some real work got done." The technical people on the committee realized that their most important goal should be to create the best scripting language they could all agree on, not bicker over marketing differences, explains Clinick, who in addition to his committee duties is program manager for the Microsoft Scripting team.

The committee began its work because of the need to create a standard scripting language for the Web, one that could replace JavaScript, a proprietary language owned by Netscape. (JavaScript doesn't actually have anything to do with Java, but that's another story.) The committee started out basing their specification on JavaScript, but ended up basing it more on Microsoft JScript, Clinick says.

With the ECMAScript specification now finished, Microsoft suggests that developers view ECMAScript as the successor to JavaScript. "In essence, you can think of ECMAScript as JavaScript 1.1 with all its problems fixed. The core language hasn't really changed," Clinick says.

The ECMAScript-262 specification is available on the Web at http://www.ecma.ch/stand/ecma-262.htm. Microsoft fully supports the specification through JScript 3.0, the scripting engine built into Microsoft Internet Explorer version 4.0, Internet Information Server version 4.0, and eventually other Microsoft products. Details about JScript and Microsoft's other scripting technologies are available on the Microsoft Scripting Web site (http://www.microsoft.com/scripting/).

Netscape goes its own way

Microsoft hopes Netscape eventually will follow through with its pledge to support ECMAScript, rather than continue to go its own way with JavaScript. The new version 1.2 of JavaScript that Netscape put in Netscape Navigator version 4.0 contains extra scripting features that aren't supported in ECMAScript.

Microsoft matched those new features in JScript 3.0 and added some of its own, such as COM support. But despite the enhancements to Microsoft's own scripting language, JScript 3.0 maintains full compatibility with the base ECMAScript specification, unlike JavaScript 1.2, Clinick says. Microsoft has promised to submit all its JScript 3.0 additions to the ECMAScript committee, for inclusion in the next version of the ECMAScript specification.

With JScript 3.0, Microsoft now has a scripting language that works on both the server and client side, is 100 percent compatible with the ECMAScript standard, and matches all the new features in the latest version of Netscape's proprietary scripting language, which works only in Netscape Navigator.

One difference to remember

Developers who want to add scripting to their Web applications don't have to understand all the differences between ECMAScript, Microsoft JScript, and Netscape JavaScript. The one important difference to remember, Clinick says, is that Microsoft JScript fully complies with the new ECMAScript standard, while Netscape JavaScript does not.

There's also no need to understand how a strange name like ECMAScript came to be, but in case you're curious, here's the answer. At Netscape's request, the committee formed to create the standard did so under the auspices of ECMA, a European-based standards group previously named the European Computer Manufacturers Association. (The association now goes just by its initials.) Since Netscape retains the rights to the JavaScript name, the group had to call its scripting standard something else.

The committee slapped the ECMA name on its project as a temporary solution. "The reason we came up with the ECMAScript name is it's the worst one we could all think of," Clinick recalls. "We knew we'd be compelled to go change it afterward."

But committee members couldn't unanimously agree on a better name later and were stuck with ECMAScript. That name is unlikely to change as the committee develops the second version of the ECMAScript specification, due out sometime next year.

Substance, not flash

So there's the brief history of ECMAScript and how it relates to Microsoft JScript. Expect to hear Microsoft get more vocal about its scripting technology in the months to come, with more news due around the time of Internet World (December 10–12 in New York City.)

In the meantime, as you read the hundreds of Comdex stories coming from the small army of reporters gathered in Las Vegas this week, remember: The most important news isn't always flashy.

Comments? Please send us e-mail.


A Visual FoxPro Manifesto

John Swenson
MSDN Online

Let's face it, FoxPro hasn't always received the attention it deserves around Microsoft. There was a time when the database management system didn't appear in many Microsoft ads, rumors circulated that Microsoft was about to abandon the product, and FoxPro fans even felt compelled to lobby the company to upgrade its own product.

I have to admit, I helped stir up some of this anxiety. In my former career as an InformationWeek reporter, I cowrote a story in the magazine a couple of years ago that said Microsoft was planning to let FoxPro die a quiet death.

I'm here to tell you now that this is old news. Microsoft is preparing an upgrade (code-named Tahoe) to Visual FoxPro 5.0 due out next year with the next version of the Microsoft Visual Studio tools suite. The company issued a strategy background paper this week (November 12, 1997) on the Visual FoxPro Web site (http://www.microsoft.com/vfoxpro/)that lays out the future of Visual FoxPro for the 500,000 developers (by Microsoft's estimate) who use the FoxPro system of developing powerful database applications. In just eight pages, this Visual FoxPro manifesto spells out Microsoft's plans for future versions of the product, describes its role in Microsoft's overall tools strategy, and explains why Microsoft plans to continue upgrading and improving Visual FoxPro.

Multitier Windows DNA applications

The new background paper tells FoxPro developers how they can use Visual FoxPro 5.0 to create "modern, scaleable, multitier business applications that can be delivered over any network." In other words, it explains how Visual FoxPro can create applications as sophisticated as anything built with Microsoft's other tools. "What this really boils down to," says Visual FoxPro product manager Robert Green, "is that Windows DNA is not just for Visual Basic and Visual C++ guys. It's also for FoxPro developers."

Windows DNA, or Windows Distributed interNet Architecture (see the related article, Windows DNA: Not Just Another Pretty Marketing Term) is the centerpiece of Microsoft's plan for developing distributed applications. Developers who follow the Windows DNA architecture have a road map for building distributed applications that integrate the new model of Web computing with the traditional client-server model. The architecture defines how dozens of different Microsoft products and technologies fit together to create multitier, distributed Windows DNA applications.

Visual FoxPro 5.0 is one of several tools that let developers create such applications. It fully supports Windows DNA and therefore can create any tier of a Windows DNA application. Developers can use Visual FoxPro to write middle-tier components, store data in another tier, and supply user-interface elements such as forms in a third tier.

The Tahoe version of Visual FoxPro will add even more support for building multitier client-server and Web-based applications. It will do this by adding features such as support for Microsoft Transaction Server and the ability to create forms that can run in a Web browser.

No need to switch tools

So why is Microsoft publishing its Visual FoxPro strategy paper today, a year after it released Visual FoxPro 5.0? Mainly because Microsoft recently announced its Windows DNA architecture and the company wants developers to know how Visual FoxPro fits into that framework. Also, "We still get questions about the future of the product and about our commitment to it," Green says. "We have an answer that works and we want to do a better job of telling everyone."

There was a time when some Microsoft managers didn't want the company throwing much support behind FoxPro. Today, Microsoft rejects any notion that FoxPro developers should switch to Visual Basic or another Microsoft tool, Green insists. Top management agrees that "The thing that's most important is to let Visual FoxPro developers use their existing investments and not throw everything away. Code doesn't die." There's no need for developers to replace Visual FoxPro with another language when Visual FoxPro can get the job done, he says.

Many longtime FoxPro developers will start building more sophisticated applications when they try Visual FoxPro 5.0 and next year's Tahoe upgrade, Green predicts. That's because Visual FoxPro now supports modern object-oriented programming and component development. "The idea of building component-based applications is a new idea to a lot of developers, but especially to the FoxPro guys," he says. "Once they see the benefits of deploying information in these new ways, I think they'll be very interested."

FoxPro suite FoxPro

Microsoft won't push FoxPro developers to switch tools, but it will try and persuade them to buy its tools suite. Most of today's developers need more than one tool, and FoxPro developers are no exception. For example, FoxPro developers who want to do some Web development might want to add Visual InterDev to their toolbox. Since buying Visual InterDev and Visual FoxPro separately costs about the same as the entire Visual Studio suite, Microsoft expects many Visual FoxPro users to buy the suite.

Microsoft will release the new version of Visual FoxPro at the same time as its other new visual tools next year. That means Visual FoxPro will gain equal billing in Visual Studio promotions, Green says. When Microsoft released Visual Studio 97 last spring, Visual FoxPro 5.0 received less promotion than the other tools because it was already six months old.

Microsoft hasn't announced a release date for the next version of Visual Studio or Visual FoxPro. However, it is expected in the first half of next year—and the next Visual FoxPro DevCon is scheduled for May, 1998, in Orlando, Florida, so draw your own conclusions and start making plans to attend.

In the meantime, rest assured that Visual FoxPro is here to stay, and that it is on par with Microsoft's other visual tools. If you see any reporters writing stories that suggest otherwise, tell them they're wrong.


ZAW, ZAK, and Zero Everywhere

John Swenson
MSDN Online

November 3, 1997

Okay, so maybe Microsoft should have named its attempt to lower the total cost of owning PCs the Nearly Zero Administration for Windows initiative. No one can eliminate all the work of administering client PCs on a network. Lift one mouse finger and you've done some work. But with Windows NT 5.0, Microsoft will try to come as close as it can to creating the network administrator's nirvana of requiring as little work as possible.

The Zero Administration for Windows (ZAW) initiative is about much more than just Windows NT 5.0, however, as I recently learned. ZAW refers to a broad set of technologies that cross many product boundaries inside and outside of Microsoft. The company created the term last year to refer to a host of technologies under development throughout Microsoft, all aimed at reducing the total cost of ownership (TCO) of PCs.

Some developers may wonder what exactly is in ZAW. To begin with, ZAW is not to be confused with ZAK, the Zero Administration for Windows Kits. If you're already familiar with the Zero Administration for Windows Kits for Windows 95 and Windows NT 4.0, these are a subset of the ZAW features coming in Windows NT 5.0 and, to a lesser extent, in Windows 98. Nor is ZAW totally contained within NT 5.0. "There has been some confusion, in the sense that people sometimes think ZAW and NT 5.0 are synonymous," says Clark Heindl, a ZAW product manager at Microsoft.

Getting started with ZAW

Because the ZAW initiative is so broad, some developers may be unclear about what it encompasses and what they can do to prepare their applications for ZAW. Trying to grasp everything Microsoft is doing to lower the total cost of managing and administering PCs is overkill if all you want to do is to learn how to make your own Windows applications less expensive for customers to own. If you just want to make your own applications easier to manage, examine the draft recommendations for Microsoft's proposed new Designed for Windows NT 5.0 and Windows 98 logo at the Microsoft Windows Family Web site (http://www.microsoft.com/windows/thirdparty/winlogo/enterprise/roadmap2.htm). Microsoft expects the "recommendations" in the proposed handbook eventually to become requirements, so it won't hurt to start implementing them now.

One of the recommendations soon to become a requirement is that applications qualifying for the new Windows logo must provide graphical installation, properly register all their components with the operating system, auto-detect the operating system onto which they're installing, and provide a default installation path to the Program Files directory.

The flip side of the new installation requirements is the new uninstallation requirements.

Applications must be capable of completely uninstalling themselves by means of an automated, registered uninstaller. This uninstaller must not remove core components or shared components necessary to other applications.

These are just two parts of the new logo recommendations. The Designed for Windows NT 5.0 and Windows 98 logo handbook also includes guidelines for using the forthcoming Microsoft IntelliMirror technologies for deploying and maintaining applications through the Windows NT 5.0 installation service. The handbook also explains how to create "clean" Windows applications that network administrators can centrally manage from a remote location.

Examining the new logo recommendations isn't the only way to prepare for ZAW. Developers who are interested in ZAW also should get a copy of Beta 2 of Windows NT 5.0 when it becomes available, Heindl advises. The next beta will include many ZAW features missing from Beta 1.

18 core features

When I started researching this column, I didn't realize ZAW encompassed so many technologies. Microsoft's Windows Administration team lists 18 "core" ZAW features due in Windows NT 5.0. These cover a range of technologies that will make it easier to install software and manage PCs, including:

  • User profiles that will contain all of the data and settings for each user on the network

  • Tools for remotely booting PCs, remotely installing applications, and even remotely installing the operating system itself

  • A framework for publishing applications and assigning them to users and PCs anywhere on the network

All that and more

ZAW will benefit users in other ways, such as allowing them to roam from PC to PC on a network (or plug in their laptop anywhere), and still have easy access to all their applications and individual desktop settings.

Microsoft is also adding ZAW technology to Systems Management Server (SMS), Internet Explorer, and even future versions of Office, among other products. PC manufacturers are participating in ZAW by building simplified, low-cost computers that meet the NetPC specifications co-developed by Microsoft and Intel.

Ready, set, go

Although many analysts "are being their typical skeptical selves" when it comes to predicting how successful ZAW will be at lowering TCO, the initiative "has created a lot of positive anticipation with customers," Heindl says.

Customers have demanded that Microsoft lower the cost of owning and managing Windows PCs. The company has responded over the past year by making ZAW a cross-product initiative that cuts across Microsoft's broad product line. Although the main pieces of ZAW aren't due until Windows NT 5.0 comes out next year, developers can start preparing today. By beginning now, developers will be ready when all the features of ZAW are finally in place.

Comments on this column? Send me mail.


Dynamic HTML and the Big Picture

John Swenson
MSDN Online

November 3, 1997

By now, most developers who follow Microsoft know we're pushing Dynamic HTML as the preferred way to create better, more interactive Web applications. Even if you have a strong understanding of Dynamic HTML and the tricks it can play in Microsoft Internet Explorer 4.0; you may wonder where this new technology fits into Microsoft's overall strategy for application development, and why we like it so much.

Windows DNA

The key to understanding where Dynamic HTML fits into the larger picture is in understanding our Windows Distributed interNet Architecture, or Windows DNA. This is the broad new term Microsoft now uses to refer to its attempt to blend application development for the Internet with the traditional desktop and client-server development models. "Whether you are building applications for the World Wide Web or the corporate network, the programming models, infrastructure services, and tools all leverage a common architecture," says Gary Voth, a group manager in Microsoft's platform marketing division.

Conceptually, Windows DNA is a framework that describes how to use the many technologies Microsoft is providing developers to help them build three-tier applications on the Windows platform. That platform is broader than many developers realize. "When we say 'Windows platform,' we're no longer talking about a desktop operating system," Voth explains. "We're talking about the whole fabric for building and delivering applications that can run anywhere on the network or Internet, not just on a single machine."

Top to bottom

Dynamic HTML is an important cross-platform component of the Windows DNA architecture because it extends the richness of HTML and yet still runs on many platforms. A key goal of Windows DNA is this interoperability with other platforms, allowing customers to use their existing hardware and software investments.

Developers are now creating modern distributed business applications with three tiers: a top tier for the client, a middle tier that separates out the business logic and processes, and a bottom storage tier. Windows DNA helps developers build applications for all three tiers.

Dynamic HTML fits into the top tier of the architecture, the client tier that contains the user interface and navigational elements of a distributed application. Dynamic HTML uses a combination of HTML and script to let developers build highly interactive front ends for their Web-enabled applications. Dynamic HTML is one of the quickest and easiest ways to build any user interface.

The middle tier in a distributed application could be a Web server, a transaction server, or some other server application. The bottom tier provides a model for accessing files, mail, and other data, no matter where it resides. This bottom-tier data could be stored on a network server, a mainframe, a UNIX server, or any computer.

Dynamic HTML works with the data on the bottom tier through a feature called data binding. Developers can use data binding to create data-driven business applications that take advantage of the Web. This feature lets users download data directly into their browser and manipulate it there (sorting a table, for example) without requiring any trips back to the server. Data binding allows users to send information back to the server, updating the database.

Ideal front end

Dynamic HTML is an ideal technology for the client portion of Windows DNA because it lets developers build a single front end for their distributed applications. A front end built with Dynamic HTML can run on Windows 95, Windows NT, Windows 3.1, Apple Macintosh, or UNIX. To use a client application built with Dynamic HTML, all users need is Internet Explorer 4.0, which will be available for all these operating systems.

Microsoft believes Dynamic HTML is important because it makes the Web a viable platform for developing applications that are truly interactive, cross-platform, and perform well. For developers used to building static Web pages and applications with plain-old HTML, "Dynamic HTML really produces a paradigm shift," says Michael Wallent, Microsoft's lead program manager for Dynamic HTML. "It really lets you build different applications."

You Want Fancy Effects?

Dynamic HTML lets developers add a host of user-interface features to their Web applications. These include collapsible outlines, numerous text effects, and the ability to resize and precisely position graphics. For examples of these effects, point your Internet Explorer 4.0 browser to our Dynamic HTML Gallery (http://www.microsoft.com/gallery/files/html/), or see how Microsoft used Dynamic HTML to redesign the Microsoft home page (http://www.microsoft.com/). (Net surfers with older versions of Internet Explorer or other browsers can view this content, but won't see the Dynamic HTML effects.)

An evolving standard

Internet Explorer 4.0 is the best way today to view Web pages and applications built with Dynamic HTML, but Dynamic HTML is not an Internet Explorer–only technology. Dynamic HTML is an open technology based on the Document Object Model (DOM) now winding its way through the standards process at the World Wide Web Consortium (W3C). Microsoft is working closely on this with the W3C, and will comply with its DOM recommendations.

The DOM makes HTML and Cascading Style Sheets (CSS) programmable through script, or through any language for that matter. This comprehensive object model exposes all page elements as objects that can be manipulated easily, simply by changing their attributes or applying methods to them at any time. You can manipulate these objects with JScript, ECMAScript, VBScript, or any scripting language.

New tools arriving

If all this sounds complicated, don't be fooled. It's not. Dynamic HTML just requires the author to understand HTML and a scripting language. Even Web authors who have never written a line of code can add Dynamic HTML to their Web pages if they use Microsoft FrontPage 98 or one of several new third-party Web tools, such as Macromedia's new Dreamweaver. These automate the creation of Dynamic HTML. (For a detailed description of Dynamic HTML tools and other information, visit Microsoft's Dynamic HTML Web site [http://www.microsoft.com/gallery/files/html/].)

One reason Microsoft is pushing Dynamic HTML is because it works so well in Internet Explorer 4.0. We think developers can use Dynamic HTML to build the most interactive and engaging applications on the Web. And they won't be locked into any proprietary technology or platform, since Dynamic HTML runs on a variety of operating systems and is built on an open, standards-based technology. Other companies are free to build tools and browsers that support Dynamic HTML, without the need to license any technology from Microsoft. This is because Dynamic HTML is based on the W3C-standard DOM.

It Works with ActiveX, Too

Microsoft also likes Dynamic HTML because it complements ActiveX, another part of our Windows DNA architecture. (For an update on the status of ActiveX, see Norvin Leach's recent column, "Is ActiveX Dead?")

Developers can use Dynamic HTML from within an ActiveX control or on the same Web page as a control. Why would they want to use an ActiveX control instead of Dynamic HTML? Although Dynamic HTML is an ideal tool for building the user interface portion of a Web application, there are certain tasks that require an ActiveX control. Dynamic HTML can't access the many services that are part of the operating system, for example, such as printing.

Compatible and easy

As Microsoft continues to expand the features and capabilities of its Windows DNA architecture over the next couple of years, developers who use Dynamic HTML can rest assured that their client applications will be compatible with all three tiers of this framework. With Dynamic HTML, you can build a fully interactive, no-compromise front end to your distributed application, surpassing what is possible with HTML alone. And because Dynamic HTML is easier to create than Java applets or ActiveX controls, you'll have more time to figure out the other tiers of the Windows DNA architecture.


Windows DNA: Not Just Another Pretty Marketing Term

John Swenson
MSDN Online

October 27, 1997

When I heard that Microsoft was introducing yet another new term to describe yet another new architecture at its Professional Developers Conference in San Diego in September, I groaned. Not another complex new technology, I thought when I first heard about Windows DNA. But as I asked around Microsoft over the past month, I learned that Windows DNA actually is aimed at simplifying Microsoft's message to developers, and cutting through some of the complexity that already exists.

Windows DNA, or Windows Distributed interNet Application Architecture, doesn't describe just one product or technology. It is a framework that defines how at least a dozen different Microsoft products and even more technologies fit together. You don't need to learn them all to understand Windows DNA. (If you do want the details, see the Technologies section of our Windows DNA Web site [http://www.microsoft.com/sitebuilder/dna/default.asp].) Instead of just throwing all these products and technologies at developers and making them figure out what to do with it all, Windows DNA provides instructions.

A Software Roadmap

Windows DNA, at its core, is about integrating Web and client-server models of computing. If you plan to use the Web in any way to build distributed applications, the Windows DNA architecture can help you. Windows DNA describes how developers can take advantage of all the distributed application services, distributed infrastructure services, and common interfaces of the Windows platform, together with a lot of useful Web technologies.

If that sounds rather broad, you're right. "Windows DNA is really a conceptual model, an architecture," explains Gary Voth, a group manager in Microsoft's Platform Marketing division. "In some ways, we're trying to paint a big picture for people. Although there are all these rapidly evolving technologies, Windows DNA tries to do a few simple things in your application: leverage HTML and scripting, build COM components, and take advantage of Windows system services."

Windows DNA is not just for developers, but also for development managers and strategic planners within large organizations. Microsoft wants to help these people who look at big architectural issues see where the Windows platform is headed. Windows DNA is like a map to help developers, technology planners, and IS managers avoid getting lost in the details of Microsoft's many operating systems, tools, technologies, and applications.

Pick your tier

Windows DNA maps out the framework for building scaleable, three-tier distributed applications that can run over any network, including the Web. Microsoft didn't invent modern three-tiered distributed applications, but it's making it easier for developers to build them. The many technologies under the Windows DNA umbrella can help developers create applications for all three tiers: navigation and user interface, business processes, and data storage. The user interface might be a Windows DNA client application that runs in a Web browser. The business process might be a Windows DNA application that runs on a Web server. Data storage could be handled by a Windows DNA application running on almost any type of computer, from PC server to mainframe.

Developers can use any language or tool to create all these applications, since Windows DNA is based on COM and open Internet standards. COM provides a language-independent object model that lets applications interoperate at all tiers of the architecture, while Internet standards ensure that many Windows DNA applications are cross platform.

Windows and the Web

Windows DNA is all about integrating the Web with client-server and desktop computing. Marketing people often overuse the term "next generation," but Windows DNA really does fit the term. It's a comprehensive architecture for building and deploying the next generation of Web-enabled, connected applications.

Notice I didn't say Windows applications. Not every application that conforms to the Windows DNA architecture has to be a Windows application, since the architecture also encompasses Web standards, not just Microsoft's own technologies. Some of the technologies in Windows DNA, such as Dynamic HTML, can even run on the Macintosh and UNIX platforms (through Internet Explorer 4.0).

Today and Tomorrow

So is Windows DNA an architecture for building applications today or a strategic roadmap for how to build them in the future? It's both. Windows DNA provides a unifying framework that describes how applications can take advantage of the integrated distributed services already built into Windows (such as transaction processing, security, and directory services). It also helps developers prepare for the many new services Microsoft will be delivering over the next couple of years.

To understand Windows DNA, don't make the same mistake I did of getting too caught up in trying to understand and define its many pieces. Just think big picture. Remember, if your application has anything to do with combining desktop or client-server computing with Internet standards, the Windows DNA architecture can help you plan which road to take.


Dynamic HTML: Converting the Java Faithful

John Swenson
MSDN Online

October 27, 1997

In the months leading up to the release of Internet Explorer 4.0, Microsoft began urging developers to create Web pages and applications using a combination of Dynamic HTML, HTML, and scripting. Such browser-based applications can match or surpass almost any interactive content you can build with a Java applet, the company promised.

Not surprisingly, some people reacted skeptically to this message, especially developers who believed the sales pitch that Java was becoming a platform. I watched Charles Fitzgerald, a program manager on Microsoft's Java team, tell a roomful of people at the Java Internet Business Expo in New York in late August that Dynamic HTML was a better cross-platform solution than Java. His comment triggered a round of snickers and smiles, as Java fans in the audience reacted with disbelief. As a member of the press at the time, I also remember being skeptical that Dynamic HTML could replace Java, in part because I still didn't understand all the things Dynamic HTML can do.

In retrospect, it's easy to understand why people initially were skeptical of Microsoft's message to skip Java and go directly to Dynamic HTML. This is such a new technology that many developers are just now beginning to understand it. And since Dynamic HTML and Java are such different technologies, comparing them can be awkward.

Some answers

Now that I'm working for Microsoft, I decided to ask around the company and learn exactly what Dynamic HTML can do. After talking with several Dynamic HTML and Java developers at Microsoft, I've rounded up the answers.

The biggest advantages of Dynamic HTML are not just that it can accomplish tricks a Java applet or ActiveX control can't match, but that it's much easier to use and more cross platform than those technologies. Creating Java applets and ActiveX controls requires full-fledged programming skills, while Dynamic HTML just requires the author to understand HTML and a scripting language. Microsoft estimates that there are over five times as many HTML authors as Java developers worldwide. So, there are many more content providers and developers with the skills to use Dynamic HTML rather than Java.

Microsoft created Dynamic HTML and decided to support it in Internet Explorer 4.0 because the company saw the need for an easier way to create really interactive and engaging Web pages and applications. "What we really wanted to do is make Dynamic HTML the easiest way to make your Web pages come alive" explains Michael Wallent, Microsoft's lead program manager for Dynamic HTML.

In addition to its ease of use, Dynamic HTML also is a better cross-platform technology than Java. It downloads quicker and runs faster than Java applets, especially on Windows 3.1 and older, 68000-series Apple Macintoshes. If you've ever drummed your fingers while watching the little "Java applet initializing" message in the bottom of your browser, you'll understand what I mean when I say Java can be slow. When you open a page with Dynamic HTML, there's almost no waiting, once the page has downloaded. And Dynamic HTML will run on all versions of Internet Explorer 4.0, including the Windows 3.1, Macintosh, and UNIX versions.

A better user interface

Because Dynamic HTML is just HTML and script, it can't do everything an ActiveX control can, such as accessing operating system services. If you want to access the Windows registry or print something, for example, you'll still need an ActiveX control. But Dynamic HTML does have some advantages of its own. It's an ideal technology for creating any sort of user interface element in a Web page or application, says Scott Isaacs, author of the forthcoming book Inside Dynamic HTML, from Microsoft Press. "Most stuff that's UI-based should be done in Dynamic HTML," he says.

Simply by adding a little script to your HTML pages, you can create such sophisticated elements as outlines that expand or collapse at the click of mouse. The text will even automatically reflow to fit the new length of the column. And there are a wide variety of mouse-over effects you can accomplish with Dynamic HTML, such as making fonts change in size or color. (To view examples of this and more, visit the Dynamic HTML Gallery on the SiteBuilder Network.)

More efficient than Java

Dynamic HTML is able to accomplish its tricks because it provides a comprehensive object model for HTML. This model exposes all page elements as objects that can be manipulated easily, simply by changing their attributes or applying methods to them at any time. This makes Dynamic HTML more efficient than Java, because it doesn't have to start up the Java virtual machine. What's more, Dynamic HTML doesn't require any return trips to the server to work its magic. Once you've downloaded the Dynamic HTML information for a page into your browser, you can modify text or graphics on the fly simply by mousing over items or clicking on them. To add Dynamic HTML to a Web page or application, developers or Web authors can use any scripting language. Some of the Dynamic HTML experts here recommend ECMAScript (the standards-based successor to JavaScript), especially if you're putting your Dynamic HTML application on the Web, where JavaScript is widely used. If you're more familiar with VBScript, then use that, they advise.

It's all about the DOM

When you break Dynamic HTML into its individual features, you'll find that they are based on the Document Object Model. The DOM makes HTML and Cascading Style Sheets (CSS) programmable through script. Since the W3C is standardizing the DOM (for details, see http://www.w3.org/Press/DOM-core.html) and Microsoft is working very closely with the W3C, you don't have to worry about getting locked into proprietary technology.

Dynamic HTML supports a host of other features I haven't even touched on, such as data binding, which adds the ability to sort tables and other data right in the browser, without requiring a return trip to the server. Dynamic HTML also lets you lets you create reusable components called scriptlets. As developers create more Dynamic HTML applications, the number of these reusable scriptlets should grow dramatically.

No more snickering

With a little research, I've learned enough to overcome my initial skepticism about Dynamic HTML's ability to substitute for Java when developing interactive content. (My newfound enthusiasm has nothing to do with joining Microsoft, really!)

As developers move more and more applications to the Web, they'll want to add life to their pages and give them all the capabilities of a full-scale desktop application. The ease of use, speed, and cross-platform capabilities of Dynamic HTML let them do that without compromise. As this new technology gathers steam, it will win many converts from the ranks of the Java faithful.


Windows CE for Washing Machines? Well, Not Yet

John Swenson
MSDN Online

October 14, 1997

If the first crop of handheld PCs running Microsoft Windows CE didn't get you excited, it's time to take another look. With the shipment of the Windows CE 2.0 operating system this week, the next wave of CE hardware, applications, and tools is on the horizon.

Most visible will be the new types of Handheld PCs (H/PCs) and other hardware running CE 2.0. Many of these new devices will look similar to the first batch of H/PCs, but others promise to change the public's idea of what Windows CE is all about.

It's probably safe to assume, for example, that most people don't think of washing machines when they think of Windows CE. Yet one company actually did try to run Windows CE on an industrial washing machine, according to Bill Baxter, CEO of Bsquare Corporation, one of 16 Microsoft Systems Integration Partners that are helping hardware manufacturers fit CE onto various types of devices. Although the washing machine project didn't pan out (mainly for business reasons, not technical reasons, Baxter says), Bsquare is among the CE systems integrators that report seeing a wide variety of hardware (most of it still unannounced) come though their labs.

Big, big volume

If you're a developer who has followed the progress of Windows CE, you've probably heard that Microsoft's embedded operating system eventually will run on telephones, game machines, WebTV set-top boxes, DVD players, and new types of H/PCs that will range from tiny "wallet PCs" to larger handhelds that look like small laptops. "All of these products are on the horizon and potentially represent very, very large volumes," says Craig Mundie, Senior Vice President in charge of Microsoft's Consumer Platforms Division. According to Mundie, the H/PC market that Microsoft started with Windows CE 1.0 and 2.0 might turn out to be fairly small compared to the market that could exist someday for all these other types of consumer devices.

Who knows, maybe some company will even succeed at getting Windows CE onto a washing machine and jump-start the market for computerized laundry devices running a lightweight operating system. Because Windows CE 2.0 is totally componentized, developers and engineers can use only the pieces of the operating system they need for the particular device they're designing. This flexibility to adapt CE to whatever a manufacturer needs should lead to new types of CE devices that haven't even been imagined yet.

Second-generation H/PCs

For now, the H/PC is where the action is in the CE market. With the shipment of Windows CE 2.0, manufacturers are preparing to ship their second generation of H/PCs by the end of the year. The most noticeable feature on many of these new H/PCs will be their bright color screens. These easier-to-read screens, combined with a host of other major improvements, such as TrueType fonts and the ability to connect second-generation H/PCs to a network, should persuade a lot more consumers and companies to buy the devices.

With the growth in the H/PC market will come demand for many new CE applications. If you're a developer, the good news is that there are now a lot more tools you can use to create these applications. With Windows CE 1.0, developers were pretty much limited to Visual C++ for Windows CE. With Windows CE 2.0, developers will have four main tools.

The first three Windows CE tools are add-ons to the full-fledged desktop versions of Visual Basic, Visual C++, or Visual J++. The Windows CE add-on toolkits will allow Windows developers to use the same familiar Microsoft tools they work with today to create Windows CE applications. Beta versions of two of these add-on toolkits—the Windows CE Toolkits for Visual Basic 5.0 and Visual C++ 5.0—are already available for download from the Microsoft Windows CE Web site (http://www.microsoft.com/windowsce/developer/). The Windows CE Toolkit for Visual J++ is still in development and will be available for download when it reaches beta.

The Windows CE Toolkit for Visual Basic, in particular, should have a big impact on the number of CE apps available, by opening up this new platform to the huge number of Visual Basic developers. Let's say you build apps in Visual Basic for your company. If your IS department decides to let some employees test the new Windows CE 2.0 H/PCs due out in the next few months, you'll be able to create Windows CE versions of your company's Visual Basic apps without having to learn a new language or development environment.

For developers who want to work at the hardware level, Microsoft will also ship a fourth tool: Windows CE Embedded Toolkit for Visual C++. This toolkit is aimed at developers and engineers who want to embed the CE operating system into new devices.

Look again

As these new tools and second-generation H/PCs roll out over the coming months, they promise to challenge almost everyone's notions of what Windows CE is all about. If you're among those who thought they understood this lightweight operating system, it's time to move beyond your first impressions of Windows CE and take another look.

Another New Face at MSDN

I'm John Swenson. I started working at Microsoft this month, after several years of covering Microsoft and other software companies for Windows Watcher newsletter, Information Week magazine, and a local newspaper in the Seattle area. I'll use my journalism background to focus on bringing you the high-level overview of new Microsoft products and technologies for developers, answering such pressing questions as "Why should I care about this?" Above all, I'll try to make it interesting for you, the developer.


ActiveX Revisited

Micro/scope
February 25, 1998

Norvin Leach
MSDN Online News Editor

A lot of you have been asking about the status of ActiveX again, in the wake of some recent online articles.

Briefly, here's the answer, followed by some practical advice about when to use ActiveX controls and when not to:

  • ActiveX is not dead. It was a $410 million market in 1997 and will be over $1 billion in 1999, according to Giga Information Group. There are 6,000 controls out there and C/Net's ActiveX site got more than 21,000 download hits during the third week of February.

  • ActiveX is not going away. The ActiveX technology is a vital piece of our technology and dropping it would leave a gaping hole in our COM strategy.

OK, so one more time, tell me what ActiveX is.

ActiveX is a brand name for a visual control framework based on Component Object Model (COM). It's packaging technology that provides a way to package COM components and pop them into applications such as (but not limited to) Web browsers.

ActiveX controls are the descendants of VBXs. You can also consider the components once called OLE Custom Controls (or OCXs) as ActiveX controls.

But I thought ActiveX was the brand name for Microsoft's whole component technology.

I'll admit it. Marketing went a little overboard with the term, leading a lot of people to believe that it represented our whole component model.

That's not right. ActiveX is only a packaging technology for COM objects.

I read that you're de-emphasizing ActiveX and emphasizing COM.

Last fall, we trimmed off the excess definitions that had grown up around ActiveX and brought it back to its original, narrow meaning.

As far as emphasizing COM, well, we've emphasized COM for a few years now. It's just a question of whom we talked to and how we talked about it.

Frankly, COM can be a difficult subject for writers to understand. It doesn't lend itself to quick news articles, thus the simplification of the message.

It's sometimes difficult to work with, too. That's why we created frameworks (like ActiveX) to simplify it. Nonetheless, COM has been the strategic core of our component story since 1993.

I want more details. What's the difference between an ActiveX control and a COM component?

An ActiveX Control is a COM component that supports the necessary protocols to be used in a visual development tool. In other words, you can visually manipulate it. Now, this doesn't mean that an ActiveX control needs to be visual at run time. It could be visible only during design time. An example of this kind of control is a timer. The developer can see it while he's designing an application, but the end user would never see it.

What are these "necessary protocols?"

They include things like the interfaces that visual development tools use to negotiate screen space and the presence of a Toolbox Bitmap entry in the registry.

Are there any other ways to differentiate ActiveX Controls?

Well, they are:

  • Usually packaged in DLLs using the extension .OCX.

  • Self-registering and unregistering.

  • Programmable via Automation.

Where does OLE fit in with all of this?

Without going into the whole lineage of our object technology, just think of OLE as another framework on top of COM, somewhat similar to ActiveX. It supports compound documents, or documents within documents.

So, when do I use ActiveX?

Use ActiveX if you want to build a powerful, small component that accesses system services and can be dropped into a thin client (like a browser). For example, if you want a component that prints or writes to the Registry, use ActiveX.

Similarly, if you want to write a component without learning a new language, use ActiveX. You can build ActiveX components in any language.

When shouldn't I use ActiveX?

If you're writing a simple, lightweight user-interface component, don't use ActiveX. We recommend Dynamic HTML.

Frankly, a lot of things out on the Web, like marquee controls or simple applications, are written as Java applets or ActiveX controls, but shouldn't be. Those things are better off being rendered by Dynamic HTML.

What about cross-platform support?

ActiveX is designed for power, not for ubiquity. These controls rely on Win32 features, so they're not available on UNIX or the Macintosh.

So, if ActiveX isn't dead, what was all the fuss about?

Too many people think of ActiveX exclusively as an Internet technology, and that's their measure of success.

ActiveX is not limited to the Internet at all. We're continuing to see growing use of ActiveX in intranets as well as in applications that don't use browsers as front ends. Writers and analysts usually don't take this into account, but that's precisely where the market for ActiveX controls is.

Say, while we're clearing the air about products, whatever happened to Microsoft Bob?

All I know is that, at Comdex 1997, we had 200 developers screaming for one of the last shrink-wrapped copies of that product. Go figure.

Is there anything you want to ask us? Send us mail.


Observations on the HelpDesk Sample

tele/scope
February 23, 1998

Norvin Leach
MSDN Online News Editor

We're posting a series of four articles today, called "Development Issues." In these articles, our MSDN developers discuss the problems and speed bumps they ran into during development of the HelpDesk sample, and explain how they worked around them.

At the same time, I'd like to share some of my own observations. Now, I didn't develop the HelpDesk sample. In fact, I didn't come into it until late in the game, when we were ready to post it as an online Feature. But still, there were some clear lessons from the posting.

You can never anticipate all the bugs

I've written about this in a previous column, and it will probably hold true for all applications forever. Still, it bears repeating. Just as we writers believe that our sterling prose never needs editing, developers often believe that their code is bug-free. But that's impossible. There are just too many combinations of systems out there for any developer to be able to test every possible scenario.

For example, one HelpDesk user discovered that his SQL Server configuration only allowed 12 characters for login names. That meant that when he logged into the HelpDesk as Administrator (13 letters), the app didn't work. None of us at MSDN used that particular SQL Server configuration, so no one caught the bug.

Again, this doesn't mean that testing is a hopeless task. It means that you should never be fooled into thinking that your application is completely clean.

The Known Issues page was an important addition to the package

Upon reflection, I should have thought of this earlier. However, it wasn't until the first bug report arrived in e-mail that I realized we needed a good way to make users aware of fixes to the HelpDesk.

Now, the bugs didn't affect everyone. Furthermore, our developers were able to wipe out the bugs quickly and put up clean versions of the files. But we were getting thousands of hits on the page, which means that at least some people still needed to be alerted.

How could we do it?

  • First option. Our e-mail news channel is the MSDN Flash, which goes out to Online Members every two weeks. It's a great vehicle for news, but clearly wasn't frequent enough for this purpose.

  • Second option. If we had required people to register their e-mail addresses before accessing the HelpDesk sample, then we might have been able to track the people who downloaded the app and send them notifications of the bugs.

    That wasn't practical, though, and we didn't want to limit access to the HelpDesk.

  • Third option. The solution we settled on was creating a Known Issues page. We made the link obvious on the HelpDesk default page, and then we organized everything on the page so that users could immediately learn about the latest problems and fixes.

  • Reality. In the end, though, we still had to answer a lot of the questions in e-mail. People downloaded the sample, ran into problems, and chose to send us mail rather than working through the Known Issues page. This is understandable, though. Which brings me to my next point . . . .

There was a lot of irrelevant e-mail

When we launched the feature on Feb. 2, we added a mailto: link on the default page of the feature.

This link was meant for comments and questions, and at first, people used it for that. Very quickly, though, users started sending in other questions. They jumped on the opportunity to converse with a live person.

We got questions about any number of odd things, such as, "Why can't I fax from NT?"

This flood of tech-support questions is symptomatic of a problem that we see everywhere in the industry—not just at Microsoft: Tech Support is a sore spot.

Developers—in fact, all users—want better connections to tech support. They want live humans rather than voice mail. They don't want to waste time in triage.

At first, this may not seem relevant to your work (although you may have experienced some of these problems yourself).

If our research is correct, most developers don't provide tech support for their products. Some of you provide training. A few provide high-level support (answering the really hard questions). But only a small number of you actually provide support for the products you build.

Nonetheless, you all risk getting hit up with tech-support questions, wherever you are. If you post in a newsgroup, if you deliver a technical talk, chances are people are going to ask you tech-support questions. And there's even a chance that they'll ask you questions about completely unfamiliar topics.

It's kind of like meeting a doctor at a party. You often can't help but ask her about a medical problem. And when people find out I work for Microsoft, they ask me how to use Excel. Eventually, I guess, you get used to it.

Is there anything you want to ask us? Send us mail.


Consolidation and Decompilation at the SD West Show

tele/scope
February 12, 1998

Norvin Leach
MSDN Online News Editor

Whenever I go to trade shows I ask people what they've seen that's hot, new, zippy. What caught their eye? What made them stop by a booth?

At the Software Development show in San Francisco during February, I got a surprisingly wide range of answers. No one agreed on one specific product or technology, and a lot of what I heard sounded familiar. I couldn't figure out why, until some people put it in perspective for me.

It's a year of consolidation.

Cool becomes mainstream

Jeff Duntemann, editor-in-chief at The Coriolis Group publishers, observed, "This year, the really buzzy stuff has been merged into the mainstream. What you're getting is polished, slick tools."

This is true in several areas.

The number of companies seems to be diminishing because of frequent acquisitions. Rational, once a one-booth company, now has its own Partner Pavilion.

Disparate technologies are merging, and some of the wars are over. Borland, for example, is now licensing and shipping the Microsoft Foundation Classes.

And even last year's "new" languages aren't new any more. Java is no longer the mystery it once was. The tools are becoming mature. And developers are figuring out what they can and can't, should and shouldn't do with the language.

Decompiling Java

I'll spare you any Microsoft marketing rhetoric about Java here, and instead, point out an interesting third-party product that I saw at the show. It's cool, it's fascinating, and like a lot of cutting-edge technology, it's potentially dangerous.

The product is the SourceAgain Professional Java decompiler from Ahpah Software (visit the Ahpah Software Web site at http://www.ahpah.com/). While I've heard of some quick-and-dirty shareware decompilers, this is a professional product that plugs into our developer tools. It can decompile Java executables and provide solid looking source code (not the assembly language that you can get from a debugger).

Beautifying code

How close is the decompiled code to the original? Ahpah claims that, if the code is written clearly, it's almost identical (although, obviously, it lacks the comments). They said that one developer is even using it to "beautify" his code. I'm not a reviewer, so I didn't check this out for myself. It's easy to evaluate for yourself, however. Ahpah's Web site has a running demo—type in the URL of a publicly available class file and it returns the source code.

Prices range from $100 to $300. The product is still in beta, though, and won't be available until the very end of March.

The danger

As I said, though, there's a danger here. If this product makes decompiling Java easy, how do you protect your investment?

I don't know if there's an answer. Ahpah has a license agreement that states that the product should only be used in certain situations, such as assessing an applet from an unknown source, analyzing compilers and optimizers, or retrieving lost source code.

Furthermore, my colleague Dr. GUI points out that this is a known risk. Decompilation is theoretically a simple thing. There's pretty much only one straightforward way to compile Java, and Java class files contain complete type information for the whole class. This means that it's easy to figure out what a Java class is doing.

Open code?

None of this lessens the danger, though. This is the first time I've seen a good, commercially available Java decompiler. And if this becomes a common tool, then it means that Java applets on the client could be considered open code. (On the other hand, it could lead to the development of tools that secure code through processes such as rearranging the byte code.)

I don't have a recommendation here, and perhaps it isn't a problem after all. I mean, you don't see Web-site authors screaming to the World Wide Web Consortium to come up with ways to protect their HTML.

But it certainly is a product to think about.


Cryptic Controls

crypto/scope
January 15, 1998

Norvin Leach
MSDN Online News Editor

This week, RSA is holding its Data Security Conference. Time for the annual Bashing of the Feds, in which one or two hapless government representatives get to sit on a panel and deflect punches from critics of the federal data-encryption policy.

It's a bitter fight and it's been going on for years. If you're not familiar with it, here's the basic battleground: The government wants to limit strong encryption, claiming that law enforcement agencies need to be able to access messages and data sent and stored by criminals. Technology and privacy advocates argue that the government shouldn't curtail privacy rights, and that encryption limits will put the United States at a competitive disadvantage.

Focal points of the battle include the strength of the encryption, prohibitions against exporting encryption technology, and the required use of escrow keys so that the law enforcement officials can get at data more easily.

What does this mean for software developers? Uncertainty, for one thing. We know where the government stands today—the Clinton administration favors limits on encryption technology. But it's unclear where we'll be tomorrow. Law-enforcement proponents like FBI Director Louis Freeh are pushing for even stronger controls but some lawmakers are trying to relax controls, through bills like the proposed SAFE Act (see the U.S. House of Representatives Web site at http://www.house.gov/goodlatte/encryption.htm).

Microsoft, by the way, supports SAFE and similar initiatives. We believe that current export controls are outdated and that customers want stronger security and privacy protections.

But this uncertainty doesn't mean that encryption technologies are out of reach. For a good overview of what's out there today, read Peter Berkman's column, "Safety Net," in the November/December 1997 issue of Developer Network News.

If you're looking at using cryptography in your application but don't know much about it, dip into Cryptography API (CryptoAPI), our library of high-level cryptographic interfaces.

CryptoAPI manages details like key management, formatting, and cipher algorithms. It also presents developers with a single interface that supports different underlying ciphers. Third-party cryptography companies such as BBN, Cylink, and Hewlett-Packard have created plug-in modules, called Cryptographic Service Providers (CSP), for the CryptoAPI.

You can get more information about the CryptoAPI and the current Cryptographic Service Providers from the Microsoft Security Advisor Web site—see especially the "CryptoAPI" (http://www.microsoft.com/security/tech/misf6.htm) and "CSP Development" (http://www.microsoft.com/security/tech/capi/cspdev.htm) pages. There is a wealth of cryptography information also available in the MSDN Library, Internet, Security bin.

Overall, the Microsoft Security Advisor Web site (http://www.microsoft.com/security/) offers a good collection of information. While a lot of the material concerns network administration and security issues, the site also houses developer-related information on technologies, such as Microsoft Authenticode technology (http://www.microsoft.com/security/tech/misf8.htm) and smart cards (http://www.microsoft.com/security/tech/misf18.htm). Information on both of these topics can also be found by searching the MSDN Library.

Incidentally, on the subject of network security, I've heard that British and Australian network administrators have been amused and confused by the latest denial-of-service attack against Windows NT and Windows 95.

At Microsoft, we call it NewTear, since it's a variant of the Teardrop attack. On the Internet, however, it's called Bonk. And, given the meaning of the term "bonking" in Britain (I'll let you guess at that), there's quite a bit of funny mail flowing around. It may not be as memorable as the Ping of Death, but it's close.

Also, our Future Directions page on the Microsoft Windows NT Server Web site (http://www.microsoft.com/ntserver/guide/nt5_pdcwp.asp) lists several white papers discussing security technologies that we're working on for Windows NT version 5.0.

Finally, if you have more questions about security, check the RSA Web site (http://www.rsa.com/). It has a lengthy FAQ file (http://www.rsa.com/rsalabs/newfaq/) that answers almost 200 questions ranging from the simple to the complex.

Is cryptography important to your applications? If the government limits strong encryption, will it affect your work? Let me know.


Titanic Failures

aqua/scope
December 18, 1997

Norvin Leach
MSDN Online News Editor

If you see the new movie Titanic, don't think about software development.

Don't think about those colossal, time-draining projects that met their fate slamming against icy user responses.

Don't think about those beautiful, sleek applications that buckled and sank under the pressures of the real world.

Just enjoy the movie.

When you return to work, though, you might want to think about a couple of things.

Blame

Researchers are still trying to figure out exactly how and why the Titanic sank. We know that she hit an iceberg. We know that the plates buckled and the seawater rushed in. But that's about it.

One theory said that the iceberg tore a huge gash in the side of the ship. This has pretty much been disproved, but the actual type of damage is still in doubt. Recent soundings of the wreck suggested that the fractures were much thinner than historians and researchers theorized.

Another theory suggests that the steel was of poor quality because the owner wanted to cut costs. Not many people believe this, but it resonates with popular imagination. People love to hate Bruce Ismay, the managing director of the White Star Line, who just happened to be one of the survivors.

Some believe that the Titanic was improperly designed. Supposedly, the bulkheads were too low, and unable to keep out the water. After the disaster, sister ship Olympic (the Titanic was one of a set of triplets) was refitted with higher bulkheads, giving her effectively a double hull.

But the third sister, the Britannic, already had a double hull, and that didn't save her from sinking when she hit a mine in the Aegean in 1916.

The Americans and the British both held inquiries, but neither was conclusive. The British inquiry, the more thorough of the two, was more concerned with absolving the White Star Line of blame than of finding the truth. In that, it was successful. The villain of the inquiry turned out to be Stanley Lord, captain of the steamship Californian.

In a moment, I'll explain why Lord got branded. First, let's see if all this has any relevance to development.

Postmortem

You've probably gone through software failures before. Do you know why your project failed? I mean really know. Did you trace back all the steps and figure out what was flawed? And then, did you figure out how to correct it?

Perhaps you skipped an area in testing. How will you cover that area in the future?

Perhaps you overestimated the application's ease of use. Does that mean you need more usability testing?

Not enough companies go through thorough postmortems after failures. One large graphics software company won a horrible reputation for bad products when, time after time, their upgrades were plagued with bugs. They never seemed to learn. No, I'm not going to name the company, but you can probably figure it out.

In general, mistakes are unavoidable. The trick is to learn from them, and in order to do that, you need a good postmortem.

A good postmortem focuses on fact-finding, not finger-pointing. It's human nature to assign and shift blame, but that shouldn't be the purpose of your analysis. The purpose should be to correct the problem.

SOS

One of the unanswered questions in the aftermath of the Titanic disaster was whether a nearby ship that ignored the distress flares could have saved more passengers.

There was certainly a ship nearby. Several passengers saw its lights. In fact, the captain of the Titanic thought the other ship was so close that he ordered the lifeboats to row over to it, drop the passengers off, and then return to the Titanic to pick up more passengers.

But the other ship just steamed away, without stopping. The survivors drifted on the sea for hours until a rescue ship reached them.

That other ship, supposedly, was the Californian. In the inquiries, the night watch on the Californian said they saw rocket flares on a distant ship, but Captain Lord told them not to stop to investigate or even radio the other ship. The American and British inquiries both condemned Captain Lord, and the steamship line that owned the Californian forced Lord to resign.

Lord's defenders have long argued that the ship that he saw was not the Titanic. It was a smaller ship, perhaps even an illegal Norwegian sealer. And, for sure, some of the testimony in the inquiries supports this contention.

Nonetheless, Lord's failure to immediately address the problem at hand—going to help a ship that was clearly in distress—was enough to blacken his career.

(At the risk of ruining this nice metaphor, Lord was quickly snapped up by another steamship company and continued his career as a captain without further incident).

Support

So, it's clear that the quality of your tech support can make or break your reputation.

Do you have a tech-support structure in place before your product goes out the door? Have you covered all the peripheral considerations, such as making sure that staffing and phone capacity are sufficient?

It's often better to overanticipate questions and complaints than to leave users hanging on the support line for hours. Do you test your support lines yourself, calling up blindly and asking questions?

Support technicians like to spread horror stories about ignorant users, but the reverse is often true, too. And while ignorant users won't hurt you if they're handled correctly, a rude support technician will.

In summary, it may be impossible to avoid a disaster, but you can buttress yourself against its ill effects, and you can always learn something from it.

Have you sunk anything big lately? Let me know.


Thinking the Unthinkable About DOS Apps

micro/scope
November 26, 1997

Norvin Leach
MSDN Online News Editor

The latest rage around MSDN Online these days is Dynamic HTML and scripting. We're still in the new-toy stage, as you might have noticed (if you're using Internet Explorer 4.0, run your cursor over the Thanksgiving graphic on the Buzz page). But I expect that we'll be moving into serious uses of this technology soon.

In fact, I heard something amazing at Comdex—a panel discussion in which a Microsoft rep and a Netscape rep both agreed on something. They agreed that DHTML was vital for the future. They agreed that, even though the Internet Explorer 4.0 implementation isn't completely compatible with the Navigator implementation, the two companies will synch up once the standards are in place.

Great times ahead, huh?

But you know, if someone asked me today if I'd be willing to chuck it all and go back to MS-DOS, I'd hesitate before turning them down.

I know. Returning to the days of the C prompt sounds like heresy. That's devolution. I'm a veritable Luddite for even thinking it. And I'm not saying I'd do it. I'm just saying I'd consider it . . . for one particular reason.

For the past 13 years, I've been running a DOS word-processing program called PC-Write. I don't use it much these days, because I finally have hardware that can run Word with sufficient speed. But I still fire it up to look at old documents.

What was so good about it?

Why did I like PC-Write? Two reasons:

  1. It was fast. Even though it was stuck using the lower 640K of memory, its response was instantaneous. No complicated graphics. No disk thrashing. The screen display kept right up with your typing and scrolling, thank you very much. (Here's a related factoid—user-interface guru Ben Schneiderman says that in order for people to be satisfied with feedback from applications, response time has to be less than 400 milliseconds. Click a button, and if nothing happens within 400 milliseconds, you start to get edgy. I would think that there would be even less tolerance for delay with direct input, such as typing.)

  2. It was configurable, and thus easy to use. PC-Write had an extensive set of custom commands and macros that you could program in. Sure, setting up macros wasn't intuitive. But you could work through it by looking up the commands in the manual. (A paper manual! Imagine that!) After a couple of years of using PC Write, I began adding more and more macros, until eventually it became as familiar and responsive as my car. It worked the way I wanted it to work.

That's why I'd hesitate before turning down a return to MS-DOS. Those two points were enough to make this application comfortable. In the end, I moved on, because it didn't have everything I needed. But it was damn close. And I'm sure thousands of people still use it.

The rush to change

What does this have to do with the current state of development?

Just a reminder that, in the rush to adopt new technology and upgrade products, we often forget the fairly simple needs of our users. We forget to think strategically, with the user in mind. The technology becomes so cool, so alluring, that we use it for its own sake.

To return to the launching point of this column, consider the turkey gobble on the Buzz page. Do I expect that the turkey will help you, the developer, do your job better? Frankly, no.

What I'm hoping it will do, however, is jump start ideas. I'm hoping the gobble will give you (and us) suggestions about how to use DHTML to improve presentation. If it causes any problems, if it slows down the page, then I'm relying on you, our readers, to complain about that. Whatever happened to PC-Write? It was marginalized, mainly because it never made the transition to Windows. The company that created it, Quicksoft, folded in 1993. Starlite Software bought the distribution rights, and still sells it as shareware. However, I'm told that the source code was such a mish-mash that it was too difficult to rewrite (a mixture of C, assembly language, and Metaware Pascal!). What a shame.

Do you still use DOS apps? Let me know.


Three Questions About Java

micro/scope
November 5, 1997

Todd Nielsen
Guest Columnist
General Manager, Developer Relations Group

MSDN Online received several responses to its recent article about why Microsoft doesn't support JNI or Remote Method Invocation (RMI) in Internet Explorer 4.0, and they asked me to answer the mail.

As I read the mail, I realized that most of it could be boiled down to three questions. So, I wrote down the answers to those questions, and then began responding to each mail individually by cutting and pasting the answers. (As a result of that exercise, I can now proclaim that I am the world's fastest "cutter and paster." I hereby challenge any of you to a cut-and-paste-off at our next Microsoft Developer Geekfest! But I digress . . . .) After working my ctrl-c and ctrl-v fingers for a while, I figured there must to be a more efficient way to address these three questions.

Therefore, my hope is that this column will answer the questions and provide some additional clarification.

Question 1

By not supporting JNI, you are preventing my applets from running on every operating system. Why are you doing this dastardly thing to me?

Answer:

JNI isn't used for portability or cross-platform compatibility. By definition, JNI is about writing native code for a specific operating system. When a developer makes an explicit decision to write native code, we want to provide the most efficient way to do this. We provide Raw Native Interface (RNI) and J/Direct, which offer better performance and more functionality than JNI. Furthermore, JNI is incompatible with previous versions of the Java Development Kit (JDK). Microsoft's RNI was based on the native method interface of JDK 1.02 and was already installed on millions of desktops before JNI was ever introduced. Sun may not care about breaking code that customers have already written, but we do.

Question 2

By not bundling RMI, you make me download the technology from your Web site in order to run RMI code with IE4. Why make me go through this pain?

Answer:

We understand this is an extra step. However, the pain of downloading RMI from our Web site is nothing like the pain you'll feel when you have to rewrite all of your applications that depend on RMI code. Will you have to? It looks that way. Sun has been highly inconsistent in its statements about the future of RMI. In June, a Sun official said it would be merged with IIOP and phased out. When users complained, Sun backed off and said it wasn't killing RMI. But Sun still hasn't provided details of how it will accomplish the merger without breaking developers' code. For those programmers who want to use RMI, we do make it available from our Web site, but we don't support it, and we don't recommend it.

Question 3

Regardless of Microsoft's opinions of these two technologies, you are required to ship whatever Sun says. You do not have the right to determine how you support Java. So, what do you think about that?!

Answer:

Actually, our contract with Sun does give us the right to do this. Our agreement with Sun gives Microsoft the sole discretion to decide whether to distribute some of, derivative works of, or a substitute for the technology we licensed from Sun. Microsoft refused to agree to restrictions that would allow Sun (or any other vendor) to dictate the future development of Microsoft products. Sun is well aware that we had no obligation to ship any of their technologies after Internet Explorer 3.0 and is now asking the courts to reinterpret the deal.

What do you think? Please send mail.


Your Letters

tele/scope
October 29, 1997

Norvin Leach
MSDN Online News Editor

It's the end of October in Seattle. The trees are almost bare. It's rainy, it's cold, and it's bleak. It's time to find shelter. Time to spend the long, lightless days contemplating mortality and catching up on letters to MSDN.

ActiveX

Lots of responses to the ActiveX column, mostly thankful for an explanation of the marketing terms. A few questions came up, though:

Most of the demos at the PDC used scriptlets and DHTML. This looks like Microsoft is, indeed, de-emphasizing ActiveX in favor of scripting. In fact, there are few, if any ActiveX controls on your Web site. And what about Java applets? Give us some guidelines on what we should use, and where we should use it.

To tell you the truth, this one stumped me, so I asked Christine Chang, a product manager in our Platform Group. Here's her answer:

Web developers should use the right tool for the job, based on what they're trying to accomplish.

  • Scriptlets are the easiest way to create and present reusable interactive content. With scriptlets, HTML and script authors can leverage existing expertise to create these components, without having to learn new languages such as C or Java. Given that scriptlets are HTML- and script-based, they download and run very quickly compared to controls and applets. However, unlike applets, scriptlets are not supported across browsers. They will be delivered in all versions of Internet Explorer 4.0 including Windows 95, Windows NT, Windows 3.1, Macintosh, and Unix.

  • ActiveX controls provide more powerful language functionality, compared to both scriptlets and applets. They also provide easier access to system services such as the registry or print queues, compared to applets. Scriptlets do not have access to system services.

  • Java applets provide more language functionality than HTML and script, although they can't access system services as easily as controls. With extensive testing and debugging, it may be possible to develop an applet that runs across multiple browsers and platforms. However, it's difficult to port significant functionality across multiple platforms. In addition, applet performance on Windows 3.1 and older Macintosh systems is often very slow. As a result, applet use is impractical on these platforms.

What happened to the ActiveX Gallery?

It's gone. That was introduced last year specifically as a marketing tool to get people familiar with the concept of ActiveX controls. It did its job, so we took it down and moved the resources elsewhere. You can find examples of ActiveX controls at the Browserwatch Web site (http://browserwatch.internet.com/activex/activex-big.html), or C/Net's How-To Web site (http://www.activex.com/). Or, even better, you can search through our ISV partners with the new MSDN ISV Directory (http://198.206.247.245/MSDN_ISV/html/Direct.asp).

Bedlam

I asked for some help-desk horror stories, and the best/worst story came from Geoffrey Feldman. It's hardware-related, but nonetheless good enough to relate:

22 years ago I was Technical Director for a little place called "The Computer Store" in Burlington, Mass. We sold Altairs and yes, Microsoft products with them. Altairs at the time came in kit form. Not motherboards and chassis but chips and boards with no solder yet. The Altair had a huge bundle of wires that went from the front panel to the motherboard.

A customer came in after attempting to build one of these things. As was often the case, he had not been successful. When I opened the case, a horrible odor of bad breath permeated the room. As I peered down into the wiring, I noticed that it was tied together very neatly (this was recommended) but he had tied it together with dental floss. Used dental floss. A quick call to the guy got his permission to spray the computer with Lysol before the service operation commenced.

On a more serious note, I'll end with an observation by one writer, who suggested that I missed the most important lesson of the Bedlam incident:

Scalable systems require administrative controls that are not necessary on systems that will remain small. The point is that by the time the mess got going, there was no way to stop it. The recent trend toward monolithic, opaque software makes this problem even worse.

I suggest that developers be required to read the comp.risks list before writing the first line of code each day. It's too easy to get buried in the task of writing and shipping code and lose perspective on the way that the system you are creating will be (mis)used.

Send me more mail.


Bedlam and the Bozo Factor

Norvin Leach
MSDN Online News Editor

October 27, 1997

You can usually draw a lesson out of any painful experience.

Take last week, for example. On Wednesday, Microsoft's internal e-mail system got slammed by a manifestation of the bozo factor.

Here's what happened: Our IT people created a group alias to test mail distribution, but they forgot to set delivery restrictions. Normally, that wouldn't have been a problem, but someone discovered this test alias, couldn't figure out why he was on it, and sent mail to the whole alias asking, "What's Bedlam DL 3?"

People started responding.

"I don't know what this alias is."

"I don't know either, but take me off."

Then came the complaints. Smug and self-righteous, the complainers demanded, "Don't Hit Reply All!!" But, of course, the senders sent this instruction to all the people on the alias.

All 18,000 of them.

The system slowed to a crawl. Our IT department figured that a month's worth of e-mail went through the pipes in a single day. On a normal day, we average four million messages.

What's the point of this story?

Well, it's not a criticism of Exchange, which stayed up and running throughout the incident. And it's not an excuse to vent about these pinheads.

My point is a simple one: You never can tell what users are going to do with your software.

This is the bozo factor—some hopeless stupidity that you never conceived when you were planning your applications.

Okay, so these inadvertent spammers weren't as brainless as the people in the help-desk horror stories. You've heard about them—the people who photocopy floppy disks or close the windows in their office instead of shutting down Windows or Microsoft Office.

And it's true, you could attribute The Bedlam Horror to problems of implementation, not design.

Nonetheless, last week's combination of events was one of the unexpected problems that developers have to face. It's a paradoxical argument—expect the unexpected. You can take comfort, though, in the fact that after a problem appears for the first time, it's no longer unexpected. You can then begin to work on solving it.

How does this apply to the real world?

Well, look at where our industry is going. Applications are becoming more complex. Networks are becoming more labyrinthine. Systems architectures are becoming incredibly elaborate. Planning for the bozo factor is only one of the things to consider when testing applications.

Testing. It's unglamorous. It's time-consuming. And it's no fun when someone highlights the flaws in your code.

But I've always been surprised at the number of developers who don't consider testing to be a priority in the development process.

I'm not just talking about debugging. I'm talking about software-quality testing. Profiling. Checking for memory leaks. Load testing. That whole bundle of expensive tools that maybe your company decided to pass by.

I'm also talking about usability tests, screenings, and other steps to make sure that your software is understood.

You can't plan for everything

The bozo factor might pop up anywhere, like a malignant jack-in-the-box. But it's not a hopeless case, as long as you commit yourself to thorough testing of your applications.

The software-testing industry is keeping pace with the advances in software technology itself. Last year, for example, a lot of the testing companies began offering Web-application testing tools. And if you're using the latest technology in development, you owe it to yourself to use the latest testing tools as well.

Not only will your software be better for it, but you never know when you might discover and close up a potential loophole for the bozo factor.

For more information on testing and development, we have a number of items in the MSDN Library. Most of the product SDKs include testing information, and The Windows Interface Guidelines for Software Design (Books, MSDN Library) also includes sections on testing.

Do you have horror stories about misguided users? Send them to me via e-mail (it's working now).


Data Access Essentials

Norvin Leach
MSDN Online News Editor

October 13, 1997

Last week I got mail from a developer who complained about our confusing array of acronyms referring to data access—ADO, RDO, DAO. Yup, there sure are a lot of them. But this is an area that will be strategically vital to you, wherever you work, so it's important that we make things clear.

Our world has a problem with data access. All the big database vendors—Microsoft, IBM, Oracle—recognize this. There's too much information out there, spread out over too many types of databases.

Companies like IBM and Oracle say that the solution is to move everything into a single database structure. Nice ideal, but we don't think that's practical. Instead, we want to provide a common way to get at data stored in different formats. We want to focus on the access rather than on the database. This means you can use the same front end to access a relational database, a mainframe database, an Excel spreadsheet, and a text document, all stored in different places.

We're going to do this through ADO and OLE DB. You've heard of them before, as part of our Universal Data Access strategy, but I think we need to show how they evolved from all of our other data access strategies. This is particularly important, because there's a compatibility gap between the current favorite interface (RDO) and the next generation (ADO). If you understand the history, you'll have a better idea of when, how, and if you should shift your code from RDO to ADO.

What I want to do here is run through the history of the relevant data access technologies over the past six years, one by one. (For you purists, yes, I'm skipping a few, like ESQL C.)

VBSQL

This was an old interface between VB and SQL Server. It was built on the C-based DB Library, which comes from the days when we were working with Sybase on SQL Server. It'll work with the upcoming version of SQL Server, but it won't support the new features. If you're using this, it's time to move on. The same applies to DB Library itself.

ODBC

ODBC is probably the most widely used interface to relational data. It gives you widespread access, but it's a low-level interface, and you pay for access with more complex applications. Also, it's not good for getting to nonrelational data. We've found that developers generally prefer to access ODBC through higher-level object interfaces such as DAO, ODBCDirect, RDO, or ADO.

DAO (Data Access Objects)

This was our first object-based interface, introduced in Visual Basic. It encapsulated functions of Jet, the Access database engine. It also let you create data-bound, or data-aware, controls. Millions of people use this today. Its only drawback is lack of scalability. It accesses SQL data through Jet, which adds overhead.

ODBCDirect

This is a variation on DAO that lets you get to ODBC without going through the Jet database engine—it really just uses RDO, with DAO object names.

RDO (Remote Data Objects)

This was a tight, lightweight interface to ODBC that we introduced a couple of years ago. It was patterned after the DAO object model, and made it easier for developers to get at the low-level power of ODBC. While it's very popular for SQL Server access, it's limited in its ability to get at Jet or ISAM data. Also, it can only access relational databases through existing ODBC drivers. We're moving beyond RDO, but if you have an RDO application that works well today, there's no reason to change it. I'll talk a little more about this later.

OLE DB

Welcome to our paradigm. This is the gateway to our Universal Data Access model. It's a low-level object-based interface that's not restricted to relational data, ISAM, Jet or anything. It can deal with any type of information. It's also something that you'll rarely encounter directly, unless you develop data stores or database engines. You'll access it through ADO, and will talk to a data store through an OLE DB provider.

ADO (ActiveX Data Objects)

This is the application-level interface to OLE-DB. It looks like RDO and DAO (in other words, it has a similar object model, so you can learn it fairly easily), but will be a superset of those technologies. You can use it to get at data through OLE DB service providers as well as existing ODBC drivers through the OLE DB for ODBC interface. It's the future. It gives you much broader access than any of our other interfaces, and we recommend that you start using this technology for future projects. There's only one problem. It's not backward compatible with RDO. It's similar, so you can learn it quickly, but you won't be able to mix your code.

So what do I do?

It won't be a snap to convert RDO code to ADO, but it's not rocket science either. Don't convert if you don't have to, but don't be afraid of learning a new skill. If you have RDO applications that are running today, just let them run. We will continue to support RDO. This will suffice for most existing applications. But in the future, start looking at ADO as the preferred way of accessing data. If you must convert your code from RDO to ADO, we'll be providing guidelines for doing that. They're not ready yet—this is still next year's technology. But MSDN Online will let you know when they're posted.

For more information today, check our Universal Data Access Web site(http://www.microsoft.com/data/).

Comments? Send them to me.


Is ActiveX Dead?

Norvin Leach
MSDN Online News Editor

Is ActiveX dead?

No.

This story comes up occasionally, and it's wrong, for one simple reason: ActiveX is a brand name for a key set of Windows component technologies. If we got rid of those technologies, we'd be gutting Windows. And we're not going to do that. Here's another reason: ActiveX is a $400 million a year market for third-party developers. We won't let that go either.

But when I looked up ActiveX on www.microsoft.com, I got a weird message that said, "Sorry! . . ."

OK, so we screwed up. That was a bad URL redirector. If you looked for the ActiveX page, you were mistakenly sent to the Active Platform page. Active Platform has been swallowed up by the larger, more relevant Windows DNA architecture. It's all part of our effort to make our message more coherent. ActiveX isn't dead. It just moved to a new house, and the post office messed up the forwarding address.

Tell me again exactly what ActiveX is

Component packaging technology for the Web. ActiveX controls are the smaller, faster descendants of VBX (Visual Basic eXtension controls) and OCX (OLE Controls). It provides a way to package COM components and pop them into applications, particularly Web browsers. If you want to learn more about it, check the ActiveX section on our COM Web site (http://www.microsoft.com/com/). If you want to see a catalog of commercial ActiveX controls, try Browserwatch (http://browserwatch.internet.com/activex/activex-big.html) or C/Net's How-To site (http://www.activex.com/).

It's part of COM?

Think of it this way. COM is our set of services that let components talk to each other. (COM+, which won't show up for at least a year, is a package of enhancements to that.) ActiveX uses these COM services. An ActiveX component is a COM component.

But how does ActiveX compete with Java?

Ah, yes. This is the root of the problem. Since it was introduced, people have stretched the definition of ActiveX to make a point. It was convenient to use "ActiveX" as a catchall to describe our component technology. Eventually, some people saw ActiveX as the whole platform. It's not. It's just the packaging and deployment technology. If anything, it competes on some levels with Java Beans. Also, let's be precise about "competing with Java." If you're talking about Java, the language, its competitors are other languages, like C++. But if you're using Sun's idea of Java as a platform, then the competitor is Windows.

How does this fit in with Windows DNA?

The Windows Distributed interNet Application Architecture (forgive the odd capitalization) is a roadmap that shows how Windows and other Microsoft products and technologies are used to create networked applications. Scalable, robust . . . you know all the words. Basically, it's a framework that tells you how our technologies fit together. COM is part of it, and so is ActiveX.


MSDN Subscriptions

MSDN™ subscriptions make it easier to take advantage of the latest Microsoft® tools and technologies. With the flexibility of tailored subscription levels and the convenience of timely updates delivered throughout the year, an MSDN subscription is essential for every developer.

The subscription basics are included here. For more information, consult the MSDN Online Web site at http://www.microsoft.com/msdn/.

Library Subscription
Professional Subscription
Universal Subscription

Library Subscription

Instant access to an encyclopedic collection of information is the key to the MSDN Library subscription. The MSDN Library delivers all the information you need to program for the Microsoft Windows® and Windows NT® operating systems and to create applications with Microsoft Office and BackOffice®. The Library includes a wide variety of technical articles, sample code, product documentation, the Microsoft Knowledge Base, select content from third-party periodicals, and Microsoft Press® books.

Library subscribers receive four quarterly editions in January, April, July, and October.

Choose the Library Subscription if:

  • You want to become more productive in your development efforts.

  • You want a centralized source of comprehensive and up-to-date information.

  • You want to learn how to incorporate the latest technologies from Microsoft into your own applications.

Getting Started with the Library

A good place to get acquainted with the Library is the liner-notes booklet included with every quarterly edition. Here you'll find information on how to install the Library, how to get online Help, and how to get technical support.

You can find information in the Library in three basic ways: browsing the table of contents (the Contents tab), using full-text queries to locate specific information (using the Search tab), and using the Index tab to look up information on functions, messages, and structures. One of the quickest ways to learn how to use the Library is to read the topics in MSDN Library Help, which is located under the Welcome to the MSDN Library topic in the table of contents. MSDN Library Help explains how to use the MSDN Library viewer, how to locate information in the Library, how to perform common tasks, and how to install and uninstall the viewer.

Library Licensing

All MSDN subscriptions include a single-user license for the Library.

Additional information about the licensing associated with MSDN subscriptions is available in the topic "MSDN Subscription Licensing."

Professional Subscription

The Professional Subscription goes beyond documentation and provides the latest Microsoft systems technology. In addition to the quarterly Library, all Professional subscribers receive a complete set of the latest released U.S. versions and international versions of Microsoft Windows 95, Windows 98, Windows NT Workstation operating systems (retail and debug) and Windows NT Server operating system, as well as software development kits (SDKs) and device driver kits (DDKs). We call this component the "Development Platform," and it is updated throughout the year via scheduled quarterly shipments and occasional interim shipments of important prereleases and final releases, such as future versions of Windows and Windows NT, as soon as they're ready.

As a Professional subscriber, you will receive:

  • All the benefits of the Library Subscription—quarterly editions of the MSDN Library CD set, bimonthly issues of the MSDN News newspaper (see note), a 20 percent discount on Microsoft Press books (see note), and your MSDN subscription card.

  • MSDN Development Platform—a complete set of Microsoft operating systems, SDKs, and DDKs with updates shipped throughout the year. Contents are arranged in three packs:
    • Development Platform—U.S. English-language versions of Microsoft operating systems (Windows 95, Windows 98, Windows NT Workstation, Windows NT Server) and SDKs, including Service Packs.

    • Development Platform—DDK Software for developing device drivers.

    • Development Platform—INTL Non-English versions of operating systems and SDKs.
  • Two priority phone-support incidents per year (see note).

Note For members in the United States and Canada only. Membership benefits vary from country to country—contact your local subsidiary for details.

Choose the Professional Subscription if:

  • You want to develop solutions with the latest versions of Windows and Windows NT, including important prerelease versions.

  • You want a comprehensive source of Microsoft SDKs and DDKs for API-level development.

Universal Subscription

The Universal Subscription was created especially for developing and testing Microsoft Office and BackOffice–based solutions. In addition to delivering the benefits of the Professional Subscription, the Universal Subscription includes Microsoft Visual Studio™ 6.0, Enterprise Edition, the BackOffice Test Platform, and the Office Test Platform (including Office Developer Edition, Microsoft FrontPage®, Microsoft Project, and more). Universal subscribers receive important releases—releases that come between quarterly shipments—as soon as they’re available.

Please note that Universal subscribers will receive Windows-based versions of Microsoft visual tools for the Intel® and RISC platforms only. (Macintosh®, and other versions of the visual tools, must be acquired separately.) Universal subscribers also receive select beta versions of the visual tools.

As a Universal subscriber, you will receive:

  • All the benefits of a Professional Subscription—quarterly editions of the MSDN Library CD, quarterly editions and interim releases of the Development Platform CDs, bimonthly issues of the MSDN News newspaper (see note), a 20 percent discount on Microsoft Press books (see note), and your MSDN subscription card.

  • BackOffice Test Platform: select servers from the BackOffice family, including (among others) Microsoft Windows NT Server, Microsoft SQL Server™, Systems Management Server, SNA Server, Internet Information Server, Exchange Server, Site Server, Commerce Server—all with a special development and test license.

  • Office Test Platform: Microsoft Office 97, Developer Edition; Microsoft Project; Microsoft FrontPage; and Microsoft Team Manager, all with a special development and test license.

  • Microsoft Visual Studio 6.0, Enterprise Edition, including: Microsoft Visual Basic®, Visual C++®, Visual FoxPro®, Visual J++™, Visual InterDev™, and Visual SourceSafe™. You'll also get any other development tools released during your subscription year.

  • The Office Test Platform & Development Tools pieces are arranged in four packs:
    • BackOffice Test Platform—U.S. English-language versions of select BackOffice family of server components with a special 10-connection, develop-and-test-only license restriction. Includes service packs and updates.

    • BackOffice Test Platform—INTL Non-English versions of select BackOffice components.

    • Office Test Platform & Development Tools—U.S. English-language versions of Office Developer Edition, FrontPage, Microsoft Project, Team Manager, and Visual Studio, Enterprise Edition.

    • Office Test Platform—INTL Non-English versions of Office Developer Edition (and Office Professional Edition when Developer Edition is not available), Project, and so on.
  • Two priority phone-support incidents per year (see note), plus two additional phone-support incidents for setup and configuration issues with BackOffice or Visual Tools (see note).

Note For members in the United States and Canada only. Membership benefits vary from country to country—contact your local subsidiary for details.

Choose the Universal Subscription if:

  • You want a single, comprehensive suite of Microsoft tools.

  • You need to stay up-to-date on development technologies from Microsoft.

  • You need to develop and test custom solutions with Microsoft BackOffice.

  • You are developing solutions using Microsoft Office or Microsoft Visual Studio.

Finding What You Need

To help you find the components you need, we've created an index listing the current contents and setup paths for all MSDN CDs. These indexes are located in the index.htm file on Disc 1 of the Development Platform—U.S. set. Each index is in table format and includes CD#, Date, Name, and Description and Setup Location fields that you can use to find the component you need. The most current indexes can also be found on our Web site: http://www.microsoft.com/msdn/services/subscription/index/.

MSDN Licensing

For information about the MSDN licensing agreement, please see "MSDN Subscription Licensing."

How to Subscribe to MSDN

For information on how to subscribe to MSDN, please see "How to Subscribe to MSDN."


How to Subscribe to MSDN

MSDN™ Subscriptions provide timely, convenient access to the essential technical programming information, developer products, and tools that developers need to be successful.

In the United States and Canada:

For the name of a reseller near you or to order directly from Microsoft:
(800) 759-5474, Dept. MLIBRARY
6:30 a.m. to 5:30 p.m. (Pacific time), Monday through Friday

Current subscription offers and pricing information can be found at http://www.microsoft.com/msdn/join/pricing.htm.

Outside of the United States and Canada:

For a complete list of phone numbers and contact information for MSDN around the world, go to http://www.microsoft.com/msdn/services/msdncs.htm. If your country is not listed, call this U.S. number for ordering information: (510) 275-0763.

Note MSDN program benefits may vary by country/region.

©1998 Microsoft Corporation. All rights reserved. Contents of the MSDN Subscription program contents, benefits, pricing, and terms are subject to change without notice. Renewals or upgrades will be processed according to the subscription terms offered at the time of the renewal or upgrade.


MSDN Subscription Licensing

This topic generally explains the licensing of the MSDN™ Library, Professional, and Universal subscriptions. For actual license terms for the Library, Development Platform, BackOffice® Test Platform, and Office Test Platform and Development Tools, please refer to license.txt located in the root directory of Disc 1 – Setup in the MSDN Library CD set, or go to the License Agreement online at http://www.microsoft.com/msdn/services/subscription/eula.htm.

What Does the MSDN License Allow?

MSDN Subscriptions include a single-user license for the Library, the Development Platform, the BackOffice Test Platform, and the Office Test Platform and Development Tools. The licensee is a specific individual, either the subscriber or a designated individual if the subscriber is an entity. The software may be used for designing, developing, and testing applications that operate in conjunction with the Microsoft® Windows® and Windows NT® platforms. The software is not licensed for production use, and as such you will need to acquire separate, fully licensed versions of several MSDN component products if you wish to use them for purposes other than designing, developing, and testing your software products. The following information is a very general overview of the licensing terms—you should refer to the MSDN Master End-User License Agreement for details.

Library-specific Licensing Terms

The Library is licensed to a single user, as defined above. The licensee may install the software necessary for viewing the Library on up to ten (10) computers used solely by the licensee to view and use the contents of the Library as described in the end-user license agreement. The licensee is also licensed to print and make copies of content from the Library as long as it is used for personal use and not redistributed beyond the licensee's premises. Additional licenses for the MSDN Library are not available direct from Microsoft; they must be obtained through your local software reseller via the Microsoft Open License Program (MOLP).

Development Platform–specific Licensing Terms

The Development Platform is licensed to a single user, as defined above. The licensee is licensed to install the software included on the Development Platform on up to ten (10) computers, as long as the software is used only by the licensee. Individual software components on the Development Platform may have additional licensing terms specified in the component software.

BackOffice Test Platform–specific Licensing Terms

The BackOffice Test Platform includes additional licensing terms:

  • The BackOffice Test Platform comes with a license for ten (10) simultaneous connections to be used exclusively for development and testing purposes. Components of the BackOffice Test Platform are hard-coded to accept no more than ten (10) connections at any one time.

  • The BackOffice server software products delivered on the BackOffice Test Platform may be installed only on a single computer.

  • The BackOffice server products may be used solely for the development and testing of applications. The server software components are not to be used as production BackOffice servers that are accessible to nondevelopment and testing clients.

  • The BackOffice Test Platform may not to be used for supporting team development (for example, as a file server for storing source code).

Office Test Platform and Development Tools–specific Licensing Terms

The Office Test Platform and Development Tools are licensed to a single user for development and test purposes. Use of many of the development tools is governed by product-specific end-user license agreements contained in those products.

Availability and Information

In the United States and Canada contact your local reseller or call the MSDN Service Center at (800) 759-5474, 6:30 a.m. to 5:30 p.m. (Pacific time), Monday through Friday, to get more information or to subscribe. Outside the United States and Canada, contact your local Microsoft subsidiary for additional information.


MSDN Support Policy

In the United States and Canada

  • Library setup and configuration: MSDN offers unlimited, no-charge support for assistance with setup and configuration of the MSDN™ Library CD only, please call (425) 635-7033, Monday through Friday, 6:00 a.m. to 6:00 p.m. (Pacific time).

  • Professional subscribers receive two Priority Developer Support incidents for software shipped as part of the Development Platform.

  • Universal subscribers receive two Priority Developer Support incidents for Development Platform software, plus two incidents for BackOffice Test Platform and/or Visual tools setup and configuration.

To use the Priority Support pack included with your subscription, call (800) 936-5800, 24 hours a day, 7 days a week. You must have your subscription number ready when you call. (This number can be found on your MSDN subscription card.)

Outside the United States and Canada

Please contact your local Microsoft subsidiary to inquire about the technical support options available in your country.


How to Send Us Feedback

Who drives the improvements you see in the MSDN™ program? Why, you do, of course! Yeah, yeah, we're busy too, but take a minute to tell us what you want to see anyway. You will be so very glad you did when we implement your idea. Send your suggestions to us at msdn@microsoft.com.

We are very interested in hearing your feedback about any of our products and about MSDN as a whole. Let us hear from you.


MSDN Library Comprehensive Index for All Subscription Levels

To help you find the components you need, we've created an index listing the current contents and setup paths for MSDN CDs that are shipped with the Professional and Universal Subscriptions. Each index is in table format and includes CD#, Date, Product Name, and Description and Setup Location fields that you can use to find the component you need.

The most current indexes can be found on our Web site at http://www.microsoft.com/msdn/services/subscription/index/.


How to Become a Microsoft Certified Solution Developer

The Microsoft® Certified Professional Program provides a way for developers to prove their command of current Microsoft products and technologies—Microsoft Certified Solution Developer (MCSD) certification. Microsoft Certified Solution Developers are qualified to design and develop custom business solutions using Microsoft development tools and technologies.

To become a Microsoft Certified Solution Developer, you must pass a series of rigorous certification exams that provide a valid and reliable measure of technical proficiency and expertise. These exams are developed with the input of professionals in the industry and reflect how Microsoft products are used in organizations throughout the world. The exams are administered by an independent organization—Sylvan Prometric—at more than 600 Prometric Authorized Testing Centers around the world.

The Microsoft Roadmap to Education and Certification contains complete information about the Microsoft Certified Professional program, including specific core and elective exam requirements for the MCSD certification. (To obtain the Roadmap, see the "For More Information" section below.)

Certification Requirements
MCSD Exam Preparation
Exam Registration
Benefits of Becoming Certified
For More Information

Certification Requirements

Microsoft Certified Solution Developers are required to pass two core technology exams and two elective exams. The core technology exams require candidates to prove their understanding of Microsoft Windows® 32-bit architecture, OLE, UI design, and Windows Open Services Architecture (WOSA) components. The elective exams require proof of expertise with Microsoft development tools. The requirements are outlined below.

MCSD Core Technology Requirements (two exams) |
Exam 70-150: | Microsoft Windows Operating Systems and Services Architecture I
Exam 70-151: | Microsoft Windows Operating Systems and Services Architecture II
MCSD Electives (two exams)* |
Exam 70-21: | Microsoft SQL Server™ 4.2 Database Implementation
Exam 70-24: | Developing Applications with C++ Using the Microsoft Foundation Class Library
Exam 70-27: | Implementing a Database Design on Microsoft SQL Server 6
Exam 70-50: | Microsoft Visual Basic® 3.0 for Windows-Application Development
Exam 70-51: | Microsoft Access 2.0 for Windows–Application Development
Exam 70-52: | Developing Applications with Microsoft Excel 5.0 Using Visual Basic for Applications
Exam 70-54: | Programming in Microsoft Visual FoxPro® 3.0 for Windows

* Additional elective exams will be made available on an ongoing basis.

Microsoft Official Curriculum for MCSD Exam Preparation

Microsoft Official Curriculum courses can help you gain the skills needed for certification. These courses are available through Microsoft Authorized Technical Education Centers (ATECs) in both instructor-led and self-paced formats. For referrals to ATECs, call (800) SOL-PROV. Outside the United States and Canada, please contact your local Microsoft office.

Exam Registration

Sylvan Prometric administers all Microsoft Certified Professional Exams. You must register with Sylvan prior to scheduling an exam. Exams may be taken at any of the more than 600 Prometric Authorized Testing Centers around the world.

Have the following information available when you register:

  • Name

  • Unique ID number. This is usually your Social Security or Social Insurance number. However, Sylvan will create and assign a Sylvan ID number for you if you prefer.

  • Mailing address and phone number

  • Organization or company name

  • Number of the exam you plan to take

  • Method of payment (credit card number or check)

Note Payment is due before an examination will be scheduled.

To register for an exam in the United States or Canada, please call Sylvan Prometric at (800) 755-EXAM or (800) 755-3926. For locations outside the U.S. and Canada, consult the table below.

Location | Phone Number
Argentina | Contact your local Prometric Authorized Training Center or Microsoft subsidiary.
Australia | 008-808-657 (toll-free)
Austria | 0660-8582 (toll-free)
Belgium | 078-11-7414 (toll-free)
Brazil | Contact your local Prometric Authorized Training Center or Microsoft subsidiary.
Caribbean | Contact your local Prometric Authorized Training Center or Microsoft subsidiary.
Chile | Contact your local Prometric Authorized Training Center or Microsoft subsidiary.
Colombia | Contact your local Prometric Authorized Training Center or Microsoft subsidiary.
Czech Republic | 49-211-500-990
Denmark | 44-71-437-6900
Ecuador | Contact your local Prometric Authorized Training Center or Microsoft subsidiary.
Finland | 44-71-437-6900
France | 33-14289-8749
Germany | 49-211-500-990
Germany | 0130-83-9708 (toll-free)
Greece | 44-71-437-6900
Hong Kong SAR, China | 00-6375 (toll-free)
Hungary | 49-211-500-990
Indonesia | 008-006-1571 (toll-free)
Ireland | 44-71-437-6900
Israel | 44-71-437-6900
Italy | 1-6787-8441 (toll-free)
Japan | 81-3-3280-7484
Korea | 007-8611-3095 (toll-free)
Malaysia | 800-2122 (toll-free)
Mexico | Contact your local Prometric Authorized Training Center or Microsoft subsidiary.
Middle East | 44-71-437-6900
Netherlands | 06-022-7584 (toll-free)
New Zealand | 080-044-1603 (toll-free)
Norway | 44-71-437-6900
Peru | Contact your local Prometric Authorized Training Center or Microsoft subsidiary.
Philippines | 102-718-0061-02161 (toll-free)
Poland | 49-211-500-990
Portugal | 33-1-4289-8749
Puerto Rico | 800-755-3926 (toll-free)
Russia | 49-211-500-990
Singapore | 800-6071 (toll-free)
Slovakia | 49-211-500-990
South Africa | 44-71-437-6900
Spain | 33-1-4289-8749
Sweden | 44-71-437-6900
Switzerland | 155-6966
Taiwan Region | 008-061-1142 (toll-free)
Thailand | 001-800-612-283 (toll-free)
Turkey | 44-71-437-6900
United Kingdom | 0800-592-873
Venezuela | Contact your local Prometric Authorized Training Center or Microsoft subsidiary.

If your country/region is not listed above, call the Sylvan Regional Service Center nearest you, from the list below.

Australia | 61-2-414-3666
France | 33-1-4289-8749
United Kingdom | 44-71-437-6900
United States | 612-921-4191

Benefits of Becoming a Microsoft Certified Solution Developer

As a Microsoft Certified Solution Developer, you receive the following benefits:

  • Industry recognition of your knowledge and proficiency with Microsoft products and technologies.

  • Access to technical information directly from Microsoft. Microsoft Certified Solution Developers receive a discount toward a one-year MSDN™ Library or Professional subscription in the U.S. and Canada (worldwide implementation to follow.) MSDN subscriptions provide valuable development resources via direct, CD-based delivery of technical information, tools, and technology. For more information on MSDN, the Microsoft Developer Network, go to http://www.microsoft.com/msdn/.

  • Ten free Priority Development and Desktop incidents with Microsoft Product Support and a 25 percent discount on purchases of additional Priority Development and Desktop support incident 10-packs. You gain access to support for any Microsoft product, 7 days a week, 24 hours a day. This provides the opportunity—when you need it—to resolve customer issues with the help of Microsoft’s Product Support Engineers.

  • A one-year subscription to the Microsoft Beta Evaluation program. This benefit provides you with up to 12 free monthly CDs containing beta software (English-only) for many of Microsoft’s newest software products, allowing you to become familiar with new versions of Microsoft products before they are generally available. This benefit also includes access to a private CompuServe forum where you can exchange information with other program members and find information from Microsoft on current beta issues and product information.

  • A free subscription to the Microsoft Certified Professional Magazine, a career and professional development magazine created especially for Microsoft Certified Professionals.

  • Microsoft Certified Solution Developer logos and other materials to let you indicate your Microsoft Certified Solution Developer status to colleagues or clients.

  • A dedicated CompuServe forum that allows Microsoft Certified Professionals to communicate directly with Microsoft and one another.

  • A quarterly newsletter from the Microsoft Certified Professional program, keeping you informed of changes and advances in the program and exams.

  • Invitations to Microsoft conferences, technical training sessions, and special events.

Note Not all benefits are available worldwide. Please check with your local Microsoft office to confirm available benefits in your country/region.

For More Information

For additional information on how to become a Microsoft Certified Solution Developer, please call Microsoft at one of the numbers below and request a copy of the Microsoft Roadmap to Education and Certification.

United States | (800) 636-7544
Canada | (800) 563-9048
Outside the U.S. and Canada | Contact your local Microsoft subsidiary.

The Microsoft Roadmap to Education and Certification can also be found on CompuServe in the Microsoft Education and Certification forum (GO MSEDCERT, Library #5) or via the Internet at Microsoft's FTP site, ftp.microsoft.com, in the \MSEdCert directory.

For Microsoft training and certification information on the Web, connect to http://www.microsoft.com/train_cert/default.htm.

For referrals to Microsoft Solution Provider Authorized Technical Education Centers, please call:

United States | (800) SOL-PROV
Canada | (800) 563-9048
Outside the U.S. and Canada | Contact your local Microsoft subsidiary.


Microsoft Press Technical Reference Books

Gene Hobbs
Microsoft Press

Updated: February 10, 1998

Microsoft Press® is the independent book division of Microsoft Corporation and the leading publisher of quality computer books. More than 10 million users at all skill levels rely on the complete line of Microsoft Press books to make learning, using, programming, and developing software easier.

Contents

Microsoft Press Ordering Information
C/C++ Languages and MFC
General Programming
Internet Development
Jet Database Engine
Miscellaneous Developer Topics
ODBC
OLE
Microsoft Visual Basic

Microsoft Press Ordering Information

When you order a Microsoft Press book, you must reference customer service code DHW and your MSDN membership number to receive your 20-percent discount (United States and Canada only).

There are two easy ways to order:

  • By phone:

    • In the United States, call (800) 677-7377 (and press option 2) from 7 a.m. to 9 p.m. Central time.
    In Canada, call (800) 268-2222.

  • Mail your order with prepayment to:
    • In the United States | Microsoft Press P.O. Box 141875 Austin, TX 78714-1875
In Canada | Microsoft Press c/o ITP Nelson 1120 Birchmount Road Scarborough, Ontario Canada M1K 5G4
In Europe | Please visit http://www.microsoft.com/europe/msdn/books/ for further information and ordering instructions.
In all other countries | Please visit http://mspress.microsoft.com/intl/intl.htm for a list of distributors worldwide. Please contact the distributor in your country to locate a reseller nearest you.

Order information required for order by mail:

  • Accurate book title, ISBN number, quantity, and total price, including shipping charges and applicable sales tax. (Shipping charges will be taxed.)

  • Your name, address (no P.O. boxes, please), city, state, ZIP, and daytime telephone number (in case there is a problem with your order).

  • Payment method (U.S. funds only): check, money order, VISA, MasterCard, or American Express. Please include expiration date on all credit card orders.

  • Refer to your customer service code DHW and your MSDN membership number to receive your 20 percent discount (in the United States and Canada only).

Shipping Charges

U.S. Shipping
Order Subtotal | U.S. Shipping Charges
$0—$30.00 | $ 5.95
$30.01—$60.00 | $ 7.95
$60.01—$90.00 | $ 9.95
$90.01—$150.00 | $12.95
$150.01—$250.00 | $15.95
$250.01+ | $19.95

All orders within the United States (except APO/FPO) will be shipped via UPS 2nd day air the day your order is received and entered (subject to stock availability). APO/FPO orders will be shipped via U.S. Postal Service and take approximately five working days for delivery. Overnight express shipping is available. Charges vary by weight and destination; a $10 rush fee will be added. Please call (800) 677-7377 for more information.

Sales Tax
State sales tax will be charged on your order subtotal, including shipping charges, in the following: AR, AZ, CA, CO, CT, DC, DE, FL, GA, HI, IA, ID, IL, IN, KS, KY, LA, MA, MD, ME, MI, MN, MO, MS, NC, ND, NE, NJ, NM, NV, NY, OH, OK, PA, RI, SC, SD, TN, TX, UT, VA, VT, WA, WI, WV, and WY.

All Microsoft Press books are backed by an unconditional 30-day money-back guarantee. Original proof of purchase is required.

All prices, states of taxation, availability dates, and shipping charges are subject to change without notice.

C/C++ Languages and MFC

3D Graphics Programming for Windows® 95

By: Nigel Thompson
Price: $ 34.95 US
Length: 400
ISBN: 1-57231-345-5

Release Date: 9/17/96

Written by a savvy Microsoft insider, 3D GRAPHICS PROGRAMMING FOR WINDOWS 95 teaches you to use the Direct3D Application Programming Interface (API) to deliver real-time three-dimensional graphics to mainstream PC users.

ActiveXTM Controls Inside Out, Second Edition

By: Adam Denning
Price: $ 39.95 US
Length: 672
ISBN: 1-57231-350-1

Release Date: 1/8/97

ACTIVEX CONTROLS INSIDE OUT is an in-depth guide for C++ and Microsoft® Visual Basic® programmers who want to build powerful custom controls and "componentware" using Microsoft's new tools and revolutionary COM (Component Object Model) technology.

Code Complete

By: Steve McConnell
Price: $ 35 US
Length: 896
ISBN: 1-55615-484-4

Release Date: 9/14/95

This runaway bestseller is a practical guide to software design that discusses the art and science of constructing software. Examples are provided in C, PascalTM, Basic, FORTRAN, and Ada, but the focus is on successful programming techniques.

Debugging the Development Process

By: Steve Maguire
Price: $ 24.95 US
Length: 216
ISBN: 1-55615-650-2

Release Date: 8/9/94

Steve Maguire gives you a compelling look at the software development process using candid accounts of his experience at Microsoft. He describes how to bring together and maintain effective teams and develop timely, high-quality commercial applications.

Developing Applications for Microsoft® Exchange with C++

By: Ben Goetter
Price: $ 39.99 US
Length: 592
ISBN: 1-57231-500-8

Release Date: 11/20/96

Hardcore programmers--release the full potential of Microsoft Exchange! This is the guidebook and essential reference to the technical underpinnings of Microsoft Exchange--and the key to great workgroup applications.

Dynamics of Software Development

By: Jim McCarthy
Price: $ 24.95 US
Length: 208
ISBN: 1-55615-823-8

Release Date: 8/26/95

Author Jim McCarthy insists that shipping great software on time can be done, and this book tells you how. DYNAMICS OF SOFTWARE DEVELOPMENT, destined to be a cult classic, charts the progress from initial design to successful product.

Inside COM

By: Dale Rogerson
Price: $ 34.99 US
Length: 416
ISBN: 1-57231-349-8

Release Date: 12/27/96

To understand distributed computing, OLE, ActiveXTM, and customizing Microsoft applications, you must understand the Component Object Model (COM). This concise, accessible guide is your key to COM and to building simple, elegant COM components...

Inside OLE, 2nd Edition

By: Kraig Brockschmidt
Price: $ 49.95 US
Length: 1232
ISBN: 1-55615-843-2

Release Date: 6/12/95

Kraig Brockschmidt uses disc-based examples to show you the principles of OLE, including structured storage, OLE Automation, and in-place activation. He builds sample programs using OLE-based code you can incorporate into your own applications.

Inside Visual C++®, Fourth Edition

By: David Kruglinski
Price: $ 49.99 US
Length: 1040
ISBN: 1-57231-565-2

Release Date: 6/4/97

Building on the solid achievements of three previous editions, INSIDE VISUAL C++, FOURTH EDITION presents detailed and comprehensive coverage of Visual C++ and the intricacies of 32-bit programming in Windows. This book offers by far the best overall explanation of the capabilities of Microsoft's powerful and complex development tool.

Learn Microsoft® Visual Basic® Scripting Edition Now

By: Gary Cornell
Price: $ 34.95 US
Length: 336
ISBN: 1-57231-347-1

Release Date: 12/23/97

There is one best way to get Microsoft's powerful scripting language for the Internet and Windows 95 working for you today--LEARN MICROSOFT VISUAL BASIC SCRIPTING EDITION NOW.

Learn Visual C++® Now

By: Mark Andrews
Price: $ 39.95 US
Length: 480
ISBN: 1-55615-845-9

Release Date: 5/14/96

LEARN VISUAL C++ NOW will help you master the powerful visual tools and automated features in Visual C++. On CD-ROM, you get a complete working Visual C++ compiler (version 1.0) that will equip you to create your own applications.

MFC Developer's Workshop

By: Microsoft Corporation
Price: $ 39.99 US
Length: 456
ISBN: 1-57231-511-3

Release Date: 4/30/97

MFC DEVELOPER'S WORKSHOP is the first book to provide developer-driven, task-oriented relief for those using the MFC library to program for Microsoft® Windows®. It targets troublesome, frequently encountered tasks--and provides solutions for them. Topics range from UI and ActiveXTM to database development.

Microsoft Press® Programmer's Bookshelf for Windows® 95

By: Microsoft Press
Price: $ 69.95 US
Length:
ISBN: 1-57231-311-0

Release Date: 6/13/96

Now you can access five important programming books for Windows 95 on a single CD-ROM! Includes the full content of Programming Windows 95 (Microsoft Press, 1996), by Charles Petzold; Advanced Windows (Microsoft Press, 1996), by Jeffrey Richter; Developing International Software for Windows 95 and Windows NT® (Microsoft Press, 1996) by Nadine Kano; OLE Controls Inside Out (Microsoft Press, 1996), by Adam Denning; and Programming the Windows 95 User Interface (Microsoft Press, 1995), by Nancy Winnick Cluts.

Microsoft® Access 97 Developer's Handbook

By: Microsoft Corporation
Price: $ 39.99 US
Length: 624
ISBN: 1-57231-358-7

Release Date: 2/26/97

This is the book for everyone who wants to use Microsoft Access 97 and its built-in Visual Basic® for Applications (VBA) 32-bit programming language to develop and distribute information systems, custom interfaces, and custom database applications.

Microsoft® Excel 97 Developer's Handbook

By: Micro Modeling Associates, Inc.
Price: $ 39.99 US
Length: 656
ISBN: 1-57231-359-5

Release Date: 5/7/97

With Microsoft Excel 97 and its built-in Microsoft Visual Basic® for Applications (VBA) 32-bit programming language, you can build and distribute professional-quality access and analysis tools. This easy-to-read, clearly illustrated book shows you how.

Microsoft® Visual Basic® 5.0 Developer's Workshop, Fourth Edition

By: John Craig
Price: $ 44.99 US
Length: 752
ISBN: 1-57231-436-2

Release Date: 5/14/97

MICROSOFT VISUAL BASIC 5.0 DEVELOPER'S WORKSHOP is a one-of-a-kind book-and-software package that gives you the recipes to build powerful, full-featured graphical applications for Windows® 95 and Windows NT®. This book demonstrates everything from creating a screen saver to building ActiveX controls that can be used in a Web page.

Microsoft® Visual C++® Language Reference

By: Microsoft Corporation
Price: $ 29.99 US
Length: 768
ISBN: 1-57231-521-0

Release Date: 3/26/97

Within the four-volume Microsoft Visual C++ 5.0 Programmer’s Reference Set, this is the C, C++, and preprocessor reference for the Microsoft Visual C++ development system. All volumes in the Reference Set are available separately.

Microsoft® Visual C++® MFC Library Reference, Part 1

By: Microsoft Corporation
Price: $ 39.99 US
Length: 1456
ISBN: 1-57231-518-0

Release Date: 4/9/97

Within the four-volume Microsoft Visual C++ 5.0 Programmer’s Reference Set, this is the first of two volumes that completely describe the classes, macros, and global functions and variables in the Microsoft Foundation Class (MFC) library. All volumes in the Reference Set are available separately.

Microsoft® Visual C++® MFC Library Reference, Part 2

By: Microsoft Corporation
Price: $ 39.99 US
Length: 1392
ISBN: 1-57231-519-9

Release Date: 4/9/97

Within the four-volume Microsoft Visual C++ 5.0 Programmer’s Reference Set, this is the second of two volumes that completely describe the classes, macros, and global functions and variables in the Microsoft Foundation Class (MFC) library. All volumes in the Reference Set are available separately.

Microsoft® Visual C++® Owner's Manual

By: Beck Zaratian
Price: $ 39.99 US
Length: 640
ISBN: 1-57231-510-5

Release Date: 6/4/97

Become a proficient user of Visual C++ with this complete user's guide to Developer StudioTM and the Microsoft Visual C++ programming tools. Here’s all the background you need--including a comprehensive look at the redesigned development environment of version 5.0.

Microsoft® Visual C++® Run-Time Library Reference

By: Microsoft Corporation
Price: $ 39.99 US
Length: 1328
ISBN: 1-57231-520-2

Release Date: 4/2/97

Within the four-volume Microsoft Visual C++ 5.0 Programmer’s Reference Set, this is the volume that completely describes all the functions and parameters in the Microsoft Visual C++ iostream class and run-time libraries. All volumes in the Reference Set are available separately.

Programming Windows® 95 with MFC

By: Jeff Prosise
Price: $ 49.95 US
Length: 1024
ISBN: 1-55615-902-1

Release Date: 5/28/96

Delving deep into the structure of the Microsoft Foundation Class Library (MFC), Jeff Prosise reveals how you can create code once and use it again and again. If you write applications for Microsoft Windows, MFC will transform the way you work.

Systems Programming for Windows® 95

By: Walter Oney
Price: $ 39.95 US
Length: 720
ISBN: 1-55615-949-8

Release Date: 7/9/96

This one-of-a-kind book is a practical, authoritative real-world guide to writing system-level code for Microsoft Windows 95. Includes a CD-ROM with valuable documentation, sample code, and utilities.

Windows® Interface Guidelines for Software Design, The

By: Microsoft Corporation
Price: $ 29.95 US
Length: 576
ISBN: 1-55615-679-0

Release Date: 7/11/95

If you develop applications for Windows and want to save training time, boost productivity, and promote user confidence, here are Microsoft's official guidelines for designing visually and functionally consistent user interfaces for Windows-based programs.

Writing Solid Code

By: Steve Maguire
Price: $ 24.95 US
Length: 288
ISBN: 1-55615-551-4

Release Date: 6/6/95

Here, from a former Microsoft developer, are super secrets for developing bug-free C programs. You'll see examples of how bugs are caught at Microsoft (actual case histories) and how to use these proven programming techniques to get products to market faster.

General Programming

Active Visual J++TM

By: Scott Ladd
Price: $ 39.99 US
Length: 352
ISBN: 1-57231-609-8

Release Date: 8/6/97

Use this book to grasp the unmatched power and compatibility of Microsoft Visual J++ and go beyond Java's Web-based roots. See how to combine important technologies-Application Foundation Classes (AFC), Java, and ActiveXTM-to create awesome, interactive Web and intranet applications. CD-ROM included.

Automation Programmer's Reference

By: Microsoft Corporation
Price: $ 24.99 US
Length: 496
ISBN: 1-57231-584-9

Release Date: 2/26/97

This is the comprehensive and official reference documentation on Automation! Use it to discover how ActiveX and OLE can multiply the power, the usefulness, and the value of all your applications for Microsoft Windows® 95 and Microsoft Windows NTTM.

Client/Server Programming with Microsoft® Visual Basic®

By: Kenneth Spencer
Price: $ 34.95 US
Length: 304
ISBN: 1-57231-232-7

Release Date: 7/16/96

CLIENT/SERVER PROGRAMMING WITH MICROSOFT VISUAL BASIC teaches you easy ways to build effective, robust client/server applications using Visual Basic 4, along with helping you maximize its new remote OLE automation capabilities.

Code Complete

By: Steve McConnell
Price: $ 35 US
Length: 896
ISBN: 1-55615-484-4

Release Date: 9/14/95

This runaway bestseller is a practical guide to software design that discusses the art and science of constructing software. Examples are provided in C, PascalTM, Basic, FORTRAN, and Ada, but the focus is on successful programming techniques.

Communications Programming for Windows® 95

By: Charles Mirho
Price: $ 39.95 US
Length: 320
ISBN: 1-55615-668-5

Release Date: 5/29/96

COMMUNICATIONS PROGRAMMING FOR WINDOWS 95 explains from the ground up the two most important communications components in Windows: the Telephony API (TAPI) and the Messaging API (MAPI). The book also includes valuable advice for adding communications capabilities to existing software applications.

Debugging the Development Process

By: Steve Maguire
Price: $ 24.95 US
Length: 216
ISBN: 1-55615-650-2

Release Date: 8/9/94

Steve Maguire gives you a compelling look at the software development process using candid accounts of his experience at Microsoft. He describes how to bring together and maintain effective teams and develop timely, high-quality commercial applications.

Developing International Software for Windows® 95 and Windows NT®

By: Nadine Kano
Price: $ 35 US
Length: 768
ISBN: 1-55615-840-8

Release Date: 6/2/95

Localize programs more easily, more quickly, and less expensively with this collection of critical reference material plus Microsoft's own guidelines for creating international software. It contains international standards and information on the culture-specific issues you need to consider when developing international software.

Dynamics of Software Development

By: Jim McCarthy
Price: $ 24.95 US
Length: 208
ISBN: 1-55615-823-8

Release Date: 8/26/95

Author Jim McCarthy insists that shipping great software on time can be done, and this book tells you how. DYNAMICS OF SOFTWARE DEVELOPMENT, destined to be a cult classic, charts the progress from initial design to successful product.

Inside COM

By: Dale Rogerson
Price: $ 34.99 US
Length: 416
ISBN: 1-57231-349-8

Release Date: 12/27/96

To understand distributed computing, OLE, ActiveXTM, and customizing Microsoft applications, you must understand the Component Object Model (COM). This concise, accessible guide is your key to COM and to building simple, elegant COM components...

Inside the Registry for Microsoft® Windows® 95

By: Günter Born
Price: $ 24.99 US
Length: 368
ISBN: 1-57231-424-9

Release Date: 1/22/97

Here’s a clear, straightforward look at one of the least documented aspects of the Microsoft Windows 95 operating system. This is the indispensable information--and safety net--that every developer, system administrator, troubleshooter, and advanced user needs.

Inside Visual C++®, Fourth Edition

By: David Kruglinski
Price: $ 49.99 US
Length: 1040
ISBN: 1-57231-565-2

Release Date: 6/4/97

Building on the solid achievements of three previous editions, INSIDE VISUAL C++, FOURTH EDITION presents detailed and comprehensive coverage of Visual C++ and the intricacies of 32-bit programming in Windows. This book offers by far the best overall explanation of the capabilities of Microsoft's powerful and complex development tool.

Learn Visual C++® Now

By: Mark Andrews
Price: $ 39.95 US
Length: 480
ISBN: 1-55615-845-9

Release Date: 5/14/96

LEARN VISUAL C++ NOW will help you master the powerful visual tools and automated features in Visual C++. On CD-ROM, you get a complete working Visual C++ compiler (version 1.0) that will equip you to create your own applications.

Microsoft Press® Programmer's Bookshelf for Windows® 95

By: Microsoft Press
Price: $ 69.95 US
Length:
ISBN: 1-57231-311-0

Release Date: 6/13/96

Now you can access five important programming books for Windows 95 on a single CD-ROM! Includes the full content of Programming Windows 95 (Microsoft Press, 1996), by Charles Petzold; Advanced Windows (Microsoft Press, 1996), by Jeffrey Richter; Developing International Software for Windows 95 and Windows NT® (Microsoft Press, 1996) by Nadine Kano; OLE Controls Inside Out (Microsoft Press, 1996), by Adam Denning; and Programming the Windows 95 User Interface (Microsoft Press, 1995), by Nancy Winnick Cluts.

Microsoft® Access/Visual Basic® Step by Step

By: Evan Callahan
Price: $ 29.95 US
Length: 368
ISBN: 1-55615-890-4

Release Date: 12/18/95

Learn to build personalized and customized Microsoft Access solutions the easy way with MICROSOFT ACCESS/VISUAL BASIC STEP BY STEP. Includes 15 self-paced lessons with disk-based practice files so you can learn at your own pace.

Microsoft® ODBC 3.0 Software Development Kit and Programmer's Reference

By: Microsoft Corporation
Price: $ 99.99 US
Length: 1488
ISBN: 1-57231-516-4

Release Date: 2/26/97

This is the kit that gives developers everything they need for using the Open Database Connectivity (ODBC) standard to build robust database connectivity into their applications.

Microsoft® Office 97, Developer Edition, Resource Library

By: Christine Solomon
Price: $ 99.99 US
Length: 1888
ISBN: 1-57231-606-3

Release Date: 6/11/97

Microsoft Office 97, Developer Edition is a terrific development platform. To get the most from it, apply the powerful development strategies you'll find in this indispensable three-volume resource set. The accompanying CD-ROM contains all sample code from all three books.

Microsoft® Office 97/Visual Basic® Language Reference

By: Microsoft Corporation
Price: $ 129.99 US
Length: 4848
ISBN: 1-57231-339-0

Release Date: 3/26/97

It’s the Official Technical Reference to Visual Basic for Applications! And it’s your key to rolling out, deploying, administering, and developing for Microsoft Office 97--whether you’re creating custom applications or modifying the existing applications.

Microsoft® Office 97/Visual Basic® Programmer's Guide

By: Microsoft Corporation
Price: $ 34.99 US
Length: 560
ISBN: 1-57231-340-4

Release Date: 12/27/96

Microsoft Office 97 is the newest version of the world’s most popular office suite--and a powerful development environment. This book shows everyone--from professional developers to power users--how to make the most of it.

Microsoft® Visual Basic® 5.0 Programmer's Guide

By: Microsoft Corporation
Price: $ 29.99 US
Length: 912
ISBN: 1-57231-604-7

Release Date: 2/26/97

For beginning Visual Basic users or experienced developers, this is the comprehensive guide to Visual Basic programming. Straight from the Microsoft Visual Basic product team, the PROGRAMMER'S GUIDE covers everything from programming fundamentals and "Your First Visual Basic Program" to optimizing and distributing applications.

Microsoft® Visual Basic®, Deluxe Learning Edition

By: Microsoft Corporation
Price: $ 129.99 US
Length: 1278
ISBN: 1-57231-551-2

Release Date: 3/26/97

MICROSOFT VISUAL BASIC DELUXE LEARNING EDITION is a comprehensive training kit that will teach you how to put Microsoft Visual Basic to work. The kit contains the complete version of Visual Basic 5.0 Learning Edition, and is the easiest way to learn to use it.

Microsoft® Visual C++® Language Reference

By: Microsoft Corporation
Price: $ 29.99 US
Length: 768
ISBN: 1-57231-521-0

Release Date: 3/26/97

Within the four-volume Microsoft Visual C++ 5.0 Programmer’s Reference Set, this is the C, C++, and preprocessor reference for the Microsoft Visual C++ development system. All volumes in the Reference Set are available separately.

Microsoft® Visual C++® MFC Library Reference, Part 1

By: Microsoft Corporation
Price: $ 39.99 US
Length: 1456
ISBN: 1-57231-518-0

Release Date: 4/9/97

Within the four-volume Microsoft Visual C++ 5.0 Programmer’s Reference Set, this is the first of two volumes that completely describe the classes, macros, and global functions and variables in the Microsoft Foundation Class (MFC) library. All volumes in the Reference Set are available separately.

Microsoft® Visual C++® MFC Library Reference, Part 2

By: Microsoft Corporation
Price: $ 39.99 US
Length: 1392
ISBN: 1-57231-519-9

Release Date: 4/9/97

Within the four-volume Microsoft Visual C++ 5.0 Programmer’s Reference Set, this is the second of two volumes that completely describe the classes, macros, and global functions and variables in the Microsoft Foundation Class (MFC) library. All volumes in the Reference Set are available separately.

Microsoft® Visual C++® Run-Time Library Reference

By: Microsoft Corporation
Price: $ 39.99 US
Length: 1328
ISBN: 1-57231-520-2

Release Date: 4/2/97

Within the four-volume Microsoft Visual C++ 5.0 Programmer’s Reference Set, this is the volume that completely describes all the functions and parameters in the Microsoft Visual C++ iostream class and run-time libraries. All volumes in the Reference Set are available separately.

Microsoft® Windows® 95 Help Authoring Kit

By: Microsoft Corporation
Price: $ 49.95 US
Length: 336
ISBN: 1-55615-892-0

Release Date: 11/7/95

The MICROSOFT® WINDOWS® 95 HELP AUTHORING KIT is an invaluable source for beginning and veteran Help authors, providing all the information and software needed to create online help files for Windows 95 applications (also for earlier versions of Windows and Windows NTTM version 3.51 or later).

PC 98 System Design Guide

By: Microsoft Corporation
Price: $ 29.99 US
Length: 672
ISBN: 1-57231-716-7

Release Date: 10/15/97

This book provides the latest, most authoritative guidelines for everyone who's creating next-generation PCs, components, peripherals, and device drivers. And that makes PC 98 SYSTEM DESIGN GUIDE the must-have reference you'll want to keep close at hand.

Programming Windows® 95

By: Charles Petzold
Price: $ 49.95 US
Length: 1120
ISBN: 1-55615-676-6

Release Date: 3/19/96

Updated for Windows 95 (with key contributions from Paul Yao), this Charles Petzold bestseller is the best-known, most widely praised, and most widely used how-to programming book on the planet. All sample programs are included on CD-ROM.

Rapid Development

By: Steve McConnell
Price: $ 35 US
Length: 680
ISBN: 1-55615-900-5

Release Date: 7/2/96

If you wrestle with development mileposts and deadlines, this book can show you the tested strategies and tactics you need to keep your projects on time and on budget. In the tradition of McConnell's bestselling Code Complete (Microsoft Press, 1996), RAPID DEVELOPMENT brings together the best research and hard-won experience to help you get control of your development projects.

Readings on Microsoft® Windows® & WOSA

By: Microsoft Corporation
Price: $ 39.95 US
Length: 512
ISBN: 1-55615-836-X

Release Date: 11/25/95

If you design custom solutions using Microsoft tools and technologies, or if you are preparing for the Microsoft Windows Operating Systems and Services Architecture I and II exams as part of the Microsoft Certified Developer program, this is the book you need.

Software Project Survival Guide

By: Steve McConnell
Price: $ 24.99 US
Length: 304
ISBN: 1-57231-621-7

Release Date: 10/15/97

This is the field guide for everyone involved in software development--especially those without formal management training. Acclaimed expert Steve McConnell maps out a proven approach to project management that you can learn and use successfully right away.

Windows® Interface Guidelines for Software Design, The

By: Microsoft Corporation
Price: $ 29.95 US
Length: 576
ISBN: 1-55615-679-0

Release Date: 7/11/95

If you develop applications for Windows and want to save training time, boost productivity, and promote user confidence, here are Microsoft's official guidelines for designing visually and functionally consistent user interfaces for Windows-based programs.

Writing Solid Code

By: Steve Maguire
Price: $ 24.95 US
Length: 288
ISBN: 1-55615-551-4

Release Date: 6/6/95

Here, from a former Microsoft developer, are super secrets for developing bug-free C programs. You'll see examples of how bugs are caught at Microsoft (actual case histories) and how to use these proven programming techniques to get products to market faster.

Internet Development

Active Visual J++TM

By: Scott Ladd
Price: $ 39.99 US
Length: 352
ISBN: 1-57231-609-8

Release Date: 8/6/97

Use this book to grasp the unmatched power and compatibility of Microsoft Visual J++ and go beyond Java's Web-based roots. See how to combine important technologies-Application Foundation Classes (AFC), Java, and ActiveXTM-to create awesome, interactive Web and intranet applications. CD-ROM included.

ActiveXTM Controls Inside Out, Second Edition

By: Adam Denning
Price: $ 39.95 US
Length: 672
ISBN: 1-57231-350-1

Release Date: 1/8/97

ACTIVEX CONTROLS INSIDE OUT is an in-depth guide for C++ and Microsoft® Visual Basic® programmers who want to build powerful custom controls and "componentware" using Microsoft's new tools and revolutionary COM (Component Object Model) technology.

AFC Programmer's Guide

By: Stephen Davis
Price: $ 39.99 US
Length: 512
ISBN: 1-57231-732-9

Release Date: 12/23/97

Kick your Internet application development into high gear. This book, designed for intermediate-level Java programmers, will show you how to use the advanced building blocks in the Application Foundation Classes (AFC)--Java class libraries from Microsoft.

Build Your Own Web Site

By: Louis Kahn
Price: $ 29.95 US
Length: 256
ISBN: 1-57231-304-8

Release Date: 8/8/96

BUILD YOUR OWN WEB SITE shows you how to publish your content on the Internet or your corporate intranet using Microsoft® Windows NT® Server and Microsoft Internet Information Server--even if you have little or no programming or networking experience.

Communications Programming for Windows® 95

By: Charles Mirho
Price: $ 39.95 US
Length: 320
ISBN: 1-55615-668-5

Release Date: 5/29/96

COMMUNICATIONS PROGRAMMING FOR WINDOWS 95 explains from the ground up the two most important communications components in Windows: the Telephony API (TAPI) and the Messaging API (MAPI). The book also includes valuable advice for adding communications capabilities to existing software applications.

Debugging the Development Process

By: Steve Maguire
Price: $ 24.95 US
Length: 216
ISBN: 1-55615-650-2

Release Date: 8/9/94

Steve Maguire gives you a compelling look at the software development process using candid accounts of his experience at Microsoft. He describes how to bring together and maintain effective teams and develop timely, high-quality commercial applications.

Developing International Software for Windows® 95 and Windows NT®

By: Nadine Kano
Price: $ 35 US
Length: 768
ISBN: 1-55615-840-8

Release Date: 6/2/95

Localize programs more easily, more quickly, and less expensively with this collection of critical reference material plus Microsoft's own guidelines for creating international software. It contains international standards and information on the culture-specific issues you need to consider when developing international software.

Dynamics of Software Development

By: Jim McCarthy
Price: $ 24.95 US
Length: 208
ISBN: 1-55615-823-8

Release Date: 8/26/95

Author Jim McCarthy insists that shipping great software on time can be done, and this book tells you how. DYNAMICS OF SOFTWARE DEVELOPMENT, destined to be a cult classic, charts the progress from initial design to successful product.

HTML in Action

By: Bruce Morris
Price: $ 29.95 US
Length: 288
ISBN: 1-55615-948-X

Release Date: 8/13/96

HTML IN ACTION is a powerhouse collection of the techniques and tricks you need to challenge the World Wide Web's most innovative sites with ultra cool ones of your own.

Inside COM

By: Dale Rogerson
Price: $ 34.99 US
Length: 416
ISBN: 1-57231-349-8

Release Date: 12/27/96

To understand distributed computing, OLE, ActiveXTM, and customizing Microsoft applications, you must understand the Component Object Model (COM). This concise, accessible guide is your key to COM and to building simple, elegant COM components...

Inside Dynamic HTML

By: Scott Isaacs
Price: $ 39.99 US
Length: 496
ISBN: 1-57231-686-1

Release Date: 10/30/97

Dynamic HTML takes the Internet to the next level of excitement in interactivity. In this book, one of the creators of DHTML gives developers the rich information and valuable techniques they need for using this important technology.

Inside Microsoft® Visual Basic® Scripting Edition

By: Scot Hillier
Price: $ 39.95 US
Length: 496
ISBN: 1-57231-444-3

Release Date: 10/30/96

INSIDE MICROSOFT VISUAL BASIC, SCRIPTING EDITION shows you how to leverage your Visual Basic programming skills to create dazzling World Wide Web applications using Visual Basic Script and ActiveX TM controls.

Inside Microsoft® Visual InterDevTM

By: Kenneth Spencer
Price: $ 39.99 US
Length: 616
ISBN: 1-57231-583-0

Release Date: 11/26/97

If you want to build high performance Web sites or create intranets, Microsoft Visual InterDev is the answer. With Visual InterDev, you get sophisticated database connectivity options; tight integration with other Microsoft tools such as Microsoft Visual Basic®, Microsoft Visual C++®, and Microsoft Visual J++TM; and site management capabilities. INSIDE MICROSOFT VISUAL INTERDEV gives you an insider's perspective on this powerful development tool.

Introducing Microsoft® FrontPage® 97

By: Kerry Lehto
Price: $ 24.99 US
Length: 416
ISBN: 1-57231-571-7

Release Date: 12/18/96

Packed with creative insights, INTRODUCING MICROSOFT FRONTPAGE 97 teaches you to create your own attractive and appealing Web pages--whether or not you have programming experience.

Learn Java Now

By: Stephen Davis
Price: $ 39.95 US
Length: 416
ISBN: 1-57231-428-1

Release Date: 10/9/96

Go beyond authoring Internet home pages! Use this book-and-disc package to add exciting interactivity to your Internet or intranet web sites with Microsoft Visual J++, Microsoft's powerful JavaTM compiler. The fully functional Publisher's Edition of Visual J++ is included on the enclosed CD-ROM.

Learn Microsoft® Visual Basic® Scripting Edition Now

By: Gary Cornell
Price: $ 34.95 US
Length: 336
ISBN: 1-57231-347-1

Release Date: 12/23/97

There is one best way to get Microsoft's powerful scripting language for the Internet and Windows 95 working for you today--LEARN MICROSOFT VISUAL BASIC SCRIPTING EDITION NOW.

Microsoft® FrontPage® 97 At a Glance

By: Stephen Nelson
Price: $ 16.99 US
Length: 272
ISBN: 1-57231-573-3

Release Date: 1/23/97

For fast answers, a picture is worth a thousand words. Here's the remarkable, visual way to learn to use the Web site development features of Microsoft FrontPage 97. MICROSOFT FRONTPAGE 97 AT A GLANCE lets you focus on a particular task and shows you, with clear, numbered steps, the easiest way to get it done right now.

Microsoft® FrontPage® 97 Step by Step

By: Catapult, Inc.
Price: $ 29.99 US
Length: 320
ISBN: 1-57231-336-6

Release Date: 1/15/97

Enjoy quick and easy training on FrontPage 97, Microsoft's powerful Web site development software, with this book-and-disk self-training package. The step-by-step method allows you to choose your best starting point and learn at your own pace.

Microsoft® FrontPage® 98 At a Glance

By: Stephen Nelson
Price: $ 16.99 US
Length: 224
ISBN: 1-57231-637-3

Release Date: 10/15/97

Here's the visual way to quickly get to work using the powerful features of Microsoft® FrontPageTM 98. MICROSOFT FRONTPAGE 98 AT A GLANCE lets you focus on a particular task and shows you, with clear, numbered steps, the easiest way to get it done.

Microsoft® FrontPage® 98 Step by Step

By: Catapult, Inc.
Price: $ 29.99 US
Length: 304
ISBN: 1-57231-636-5

Release Date: 11/17/97

MICROSOFT® FRONTPAGE® 98 STEP BY STEP is the easiest and fastest way to teach yourself to create attractive and appealing Web pages using Microsoft® FrontPage® 98.

Microsoft® Office 97/Visual Basic® Programmer's Guide

By: Microsoft Corporation
Price: $ 34.99 US
Length: 560
ISBN: 1-57231-340-4

Release Date: 12/27/96

Microsoft Office 97 is the newest version of the world’s most popular office suite--and a powerful development environment. This book shows everyone--from professional developers to power users--how to make the most of it.

Microsoft® OLE DB 1.1 Programmer's Reference and Software Development Kit

By: Microsoft Corporation
Price: $ 39.99 US
Length: 720
ISBN: 1-57231-612-8

Release Date: 4/16/97

Here's the information you need to get the most from OLE DB, the basis of Microsoft's new universal access architecture. This is an official technical document created by Microsoft's OLE DB team.

Microsoft® Publisher 97 by Design

By: Luisa Simone
Price: $ 27.95 US
Length: 560
ISBN: 1-57231-355-2

Release Date: 2/26/97

MICROSOFT PUBLISHER 97 BY DESIGN is packed with design examples and procedures that will help you create World Wide Web pages and effective, professional-quality publications quickly and easily, using Microsoft Publisher 97!

Official Microsoft® FrontPage® 98 Book

By: Kerry Lehto
Price: $ 24.99 US
Length: 400
ISBN: 1-57231-629-2

Release Date: 10/8/97

The OFFICIAL MICROSOFT FRONTPAGE 98 BOOK gives you all the information you need to use Microsoft FrontPage 98 quickly and effectively. Packed with creative insights, this book is the ideal guide to follow as you build great Web pages.

Official Microsoft® Internet Explorer 4 Site Builder Toolkit

By: Alan Simpson
Price: $ 39.99 US
Length: 664
ISBN: 1-57231-572-5

Release Date: 11/26/97

This authoritative guide, written by bestselling Internet author Alan Simpson, starts you off with a basic HTML review and an introduction to scripting, and then builds on those skills to show you how to manipulate objects in your Web pages.

Official Microsoft® Intranet Solutions

By: Micro Modeling Associates, Inc.
Price: $ 39.99 US
Length: 704
ISBN: 1-57231-509-1

Release Date: 4/9/97

Build on your investment in Microsoft Office documents, experience, and technical resources--learn how to use Microsoft Office 97, Microsoft FrontPageTM 97, and Microsoft Internet Explorer to develop and support professional-quality intranets.

Programming Active Server Pages

By: New Technology Solutions
Price: $ 49.99 US
Length: 336
ISBN: 1-57231-700-0

Release Date: 11/17/97

Active Server Pages give you the power to generate customized HTML pages on the fly. It's a breakthrough-and PROGRAMMING ACTIVE SERVER PAGES shows you how to make the most of it.

Running Microsoft® FrontPage® 98

By: Jim Buyens
Price: $ 39.99 US
Length: 688
ISBN: 1-57231-645-4

Release Date: 10/22/97

It's packed with everything from quick, clear instructions for new users to comprehensive answers for power users. And it's complete in one volume. In short, RUNNING MICROSOFT FRONTPAGE 98 is the authoritative handbook you'll keep by your computer and use every day.

Understanding ActiveXTM and OLE

By: David Chappell
Price: $ 22.95 US
Length: 352
ISBN: 1-57231-216-5

Release Date: 9/17/96

Now strategic decision-makers like you can learn about COM (Microsoft's object technology), OLE (Microsoft's technology for compound documents), and ActiveX (Microsoft's powerful new technology for the Internet). And you won't get bogged down in programming details.

Understanding Electronic Commerce

By: David Kosiur
Price: $ 19.99 US
Length: 304
ISBN: 1-57231-560-1

Release Date: 4/23/97

Here’s where technical managers and others get a clear view of revolutionary online transaction technology and its strategic implications for business. This book is part of the Strategic Technology Series, so it’s colorful, quick, comprehensive, and easy to browse.

Windows® Interface Guidelines for Software Design, The

By: Microsoft Corporation
Price: $ 29.95 US
Length: 576
ISBN: 1-55615-679-0

Release Date: 7/11/95

If you develop applications for Windows and want to save training time, boost productivity, and promote user confidence, here are Microsoft's official guidelines for designing visually and functionally consistent user interfaces for Windows-based programs.

Jet Database Engine

Client/Server Programming with Microsoft® Visual Basic®

By: Kenneth Spencer
Price: $ 34.95 US
Length: 304
ISBN: 1-57231-232-7

Release Date: 7/16/96

CLIENT/SERVER PROGRAMMING WITH MICROSOFT VISUAL BASIC teaches you easy ways to build effective, robust client/server applications using Visual Basic 4, along with helping you maximize its new remote OLE automation capabilities.

Microsoft® Jet Database Engine Programmer's Guide, Second Edition

By: Microsoft Corporation
Price: $ 49.99 US
Length: 792
ISBN: 1-57231-342-0

Release Date: 8/13/97

This is the official programmer's guide from Microsoft--the definitive reference created by the same team that developed Microsoft Jet. Inside you'll find newly updated and expanded coverage of all aspects of Microsoft Jet, including its structure and services.

Microsoft® Office 97/Visual Basic® Language Reference

By: Microsoft Corporation
Price: $ 129.99 US
Length: 4848
ISBN: 1-57231-339-0

Release Date: 3/26/97

It’s the Official Technical Reference to Visual Basic for Applications! And it’s your key to rolling out, deploying, administering, and developing for Microsoft Office 97--whether you’re creating custom applications or modifying the existing applications.

Miscellaneous Developer Topics

Active Visual J++TM

By: Scott Ladd
Price: $ 39.99 US
Length: 352
ISBN: 1-57231-609-8

Release Date: 8/6/97

Use this book to grasp the unmatched power and compatibility of Microsoft Visual J++ and go beyond Java's Web-based roots. See how to combine important technologies-Application Foundation Classes (AFC), Java, and ActiveXTM-to create awesome, interactive Web and intranet applications. CD-ROM included.

Automation Programmer's Reference

By: Microsoft Corporation
Price: $ 24.99 US
Length: 496
ISBN: 1-57231-584-9

Release Date: 2/26/97

This is the comprehensive and official reference documentation on Automation! Use it to discover how ActiveX and OLE can multiply the power, the usefulness, and the value of all your applications for Microsoft Windows® 95 and Microsoft Windows NTTM.

Code Complete

By: Steve McConnell
Price: $ 35 US
Length: 896
ISBN: 1-55615-484-4

Release Date: 9/14/95

This runaway bestseller is a practical guide to software design that discusses the art and science of constructing software. Examples are provided in C, PascalTM, Basic, FORTRAN, and Ada, but the focus is on successful programming techniques.

Communications Programming for Windows® 95

By: Charles Mirho
Price: $ 39.95 US
Length: 320
ISBN: 1-55615-668-5

Release Date: 5/29/96

COMMUNICATIONS PROGRAMMING FOR WINDOWS 95 explains from the ground up the two most important communications components in Windows: the Telephony API (TAPI) and the Messaging API (MAPI). The book also includes valuable advice for adding communications capabilities to existing software applications.

Debugging the Development Process

By: Steve Maguire
Price: $ 24.95 US
Length: 216
ISBN: 1-55615-650-2

Release Date: 8/9/94

Steve Maguire gives you a compelling look at the software development process using candid accounts of his experience at Microsoft. He describes how to bring together and maintain effective teams and develop timely, high-quality commercial applications.

Developing International Software for Windows® 95 and Windows NT®

By: Nadine Kano
Price: $ 35 US
Length: 768
ISBN: 1-55615-840-8

Release Date: 6/2/95

Localize programs more easily, more quickly, and less expensively with this collection of critical reference material plus Microsoft's own guidelines for creating international software. It contains international standards and information on the culture-specific issues you need to consider when developing international software.

Dynamics of Software Development

By: Jim McCarthy
Price: $ 24.95 US
Length: 208
ISBN: 1-55615-823-8

Release Date: 8/26/95

Author Jim McCarthy insists that shipping great software on time can be done, and this book tells you how. DYNAMICS OF SOFTWARE DEVELOPMENT, destined to be a cult classic, charts the progress from initial design to successful product.

Inside COM

By: Dale Rogerson
Price: $ 34.99 US
Length: 416
ISBN: 1-57231-349-8

Release Date: 12/27/96

To understand distributed computing, OLE, ActiveXTM, and customizing Microsoft applications, you must understand the Component Object Model (COM). This concise, accessible guide is your key to COM and to building simple, elegant COM components...

Inside OLE, 2nd Edition

By: Kraig Brockschmidt
Price: $ 49.95 US
Length: 1232
ISBN: 1-55615-843-2

Release Date: 6/12/95

Kraig Brockschmidt uses disc-based examples to show you the principles of OLE, including structured storage, OLE Automation, and in-place activation. He builds sample programs using OLE-based code you can incorporate into your own applications.

Inside the Registry for Microsoft® Windows® 95

By: Günter Born
Price: $ 24.99 US
Length: 368
ISBN: 1-57231-424-9

Release Date: 1/22/97

Here’s a clear, straightforward look at one of the least documented aspects of the Microsoft Windows 95 operating system. This is the indispensable information--and safety net--that every developer, system administrator, troubleshooter, and advanced user needs.

Inside Visual C++®, Fourth Edition

By: David Kruglinski
Price: $ 49.99 US
Length: 1040
ISBN: 1-57231-565-2

Release Date: 6/4/97

Building on the solid achievements of three previous editions, INSIDE VISUAL C++, FOURTH EDITION presents detailed and comprehensive coverage of Visual C++ and the intricacies of 32-bit programming in Windows. This book offers by far the best overall explanation of the capabilities of Microsoft's powerful and complex development tool.

Learn Visual C++® Now

By: Mark Andrews
Price: $ 39.95 US
Length: 480
ISBN: 1-55615-845-9

Release Date: 5/14/96

LEARN VISUAL C++ NOW will help you master the powerful visual tools and automated features in Visual C++. On CD-ROM, you get a complete working Visual C++ compiler (version 1.0) that will equip you to create your own applications.

Microsoft Press® Programmer's Bookshelf for Windows® 95

By: Microsoft Press
Price: $ 69.95 US
Length:
ISBN: 1-57231-311-0

Release Date: 6/13/96

Now you can access five important programming books for Windows 95 on a single CD-ROM! Includes the full content of Programming Windows 95 (Microsoft Press, 1996), by Charles Petzold; Advanced Windows (Microsoft Press, 1996), by Jeffrey Richter; Developing International Software for Windows 95 and Windows NT® (Microsoft Press, 1996) by Nadine Kano; OLE Controls Inside Out (Microsoft Press, 1996), by Adam Denning; and Programming the Windows 95 User Interface (Microsoft Press, 1995), by Nancy Winnick Cluts.

Microsoft® Access/Visual Basic® Step by Step

By: Evan Callahan
Price: $ 29.95 US
Length: 368
ISBN: 1-55615-890-4

Release Date: 12/18/95

Learn to build personalized and customized Microsoft Access solutions the easy way with MICROSOFT ACCESS/VISUAL BASIC STEP BY STEP. Includes 15 self-paced lessons with disk-based practice files so you can learn at your own pace.

Microsoft® ODBC 3.0 Software Development Kit and Programmer's Reference

By: Microsoft Corporation
Price: $ 99.99 US
Length: 1488
ISBN: 1-57231-516-4

Release Date: 2/26/97

This is the kit that gives developers everything they need for using the Open Database Connectivity (ODBC) standard to build robust database connectivity into their applications.

Microsoft® Office 97 Developer's Handbook

By: Christine Solomon
Price: $ 39.99 US
Length: 608
ISBN: 1-57231-440-0

Release Date: 4/16/97

All you need is Microsoft Office 97 and this book. Here you'll discover how to build applications that extend and customize the office suite, mesh with network and data resources, and expand and automate your business.

Microsoft® Office 97, Developer Edition, Resource Library

By: Christine Solomon
Price: $ 99.99 US
Length: 1888
ISBN: 1-57231-606-3

Release Date: 6/11/97

Microsoft Office 97, Developer Edition is a terrific development platform. To get the most from it, apply the powerful development strategies you'll find in this indispensable three-volume resource set. The accompanying CD-ROM contains all sample code from all three books.

Microsoft® Office 97/Visual Basic® Language Reference

By: Microsoft Corporation
Price: $ 129.99 US
Length: 4848
ISBN: 1-57231-339-0

Release Date: 3/26/97

It’s the Official Technical Reference to Visual Basic for Applications! And it’s your key to rolling out, deploying, administering, and developing for Microsoft Office 97--whether you’re creating custom applications or modifying the existing applications.

Microsoft® Office 97/Visual Basic® Programmer's Guide

By: Microsoft Corporation
Price: $ 34.99 US
Length: 560
ISBN: 1-57231-340-4

Release Date: 12/27/96

Microsoft Office 97 is the newest version of the world’s most popular office suite--and a powerful development environment. This book shows everyone--from professional developers to power users--how to make the most of it.

Microsoft® Visual Basic®, Deluxe Learning Edition

By: Microsoft Corporation
Price: $ 129.99 US
Length: 1278
ISBN: 1-57231-551-2

Release Date: 3/26/97

MICROSOFT VISUAL BASIC DELUXE LEARNING EDITION is a comprehensive training kit that will teach you how to put Microsoft Visual Basic to work. The kit contains the complete version of Visual Basic 5.0 Learning Edition, and is the easiest way to learn to use it.

Microsoft® Visual C++® Language Reference

By: Microsoft Corporation
Price: $ 29.99 US
Length: 768
ISBN: 1-57231-521-0

Release Date: 3/26/97

Within the four-volume Microsoft Visual C++ 5.0 Programmer’s Reference Set, this is the C, C++, and preprocessor reference for the Microsoft Visual C++ development system. All volumes in the Reference Set are available separately.

Microsoft® Visual C++® MFC Library Reference, Part 1

By: Microsoft Corporation
Price: $ 39.99 US
Length: 1456
ISBN: 1-57231-518-0

Release Date: 4/9/97

Within the four-volume Microsoft Visual C++ 5.0 Programmer’s Reference Set, this is the first of two volumes that completely describe the classes, macros, and global functions and variables in the Microsoft Foundation Class (MFC) library. All volumes in the Reference Set are available separately.

Microsoft® Visual C++® MFC Library Reference, Part 2

By: Microsoft Corporation
Price: $ 39.99 US
Length: 1392
ISBN: 1-57231-519-9

Release Date: 4/9/97

Within the four-volume Microsoft Visual C++ 5.0 Programmer’s Reference Set, this is the second of two volumes that completely describe the classes, macros, and global functions and variables in the Microsoft Foundation Class (MFC) library. All volumes in the Reference Set are available separately.

Microsoft® Visual C++® Run-Time Library Reference

By: Microsoft Corporation
Price: $ 39.99 US
Length: 1328
ISBN: 1-57231-520-2

Release Date: 4/2/97

Within the four-volume Microsoft Visual C++ 5.0 Programmer’s Reference Set, this is the volume that completely describes all the functions and parameters in the Microsoft Visual C++ iostream class and run-time libraries. All volumes in the Reference Set are available separately.

Microsoft® Windows® 95 Help Authoring Kit

By: Microsoft Corporation
Price: $ 49.95 US
Length: 336
ISBN: 1-55615-892-0

Release Date: 11/7/95

The MICROSOFT® WINDOWS® 95 HELP AUTHORING KIT is an invaluable source for beginning and veteran Help authors, providing all the information and software needed to create online help files for Windows 95 applications (also for earlier versions of Windows and Windows NTTM version 3.51 or later).

PC 98 System Design Guide

By: Microsoft Corporation
Price: $ 29.99 US
Length: 672
ISBN: 1-57231-716-7

Release Date: 10/15/97

This book provides the latest, most authoritative guidelines for everyone who's creating next-generation PCs, components, peripherals, and device drivers. And that makes PC 98 SYSTEM DESIGN GUIDE the must-have reference you'll want to keep close at hand.

Programming Active Server Pages

By: New Technology Solutions
Price: $ 49.99 US
Length: 336
ISBN: 1-57231-700-0

Release Date: 11/17/97

Active Server Pages give you the power to generate customized HTML pages on the fly. It's a breakthrough-and PROGRAMMING ACTIVE SERVER PAGES shows you how to make the most of it.

Programming Windows® 95

By: Charles Petzold
Price: $ 49.95 US
Length: 1120
ISBN: 1-55615-676-6

Release Date: 3/19/96

Updated for Windows 95 (with key contributions from Paul Yao), this Charles Petzold bestseller is the best-known, most widely praised, and most widely used how-to programming book on the planet. All sample programs are included on CD-ROM.

Rapid Development

By: Steve McConnell
Price: $ 35 US
Length: 680
ISBN: 1-55615-900-5

Release Date: 7/2/96

If you wrestle with development mileposts and deadlines, this book can show you the tested strategies and tactics you need to keep your projects on time and on budget. In the tradition of McConnell's bestselling Code Complete (Microsoft Press, 1996), RAPID DEVELOPMENT brings together the best research and hard-won experience to help you get control of your development projects.

Readings on Microsoft® Windows® & WOSA

By: Microsoft Corporation
Price: $ 39.95 US
Length: 512
ISBN: 1-55615-836-X

Release Date: 11/25/95

If you design custom solutions using Microsoft tools and technologies, or if you are preparing for the Microsoft Windows Operating Systems and Services Architecture I and II exams as part of the Microsoft Certified Developer program, this is the book you need.

Software Project Survival Guide

By: Steve McConnell
Price: $ 24.99 US
Length: 304
ISBN: 1-57231-621-7

Release Date: 10/15/97

This is the field guide for everyone involved in software development--especially those without formal management training. Acclaimed expert Steve McConnell maps out a proven approach to project management that you can learn and use successfully right away.

Windows® Interface Guidelines for Software Design, The

By: Microsoft Corporation
Price: $ 29.95 US
Length: 576
ISBN: 1-55615-679-0

Release Date: 7/11/95

If you develop applications for Windows and want to save training time, boost productivity, and promote user confidence, here are Microsoft's official guidelines for designing visually and functionally consistent user interfaces for Windows-based programs.

Writing Solid Code

By: Steve Maguire
Price: $ 24.95 US
Length: 288
ISBN: 1-55615-551-4

Release Date: 6/6/95

Here, from a former Microsoft developer, are super secrets for developing bug-free C programs. You'll see examples of how bugs are caught at Microsoft (actual case histories) and how to use these proven programming techniques to get products to market faster.

ODBC

Client/Server Programming with Microsoft® Visual Basic®

By: Kenneth Spencer
Price: $ 34.95 US
Length: 304
ISBN: 1-57231-232-7

Release Date: 7/16/96

CLIENT/SERVER PROGRAMMING WITH MICROSOFT VISUAL BASIC teaches you easy ways to build effective, robust client/server applications using Visual Basic 4, along with helping you maximize its new remote OLE automation capabilities.

Field Guide to Microsoft® Access 2 for Windows®

By: Stephen Nelson
Price: $ 9.95 US
Length: 192
ISBN: 1-55615-581-6

Release Date: 3/26/96

This illustrated pocket-size guide is arranged by task and organized in easy-to-use, easy-to-remember sections with rich cross-referencing for easy lookup. The colorful, lighthearted approach to information will put you at ease, and the tips, hints, and tricks make using Microsoft Access easier.

Microsoft® ODBC 3.0 Software Development Kit and Programmer's Reference

By: Microsoft Corporation
Price: $ 99.99 US
Length: 1488
ISBN: 1-57231-516-4

Release Date: 2/26/97

This is the kit that gives developers everything they need for using the Open Database Connectivity (ODBC) standard to build robust database connectivity into their applications.

Microsoft® SQL ServerTM Training

By: Microsoft Corporation
Price: $ 199.95 US
Length: 1088
ISBN: 1-55615-930-7

Release Date: 9/25/96

This two-volume kit with two CD-ROMs will train you to install, configure, and troubleshoot SQL Server in your organization and will help you to prepare for the Microsoft Certified Professional exams for Microsoft SQL Server.

Readings on Microsoft® Windows® & WOSA

By: Microsoft Corporation
Price: $ 39.95 US
Length: 512
ISBN: 1-55615-836-X

Release Date: 11/25/95

If you design custom solutions using Microsoft tools and technologies, or if you are preparing for the Microsoft Windows Operating Systems and Services Architecture I and II exams as part of the Microsoft Certified Developer program, this is the book you need.

OLE

ActiveXTM Controls Inside Out, Second Edition

By: Adam Denning
Price: $ 39.95 US
Length: 672
ISBN: 1-57231-350-1

Release Date: 1/8/97

ACTIVEX CONTROLS INSIDE OUT is an in-depth guide for C++ and Microsoft® Visual Basic® programmers who want to build powerful custom controls and "componentware" using Microsoft's new tools and revolutionary COM (Component Object Model) technology.

Automation Programmer's Reference

By: Microsoft Corporation
Price: $ 24.99 US
Length: 496
ISBN: 1-57231-584-9

Release Date: 2/26/97

This is the comprehensive and official reference documentation on Automation! Use it to discover how ActiveX and OLE can multiply the power, the usefulness, and the value of all your applications for Microsoft Windows® 95 and Microsoft Windows NTTM.

Client/Server Programming with Microsoft® Visual Basic®

By: Kenneth Spencer
Price: $ 34.95 US
Length: 304
ISBN: 1-57231-232-7

Release Date: 7/16/96

CLIENT/SERVER PROGRAMMING WITH MICROSOFT VISUAL BASIC teaches you easy ways to build effective, robust client/server applications using Visual Basic 4, along with helping you maximize its new remote OLE automation capabilities.

Inside COM

By: Dale Rogerson
Price: $ 34.99 US
Length: 416
ISBN: 1-57231-349-8

Release Date: 12/27/96

To understand distributed computing, OLE, ActiveXTM, and customizing Microsoft applications, you must understand the Component Object Model (COM). This concise, accessible guide is your key to COM and to building simple, elegant COM components...

Inside OLE, 2nd Edition

By: Kraig Brockschmidt
Price: $ 49.95 US
Length: 1232
ISBN: 1-55615-843-2

Release Date: 6/12/95

Kraig Brockschmidt uses disc-based examples to show you the principles of OLE, including structured storage, OLE Automation, and in-place activation. He builds sample programs using OLE-based code you can incorporate into your own applications.

Microsoft Press® Programmer's Bookshelf for Windows® 95

By: Microsoft Press
Price: $ 69.95 US
Length:
ISBN: 1-57231-311-0

Release Date: 6/13/96

Now you can access five important programming books for Windows 95 on a single CD-ROM! Includes the full content of Programming Windows 95 (Microsoft Press, 1996), by Charles Petzold; Advanced Windows (Microsoft Press, 1996), by Jeffrey Richter; Developing International Software for Windows 95 and Windows NT® (Microsoft Press, 1996) by Nadine Kano; OLE Controls Inside Out (Microsoft Press, 1996), by Adam Denning; and Programming the Windows 95 User Interface (Microsoft Press, 1995), by Nancy Winnick Cluts.

Microsoft® OLE DB 1.1 Programmer's Reference and Software Development Kit

By: Microsoft Corporation
Price: $ 39.99 US
Length: 720
ISBN: 1-57231-612-8

Release Date: 4/16/97

Here's the information you need to get the most from OLE DB, the basis of Microsoft's new universal access architecture. This is an official technical document created by Microsoft's OLE DB team.

Microsoft® SQL ServerTM Training

By: Microsoft Corporation
Price: $ 199.95 US
Length: 1088
ISBN: 1-55615-930-7

Release Date: 9/25/96

This two-volume kit with two CD-ROMs will train you to install, configure, and troubleshoot SQL Server in your organization and will help you to prepare for the Microsoft Certified Professional exams for Microsoft SQL Server.

Programming Windows® 95

By: Charles Petzold
Price: $ 49.95 US
Length: 1120
ISBN: 1-55615-676-6

Release Date: 3/19/96

Updated for Windows 95 (with key contributions from Paul Yao), this Charles Petzold bestseller is the best-known, most widely praised, and most widely used how-to programming book on the planet. All sample programs are included on CD-ROM.

Readings on Microsoft® Windows® & WOSA

By: Microsoft Corporation
Price: $ 39.95 US
Length: 512
ISBN: 1-55615-836-X

Release Date: 11/25/95

If you design custom solutions using Microsoft tools and technologies, or if you are preparing for the Microsoft Windows Operating Systems and Services Architecture I and II exams as part of the Microsoft Certified Developer program, this is the book you need.

Understanding ActiveXTM and OLE

By: David Chappell
Price: $ 22.95 US
Length: 352
ISBN: 1-57231-216-5

Release Date: 9/17/96

Now strategic decision-makers like you can learn about COM (Microsoft's object technology), OLE (Microsoft's technology for compound documents), and ActiveX (Microsoft's powerful new technology for the Internet). And you won't get bogged down in programming details.

Windows® Interface Guidelines for Software Design, The

By: Microsoft Corporation
Price: $ 29.95 US
Length: 576
ISBN: 1-55615-679-0

Release Date: 7/11/95

If you develop applications for Windows and want to save training time, boost productivity, and promote user confidence, here are Microsoft's official guidelines for designing visually and functionally consistent user interfaces for Windows-based programs.

Visual Basic

Active Visual Basic® 5.0

By: Guy Eddon
Price: $ 39.99 US
Length: 416
ISBN: 1-57231-512-1

Release Date: 4/9/97

A valuable, practical alternative to learning new programming languages and tools, ACTIVE VISUAL BASIC shows you how to take advantage of your existing knowledge of Visual Basic to create new Internet-enabled applications and interactive Web content.

Advanced Microsoft® Visual Basic® 5

By: The Mandelbrot Set, Ltd.
Price: $ 49.99 US
Length: 832
ISBN: 1-57231-414-1

Release Date: 7/23/97

Here's an invaluable collection of advanced experience, skills, and insights from seasoned pros. The focus is on core topics, including client/server issues, intranet subjects, designing distributed applications, and much more. The enclosed CD contains complete source code plus utilities.

Building Applications with Microsoft® OutlookTM 97

By: Microsoft Corporation
Price: $ 39.99 US
Length: 528
ISBN: 1-57231-536-9

Release Date: 3/12/97

BUILDING MICROSOFT OUTLOOK 97 APPLICATIONS is a results-oriented book that gives you the information, strategies, and sample applications you need to easily build useful groupware applications, make your workplace more productive, and get the most out of your Office 97 investment. You can learn it in less than a day!

Client/Server Programming with Microsoft® Visual Basic®

By: Kenneth Spencer
Price: $ 34.95 US
Length: 304
ISBN: 1-57231-232-7

Release Date: 7/16/96

CLIENT/SERVER PROGRAMMING WITH MICROSOFT VISUAL BASIC teaches you easy ways to build effective, robust client/server applications using Visual Basic 4, along with helping you maximize its new remote OLE automation capabilities.

Hardcore Visual Basic®, Second Edition

By: Bruce McKinney
Price: $ 49.99 US
Length: 760
ISBN: 1-57231-422-2

Release Date: 7/9/97

Discover object-oriented solutions for unleashing the hardcore power of Microsoft® Visual Basic 5.0. Here's coverage on everything from the improved type library to the deeper mysteries of interfaces and the Common Object Model. Includes a CD-ROM full of samples, tools, and utilities.

Hitchhiker's Guide to Visual Basic® and SQL ServerTM, 5th edition

By: William Vaughn
Price: $ 49.99 US
Length: 816
ISBN: 1-57231-567-9

Release Date: 5/28/97

Greatly expanded and updated, the newest edition of this bestseller gives you a ton of information for using Visual Basic (including Microsoft Visual Basic 5.0) to design, code, debug, and tune front-end applications for SQL Server.

Inside Microsoft® Visual Basic® Scripting Edition

By: Scot Hillier
Price: $ 39.95 US
Length: 496
ISBN: 1-57231-444-3

Release Date: 10/30/96

INSIDE MICROSOFT VISUAL BASIC, SCRIPTING EDITION shows you how to leverage your Visual Basic programming skills to create dazzling World Wide Web applications using Visual Basic Script and ActiveX TM controls.

Learn Visual Basic® Now

By: Michael Halvorson
Price: $ 39.95 US
Length: 480
ISBN: 1-55615-905-6

Release Date: 2/20/96

Easy step-by-step exercises help you design a user interface and build programming code for Microsoft Windows® 95-based applications. You also get a CD-ROM of the Visual Basic 4.0 Working Model--a great way to "kick the tires" of Visual Basic without having to spend a lot of money on software!

Microsoft® Access 97 Developer's Handbook

By: Microsoft Corporation
Price: $ 39.99 US
Length: 624
ISBN: 1-57231-358-7

Release Date: 2/26/97

This is the book for everyone who wants to use Microsoft Access 97 and its built-in Visual Basic® for Applications (VBA) 32-bit programming language to develop and distribute information systems, custom interfaces, and custom database applications.

Microsoft® Access 97/Visual Basic® Step by Step

By: Evan Callahan
Price: $ 34.95 US
Length: 416
ISBN: 1-57231-319-6

Release Date: 2/12/97

MICROSOFT ACCESS 97/VISUAL BASIC STEP BY STEP provides quick, easy, book-and-disk self-training on Microsoft Access/Visual Basic-to help you create custom applications, automate database tasks, and much more. The step-by-step method allows you to choose your best starting point and learn at your own pace.

Microsoft® Access/Visual Basic® Step by Step

By: Evan Callahan
Price: $ 29.95 US
Length: 368
ISBN: 1-55615-890-4

Release Date: 12/18/95

Learn to build personalized and customized Microsoft Access solutions the easy way with MICROSOFT ACCESS/VISUAL BASIC STEP BY STEP. Includes 15 self-paced lessons with disk-based practice files so you can learn at your own pace.

Microsoft® Excel 97 Developer's Handbook

By: Micro Modeling Associates, Inc.
Price: $ 39.99 US
Length: 656
ISBN: 1-57231-359-5

Release Date: 5/7/97

With Microsoft Excel 97 and its built-in Microsoft Visual Basic® for Applications (VBA) 32-bit programming language, you can build and distribute professional-quality access and analysis tools. This easy-to-read, clearly illustrated book shows you how.

Microsoft® Excel 97 Developer's Kit

By: Microsoft Corporation
Price: $ 49.99 US
Length: 608
ISBN: 1-57231-498-2

Release Date: 6/4/97

This is THE authoritative technical reference for extending and customizing Microsoft Excel using C and the Microsoft Excel API. Plus, the enclosed CD-ROM supplies sample code from the book, VBA and C source code, and tools and utilities.

Microsoft® Excel 97/Visual Basic® Step by Step

By: Reed Jacobson
Price: $ 34.95 US
Length: 368
ISBN: 1-57231-318-8

Release Date: 3/19/97

MICROSOFT EXCEL 97/VISUAL BASIC STEP BY STEP provides quick, easy, book-and-disk self-training on Microsoft Excel/Visual Basic--to help you create custom applications, automate spreadsheet tasks, and much more. The step-by-step method allows you to choose your best starting point and learn at your own pace.

Microsoft® Office 97 Developer's Handbook

By: Christine Solomon
Price: $ 39.99 US
Length: 608
ISBN: 1-57231-440-0

Release Date: 4/16/97

All you need is Microsoft Office 97 and this book. Here you'll discover how to build applications that extend and customize the office suite, mesh with network and data resources, and expand and automate your business.

Microsoft® Office 97/Visual Basic® Language Reference

By: Microsoft Corporation
Price: $ 129.99 US
Length: 4848
ISBN: 1-57231-339-0

Release Date: 3/26/97

It’s the Official Technical Reference to Visual Basic for Applications! And it’s your key to rolling out, deploying, administering, and developing for Microsoft Office 97--whether you’re creating custom applications or modifying the existing applications.

Microsoft® Office 97/Visual Basic® Programmer's Guide

By: Microsoft Corporation
Price: $ 34.99 US
Length: 560
ISBN: 1-57231-340-4

Release Date: 12/27/96

Microsoft Office 97 is the newest version of the world’s most popular office suite--and a powerful development environment. This book shows everyone--from professional developers to power users--how to make the most of it.

Microsoft® Office 97/Visual Basic® Step by Step

By: David Boctor
Price: $ 34.99 US
Length: 368
ISBN: 1-57231-389-7

Release Date: 6/18/97

MICROSOFT OFFICE 97/VISUAL BASIC STEP BY STEP gives you quick and easy self-paced training in Visual Basic for Applications. Work through every lesson to complete the full course, or do individual lessons to learn just the skills you need. Either way, you learn at your optimum pace from the teacher who knows you best--you.

Microsoft® Visual Basic® 5 Step by Step

By: Michael Halvorson
Price: $ 34.99 US
Length: 416
ISBN: 1-57231-435-4

Release Date: 3/5/97

MICROSOFT VISUAL BASIC 5 STEP BY STEP provides quick, easy, book-and-disk self-training on Microsoft Visual Basic 5--to help you easily create custom programs for Microsoft Windows 95.

Microsoft® Visual Basic® 5.0 ActiveXTM Controls Reference

By: Microsoft Corporation
Price: $ 24.99 US
Length: 784
ISBN: 1-57231-508-3

Release Date: 3/12/97

The ACTIVEX CONTROLS REFERENCE has two parts: The first provides A-Z entries for all the custom controls that ship with Visual Basic. Then, for each control, the relevant properties, events, and methods are described alphabetically.

Microsoft® Visual Basic® 5.0 Developer's Workshop, Fourth Edition

By: John Craig
Price: $ 44.99 US
Length: 752
ISBN: 1-57231-436-2

Release Date: 5/14/97

MICROSOFT VISUAL BASIC 5.0 DEVELOPER'S WORKSHOP is a one-of-a-kind book-and-software package that gives you the recipes to build powerful, full-featured graphical applications for Windows® 95 and Windows NT®. This book demonstrates everything from creating a screen saver to building ActiveX controls that can be used in a Web page.

Microsoft® Visual Basic® 5.0 Language Reference

By: Microsoft Corporation
Price: $ 39.99 US
Length: 1600
ISBN: 1-57231-507-5

Release Date: 3/5/97

The LANGUAGE REFERENCE contains A-Z listings for the objects, functions, statements, methods, properties, and events encompassed by the Visual Basic language. Additional appendixes supply reference information to the ANSI character set, Visual Basic data types, operators, and derived math functions.

Microsoft® Visual Basic® 5.0 Programmer's Guide

By: Microsoft Corporation
Price: $ 29.99 US
Length: 912
ISBN: 1-57231-604-7

Release Date: 2/26/97

For beginning Visual Basic users or experienced developers, this is the comprehensive guide to Visual Basic programming. Straight from the Microsoft Visual Basic product team, the PROGRAMMER'S GUIDE covers everything from programming fundamentals and "Your First Visual Basic Program" to optimizing and distributing applications.

Microsoft® Visual Basic®, Deluxe Learning Edition

By: Microsoft Corporation
Price: $ 129.99 US
Length: 1278
ISBN: 1-57231-551-2

Release Date: 3/26/97

MICROSOFT VISUAL BASIC DELUXE LEARNING EDITION is a comprehensive training kit that will teach you how to put Microsoft Visual Basic to work. The kit contains the complete version of Visual Basic 5.0 Learning Edition, and is the easiest way to learn to use it.

Microsoft® Word 97/Visual Basic® Step by Step

By: Michael Halvorson
Price: $ 34.99 US
Length: 320
ISBN: 1-57231-388-9

Release Date: 4/30/97

MICROSOFT WORD 97/VISUAL BASIC STEP BY STEP provides quick, easy, book-and-disk self-training on Microsoft Word/Visual Basic--to help you create custom applications, automate word processing tasks, and much more. The step-by-step method allows you to choose your best starting point and learn at your own pace.

Readings on Microsoft® Windows® & WOSA

By: Microsoft Corporation
Price: $ 39.95 US
Length: 512
ISBN: 1-55615-836-X

Release Date: 11/25/95

If you design custom solutions using Microsoft tools and technologies, or if you are preparing for the Microsoft Windows Operating Systems and Services Architecture I and II exams as part of the Microsoft Certified Developer program, this is the book you need.


Topic Not Found

No matching topic was found. Some possible reasons and remedies are as follows:

  • The file (.chm) that contains the destination topic is not in the expected location.

    Remedy: Rerun the MSDN Library Setup.

  • The file (.chm) that contains the current topic or destination topic is out-of-date and the link is no longer valid.

    Remedy: Install the latest version of the MSDN Library.

  • The MSDN Library CD is not in the CD-ROM drive.

    Remedy: Insert the MSDN Library CD into the CD-ROM drive.


Copyright

Information in this document is subject to change without notice. The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation. Permission to print one copy is hereby granted if your only means of access is electronic.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 1991-1998 Microsoft Corporation. All rights reserved.

Microsoft® Visual Studio™ 6 Development System

Microsoft, MS, MS-DOS, ActiveX, FoxPro, the Fox head design, Internet Explorer, Microsoft Developer Studio, Microsoft Press, Microsoft QuickBasic, PivotTable, Rushmore, Visual Basic, Visual C++, Visual FoxPro, Visual InterDev, Visual J++, Visual SourceSafe, Windows, Windows NT, Win32, and Win32s are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.

Java is a trademark of Sun Microsystems, Inc.

TrueType is a registered trademark of Apple Computer, Inc.

Other product and company names mentioned herein may be the trademarks of their respective owners.


Read Me

Microsoft Developer Network Library Readme

(c) 1997, 1998 Microsoft Corporation

This document includes up-to-date information about the Visual Studio 98 pre-release of the Microsoft Developer Network Library Visual Studio 98. This document is found in a file named readmsdn.htm located in the root directory on Disc 1.

Installation

Known Issues For Pre-Release

Notes

Installation

Typical and custom installation options

Installing Internet Explorer with the MSDN Library

The Visual Studio 98 MSDN Library is the first library release using the HTML Help viewer technology. You are not required to uninstall previous versions of the MSDN Library which use InfoViewer 5.0 technology. For example, the October 97 MSDN Library and all earlier libraries will coexist with the Visual Studio 98 Library. If you do wish to uninstall any library always use the Add/Remove Programs option from the Control Panel or the Setup program from the CD of the MSDN Library you wish to uninstall.

If you have not yet installed Visual Studio 98 or any of its components, but plan to do so in the future, the drive and directory that you choose as the install location for the MSDN Library will also be the default drive and directory for the Visual Studio 98 installation. If you attempt to install Visual Studio 98 or any of its components and there is not enough room on the drive you selected, you should 1) uninstall the MSDN Library, 2)install Visual Studio 98 or its component(s), and 3) then re-install the MSDN Library.

Typical and Custom installation options

During Setup you will be asked to choose between Typical and Custom installation options. The Typical setup option allows you to run the MSDN Library from the CD. Setup will copy the minimum set of files to your local hard drive. These files include the MSDN viewer system files, contents index files, and help files that are used by the Visual Studio development products.

Custom installation allows you to specify local installation of a subset of the MSDN Library. The files you select will be copied to your local hard drive along with the files mentioned in the Typical setup description. You will still see the entire Library table of contents. If you select content that has not been installed locally, you will be prompted to insert the MSDN Library CD.

Installing Internet Explorer with the MSDN Library

In order for the MSDN Library to function properly, you need to have version 4.01 or higher of a released version of Microsoft Internet Explorer installed on your system. If you do not have one of these versions installed, you will be prompted during Setup to install Internet Explorer version 4.01.

If you select Yes, MSDN setup will halt and display a dialog box saying, "MSDN Setup was not completed successfully." You must click OK and manually install Internet Explorer. For your convenience, IE 4.01 is included on the MSDN Library CD in the IE4 folder. Run ie4setup.exe to install. You must then restart MSDN setup and continue installation.

If you select No, MSDN setup will continue with installation.

Install from the MSDN CD (in the IE4 folder) or connect to http://www.microsoft.com/ie/ download the latest version.

Known Issues for the Pre-Release

"Incorrect Internet Explorer Version" message on Set-up

Documentation "in progress" for this release

Infotypes not implemented in this release

No prompt to insert the correct CD

Hyperlinks

URLs that do not connect

"Incorrect Internet Explorer Version" on Set-up

On set-up, the "Incorrect Explorer Version" dialog box could appear. If Internet Explorer was installed as part of Visual Studio, or Internet Explorer was installed from the MSDN Visual Studio CD, selecting the the No option

Documentation "in progress" for this release

The MSDN Library contains current product documentation for Visual Studio 98 and includes a substantial portion of the current MSDN Library. For additional content not included in this pre-release version consult www.microsoft.com/msdn/ for the online version of the MSDN Library or use the October MSDN Library CD.

Infotypes not implemented in this release

Previous MSDN Library releases have the ability to create subsets of a topic and browser or search this user defined subset. MSDN Library, Visual Studio 98 will implement a new technology using Infotypes to create similar "subsets" of information. Infotypes are not implemented in this release.

No prompt to insert the correct CD

If the document is not installed on the local drive, and you attempt to access this remote document, you will get a message box saying: "Internet Explorer cannot open the Internet site <path to help file>. An unexpected error has occurred." Insert CD to access the file.

Hyperlinks

Some of the hyperlinks included in the MSDN Library may not function correctly. Clicking these may result in a "requested topic does not exist" error message. We are always working to correct problems of this type in every release of the MSDN Library.

URLs that do not connect

Because of the volatile nature of the Web, some Uniform Resource Locators (URLs) that connected to Web sites at the time of publication may no longer connect. MSDN is always working on keeping URLs current.

Notes

What are these COL, CHM, CHI, CHW and CHQ files on my CD?

Library contents

What are these COL, CHM, CHI, CHW and CHQ files on my CD?

A .COL file defines the document set which consists of a number of CHM files.

MSDN document files are compiled HTML files called "chums" and they have an .CHM file extension. Separating information into .CHM files allow us to provide interim content updates on the Web.

The CHI and CHW and CHQ files are index files created to enhance index, keyword, and full-text search performance with the MSDN Viewer.

Library contents

The contents of the Visual Studio 98 Library Edition will continue to evolve. We have provided product documentation and a substantial portion of the current MSDN Library.

The Microsoft Developer Network team does not edit most of the product documentation, specs, and articles included in the MSDN Library. You may encounter documentation errors, references to page numbers, and formatting problems. We will communicate any errors you report to the appropriate product documentation groups.