i work with c++ programming, I use an example for understanding main of my question.
Suppose, we want get current username in windows operation system, we can use follow code :
#include <windows.h>
#include <Lmcons.h>
char username[UNLEN+1];
DWORD username_len = UNLEN+1;
GetUserName(username, &username_len);
also, we can use wmi by follow the instruction explained on here and use Win32_ComputerSystem.UserName .
so, I hope you have fully understood, what's different between wmi and using api or any other way?
tank you for your response.
disadvantage :
Speed (mainly disadvantage)
if user turn off wmi service, wmi doesn't work.
advantage :
Wraps the native API
richer data, if you use wmi, you can get rich data
standardized, all the 'entities' are represented in a standardized way
These are the most important issues for using wmi.
Windows Management Instrumentation (WMI) is a set of specifications from Microsoft for consolidating the management of devices and applications in a network from Windows computing systems.
It is Microsoft implementation of Web-Based Enterprise Management.
WMI - Services are installed on Windows OS, but the service can be turned off. So if user disabled the service you wont get any information about the system. It is just for reporting purpose.
Whereas the APIs are ways thru which the Microsoft provides the access to the information to local Application and some how you can also manipulate the information provided.
WMI is query Based and its run very slow where as API are much faster to run .
Ex :- if you wanna check some System specification in your application before startup you should better use APIs . This will make you app Start faster.
WMI has advantage over api call WMI information is richer and easy to read where as to get that kind of same result we have to make several api calls .
The GetUserName API is merely a call to the function exported by the Advapi32.dll wich belongs to base kernel functions.
Using Win32_ComputerSystem class you are going to query Windows Management Instrumentation which is a complex and comprehensive infrastructure services which deals with most of the administrative tasks on Windows.
Posting a query to WMI involves much more resources and execution time so, if your goal is simply getting the user name, I suggest you to rely on the GetUserName API.
Related
I am using WMI to monitor certain hardware metrics, and specifically, I am using WMIExplorer.exe to find WMI classes and their instances(link to WMIExplorer.exe download: https://www.bleepingcomputer.com/download/wmi-explorer/). When I try to retrieve instances of the Win32_Fan class within the Root\cimv2 namespace, I get 0 instances. I am wondering why this is, since I do have a fan in my laptop. Do some fans/pieces of hardware not support retrieval through the WMI interface?
Note that I also tried the "Get-WmiObject -query "SELECT * FROM Win32_Fan" command in PowerShell to confirm there are no instances; there was no output from this command. I am simply wondering if there's any cause of an instance not showing up other than the hardware simply not being compatible with WMI. Or are there alternatives to finding fan speed without downloading third-party applications?(I want to get the fan speed within a personal C++ program).
Win32_Fan instances are provided by Windows\System32\wbem\cimwin32.dll. If you disassemble it you will see that it reads SMBIOS data (specifically entries with type 27) to get fan device information. So having no such instances means your system manufacturer did not write fan device info into SMBIOS, which is part of ROM.
Is there a way to access the netsh API (e.g. WIN32 API, WDK)?
For example, I'm trying to get mobile broadband information via netsh with the following command:
netsh mbn show interfaces
So I guess the real question is: what's the actual programmatic representation of netsh mbn show interfaces using Windows SDK methods?
An example in pseudo code:
MBN_DEVICE mbn;
GetMbnDev(&mbn);
char* Name = mbn.Name;
char* IMEI = mbn.IMEI;
char* DeviceId = mbn.DevId;
float signal = mbn.Signal;
What APIs (Win32/.Net/.Core) would I have to call to get the same result in a data structure like with the command above?
Some of the Microsoft tools use internal/undocumented APIs to perform their work so cloning them often require a bit of investigation.
The first step is to download Dependency Walker and take a look at the functions netsh imports. In this case it does not look like it imports a lot of network related stuff (on my Windows 8 machine) but it does import CoCreateInstance and GetProcAddress so you can set a breakpoint on both in your debugger, this should allow you to determine the functions/interfaces it ultimately ends up calling.
Even before you get that far you can simply Google "Mobile Broadband API", it should lead you to this MSDN page. You should take a look at those interfaces and see if they provide the information you are after...
I found the answer right on this link: https://social.msdn.microsoft.com/Forums/vstudio/en-US/2d810752-f647-41f6-9299-27b6adddd536/how-to-get-the-signal-strength-from-a-mobile-broadband-network-adapter-in-windows-7-using-c?forum=csharpgeneral
Add a mbnapi_uuid.lib to your C++ project (Linker->Input->Additional
Dependencies).
Add a reference to COM Tab for C# project: 'Definition: UCM Extension
API for MBN Type Library'
Did anyone manage to read a Windows machine's longtitude & latitude (GPS Position), without using .Net 4 libraries (Windows.Devices namespace) nor Javascript or other webbish code ?
There must be a native way.
The location sensor is in the Control Panel,
I could not find any API nor valid documentation which allows me to read off of it, I would like to avoid having Net framework 4.0 as a dependency and invoking a browser process in the background, just to read current user's location via javascript is a huge overhead in my opinion
The native Win32 API is the Sensor API. The Sensor API Programming Guide has some fairly detailed C++ examples.
Good article: Using Windows 7 Location API
(Google the above terms if the links ever break).
I am developing an application on Windows 10 that interacts with custom device drivers, the NTFS filesystem and DirectX 12. The app is a Windows Universal App written in C++, WRL, XAML and DirectX. For DirectX I have chosen a SwapChainPanel control and the DirectX portion of the app works great. The app is Sideloaded so I have a bit more freedom than an app that needs to go through the store
Unfortunately the Windows Universal Apps have a number of restrictions with regards to API calls. WinRt APIs are favored.
Here are a list of WinRt APIs to call to replace Win32 APIs:
https://msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx
In addition Windows Universal Apps can call Win32 APIs that are partitioned to the application (however not the ones partitioned to the desktop) as indicated in the documentation of each function and in the header file. Here is a link:
https://msdn.microsoft.com/en-us/library/windows/apps/br205762.aspx
In addition the Winsock APIs are now allowed from Windows Universal Apps
However I am still left without my favorite (and necessary APIs)
CreateFile()
ReadFile()
WriteFile()
DeviceIoControl()
CloseHandle()
In particular I need to read and write files to all locations without user interaction (and not to the locations restrict by the Windows Universal App Sandbox). In addition I need to send IOCTLs to my multiple device drivers.
I could abandon Windows Universal Apps and go with WPF. However I have a touch intensive application and I need touch to work really well. In addition I have to wonder about the lack of fixes and commitment to WPF on the behalf of Microsoft. I have considered other UI frameworks but none have been as promising as a Windows Universal App.
Microsoft has allowed two paths in Windows 10 for Universal Apps that will allow calling all Win32 functions (For side loaded apps).
Brokered Windows Runtime Component
and IPC though TCPIP
I have written a brokered windows runtime component and it works well. However the solution requires a C# app to be in the mix and I do not need/want that as I need fast load times of the app and do not want to pull the CLR in.
The next option is IPC through TCPIP. I would use Fast TCP Loopback as explained in the blog post: Fast TCP Loopback Performance and Low Latency with Windows Server 2012 TCP Loopback Fast Path. I would link to it but I am at my (very generous) two link limit for a first post.
I have a couple of questions:
1) If I go this route should I place the IPC between the XAML controls/buttons and the rest of the App? This would allow the rest of the app to be strictly Win32. Or should I just place the IPC between the app and calls to the specific functions I need that fall outside of the those allowed by Win32.
2) I have looked for a library or paper that has code and/or ideas for implementing IPC with TCPIP. However so far the papers that talk about IPC with TCPIP seem to simply describe winsock programming which is something I already know how to do. I would enjoy coding up IPC but would prefer a solution that has been tested. This needs to work flawlessly and I would rather have code with some time on it. Has anyone used or heard of code and or a design for IPC over TCPIP that is available to share?
I have an application developed in VB 6.0. I don't have access to its code. This application also exposes its functionality through certain API provided in its dlls. Is there a way for me to check what methods of the API the consumers of this application's API are calling across anywhere the API is deployed. I want a C# program to just sit in that target environment and intercept the calls made to that API and report it back to my service via a service. I wont be modifying the API or the code calling the API. Is this possible in C# or would I need to go with C++?
Update
Lets say for sake of simplicity, that its a simple VB application developed in VB 6 called SimpleAPP, and it has a button that displays records in a grid. It does this by calling a component CMPA.dll with a public method GetRecords(string ID) which returns an Array of records. I have another few applications called CustomerApp.exe and AnotherCustomerApp.exe which also have a reference to CMPA.dll and they both calls this same method to get the records. Now, I want to develop a program called Interceptor.exe that will actually sit in the environment where CustomerApp and AnotherCustomerApp is deployed and will log internally which of these two applications called that CMPA dll's public method GetRecords and also log what parameter it sent in and what results were retrieved.
I had to google to find the library that was on the tip of my tongue.
That googling turned up some interesting articles: a new to me 1999 Microsoft Research article called “Intercepting and Instrumenting COM Applications” and an Microsoft Systems Journal article from january 1999 that I do remember, “Building a Lightweight COM Interception Framework”.
The library you want is probably Microsoft Detours. I have only used it from C++, not from C#, and I have only used it for intercepting calls to Windows API functions, not COM methods, so I can’t guarantee that it’s well suited. But it's not exactly rocket science to interface these two languages, if needed.
If Detours doesn’t turn out to fill your needs, then look at the articles cited. Quite possibly they resulted in some framework you can use. And otherwise they have the information you need to build your own. You might then also check out if ParkPlace ever made what you want. There was once great interest in “cross concern“ functionality, and ParcPlace did some of the most interesting research, as I recall.