Export (0) Print
Expand All
1 out of 1 rated this helpful - Rate this topic

Provider Framework Utility Classes

[WMI C++ classes that are part of the WMI Provider Framework are no longer available for use as of Windows Vista. Instead, see Using WMI for the preferred ways to write a WMI COM provider or a WMI provider that uses the .NET Framework System.Management namespaces.]

The provider framework libraries Framedyd.dll (debug version) and Framedyn.dll (release version) implement several provider helper classes. Some functions in Framedyn.dll have been removed from the header files for Windows XP. To continue to use these functions, add #define FRAMEWORK_ALLOW_DEPRECATED to your code before including Fwcommon.h.

Beginning in Windows XP, you can unload individual providers that are no longer required.

To use this capability, you must make the three following changes to your provider in MainDll.cpp:

  • In the function DllMain where you call CWbemProviderGlue::FrameworkLoginDLL, you must add a second parameter which is a pointer to a long.
  • In the function DllCanUnloadNow where you call CWbemProviderGlue::FrameworkLogoffDLL, you must add a second parameter which is a pointer to a long.
  • In the function DllGetClassObject where you create an instance of CWbemGlueFactory, you must add a parameter which is a pointer to a long.

In all three cases, the pointer to a long must be the same pointer.

Note  In Maindll.cpp, DllGetClassObject, DllCanUnloadNow, DllRegisterServer, DllUnregisterServer and DllMain routines must be wrapped in a try/catch block.

Caution  Provider debug builds link with Framedyd.lib for Framedyd.dll. Framedyd.dll is in the Microsoft Windows Software Development Kit (SDK) \bin directory which is not included in the system path. When a debug build of a provider is tested with the Windows Management service, the framework provider will fail to load because Framedyd.dll or one of its dependencies will not be located. Therefore, you must either copy Framedyd.dll from the Windows SDK \bin directory to the \system32\wbem directory or add the Windows SDK \bin directory to the system search path.

The following table lists the provider framework utility classes.

Utility classDescription
CHString Provides string comparison and manipulation functions for WMI.
CHStringArray Contains for creating and manipulating arrays of CHString.
TRefPointerCollection Grants access to a container class for pointers.
WBEMTime Facilitates conversions between various Windows and ANSI C run-time time formats.
WBEMTimeSpan Contains helper functions used to calculate and hold the time span difference between two WBEMTime objects.

 

Note  The CHString and CHStringArray classes are similar to the Microsoft Foundation Classes (MFC) CString and CStringArray. The WMI versions exist so that developers can access to string manipulation and comparison methods without having to access MFC. The WBEMTime and WBEMTimeSpan classes are also similar to the MFC CTime and CTimeSpan classes. The WMI versions are capable of storing time to nanosecond accuracy, and can also convert to and from BSTR. For more information about the CString, CStringArray, CTime, and CTimeSpan classes, see the Microsoft Foundation Classes on MSDN.

BSTR values returned by WBEMTime methods are in Date and Time Format: "yyyymmddHHMMSS.mmmmmmsUUU"

BSTR values returned by WBEMTimeSpan methods are in Interval Format: "ddddddddHHMMSS.mmmmmm:000"

Although times and time spans are stored internally as nanoseconds, they are not necessarily stored with nanosecond accuracy. This is because WBEMTime objects can be constructed using time formats that are accurate to a second (struct tm, and time_t). Adding artificial decimal places does not increase the accuracy.

 

 

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.