#133847 - 2005-02-23 10:32 PM
Re: Detect amount of RAM / memory
|
Allen
KiX Supporter
Registered: 2003-04-19
Posts: 4562
Loc: USA
|
Thanks Doc. I think I just stick with my "bloated" code. 
|
|
Top
|
|
|
|
|
#133848 - 2005-02-25 12:26 AM
Re: Detect amount of RAM / memory
|
Glenn Barnas
KiX Supporter
Registered: 2003-01-28
Posts: 4401
Loc: New Jersey
|
Allen,
Feel free to champion your testing efforts!  Without testers (and testers that provide accurate feedback, to boot), the code we all post would not be as good as it is. It's also important for people who test the code to not be too involved with the actual coding, so they remain objective. Some of the best testers aren't coders at all. They like to experiment, and are anal about documenting the results. I work with a guy like that, and really enjoy reading his feedback.
On to your comment about the different logic working with the same data...
The last 4 bytes (8 hex chars) of the .Translated key is supposed to represent the physical memory ABOVE the 16 meg boundary. So, in theory, you can take the last 8 chars, reverse them in hex bytes (7-8, 5-6, 3-4, & 1-2) add 16 meg, and convert to decimal. This is what the code posted at the top does.
What .Translated actually contains is a physical memory map. Starting at the 65th character position, and every 32 characters after that, are 4 hex bytes (8 chars) representing physical memory within the machine. Oddly, the first 640K is not accounted for in this string!
You can see in my UDF that I take the 8 chars, from 65 to the end of the string, stepping in increments of 32, and add them together. Well, it's just a tad more complicated than that.
I assemble the hex values from the string. Starting at position 65+6 (71), I take two chars, then append the 2 chars from position 65+4 (69), then 2 chars from position 65+2 (67) and finally the two chars from position 65. This is because the hex bytes are stored "reverse" to what we need for arithmetic. So - "000f3cb0" in the string is translated to "b03c0f00". This hex value is converted to decimal, divided by 1024, then added to a subtotal. The division at this step is primarily to keep the value managable (in KBytes instead of Bytes) without worrying about program limitations and overflow.
This process is repeated as many times as necessary, shifting the starting point (65) by 32 each time, until we reach the end of the string. This gives a much more accurate report of the physical memory installed.
Once the entire .Translated string is parsed, the first 640K of memory is added back into the value, and the entire value is divided by 1024 again to represent the value in Meg.
Finally, by using CInt() instead of Int(), an even value is returned.
One of the most crucial pieces of logic here was provide by Richard H., which handles the Hex conversion without overflow - which causes negative values. We have a "string" of hex digits. By inserting an "&" in front of the string, we can place it into a Val() and get the decimal value. The problem here is that Val() has limits, and certain values are treated as negative once one of the bits is set. I haven't seen a way to cast the result of Val() as a double. Richard's elegant solution recognizes that each hex digit is a multiple of 16. So, for each character in the text string, we convert that ONE character to decimal and add it to a sum varialble, which is first multiplied by 16. Since the first time we do this the sum_var is zero, only the base value is added to the sum. Since the hex value is never more than 15, and the sum_var is declaed to be a double, we neverhav problems with overflow and negative results.
I hope this clears up any mystery about the two different approaches to using this data! Thanks again to Allen and all the testers, to Richard, for the elegant hex conversion routine. It really shows how much this is a community effort.
Glenn
_________________________
Actually I am a Rocket Scientist! 
|
|
Top
|
|
|
|
Moderator: Glenn Barnas, NTDOC, Arend_, Jochen, Radimus, Allen, ShaneEP, Ruud van Velsen, Mart
|
0 registered
and 601 anonymous users online.
|
|
|
