There are any advantages or disadvantages of using the WMI instead of Windows API to access to the information of the system? as speed, additional permissions, memory usage.
or depends on the WMI class and how the WMI implements the access to the information?
The main disadvantage of WMI is speed, it is slow to query data and if you are trying to use it during start up it can delay you starting as the WMI service takes a long time to come up.
However, WMI information is richer, as in you need to sometimes make several API calls to get the same amount, some information is a lot easier to get at and the filtering syntax can dramatically reduce the amount code you have to write.
If speed isn't a massive issue, I would always lean towards WMI.
Disadvantage: Speed
Advantage: Wraps the native API, so as API calls change, unless the WMI changed also you will (might) get the benefits. It will also save you some coding.
And richer data. Since programmers can write their own WMI providers, you can get data from third party software. That's what Microsoft is doing in their security center interface-getting data from third-party antivirus and firewall softwares.
Advantage of WMI: Can get info about remote machines as easily as current machine
And impersonation!
You may have your program run with a non-proviledged user, but access a remote machine by specifying credentials.
If it is for system scope
Advantage of WMI:
Do not need to implement additional driver efforts
Disadvantage of WMI:
Need BIOS to wrap code
it is only for Windows. there's no Linux inbox driver.
Related
I am programming an activation code for my application, I need to provide the key file with information about the licensed computer, I need to retrieve information about some devices like processor ID and DiskDrive Serial number, and the BIOS Serial as well ,, and so on with some devices, but these are the major ones.
I need to combine the method with another application programmed by another language so I cannot use WMI, but I can use winapi.
is there a way to fetch the physical data using winapi?if so, then how?
If you are able to call Windows API functions, then you can use WMI. After all, the WMI interface is part of the Windows API.
Take a look at the Win32_BIOS class and the PROCESSOR_POWER_INFORMATION structure.
Accessing motherboard information without WMI seems not to be doable with current means. Here you can find a similar question:
Access Motherboard information without using WMI
I'm doing various OS management and querying tasks using WMI, but it allways take a long time for first WMI call(10 to 15s).
When I tried few tools from sysinternals I found that they are so much faster and I want to know how is this possible.
For instance how can PsList tool returns result in under 2 second and for wmi it takes at least 15 seconds. Much of this time is used for authentication and not actual work, and next wmi query for the same machine is much faster.
Is possible to see the source code of sysinternals utilites ? Do they use WMI or direct win32 api calls ?
WMI has a lot of overhead: authentication/authorizing access to WMI namespaces/DCOM/RPC. It is designed for easy and secure management, not for performance.
Suggested reading:
WMI: Improving your WMI application performance in fan-out scenario
Now I'am working on a MFC program. What I want to know is the speed a process receive/send to the network. Suppose I have a process named chrome.exe, it may receive 1008B/s, send 2987B/s. I know I can get what I want in the Win 7 Resource Monitor. But how can I get those data in my program. Dose MFC or Win32api support this?
You can obtain this information, as well as a wealth of other performance data using WMI:
Monitoring Performance Data
This class is probably what you are looking for:
Win32_PerfFormattedData_Tcpip_NetworkInterface
From a native C++/MFC application, you'll access WMI through some COM interfaces
Have fun!
My company is looking at implementing a new VPN solution, but require that the connection be maintained programatically by our software. The VPN solution consists of a background service that seems to manage the physical connection and a command line/GUI utilty that initiates the request to connect/disconnect. I am looking for a way to "spy" on the API calls between the front-end utilty and back-end service so that our software can make the same calls to the service. Are there any recommended software solutions or methods to do this?
Typically, communications between a front-end application and back-end service are done through some form of IPC (sockets, named pipes, etc.) or through custom messages sent through the Service Control Manager. You'll probably need to find out which method this solution uses, and work from there - though if it's encrypted communication over a socket, this could be difficult.
Like Harper Shelby said, it could be very difficult, but you may start with filemon, which can tell you when certain processes create or write to files, regmon, which can do the same for registry writes and reads, and wireshark to monitor the network traffic. This can get you some data, but even with the data, it may be too difficult to interpret in a manner that would allow you to make the same calls.
I don't understand why you want to replace the utility, instead of simply running the utility from your application.
Anyway, you can run "dumpbin /imports whatevertheutilitynameis.exe" to see the static list of API function names to which the utility is linked; this doesn't show the sequence in which they're called, nor the parameter values.
You can then use a system debugger (e.g. Winice or whatever its more modern equivalent might be) to set breakpoints on these API, so that you break into the debugger (and can then inspect parameter values) when the utility invokes these APIs.
You might be able to glean some information using tools such as Spy++ to look at Windows messages. Debugging/tracing tools (Windbg, or etc.) may allow you to see API calls that are in process. The Sysinternals tools can show you system information to some degree of detail of usage.
Although I would recommend against this for the most part -- is it possible to contact the solution provider and get documentation? One reason for that is fragility -- if a vendor is not expecting users to utilize that aspect of the interface, they are more likely to change it without notice.
I've got a third-party program that's making WMI queries to local WMI providers (so it's not using DCOM, so packet-sniffers are out). I'd like to find out what queries these are.
It's also on XP, so the new Vista WMI tracing infrastructure is out, as well, unfortunately.
Any pointers?
Have you tried setting the WMI logging level to Verbose using wmimgmt.msc? (More info on the MSDN Logging WMI Activity page)
You should then see the queries logged to the %windir%\system32\wbem\logs\wbemcore.log file.
-dave
I believe that WMI uses DCOM for communication, you can use WireShark to do a packet capture of the DCOM packets. I believe that the dissector in WireShark for DCOM is usable though it still might help to reference this article (old, but should still be pertinent).
This will not work for WMI queries to localhost so you'll need to make sure it's querying a remote computer.
If you do want to log local queries take a look at this MSDN article on logging WMI queries.