Prev: How to C++ exe without installing C++ Redistributable Package
Next: Which Visual Studio for 64 Bit Apps
From: Jackie on 30 May 2010 19:17
On 5/30/2010 23:19, Jackie wrote:
> Here it is: http://pastebin.com/u7fCZKd8

Forgot to mention that I have left out error-checking by intention to
make it easier to see what's going on.
From: nki00 on 30 May 2010 20:14
Thanks a lot! It did work, but now I've encountered two unexpected issues:

(1) If linked like that the code doesn't run on Windows 2000 Pro. (I can
probably fix it by using LoadLibrary and GetProcAddress)

(2) Even though the amount of RAM is reported correct on my previous test
machines, one Windows XP produced very interesting results. The machine has
4GB of RAM installed in it. It has a 32-bit version of XP with SP3 and if I
check it in My Computer properties it is reported as 3GB of RAM. But if I
run your updated program (with WMI Data) it is reported as 4Gib there.
GlobalMemoryStatusEx() returns it as 3GB as well. Have you ever encountered
anything like that?


From: nki00 on 30 May 2010 21:49
A follow-up to your code. This is an interesting WMI class that reports a
lot of stuff about the installed memory.

As I said in my post above, I encountered an issue with your sample not
running on Win2K (not a big deal for many people, but it's easily fixable).

If you attempt to run it as-it-is you'd get an error, saying that "The
ordinal 435 could not be located in the dynamic link library OLEAUT32.dll".
Luckily it has nothing to do with the WMI interfaces used. The ordinal 435
is a call to VarUI8FromStr(). Thus it would be wise to replace it with calls
available through the C run time:

//Where you're converting from VARIANT into UINT64
UINT64 capacity;
_bstr_t bs(val.bstrVal);
if(_stscanf(bs, _T("%I64d"), &capacity) == 1)
totalPhys += capacity;

On the sidenote, I was not able to retrieve the value from 'val' of the type
VARIANT in a 64-bit integer directly without first getting it as a string,
but that is OK. The overhead that it's causing is minuscule.

Thanks again!


From: Leslie Milburn on 31 May 2010 02:45

"nki00" <lukkycharm1(a)gmail.com> wrote in message
news:htuv0h$7ta$1(a)speranza.aioe.org...
> Thanks a lot! It did work, but now I've encountered two unexpected issues:
>
> (1) If linked like that the code doesn't run on Windows 2000 Pro. (I can
> probably fix it by using LoadLibrary and GetProcAddress)
>
> (2) Even though the amount of RAM is reported correct on my previous test
> machines, one Windows XP produced very interesting results. The machine
> has 4GB of RAM installed in it. It has a 32-bit version of XP with SP3 and
> if I check it in My Computer properties it is reported as 3GB of RAM. But
> if I run your updated program (with WMI Data) it is reported as 4Gib
> there. GlobalMemoryStatusEx() returns it as 3GB as well. Have you ever
> encountered anything like that?

From memory, 32 Bit Windows only sees 3GB maximum, anything over is ignored.
Not true of 64 Bit Windows.
hth


From: Ulrich Eckhardt on 31 May 2010 02:48
nki00 wrote:
> I'm trying to determine the total amount of physical RAM in the system
[...]
> It seems to work in Windows XP, but in Vista and Windows 7 I get the
> following discrepancies:
>
> RAM reported in msx.ullTotalPhys = 4252442624 bytes
> RAM resulting in strSz = "3.96 GB"
> RAM reported in the properties for My Computer = "Memory (RAM): 4.00 GB"

Those should be GiB. Anyway, is this on the same computer? I ask because
some computers actually use normal system RAM for graphics.

Uli

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: How to C++ exe without installing C++ Redistributable Package
Next: Which Visual Studio for 64 Bit Apps