This chapter describes the use of Object Rexx as a Windows Scripting Host (WSH) engine.
Object Rexx is automatically enabled as an engine for Windows Scripting Host at installation. This chapter gives a brief description of WSH and how Object Rexx interacts with it, and shows you how you can best use this feature.
The easiest part of this feature to understand and to become immediately productive with is its ability to use Object Rexx as a scripting language for Microsoft's Web browser, Internet Explorer. To go quickly to using this technique, see Invocation by the Browser.
Windows Scripting Host (WSH) is a unified scripting environment for all Microsoft products. It is usable by any macro language that follows its specification. WSH is the mechanism that allows users to customize and dynamically control the products that support its hosting standard.
The Windows Scripting Host engine for Object Rexx enables users to drive Microsoft's products, notably Internet Explorer. Other products that can be driven include the components of the Office suite, like Word, Excel, and so on.
The difference between WSH and the OLE support that Object Rexx provides is the context in which the script resides. OLE scripts are exterior to the product, and WSH scripts can be embedded in the files that the product uses. The advantage of embedding the script is that the user has fewer files to manage. The Object Rexx engine for WSH enables users to accomplish this in a seamless fashion.
There are two components to WSH. The first is the host - the product that can be scripted. The second is the engine - the product that interprets the script.
Object Rexx supplies the engine component of WSH.
As with many new technologies today, WSH introduces several new concepts and terms. The best way to describe these is to start with an overview of the problem that WSH addresses, and its history.
Until recently, Microsoft provided users simply with a COM (Common Object Model) interface to their office products. COM is a binary, as opposed to text, command input system. These commands drove the product - by, for example, telling Microsoft Word to print the current document - and did not contain any logic or decision-making capabilities. Users who wanted such capabilities developed them in programs external to the COM object. Accessing the interface required the user to develop the logic to drive the COM object at first in C++, then later in Visual Basic. The investment for the user, in development time, was quite significant.
WSH is a consolidation of the scripting language proliferation. Borrowing heavily from the browser paradigm, the host interprets a language-independent XML file that contains one or more scripts where each script is encapsulated in a script (script tag) that denotes the language of the script, and any other necessary environmental parameters. The host extracts the script from the file, and passes it to the appropriate interpreter.
Microsoft provides three fully-implemented scripting hosts. They are Microsoft Internet Explorer, CScript, and WScript. As an expansion on the concept of using a scripting language to drive external products, CScript and WScript were developed to control the Windows operating system. The two modules are so similar that they are sometimes referred to as C/WScript. CScript is intended to be used from the command line, and WScript is best used in the Windows environment. Both provide their services to the script through the WScript object. Using the default method for output WScript~Echo(), CScript sends the output to a console screen in the same manner as the Object Rexx command Say, whereas WScript~Echo() in a script controlled by WScript will create a pop-up box in which the user must click the OK button to make it disappear.