feat(win32): query physical memory POC

[provrb]

Note: This code does NOT compile or pass any sort of tests.

Description

Below is a proof of concept to obtain detailed information regarding the installed physical memory for Windows only. This feature utilizes the WMI crate to establish a connection with the COM library, then the Windows Management Instrumentation (WMI), and then query the WMI for all information regarding the Win32_PhysicalMemory class.

In theory, this works amazingly. You can view the original idea here (can't do a Rust playground unfortunately due to external crates). This concept was also referenced in issue #1260

However, we're met with a problem.

Problem

The function raw_query from the WMI crate requires that the template return value implement the trait serde::de::DeserializeOwned. Using #[cfg_attr(feature = "serde", derive(Deserialize)]), as implemented in other parts of the codebase, does not suffice, and the error persists.

Possible solutions and questions

As a result, I have a couple of questions for this feature to be implemented:

1. Do we make serde mandatory in the cargo.toml file?
2. Should we remove the WMI crate entirely and use the Windows API instead? Removing the entire serde problem.
3. Do we make this feature optional alongside serde?

Let me know, and I can start working on this right away!
Excuse me if there is an obvious workaround I've missed.

[GuillaumeGomez]

Overall, this seems like a new feature to have. However: from all the fields/information provided with this PoC, how many of them can be retrieved from other systems? Having a smaller but common ground would likely be a better start.

Also, the goal of sysinfo is to provide a unified (at least as much as possible) interface to query multiple systems information. If only windows support this feature, it makes it much less interesting.

In any case, if you're interested into iterating over this feature, I'm totally open to adding it with the conditions mentioned above.

[provrb]

To be honest, I'm unsure if anything like this would work across different operating systems. In general, Linux doesn't provide this much information unless you're sudo. I haven't had a chance to test with Mac.

If anything, it could probably be a Windows "extended memory details" feature. Any ideas?

[GuillaumeGomez]

I want to avoid features specific to one OS as much as possible. If there is no way to get at least some part of this feature in another OS than windows, then sorry but I'll likely reject it.

[provrb]

No problem, that's understandable!

[CarterLi]

FYI this is what Fastfetch does:

For most systems, you get physical memory device information from SMBIOS Type 17. The problem is how to acquire the raw SMBIOS binary data.

1. No root / admin permission required:
   1. Windows: GetSystemFirmwareTable. Querying WMI is 100 times slower than calling GetSystemFirmwareTable
   2. SunOS (Solaris, OpenIndiana, etc): read /dev/smbios
2. Root permission required:
   1. Linux: read /sys/firmware/dmi/tables/DMI
   2. FreeBSD: get entry address from kenv hint.smbios.0.mem then read /dev/mem
   3. NetBSD: get entry address from sysctl machdep.smbios then read /dev/smbios
3. Legacy BIOS only. You may get the entry address by searching for SMBIOS2 entry tag _SM_ in physical memory (/dev/mem) region 0xF0000-0xFFFFF
   1. OpenBSD: to access /dev/mem, you have to set kern.securelevel=-1 in /etc/sysctl.conf. Root permission is also necessary
   2. DragonFly: root needed
   3. Haiku: you can read /dev/mem directly since there is no root user at all (!)

---

On macOS it's different, as SMBIOS is either inaccessable (Intel) or not existed at all (Apple Silicon). Command system_profiler SPMemoryDataType -detailLevel full can be used instead. Note the result structure is different between Intel and Apple Silicon. Root is not required.