Confusion over total physical memory reporting
in [Win32 API]
|
Prev: How to C++ exe without installing C++ Redistributable Package
Next: Which Visual Studio for 64 Bit Apps
From: nki00 on 31 May 2010 20:12 "Jackie" <Jackie(a)an.on> wrote in message news:4c038680$0$25005$c3e8da3(a)news.astraweb.com... > Maybe I got it. > Please see the code here: http://pastebin.com/hjDYhaKD > > TotalVisibleMemorySize from Win32_OperatingSystem: > http://msdn.microsoft.com/en-us/library/aa394239(v=VS.85).aspx > "Total amount, in kilobytes, of physical memory available to the operating > system. This value does not necessarily indicate the true amount of > physical memory, but what is reported to the operating system as available > to it." > > I used pretty much the same code and it works at least. > > Output: > ---------------------------------------- > Total visible memory: > 4.00: GiB > 4.19: GB > ---------------------------------------- > > On my (64-bit) system, it is just slightly less than 4 GiB (4094.06 MiB). Hah, I just tried to alter your code with the Win32_OperatingSystem class and it gave a totally ridiculous result on my test Windows XP SP3 machine (32-bit): It gave out 2,620,396 bytes! The amount should be 4GiB. I did the following changes: 1. Line 33, the SQL string becomes "SELECT * FROM Win32_OperatingSystem" I used * just in case. 2. Line 50, the select statement becomes: hr = classObj->Get(L"TotalVisibleMemorySize", 0, &val, NULL, 0); The rest stays the same. Right?
From: nki00 on 31 May 2010 20:37 "nki00" <lukkycharm1(a)gmail.com> wrote in message news:hu1j8o$23u$1(a)speranza.aioe.org... > > "Jackie" <Jackie(a)an.on> wrote in message > news:4c038680$0$25005$c3e8da3(a)news.astraweb.com... >> Maybe I got it. >> Please see the code here: http://pastebin.com/hjDYhaKD >> >> TotalVisibleMemorySize from Win32_OperatingSystem: >> http://msdn.microsoft.com/en-us/library/aa394239(v=VS.85).aspx >> "Total amount, in kilobytes, of physical memory available to the >> operating system. This value does not necessarily indicate the true >> amount of physical memory, but what is reported to the operating system >> as available to it." >> >> I used pretty much the same code and it works at least. >> >> Output: >> ---------------------------------------- >> Total visible memory: >> 4.00: GiB >> 4.19: GB >> ---------------------------------------- >> >> On my (64-bit) system, it is just slightly less than 4 GiB (4094.06 MiB). > > > Hah, I just tried to alter your code with the Win32_OperatingSystem class > and it gave a totally ridiculous result on my test Windows XP SP3 machine > (32-bit): > > It gave out 2,620,396 bytes! The amount should be 4GiB. > > I did the following changes: > > 1. Line 33, the SQL string becomes "SELECT * FROM Win32_OperatingSystem" > I used * just in case. > > 2. Line 50, the select statement becomes: > hr = classObj->Get(L"TotalVisibleMemorySize", 0, &val, NULL, 0); > > The rest stays the same. Right? OK. I admit my mistake. I should've read the description better. That value of 2,620,396 is in KB's and that is closer to the truth, although again, even if it matches on my XP machine that method returns 3.96Gib and 4.15GB on the 64-bit Vista with 4.00 GB reported by Windows. They must be rounding it up. There's no other way?
From: Jackie on 31 May 2010 20:41 On 6/1/2010 02:06, nki00 wrote: > Yes, it is interesting and I actually like this result :) That's great. Not sure if you checked out my latest code but at least you have something to choose from. > Just curious, how do you debug it? Do you use something like SoftICE? I wanted to use OllyDbg but I realized that when you open "My Computer" (or similar) in Windows 7, a new process starts and then closes. Some "dllhost.exe". Maybe injects something into explorer.exe (wild guess here)? Would have imagined that the process would stick, so I am not sure if it's handled by explorer.exe entirely or what. Because of this, I realized it wasn't going to be super easy, so I didn't bother thinking more about it. On a 32-bit system at least, I guess one could use Syser which aims to be a SoftICE replacement. 64-bit.. I am not really sure. WinDbg, maybe? Never really got around to use it. Not sure if IDA also works as a kernel debugger. > Yeah, I noticed it. I learned something too. For instance, the following is > a valid and complilable construct in MS VC++: > > a.. while (enumClassObj) > a.. { > a.. //.... > a.. } > a.. while (returned> 0); > > > Both while's aren't actually necessary, by the way. The first one should've > been the 'if' to check if enumClassObj is not NULL. Then it can be an > infinite loop, like while(1) and the way you get out of it is when retuned > == 0, right? "while (returned> 0);" does nothing while (returned > 0). I also realized that enumClassObj remained unchanged but I saw that they used a while loop in an example code on MSDN, so I just did the same. IEnumWbemClassObject* pEnumerator = NULL; .... while (pEnumerator) .... http://msdn.microsoft.com/en-us/library/aa390423(v=VS.85).aspx After looking a bit more at their example, it seems like you should call enumClassObj->Release() in the end as well which I didn't do. Their example checks for errors as well.
From: Jackie on 31 May 2010 20:54 On 6/1/2010 02:37, nki00 wrote: > They must be rounding it up. There's no other way? Interesting. Maybe it's showing less because some of the memory is reserved for the OS or something. If you can somehow know how much is reserved, maybe you could sum those two values? I am interested in the answer myself. If you wish, you could try to find out whether it is likely and how to get that value. I need to get some sleep right now at least. :)
From: nki00 on 31 May 2010 22:26
"Jackie" <Jackie(a)an.on> wrote in message news:4c045a54$0$22937$c3e8da3(a)news.astraweb.com... > On 6/1/2010 02:37, nki00 wrote: >> They must be rounding it up. There's no other way? > > Interesting. Maybe it's showing less because some of the memory is > reserved for the OS or something. If you can somehow know how much is > reserved, maybe you could sum those two values? I am interested in the > answer myself. If you wish, you could try to find out whether it is likely > and how to get that value. I need to get some sleep right now at least. :) :) Yeah, I scoured all over the MSDN and the web as well and can't find any explanation as to where that memory might be going to. The strange thing is that I agree that such can be true with my Dell laptop (and Vista 64) that has a crappy video card and probably uses some of the system RAM. But the second machine is a desktop with Windows 7 64-bit, and a graphics card with dedicated 1GB of its own RAM, so there's clearly no need for that machine to use up any of the system RAM. IMHO, this is something new OS's do when the amount of RAM is right-on-the-nose, so to speak. (That's pretty much how they sell those new HDD's. Mine has 1.5 TB on the cover and Windows shows 1.36 TB.) I have no proof of it though. I wish I was better at debugging. I used to do it with SoftICE (while it still existed) but now it's a completely different ballgame with a 64-bit architecture. |