WMI SDK Sample - TempConsumer

Windows Management Instrumentation SDK Sample

TempConsumer

The TempConsumer sample demonstrates a temporary asynchronous event consumer application. TempConsumer consumes events produced by the provider in the EventProvider WMI SDK sample project. The events that this consumer requests are those of class MyEvent. The EventConsumer program will continue to run and print received event information until the user presses the <ENTER> key.

NOTE: The TempConsumer sample registers to receive WMI events of the MyEvent class which are generated by the EventProvider sample. If the EventProvider sample provider has not been built and registered prior to using the TempConsumer sample, TempConsumer will not receive any events. Refer to the EventProvider sample documentation for instructions on building and registering the provider.

Building the TempConsumer Application

The application can be built from the command line using NMAKE, or it can be built using Microsoft Visual C++.

From the command line in the sample installation directory, type the following:

NMAKE /f "Makefile"

From Microsoft Visual C++:

1. Select File + Open Workspace

2. Select the TempConsumer.dsp file

Using the TempConsumer Application

1. Build and register the EventProvider sample provider if this has not already been done. See the EventProvider sample documentation for details.
2. Build the TempConsumer application as shown above.
3. Execute the TempConsumer application in the command prompt window in the sample installation directory:

TempConsumer.exe

4. Press the <ENTER> key when you wish to stop collecting events.

General Notes

Things to remember when you're building your own WMI client application:

1. If you want your client to run on NT and non-DCOM versions of Windows 95, manually load the ole32.dll and see if CoInitializeSecurity() exists. This routine won’t exist on Windows 95 installations that don’t have DCOM installed separately. If this routine doesn't exist, the asynchronous routines in this sample won’t work because of mismatched security level problems. The synchronous techniques will still work.

2. If you don’t care about non-DCOM versions of Windows 95, you can define _WIN32_DCOM so that CoInitializeSecurity() is available for implicit linking. Don't use _WIN32_WINNT to get this prototype since it won't compile under the Windows 95/98 operating systems.

3. In any case, the CoInitializeSecurity() call (in InitInstance()) is required to work around a security problem when WMI trying to call a Sink object but won't identify itself. The CoInitializeSecurity() call turns off the authentication requirement.

4. WMI interfaces are defined in wbemcli.h and wbemprov.h found in the wmi\include directory. You may #include both these files by including just wbemidl.h located in the same directory.

5. WMI interface CLSIDs are defined in wbemuuid.lib. If you get unresolved externals in interfaces and CLSIDs, this is what is missing.

6. You'll need to link with oleaut32.lib and ole32.lib to get the needed COM support.

7. In the Link|Output settings, specify 'wWinMainCRTStartup' as the entry point. This is per the Unicode programming instructions.

8. If you're using the makefiles, don't forget to set the Visual C++ environment variables. This is done by running VCVARS32.BAT.