Introduction to Windows Script Components

To properly introduce WSC, I need to dive a bit deeper into developer-speak than I'm accustomed to doing; so bear with me. First, you should realize that you're already using programming objects in your scripts. Specifically, you're using objects-or components-written to Microsoft's Component Object Model, or COM. I briefly touched on COM in Chapter 5, but here's a quick refresher on what it does for you.

When you create, or instantiate, a COM class in a script, you do so by using the CreateObject statement. For example, CreateObject("Scripting.FileSystemObject") creates a new FileSystemObject. When VBScript executes that command, it asks COM to load "Scripting.FileSystemObject" into memory and make it available to VBScript. COM looks up the class "Scripting.FileSystemObject" in the registry. You can open the registry yourself, using Regedit or another editor, and search for "Scripting.FileSystemObject." You'll find that it has a globally unique identifier (GUID) of "{0D43FE01-F093-11CF-8940-00A0C9054228}" and that it's in-process server (InprocServer32) is C:\Windows\System32\scrrun.dll, which is the Microsoft Scripting Runtime DLL. COM loads that DLL into memory when you ask for a FileSystemObject.

All COM components must have an in-process server. When you create a new WSC, you're essentially creating a script that pretends to be a COM component. That pretense is helped by Scrobj.dll, which is the WSC in-process server. You can create instances of WSCs within scripts, and when you do so, COM loads Scrobj.dll, which in turn loads the actual WSC script and executes it. So a WSC is a regular VBScript masquerading as a DLL! In fact, any programming language that uses DLLs-including Visual Basic, Delphi, VBScript, C++, and more-can use a WSC, because WSCs meet all of the requirements for regular COM components.

Okay, that's enough developer-ese for one chapter. It's time to start looking at how you create these things.

In- and Out-of-Process What, exactly, is the difference between in-process and out-of-process? In IIS 5.0 (and earlier), each Web site on a server runs in a separate instance of Inetinfo.exe. Each Inetinfo.exe has its own memory space, and any COM objects that an ASP page instantiates generally run inside that memory space. It's easy for programmers, but if a COM object causes a problem, it can take down the entire Web site. Almost all objects you'll use in ASP run in process; out-of-process components run in their own memory space, and must implement special techniques to allow communications between their own space and Inetinfo.exe's. IIS 6.0 introduces a slightly new model called worker process isolation. Without going into the gory detail of IIS 6.0's architecture, it works something like this: Only one copy of Inetinfo.exe runs on the server. It spawns several subordinate worker processes, each with its own memory space, to execute Web sites. In-process servers run in these worker process spaces, effectively protecting different Web sites from a crash in any one site.