This chapter is from the book
This chapter is from the book
This chapter is from the book
Locating and Using Unusual Objects
Several powerful, commonly used objects provided with Windows are documented by Microsoft in the Windows Scripting reference documents, and I'll discuss most of these in Chapters 4 through 10 and in Appendix C, "WSF and WSC File Format Reference." If you're new to scripting, these will be enough to get you started, so you may just want to skip ahead to Chapter 4.
In addition to these standard objects, many developers and companies provide add-in objects for free or for sale. You can find many of these listed at http://www.microsoft.com/com/tech/activex.asp and on the many Web sites devoted to ActiveX and to scripting. Some of these sites are listed on pages 41-42.
There is, however, a wealth of objects already on your computer: Hundreds of COM objects are supplied with Windows, and hundreds more are added if you install applications such as Word, Excel, and Visio. Many were designed just for the use of specific application programs and are of no use to script authors. Others are general-purpose objects for use by scripts and by compiled programs. How can you tell what objects are installed on your computer and of those, which are useful for scripting? To be honest, identifying useful objects is tricky business. But if you enjoy detective work, read on.
To get an idea of what I mean by "hundreds of objects," take a look at the Windows Registry.
CAUTION
Improper changes to the Windows Registry can make your computer nonfunctional. There is no undo command in the Registry Editor, so be very careful not to make any changes while examining the Registry.
To view the Registry, click Start, Run, type regedit, and press Enter. Expand the entry for HKEY_CLASSES_ROOT and scroll down past the .xxx-format entries into the entries that spell out names like "something dot something," as shown in Figure 3.4. Most of the entries from here down represent object classes; you can tell which ones do by the presence of a CLSID or CurrVer key under the object name.
){kind=small}
Figure
3.4 COM object classes are listed in the Registry under HKEY_CLASSES_ROOT,
after the .xxx entries. Objects have an associated CLSID entry.
In Figure 3.4, the FaxControl.FaxControl.1 entry has a CLSID entry, so it is an object. A CLSID (or class ID) is a very long, essentially random number that object authors use to give their object a unique "fingerprint." A CurrVer entry, such as the one found under FaxControl.FaxControl is used when there's a chance more than one version of the class program might be installed on your computer. The CurrVer value tells Windows where to look to find the class information for the most recent version of the object. Find that entry, and you'll find the object's CLSID.
The first step in scouting out new and interesting objects is to peruse the Registry for names that sound interesting. For this example, I'll follow up the FaxControl.FaxControl.1 object from Figure 3.4.
When you've found a CLSID value for a potentially interesting object, locate the matching value under My Computer\HKEY_CLASSES_ROOT\Clsid, where you'll find the information Windows uses to locate and run the program file that actually manages the object.
Figure 3.5 shows the class information for FaxControl.FaxControl.1. The InprocServer32 entry shows the actual program module (usually a DLL or OCX file) that manages the object. In this case, the program is \WINDOWS\system32\Setup\fxsocm.dll. The name of this object and the location of its DLL make it sound like it might be used for setting up the Fax service. But how?
The first thing that you have to check is whether the object is even suitable for use in script programs; some aren't. The first test, then, is to see whether you can create an object in your chosen scripting language. Use the server.object name that you found under HKEY_CLASSES_ROOT. In VBScript, it would look like this:
set obj = CreateObject("FaxControl.FaxControl.1")
WScript.echo "CreateObject worked!"
)
Figure
3.5 Class ID information for the FaxControl.FaxControl.1 object.
If this script produces an error message, the object can't be used in scripts. If it runs without an error message, as it did when I tested FaxControl.FaxControl.1, the object has passed the first hurdle.
TIP
On http://www.helpwinxp.com/hood, I've listed all the undocumented objects provided with Windows XP that pass this test—to scout for interesting objects, start with that listing.
Now comes the hard part: extracting information about the object's methods and properties. In some cases, Microsoft or the object's creator will have supplied a help file describing the object. See if the Clsid registry values list has a help file ending in .hlp or .chm. If it does, at a command prompt type
start pathname\helpfile.xxx
where pathname\helpfile.xxx is the full path to the help file listed in the Registry. This may show you how the object works. In the case of FaxControl.FaxControl.1, there is no help file.
If no help file is named, don't give up. Because COM objects are designed to be used by many different programming languages, they have to record the types of values their properties and methods use—numeric, string, date, and so on—and they have to make this information available to any program that asks. You may be able to burrow into the object's program file to find this information.
The easiest way to do this is with an object browser, a program that's designed to do just this sort of burrowing. Microsoft provides one with many of its applications. If you have Microsoft Word, Excel, or PowerPoint, the Object Browser is included as part of the Macro Editor. Start the application and click Tools, Macro, Visual Basic Editor. Then click View, Object Browser. If you have the full developer's version of Visual Basic installed, run it and click View, Object Browser.
To view information for a questionable class, you'll need to tell Word (or Visual Basic, and so on) to look into the class's program file. To do this, click Tools, References. Click Browse and locate the DLL or OCX file you found in the Registry. Click Open, and the library will appear as a checked item in the Available References list, as shown in Figure 3.6.
)
Figure
3.6 Selecting an object class type library to view in the Object Browser.
When the object type is listed and checked under Available References, click OK.
Then, select the class name from the library list in the upper-left corner of the Object Browser window, as shown in Figure 3.7. Choose object types in the left panel, and the browser will display the object's methods, procedures, and predefined constants in the right panel under "Members." You can select the objects in this list one by one, and in the bottom panel, the browser will display the method or procedure's arguments, if any, and any explanatory text it can dig up.
){kind=small}
Figure
3.7 Viewing a class's type information in the Object Browser.
If you don't have any of the applications I've mentioned, another tool, called the OLE/COM Object Viewer, is provided as part of Visual C++ as well as with the Windows XP and Windows 2000 Resource Kits. You can also download it from http://www.microsoft.com by searching for "OLE/COM Object Viewer."
The OLE/COM Object Viewer is much more difficult to use than the Object Browser. Here are some tips for using this viewer:
Try to find the object of interest under Object Classes, All Objects. I've found that not all the objects I'm interested in are listed there. For example, Scripting.Dictionary is present, whereas Scripting.FileSystemObject is missing. If you can't find it there, look under Type Libraries.
Double-click the library or object to view its class information. This information is designed for COM object programmers, not end users, so it's going to be tough to understand.
Typedef items list some predefined constant values used by all the objects provided by the server.
Coclass items define the objects that the class server can create. If you view the contents of a coclass item, you'll find the class's predefined constants, properties, and methods.
You should also search the Internet for references to the object name (for example, search for FaxControl.FaxControl.1 or FaxControl.FaxControl) or the program file itself. I've found that google.com is a great place to start. Be sure to search both the Web and Groups directories. Many programmers haunt the comp.xxx groups, and you may find an archived discussion about the object.
Although either object browser can show you what sorts of values the methods and properties expect and return, it can't tell you what these values mean, so you'll have to experiment to find out if and how you can use them. In the case of FaxControl.FaxControl.1, the Object Browser showed two properties and two methods, as listed in Reference List 3.4.
Reference List 3.4 Properties and Methods of the FaxControl.FaxControl Object.
IsFaxServiceInstalled
Property; returns a Boolean value.
IsLocalFaxPrinterInstalled
Property; returns Boolean value.
InstallFaxService
Method; returns no value and takes no arguments.
InstallLocalFaxPrinter
Method; returns no value and takes no arguments.
This sounds pretty straightforward. There are no arguments to supply to these methods, so there's no detective work required there. Also, the names sound pretty self-explanatory. This object lets you know whether the Fax service and the Fax Printer are installed, and it can install them. But does it work?
Here's a sample script I wrote to check:
set obj = CreateObject("FaxControl.FaxControl.1")
WScript.echo "IsFaxServiceInstalled =", obj.IsFaxServiceInstalled
WScript.echo "IsLocalFaxPrinterInstalled =", obj.IsLocalFaxPrinterInstalled
The results when I ran it on a Windows XP computer that had a modem but did not have the fax service set up were
IsFaxServiceInstalled = 0 IsLocalFaxPrinterInstalled = 0
When I ran the script
set obj = CreateObject("FaxControl.FaxControl.1")
obj.InstallFaxService
Windows Setup asked for my Windows XP CD disk and installed the Fax service and printer. The first script's output became this:
IsFaxServiceInstalled = -1 IsLocalFaxPrinterInstalled = -1
Here, -1 means True, (any nonzero value means True) so the object really does the job you'd expect it to. Here's a script that can automatically be sure a user's Windows XP system has the Fax service as well as a fax and printer installed:
set obj = CreateObject("FaxControl.FaxControl.1")
if not obj.IsFaxServiceInstalled then
WScript.echo "Installing Fax Service..."
obj.InstallFaxService
elseif not obj.IsLocalFaxPrinterInstalled then
WScript.echo "Reinstalling Fax Printer..."
obj.InstallLocalFaxPrinter
else
WScript.echo "Fax printer is ready to go."
end if
This works like a charm. Of course, it's easier to do this same thing from the Windows XP user interface in the Printers and Faxes folder. Nevertheless, this is a good example of the functionality you can find by digging into the many objects that come with Windows, and it shows the kinds of scripts you can write to manage Windows computers so that other users don't have to poke around with the Control Panel themselves.