digitalmars.D.learn - How to retrieve total amount of system RAM?
- Benji Smith (5/5) Aug 13 2008 I've been looking through Tango documentation for a function that'll
- Steven Schveighoffer (5/9) Aug 13 2008 This is something that is highly OS-dependant (and even different versio...
- Benji Smith (5/17) Aug 13 2008 Okay. I suppose I'll have to find the win32 & linux functions and write
- Denis Koroskin (8/21) Aug 13 2008 The same goes for IO (console I/O, file I/O, socket etc). Despite that i...
- Steven Schveighoffer (12/36) Aug 13 2008 Getting system memory isn't part of any standard that I know of (at leas...
- Benji Smith (15/29) Aug 13 2008 In win32, it looks like the GlobalMemoryStatus (for all non-NT versions)...
- Wyverex (7/43) Aug 13 2008 Id default to NT version since its Win 2000+,
- Benji Smith (10/17) Aug 13 2008 For this project, I'm trying to support all versions of windows, even
- Wyverex (3/24) Aug 13 2008 Looks like you'd have to try to get the function address from the DLL..
- Benji Smith (5/8) Aug 13 2008 Cool. Is there a D library that already provides basic DLL
- Wyverex (7/18) Aug 13 2008 //tango
- Benji Smith (3/11) Aug 13 2008 Very nice! Lots of useful stuff in there!
- Lars Ivar Igesund (7/14) Aug 14 2008 tango.sys.SharedLib
- Steven Schveighoffer (7/23) Aug 13 2008 Usually, the non-EX versions of MS functions work fine on the newer
- Benji Smith (8/17) Aug 13 2008 Well, there's this litle tidbit:
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
"Benji Smith" wroteI'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
Steven Schveighoffer wrote:"Benji Smith" wroteOkay. I suppose I'll have to find the win32 & linux functions and write the wrappers myself. Thanks! --benjiI'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
On Wed, 13 Aug 2008 22:39:36 +0400, Steven Schveighoffer <schveiguy yahoo.com> wrote:"Benji Smith" wroteThe 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?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
"Denis Koroskin" wroteOn Wed, 13 Aug 2008 22:39:36 +0400, Steven SchveighofferGetting 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"Benji Smith" wroteThe 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?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
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. -SteveIn 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
Benji Smith wrote:Steven Schveighoffer 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;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. -SteveIn 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
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
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).aspxId 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
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).aspxCool. Is there a D library that already provides basic DLL functionality, (wrapping the LoadLibrary and GetProcAddress functions)? Thanks again, --benji
Aug 13 2008
Benji Smith wrote:Wyverex wrote://tango tango.sys.win32.UserGdi //winapi bindings win32.core //Phobos std.c.windows.windowsLooks like you'd have to try to get the function address from the DLL.. http://msdn.microsoft.com/en-us/library/ms724832(VS.85).aspxCool. Is there a D library that already provides basic DLL functionality, (wrapping the LoadLibrary and GetProcAddress functions)? Thanks again, --benji
Aug 13 2008
Wyverex wrote://tango tango.sys.win32.UserGdi //winapi bindings win32.core //Phobos std.c.windows.windowsVery nice! Lots of useful stuff in there! --benji
Aug 13 2008
Benji Smith wrote:Wyverex wrote:tango.sys.SharedLib -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the TangoLooks like you'd have to try to get the function address from the DLL.. http://msdn.microsoft.com/en-us/library/ms724832(VS.85).aspxCool. Is there a D library that already provides basic DLL functionality, (wrapping the LoadLibrary and GetProcAddress functions)?
Aug 14 2008
"Benji Smith" wroteWyverex 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 -SteveId 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?
Aug 13 2008
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 -SteveWell, 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