Win32: Detect actual physical memory when /maxmem is present

[kihjin]

Hi, this is my first post here. I tried to read the Posting Guidelines but the page was blank. I'll try to use basic common sense, but please forgive (and inform) me if I commit an error in my post.

My goal is to detect the total amount of physical memory in the system regardless of any value set via /maxmem in boot.ini. The principle behind this technique is that if maxmem is set in boot.ini, and the value it is set to is less than what the system actually reports, then the system's memory is being artificially crippled. I don't need help parsing boot.ini or comparing, just where to look to get the hardware-level memory size.

I am working in (Visual Studio 2005) C++ in the Win32 environment. My target platform is Windows XP Service Pack 2. I actually have a solution in C# using .NET, but this does not work since .NET is unlikely to be pre-Installed on machines the program is used on.

The following is a C# snippet which doesn't seem to be restricted by /maxmem.

            ManagementObjectSearcher searcher =
               new ManagementObjectSearcher("SELECT * FROM Win32_PhysicalMemory");
            foreach (ManagementObject bank in searcher.Get()) {
                MessageBox.Show(" size = " + bank["Capacity"].ToString());
            } 
 

I've been attempting to translate this into C++ (sans .NET) without much success.

I've tried GetMemoryStatusEx; unfortunately what it returns for "total memory" is still restricted by maxmem. If I find a solution before anyone responds I'll post back.

[Banfa]

I have an idea about how this may be done, however I can't remember it. I need to get to the computer where I have the information stored which will happen tomorrow. Let us know if you find the answer before then.

[kihjin]

Thanks Banfa. No solution found yet.

[kihjin]

I still haven't figured this out. If you know of a solution please assist.

[ddougg]

Have you seen this post?
Reading physical memory size from the registry
http://blog.delphi-jedi.net/2009/03/20/324/