Partager via

COM Objects

  • Article

Microsoft® Windows® 2000 Scripting Guide

The Component Object Model (COM) provides a standard way for applications (.exe files) or libraries (.dll files) to make their functionality available to any COM-compliant application or script. That is the textbook definition of COM. What COM really does, however, is make it possible for nonprogrammers to write scripts for managing Windows operating systems. COM provides a mechanism for translating script code into commands that can be acted on by the operating system. Without COM, anyone hoping to automate system administration would have to master not only a high-level programming language such as C++ or Visual Basic but also all of the Windows Application Programming Interfaces (APIs). In effect, COM brings Windows programming to the masses.

COM components are files (typically .exe or .dll files) that contain definitions of the objects the component has available for use. (These definitions are known as classes.) When you create a COM object in a script (a process known as instantiation), you are creating an instance, or copy, of one of the classes contained within the COM component. After the instance has been created, you can then take advantage of the properties, methods, and events exposed by the object.

Objects that make their functionality available through COM are known as COM servers. Applications or scripts that make use of that functionality are referred to as COM clients. For example, when you write a script that uses WMI, WMI is the COM server and your script is the COM client. COM servers can be implemented in one of two ways:

  • Out-of-process servers. Out-of-process servers are typically implemented in executable files and run in a different process than the script. For example, when you start a script, an instance of Wscript.exe begins to run. If you next instantiate a Microsoft Word object, you are then working with two processes: Wscript.exe and the Winword.exe process in which the Microsoft Word object runs.

  • In-process servers. Libraries (.dll files) are known as in-process servers because they run in the same process as the application or script that called them. For example, when you call the FileSystemObject from within a script, no new process is created. This is because the FileSystemObject (which is found in the Scrrun.dll library) is an in-process server and thus runs in the same process as the script. In-process servers typically run faster than out-of-process servers because the operating system does not have to cross process boundaries (from the script process to the object process and then back) to access the objects methods and properties.

As noted previously in this chapter, VBScript works with a subset of objects known as Automation objects. All COM objects must support one or more interfaces, which are simply the avenues by which a COM client can access the COM server. Any object that supports the IDispatch interface is known as an Automation object. Because not all COM objects support the IDispatch interface, VBScript cannot access all of the COM objects on your computer.