)
Figure 10-2 diagrams the overall architecture of WMI. In the WMI model, the world is divided into consumers and providers of data and events. Consumers consume, and providers provide, blocks of data that are instances of abstract classes. The concept involved here is no different from that of a class in the C++ language. Just like C++ classes, WMI classes have data members and methods that implement behaviors for objects. What goes inside a data block isn't specified by WMI—that depends on who's producing and for what purpose. When it comes to device drivers, though, the content of a WMI data block is most likely going to be statistical in nature. Consumers of driver data, therefore, are often performance monitors of one kind or another.
Figure 10-2. The world of WMI.
WMI allows for multiple namespaces, each of which contains classes belonging to one or more user-mode providers. Providers register with the Windows Management Service by using COM interfaces that are documented in the Platform SDK. When Windows 2000 ships, the operating system (including all device drivers) will support a namespace called root\cimv2, which stands for Version 2 of the Common Information Model. At the time of this writing, the structure of the CIMV2 namespace was rather fluid, with the consequence that Microsoft has temporarily decided to use another namespace, root\wmi, for device driver classes.
A WDM driver can act as a provider of instances of a WMI class. The description of all the classes a driver can provide data for is known as the driver's schema. You define a schema by using a language named the Managed Object Format, or MOF. The system maintains a data dictionary known as the repository that contains the definitions of all known schemas. Assuming you do all the right things in your driver, the system will automatically put your schema into the repository when it initializes your driver.
Later in this chapter, I'll show you a sample named WMI42.SYS, which is available on the companion disc. This sample has the following MOF schema:
1 |
[Dynamic, Provider("WMIProv"),
WMI,
Description("Wmi42 Sample Schema"),
guid("A0F95FD4-A587-11d2-BB3A-00C04FA330A6"),
locale("MS\\0x409")]
class Wmi42
{
[key, read]
string InstanceName;
[read] boolean Active;
[WmiDataId(1),
Description("The Answer to the Ultimate Question")
]
uint32 TheAnswer;
};
|
I don't propose to describe all the details of the MOF syntax; that information is available as part of the Platform SDK and WMI SDK (http://msdn.microsoft.com/developer/sdk/) documentation. You can either construct your MOF by hand, as I did for this simple example, or use a tool named WBEM CIM Studio that comes with the Platform SDK and WMI SDK. Here, however, is a brief explanation of the contents of this MOF file:
As developers, we would run the MOF compiler on this schema definition to produce a binary file that eventually ends up as a resource in our driver executable file. (Resource in this sense is the same concept that application developers have in mind when they build dialog box templates, string tables, and other things that are part of their project's resource script.) Part of the process of initializing our driver is telling the WMI provider where the resource is so that it can read the schema and augment the repository.
We should also run a utility named WMIMOFCK.EXE, which is available in the DDK, after compiling our schema. This utility performs additional checks to make sure that the schema is compatible with WMI.
2