The Scoop on Script

Robert Hess
Developer Relations Group
Microsoft Corporation

January 11, 1999

The following article was originally published in the Site Builder Magazine (now known as MSDN Online Voices) "More or Hess" column.

Personal Computers once were a lot simpler than they are today. Memory was scarce, hard drives were virtually non-existent, and what limited graphics there were could normally be found only in games.

But many personal computers had a programming language that was all but integrated into the operating system. BASIC was used on almost all systems -- and because of this, a very high percentage of users in those days spent a lot of time dabbling in writing their own programs. Over time, as users gained more experience with BASIC, they would encounter various limitations of the system-supplied version. It might be the speed of execution, or the lack of being able to compile the code into binary form to ensure protection of "intellectual property." These users moved on to commercial programming languages -- either better versions of BASIC, or perhaps Assembler, Pascal, Forth, or the new language on the block, "C".

As more and more programmers gave scant glances at the versions of BASIC that came with their OS, the focus and importance of having such a built-in interpreter appeared to diminish. The Macintosh came out without any form of programming language built into it. In the early days, anybody who wanted to program on the Mac had to purchase a different computer (the Lisa) to do it. Windows, too, had no notion of a user-accessible programming language. Over time, various products were introduced that took charge of this niche. Apple came out with HyperCard for the Mac, Microsoft introduced Visual Basic® for Windows, and various other software companies released products that provided similar programming interfaces.

Enter the <SCRIPT>

The Web has now unexpectedly created a renewed interest in providing a general-purpose programming model for the operating system. As Web authors wanted more and more functionality out of the pages they built, the <SCRIPT> element made its debut as the method to provide this. And as browser technology is integrated into the operating system, this notion of a system-level script interface suddenly becomes real again.

Microsoft has made available a Windows Scripting Host, which is freely downloadable, and can be installed onto Windows 95 or Windows NT 4.0 (it will be built into the system beyond those versions; if you're using Windows 98, you've got it already). This component exposes the Visual Basic Scripting Edition (VBScript) and JScript® interpreters out to the system, so your script code can interoperate with the base system, as well as with applications installed on the system. While perhaps those scripts' functionality of isn't nearly as robust as what you could accomplish with Visual Basic, their importance lies in being offered directly by the Windows operating system. This is important for both users and application developers.

For the standard user, this now provides an environment similar to the .BAT processing of MS-DOS, but far more robust and able to directly interact with Windows applications.

Expose and Extend

For application developers (by that, I mean developers working on commercial-level application development), this is important even if they don't directly use scripting in their applications. By exposing COM-based automation interfaces for the functionality of their application, Windows Scripting allows the automation of applications -- either for internal testing or for users to build up scripts that perform standard tasks with the applications they use. For corporate users, this can minimize repetition and increase productivity.

Just as an example, let me describe a possible scenario:

You've got a digital camera, and you regularly use it to take pictures that you later post onto a "Family Photo Album" published on your personal Web site. After taking a number of pictures, you simply plug your camera into your Windows PC; after a few minutes, your new page "'magically" appears on your Web site.

Script running on the PC detects the connection event that was fired when the camera was plugged into the PC.
This script then fires up the camera manufacturer's custom photo download utility, and instructs it to download all of the images from the camera.
The script code then sends the images, one at a time through an image-processing application, and automatically builds thumbnails and full-size graphics of each image.
The script then fires up a Web-authoring application. Using some pre-defined templates, the authoring app creates a thumbnail gallery page, which links to individual full size image pages for each photo. The existing index page is updated to list an entry for this new thumbnail page.
An FTP utility is then fired up, a connection is made to the Web server that hosts the site, and the new/updated files are transferred over.
Finally, an e-mail message is sent out to all family members telling them that a new page was created, and providing the URL to it.

The above illustrates a fictional collaboration between possibly six different applications, none of which knew about the other -- and yet the end result provides a unique solution to a very specific problem. The only thing missing from making this scenario work today is the lack of application support for exposing app interfaces so that they can be called from script. While it is conceivable that a single application could encompass all of this, such an application would either need to be extremely complex (and expensive) to have the flexibility to deal with all of the permutations of devices and interfaces, or its functionality would be so limited that it wouldn't really solve anyone's problems.

Scripting and Windows DNA

In the past months, we've been talking a lot about Internet applications and Windows Distributed InterNet Applications Architecture (DNA), and you might wonder how this column's topic fits into the Windows DNA theme. The scripting interfaces offered by Windows Scripting are the same as those used by both client-side script and the server-side script employed Active Server Pages (ASP) files. Those same interfaces can be called by server components written in Visual Basic or C to add a specific application functionality to a server-based solution. But probably more important, the introduction of Windows Scripting also provides a method by which corporations can build their own Windows DNA-based solutions that use script code to draw together the functionality of a diverse set of applications into a customized distributed solution.

As the operating system and development tools move forward, I expect we will see a lot more importance put onto this level of collaboration and interface exposure for Windows applications. You could even start to see more applications that have no user interface of their own - applications that expect users to interoperate with them at a script or component level.

Robert Hess is an evangelist in Microsoft's Developer Relations Group. Fortunately for all of us, his opinions are his own.