archive
/
windows-server-2003
mirror of https://github.com/selfrender/Windows-Server-2003
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
Leaked source code of windows server 2003
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
4 Commits
1 Branch
0 Tags
1.5 GiB
Tree: 5c6fe3db62
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '5c6fe3db62'
${ noResults }
windows-server-2003/base/ntos/wmi/sample/wmifilt/wmifilt.htm

106 lines
6.4 KiB
Raw Normal View History

commiting as it is
4 years ago
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
  2. <HTML>
  3. <HEAD>
  4. <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-
  5. 1252">
  6. <META NAME="Generator" CONTENT="Microsoft Word 97">
  7. <TITLE>WMIFilt</TITLE>
  8. </HEAD>
  9. <BODY LINK="#0000ff">
  11. <FONT FACE="Verdana" SIZE=5><H2>WMIFilt</H2>
  12. </FONT><FONT FACE="Verdana" SIZE=2>
  13. <P><span style="color:#FF0000;font-size:10pt;font-family:Arial">[This is preliminary
  14. documentation and subject to change.]</span></P>
  16. <H3>SUMMARY</H3></FONT><FONT FACE="Verdana" SIZE=2><P>
  17. This is a sample Plug and Play filter
  18. driver that provides WMI data blocks. Typically, driver writers will copy the sample code into their own driver
  19. and make any minor
  20. modifications so that the WMI data blocks are always available when the driver is loaded. Alternatively, WmiSamp
  21. can be left as a filter driver if WMI data blocks should only be made available when the filter driver is loaded.<p>
  23. <H3>BUILDING THE SAMPLE</H3></FONT><FONT FACE="Verdana"
  24. SIZE=2><P>
  25. Follow these steps to WMI-enable a driver with the sample code.<p>
  27. 1. Determine what data needs to be provided and organize it into data blocks that contain related data items. For example,
  28. packets sent and bytes sent could be part of a single data block, while transmit errors could be part of a data block that
  29. contains other error counts. Determine if the device needs notification when to enable and disable
  30. collections in the case of data blocks that impose a performance hit to collect.<p>
  32. 2. Write one or more Managed Object Format (.mof) files that describe the data blocks. In doing this, the driver writer
  33. will need to run the GUIDgen tool to create globally unique GUIDs that are assigned to the data blocks. GUIDgen
  34. <I>must</I> be run so that no two data block formats have the same GUID.
  35. Compile the .mof files into .bmf files by using the Mofcomp tool.
  36. The resulting .bmf files are platform-independent binaries, and
  37. can be reported as resources attached to the .sys file or as one or more instances of a data block queried by WMI. The
  38. former mechanism is useful for drivers with a static .mof and the latter for drivers with a dynamic .mof. For .mof data
  39. reported via a resource attached to the .sys file, reference the .bmf file in the driver's .rc file so that the .bmf file
  40. data is included as a resource of the driver's .sys file. For .mof data reported as instances of a data block, the .x files
  41. are included into the source of
  42. the driver as a global data buffer.
  43. Note that .x files are created by wmimofck.exe and are the ASCII representation of the .bmf file.
  44. It is possible that a driver reporting via the data block query mechanism could have many
  45. instances of the binary .mof data block and only report those that are appropriate depending upon the state of the device.
  47. See the USE_BINARY_MOF_QUERY definition for more information. Also note that one of the byproducts of generating the
  48. binary .mof file is a header file that contains GUID and structure definitions for the data blocks. Use this header
  49. because it will always be up to date with the .mof.
  50. <p>
  51. 3. Build the WMIGUIDREGINFO structure with the GUIDs for the data blocks defined in the .mof file. If the device should be
  52. notified when to start and stop collection of a data block, the WMIREG_FLAG_EXPENSIVE flag should be set for the data block in the WMIGUIDREGINFO structure.<p>
  54. 4. Implement the six WMI function callback routines and reference them in a WMILIB_CONTEXT structure. Note that some of them are optional.<p>
  56. 5. Modify the sources and makefile.inc files so that the .mof file is compiled into the .bmf, .x, .vbs and .h file. Also check that USE_BINARY_MOF_QUERY is defined appropriately for the method of reporting MOF data.
  57. <p>
  59. <B>Note</B>: Another byproduct of compiling the .mof is a .vbs file. This is a VBScript file that is run from the command line on the target machine running the new device driver. It will cause WMI to query all data blocks and properties, and put the results into a .log file. This can be very useful for testing WMI support in your driver. For more sophisticated testing, the VBScript can be extended by hand. The WBEMTest tool (located in %windir%\system32\wbem\) can also be used.
  60. <P>
  63. <H3>RESOURCES</H3></FONT><FONT FACE="Verdana" SIZE=2><P>
  65. Please see the Kernel-Mode driver section of DDK documentation for more information on WMI.
  67. <B>WMI Mof Check Tool</B><P>
  69. WmiMofCk validates that the classes, properties, methods and events specified in a binary mof file (.bmf) are valid for use with WMI. It also generates useful output files needed to build and test the WMI data provider.<p>
  71. If the -h parameter is specified, a C language header file is created that defines the GUIDs, data structures, and method indices specified in the MOF file.<p>
  73. If the -t parameter is specified, a VBScript applet is created that will query all data blocks and properties specified in the .mof file. This can be useful for testing WMI data providers.<p>
  75. If the -x parameter is specified, a text file is created that contains the text representation of the binary .mof data. This can be included in the source of the driver if the driver supports reporting the binary .mof via a WMI query rather than a resource on the driver image file.<p>
  77. <B>Usage</B>: wmimofck -h&lt;C Header output file&gt;
  78. -x&lt;Hexdump output file&gt; -t&lt;VBScript test output file&gt; &lt;binary
  79. mof input file&gt;<p>
  82. <H3>CODE TOUR</H3>
  83. <H4>File Manifest</H4>
  84. </FONT><U><PRE>File&#9;&#9;Description
  85. </U>
  86. Filter.c NULL filter driver (boilerplate code)
  87. Filter.h Header file for the filter driver
  88. Filter.mof Managed Object Format file that contains descriptions of the data blocks events and methods implemented by the driver
  89. Filter.rc Resource file containing version information
  90. Inf.txt Sections of the .inf file to change
  91. Makefile Standard Windows NT makefile
  92. Pnp.c Plug and Play routines
  93. Power.c Power Management routines
  94. Sources Sources for build
  95. Util.c NULL filter driver&#151;boilerplate code
  96. Wmisamp.c Sample device driver that shows various mechanisms for using WMI in a kernel-mode driver
  97. <p>
  98. </FONT><P ALIGN="CENTER"><A HREF="#top"><FONT FACE="Verdana" SIZE=2>Top of page</FONT></A><FONT FACE="Verdana" SIZE=2> </P></FONT>
  99. <TABLE CELLSPACING=0 BORDER=0 WIDTH=624>
  100. <TR><TD VALIGN="MIDDLE" BGCOLOR="#00ffff" HEIGHT=2>
  101. <P></TD>
  102. </TR>
  103. </TABLE>
  105. <FONT FACE="MS Sans Serif" SIZE=1><P>&copy; 1999 Microsoft Corporation</FONT><FONT FACE="Verdana" SIZE=2> </P></FONT></BODY>
  106. </HTML>