[Previous] [Table of Contents] [Next]

# Introduction

When Microsoft Windows 3.1 was released, I had hoped that it would come with an operating system-hosted script language. Other operating systems did provide such languages, but Windows 3.1 had only the old-style MS-DOS batch files. For a number of reasons, I didn't want to use third-party solutions such as PowerBASIC and Rexx. After Microsoft Windows 95 became available, I used Microsoft Visual Basic, Visual Basic for Applications (VBA), and HTML scripts from time to time. In 1998, while I was writing the Microsoft Windows 98 handbook for Microsoft Press Germany, I discovered that Windows 98 had a new feature called Windows Scripting Host (WSH), which provided two scripting languages, Microsoft Visual Basic, Scripting Edition (VBScript) and Microsoft JScript.

Later that year, I began writing the Microsoft Windows 98 Power Toolkit for Microsoft Press. I wanted to cover WSH extensively in the book and explain how to use scripts to automate such tasks as backing up files, mapping network drives and printers, and showing user dialog boxes. However, I couldn't find any documentation about WSH, and the help files that shipped with Windows 98 didn't cover script programming. The Windows Script Host Reference was basically just a white paper, and the books and Web sites I consulted dealt only with HTML scripting using VBScript and JScript. So I started investigating the WSH samples that shipped with Windows 98, visiting Microsoft's scripting site, and writing my own WSH samples.

I struggled to figure out which objects to use in a given situation, how to get information about properties and methods, and how to implement a script in either VBScript or JScript. Debugging my first scripts was a painful process. WSH 1 reported mostly cryptic run-time error messages in line x—or else the script simply didn't do what I expected. (At the time, I didn't know how to use the Microsoft Script Debugger in a scripting environment.) After receiving a run-time error message, I would load the script again and again into Notepad, count the lines manually to find the faulty line, and try to amend the code using a trial-and-error approach. After a few hours, I decided that this approach couldn't possibly be the right way to do script programming.

Once I started visiting WSH newsgroups, I found that other people were having the same problems. Newsgroup participants such as Ian Morrish, Clarence Washington, and Michael Harris shared a great deal of useful knowledge, but I still needed more details, especially about advanced programming. I had written books about VBA programming and HTML scripting, so I was familiar with Internet sites dealing with HTML scripting and ActiveX programming. From these sites, I learned that some editors supported script programming, and I learned how to use the script debugger and tools such as the Object Browser in Visual Basic to find out more about objects and their methods and properties. I was able to increase my productivity significantly and create scripts in a relatively comfortable environment.

At the outset, I had used the typical "macro programmer" approach—I tried to combine simple statements to create a script program. Sometimes this approach worked, but often I was bombarded by syntax and run-time error messages. I also missed powerful statements that I could have used to copy files, launch programs, retrieve user input, and so on. In the WSH newsgroups, some people recommended third-party tools and languages that promised a rich collection of statements. I knew from past experience, however, that if a language provides a rich collection of statements, that language is difficult to learn and to use.

Using my VBA programming experience as a foundation, I began to explore the philosophy behind scripting. I learned that you don't need statements "buried" in a scripting language for tasks such as reading script arguments and copying files because WSH gives you access to all COM objects installed on a system. So a script can use the features offered by such COM objects to handle its tasks. You can also add new COM objects to a system, which increases the number of scriptable functions without changing the underlying scripting language. If an object provides spell checking, for example, you can simply use that object in a script. Once I became more familiar with WSH, I found it to be the hottest technology from Microsoft in recent years. WSH is the glue that combines objects (for example, a Microsoft Office spell checker, a word processor, a browser, and a mail system) into a new, customized application. You can implement a sophisticated application quickly and easily, using just a few lines of script code.

By this point, I had collected a lot of material, gained some experience, and written many samples. I had also written a brief section on WSH in the Microsoft Windows 98 Power Toolkit. At the 1998 Frankfurt book fair, I met with Microsoft Press acquisitions editors Thomas Pohlmann and Stephen Guty, and the idea for a WSH script programming title was born. Six weeks later, my German manuscript was ready. The first edition of the book was published in January 1999. It was the first WSH 1 book published worldwide. In the spring, the first WSH 2 beta version was released. We decided to wait until the release of Windows 2000 before going ahead with a WSH 2 book. I spent the additional time investigating WSH 2 and other hot technologies such as ActiveX Data Objects (ADO), Active Directory Service Interfaces (ADSI), and Windows Management Instrumentation (WMI). I also wrote an article series for WSH beginners in a computer magazine, created the WSH Bazaar on my Web site, and spent many hours visiting the WSH newsgroups to learn more about the troubles that script programmers were experiencing.

The material I collected was enough for two books—this one, for beginners and intermediate users, and a volume for advanced users that deals with scripting technologies. Microsoft Press will publish the second book, Advanced Development with Microsoft Windows Script Host 2.0, later this year. That book is for advanced script programmers who want in-depth coverage of the topics covered in this introductory volume. Advanced Development with Microsoft Windows Script Host 2.0 will explain how to use additional objects to extend your scripting capabilities. Special topics, such as the XML structure of .wsf files and many undocumented hints that pertain to those files, will be covered. Also included will be explanations of how to use additional tools such as the OLE/COM Object Viewer or the Object Browser to find out more about objects and their methods and properties. Along with other useful techniques, you'll learn how to access Microsoft Office applications from WSH scripts and how to use objects such as Microsoft Excel spreadsheets, the Office spell checker, Microsoft Word documents, and Microsoft Outlook features. You'll also learn how to read and write to databases from scripts by using Microsoft Access or ActiveX Data Objects (ADO). The book also explains how administrators can access Active Directory Service Interfaces (ADSI) from WSH scripts to maintain user accounts, services, or shares. You'll learn about the new technology Web-Based Enterprise Management (WBEM), and its Microsoft implementation called Windows Management Interface (WMI), and you'll find out how to use scripts to access networking and machine information and to cancel running processes. You'll also discover how to write ActiveX controls by using Visual Basic 5 Control Creation Edition (CCE) to access Windows API functions, create ActiveX forms, access the Clipboard, control the CD tray, and much more. I'll delve into the source code of several ActiveX controls used within this book in much greater detail. Whereas Microsoft Windows Script Host 2.0 Developer's Guide teaches you what you need to know to begin scripting with WSH, Advanced Development with Microsoft Windows Script Host 2.0 will provide you with the information you need to become an expert WSH programmer. You'll learn the programming tricks professional developers use to help get the most out of WSH.