Hardware Info and Monitoring API's for Project Reunion

[AathifMahir]

Currently, we are limited with very less number of information on hardware on UWP api's that win32 had for decades.

List of things should be added sooner than later into a family of UWP APIs:

• CPU Information and Monitoring ( Clock Speed, OEM, TDP, Model No, Model Name, Number of Physical Cores, Technology, Etc..)
• Total System Memory and Installed System Memory
• GPU Information and Monitoring ( Clock Speed, OEM, TDP, Model No, Model Name, Number of Physical Cores, Technology, Etc..)
• Installed GPU Memory and Total Available GPU Memory

For Eg:
With current UWP APi's we can't even find the cpu information except number of logical cores and processor architecture

Proposal: [windows.system.processor / windows.system.gpu]

Summary

Hardware Info and Monitoring Api's for Project Reunion

Rationale

• These types of api's already present on all the major operating system on their native framworks that includes mobile operating systems
• These api's should be available during the release of windows 10 but didn't had it but its never too late.

Scope

Capability	Priority
Allow developers to capture information from foreground and background for use in their apps	Must
Provide a way for end users to revoke access to this capture information in Privacy Settings	Should
This proposal will allow developers to accomplish needs based on client systems	Could
This proposal will allow end users to have better system in the long run	Could

Important Notes

Open Questions

[jaigak]

You can already get all information about any hardware using the APIs in Windows.Devices.Enumeration namespace. You can get the information about the GPU, CPU, Network adapters, speakers, and more. Here's an example of how you might get the CPU name: var information = await Windows.Devices.Enumeration.DeviceInformation.FindAllAsync(@"System.Devices.InterfaceClassGuid:=""{97FADB10-4E33-40AE-359C-BEF029DBDD0}""");

[AathifMahir]

You can already get all information about any hardware using the APIs in Windows.Devices.Enumeration namespace. You can get the information about the GPU, CPU, Network adapters, speakers, and more. Here's an example of how you might get the CPU name: var information = await Windows.Devices.Enumeration.DeviceInformation.FindAllAsync(@"System.Devices.InterfaceClassGuid:=""{97FADB10-4E33-40AE-359C-BEF029DBDD0}""");

Device Enumeration does show only basic info, doesn't include information that i have provided above

Current Winrt system information api's limited these information only

[wjk]

Since we’re talking about adding APIs for getting hardware specs, I would like to see an easier way for an app to obtain the SMBIOS motherboard UUID. I use this particular piece of information to implement per-machine licensing and activation. Currently, the only (easy) way I can get this value is to run wmic.exe csproduct get uuid and parse its output. Thanks!

[jonwis]

@wjk - for licensing and device identification, check out HardwareToken and SystemIdentification. I think we'd want to think carefully about the privacy implications of adding these APIs to Project Reunion (cc @ptorr-msft )

[ptorr-msft]

FWIW I would not recommend HardwareToken due to complexity; you need to store IDs and track drift over time and determine if you feel good about the changes or not. SystemIdentification should be fine, as long as you have a way for customers to tell you "no really, I bought a new motherboard but it should still be using the same license." Nevertheless, SystemInformation doesn't work if your app isn't packaged (and if it is packaged, but you change Publisher ID, it will change). So there's still work to be done.

[AathifMahir]

@wjk - for licensing and device identification, check out HardwareToken and SystemIdentification. I think we'd want to think carefully about the privacy implications of adding these APIs to Project Reunion (cc @ptorr-msft )

That's true, Privacy implications should be considered as well but the current limitations with windows runtime Api's is major drawback as well. I hope once many of the system components taken out of the kernel with project Reunion. These kind of Api's won't be much of privacy concern.

[ptorr-msft]

I hope once many of the system components taken out of the kernel with project Reunion. These kind of Api's won't be much of privacy concern.

FYI the privacy concern isn't tied to being in the kernel or not; it's about limiting the tracking data apps can have about users. But the current APIs don't meet all requirements, so we welcome your feedback to make them better.

[ptorr-msft]

@AathifMahir can you help us by pointing to the Win32 / COM / WMI / etc. APIs that you would like to have WinRT equivalents for?

[AathifMahir]

@AathifMahir can you help us by pointing to the Win32 / COM / WMI / etc. APIs that you would like to have WinRT equivalents for?

https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/computer-system-hardware-classes

https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-computersystem

https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/

https://docs.microsoft.com/en-us/windows/win32/sysinfo/system-information-functions

https://docs.microsoft.com/en-us/windows/win32/sysmon/system-monitor-portal

https://docs.microsoft.com/en-us/windows/win32/diagnostics

Couple of specific Api's in the above list supports Windows Runtime but lots of them don't.

Here's an UWP app that I made using all the currently available Api's. You can see the limitations of current Api's with this app that app has very less hardware informations.
https://www.microsoft.com/en-us/p/specs-analysis-beta/9wzdncrdgx54#activetab=pivot:overviewtab

Note: I might missed some Api's that still works with Win32 / COM / WMI / etc..

Anyone, Feel free to share the list of system info and monitoring Api's here

[AathifMahir]

@ptorr-msft Anything else needed for this request?

[ptorr-msft]

No thanks, that's great information. I'm not sure where this will land in the roadmap though; for now you should stick to a "Win32"-style app for deep hardware diagnostics and information.

[mdtauk]

Any sensitive device details, could be put behind a permissions dialog for UWP apps

[77376]

@stevewri this issue still in need of triage. please take a look

[ghost]

@ptorr-msft
if proposals like Localhost access or this raises concerns about privacy , then introduce such information through the settings> about page , how are we advanced users supposed to gather such information in managed OSes like 10X?

if the OS is too much bent on not giving devs the access to these APIs , then why on earth UWP apps provide permissions dialog? what's the rationale behind it?

UWP preaches Users first then Devs, so it should be in reality too. let the User decide with his consent that what apps can track or gather information about his/her machine. UWP app's too much restrictions like this are not really acceptable for advanced users.

[jaigak]

@ecovio1 UWP is not that restrictive. I do think LocalHost should be allowed via brokering but there's no need for extra hardware info. You can already gather a lot of information about the hardware in UWP but apps should not rely on it extensively. UWP is about making Windows much better and more secure. Please don't make UWP as bad as Win32 but provide more functionality in a different way. Not all app needs full access to everything.

[jaigak]

For hardware info UWP developers can use EasClientDeviceInformation class, DeviceInformation class, GetSystemInfo (C++ function), Windows.System.Profile.SystemManufacturers namespace, Windows.System.Profile namespace. For GPU information you could use DirectX. Other additional monitoring and gathering info can be done with Win32 and no need for UWP.

[ghost]

UWP is not that restrictive.

okay go ask some developers if it really is or not. for example their answer will be something like this HandBrake/HandBrake#818 (comment) also not to mention a lot of general use cases UWP proposals are here.

UWP is about making Windows much better and more secure. Please don't make UWP as bad as Win32 but provide more functionality in a different way. Not all app needs full access to everything.

this is an issue of privacy . I don't get how get it down to "Security" concern. this is the winRT way of providing functionalities through permissions.

there is a reason why developers stick to win32 . win32 provides more general use cases functionalities where UWP is not. also I don't get how an OS platform becomes "more better" by removing functionalities. no wonder why windows RT was rejected by people.

[jaigak]

@ecovio1 Reason why Handbreak fails is they use older ways and APIs and needs to adopt modern ones. Also, you no longer need to enable developer mode to sideload Appx/MSIX package. Just double click and install. I do agree UWP has some limitations but do you research on alternatives before you propose something. Many limitations can be easily overcome.

[jaigak]

Loopback is something that can't be done so please continue proposing features which you want and let Microsoft decide whether to add it or not but for this proposal, there are alternatives already like using those APIs that I mentioned before. None of those provide CPU name but you could use CPUID for that. There's no WinRT API for GPU info, but DirectX provides it all and already available for UWP.