www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How to retrieve total amount of system RAM?

reply Benji Smith <dlanguage benjismith.net> writes:
I've been looking through Tango documentation for a function that'll 
tell me the total amount of RAM installed on the system, bu I can't find 
anything that looks helpful. Anyone have any suggestions?

Thanks!

--benji
Aug 13 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Benji Smith" wrote
 I've been looking through Tango documentation for a function that'll tell 
 me the total amount of RAM installed on the system, bu I can't find 
 anything that looks helpful. Anyone have any suggestions?

 Thanks!

This is something that is highly OS-dependant (and even different versions of the same OS do it differently). It's not something that Tango is likely to provide an abstract interface for. -Steve
Aug 13 2008
next sibling parent Benji Smith <dlanguage benjismith.net> writes:
Steven Schveighoffer wrote:
 "Benji Smith" wrote
 I've been looking through Tango documentation for a function that'll tell 
 me the total amount of RAM installed on the system, bu I can't find 
 anything that looks helpful. Anyone have any suggestions?

 Thanks!

This is something that is highly OS-dependant (and even different versions of the same OS do it differently). It's not something that Tango is likely to provide an abstract interface for. -Steve

Okay. I suppose I'll have to find the win32 & linux functions and write the wrappers myself. Thanks! --benji
Aug 13 2008
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 13 Aug 2008 22:39:36 +0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 "Benji Smith" wrote
 I've been looking through Tango documentation for a function that'll  
 tell
 me the total amount of RAM installed on the system, bu I can't find
 anything that looks helpful. Anyone have any suggestions?

 Thanks!

This is something that is highly OS-dependant (and even different versions of the same OS do it differently). It's not something that Tango is likely to provide an abstract interface for. -Steve

The same goes for IO (console I/O, file I/O, socket etc). Despite that it is present in Tango. I see a huge benefit of having (at least basic) OS statistics (like OS name, version, type, device presence and capabilities - RAM, CPU, etc) in the standard library. Isn't is supposed to eliminate custom platform-specific code?
Aug 13 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Denis Koroskin" wrote
 On Wed, 13 Aug 2008 22:39:36 +0400, Steven Schveighoffer
 "Benji Smith" wrote
 I've been looking through Tango documentation for a function that'll 
 tell
 me the total amount of RAM installed on the system, bu I can't find
 anything that looks helpful. Anyone have any suggestions?

 Thanks!

This is something that is highly OS-dependant (and even different versions of the same OS do it differently). It's not something that Tango is likely to provide an abstract interface for. -Steve

The same goes for IO (console I/O, file I/O, socket etc). Despite that it is present in Tango. I see a huge benefit of having (at least basic) OS statistics (like OS name, version, type, device presence and capabilities - RAM, CPU, etc) in the standard library. Isn't is supposed to eliminate custom platform-specific code?

Getting system memory isn't part of any standard that I know of (at least on the posix side), and there's not a large demand for it. The API for getting memory is decided on by OS implementors. What you would end up with is a list of versions for not only different OSes, but different versions of the OS. It's along the same lines as getting/setting network interface addresses. From experience (I have written a program to get system memory size), it is not trivial. And not always accurate. This is not to say that it couldn't be added. If you come up with something that looks reasonable, Tango might accept it. -Steve
Aug 13 2008
parent reply Benji Smith <dlanguage benjismith.net> writes:
Steven Schveighoffer wrote:
 Getting system memory isn't part of any standard that I know of (at least on 
 the posix side), and there's not a large demand for it.  The API for getting 
 memory is decided on by OS implementors.  What you would end up with is a 
 list of versions for not only different OSes, but different versions of the 
 OS.  It's along the same lines as getting/setting network interface 
 addresses.
 
 From experience (I have written a program to get system memory size), it is 
 not trivial.  And not always accurate.
 
 This is not to say that it couldn't be added.  If you come up with something 
 that looks reasonable, Tango might accept it.
 
 -Steve 

In win32, it looks like the GlobalMemoryStatus (for all non-NT versions) and GlobalMemoryStatusEx (for all NT-based versions), from kernel32.dll, would do the trick. http://msdn.microsoft.com/en-us/library/aa366586.aspx http://msdn.microsoft.com/en-us/library/aa366589(VS.85).aspx In linux, a bare-minimum solution would be to read from /proc/meminfo, even if there's no POSIX function. Of course, I'm talking out of my ass here, because my experience with C/C++ programming is very thin. I don't know, for example, how you'd check for the existence of the GlobalMemoryStatusEx function and fall back to GlobalMemoryStatus when it doesn't exist. It seems doable, though my own systems programming experience is probably too lacking for me to make it happen myself. --benji
Aug 13 2008
parent reply Wyverex <wyverex.cypher gmail.com> writes:
Benji Smith wrote:
 Steven Schveighoffer wrote:
 Getting system memory isn't part of any standard that I know of (at 
 least on the posix side), and there's not a large demand for it.  The 
 API for getting memory is decided on by OS implementors.  What you 
 would end up with is a list of versions for not only different OSes, 
 but different versions of the OS.  It's along the same lines as 
 getting/setting network interface addresses.

 From experience (I have written a program to get system memory size), 
 it is not trivial.  And not always accurate.

 This is not to say that it couldn't be added.  If you come up with 
 something that looks reasonable, Tango might accept it.

 -Steve 

In win32, it looks like the GlobalMemoryStatus (for all non-NT versions) and GlobalMemoryStatusEx (for all NT-based versions), from kernel32.dll, would do the trick. http://msdn.microsoft.com/en-us/library/aa366586.aspx http://msdn.microsoft.com/en-us/library/aa366589(VS.85).aspx In linux, a bare-minimum solution would be to read from /proc/meminfo, even if there's no POSIX function. Of course, I'm talking out of my ass here, because my experience with C/C++ programming is very thin. I don't know, for example, how you'd check for the existence of the GlobalMemoryStatusEx function and fall back to GlobalMemoryStatus when it doesn't exist. It seems doable, though my own systems programming experience is probably too lacking for me to make it happen myself. --benji

Id default to NT version since its Win 2000+, Then force version flag for non-NT, or dont support 95, 98, ME version(WIN_NO_NT) alias GlobalMemoryStatus GlobalMemoryStat; else alias GlobalMemoryStatusEx GlobalMemoryStat;
Aug 13 2008
parent reply Benji Smith <dlanguage benjismith.net> writes:
Wyverex wrote:
 Id default to NT version since its Win 2000+,
 Then force version flag for non-NT,  or dont support 95, 98, ME
 
 version(WIN_NO_NT)
   alias GlobalMemoryStatus GlobalMemoryStat;
 else
   alias GlobalMemoryStatusEx GlobalMemoryStat;

For this project, I'm trying to support all versions of windows, even those old beasties 95, 98, and ME. (The project is a library for reporting anonymous statistics about user behavior. Failing to support the older operating systems would create a bias in the reporting that I'd rather avoid.) And, if at all possible, I'd rather just compile a single binary, even if it means jumping through some weird hoops in writing my code. Is there any feasible solution? --benji
Aug 13 2008
next sibling parent reply Wyverex <wyverex.cypher gmail.com> writes:
Benji Smith wrote:
 Wyverex wrote:
 Id default to NT version since its Win 2000+,
 Then force version flag for non-NT,  or dont support 95, 98, ME

 version(WIN_NO_NT)
   alias GlobalMemoryStatus GlobalMemoryStat;
 else
   alias GlobalMemoryStatusEx GlobalMemoryStat;

For this project, I'm trying to support all versions of windows, even those old beasties 95, 98, and ME. (The project is a library for reporting anonymous statistics about user behavior. Failing to support the older operating systems would create a bias in the reporting that I'd rather avoid.) And, if at all possible, I'd rather just compile a single binary, even if it means jumping through some weird hoops in writing my code. Is there any feasible solution? --benji

Looks like you'd have to try to get the function address from the DLL.. http://msdn.microsoft.com/en-us/library/ms724832(VS.85).aspx
Aug 13 2008
parent reply Benji Smith <dlanguage benjismith.net> writes:
Wyverex wrote:
 Looks like you'd have to try to get the function address from the DLL..
 
 http://msdn.microsoft.com/en-us/library/ms724832(VS.85).aspx

Cool. Is there a D library that already provides basic DLL functionality, (wrapping the LoadLibrary and GetProcAddress functions)? Thanks again, --benji
Aug 13 2008
next sibling parent reply Wyverex <wyverex.cypher gmail.com> writes:
Benji Smith wrote:
 Wyverex wrote:
 Looks like you'd have to try to get the function address from the DLL..

 http://msdn.microsoft.com/en-us/library/ms724832(VS.85).aspx

Cool. Is there a D library that already provides basic DLL functionality, (wrapping the LoadLibrary and GetProcAddress functions)? Thanks again, --benji

//tango tango.sys.win32.UserGdi //winapi bindings win32.core //Phobos std.c.windows.windows
Aug 13 2008
parent Benji Smith <dlanguage benjismith.net> writes:
Wyverex wrote:
 //tango
 tango.sys.win32.UserGdi
 
 //winapi bindings
 win32.core
 
 //Phobos
 std.c.windows.windows

Very nice! Lots of useful stuff in there! --benji
Aug 13 2008
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Benji Smith wrote:

 Wyverex wrote:
 Looks like you'd have to try to get the function address from the DLL..
 
 http://msdn.microsoft.com/en-us/library/ms724832(VS.85).aspx

Cool. Is there a D library that already provides basic DLL functionality, (wrapping the LoadLibrary and GetProcAddress functions)?

tango.sys.SharedLib -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Aug 14 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Benji Smith" wrote
 Wyverex wrote:
 Id default to NT version since its Win 2000+,
 Then force version flag for non-NT,  or dont support 95, 98, ME

 version(WIN_NO_NT)
   alias GlobalMemoryStatus GlobalMemoryStat;
 else
   alias GlobalMemoryStatusEx GlobalMemoryStat;

For this project, I'm trying to support all versions of windows, even those old beasties 95, 98, and ME. (The project is a library for reporting anonymous statistics about user behavior. Failing to support the older operating systems would create a bias in the reporting that I'd rather avoid.) And, if at all possible, I'd rather just compile a single binary, even if it means jumping through some weird hoops in writing my code. Is there any feasible solution?

Usually, the non-EX versions of MS functions work fine on the newer platforms, they are just not preferred. Unless, of course, there is some resolution issue :) In that case, you can call the GetVersion function. http://msdn.microsoft.com/en-us/library/ms724439.aspx -Steve
Aug 13 2008
parent Benji Smith <dlanguage benjismith.net> writes:
Steven Schveighoffer wrote:
 Usually, the non-EX versions of MS functions work fine on the newer 
 platforms, they are just not preferred.
 
 Unless, of course, there is some resolution issue :)
 
 In that case, you can call the GetVersion function. 
 http://msdn.microsoft.com/en-us/library/ms724439.aspx
 
 -Steve 

Well, there's this litle tidbit: "On computers with more than 4 GB of memory, the MEMORYSTATUS structure can return incorrect information, reporting a value of 1 to indicate an overflow. If your application is at risk for this behavior, use the GlobalMemoryStatusEx function instead of the GlobalMemoryStatus function." http://msdn.microsoft.com/en-us/library/aa366772(VS.85).aspx --benji
Aug 13 2008