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 22:34 > That's great. Not sure if you checked out my latest code but at least > you have something to choose from. No, what is the link to it? > 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. > Yeah, I looked into this Windows 7 64-bit version I just got and it is quite difficult to tap into. I was actually more concerned with the Registry and even there all the data seems to be scrambled (although in some easy manner) but it is not what it used to be even in XP. Plus, the amounts of memory available for Windows and the speed with which the code can be executed and written makes it very difficult to use a debugger on. I'm not sure if most of that Windows 7 stuff is well documented anyway? > 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) > ... This 'while' serves as both an 'if' in case pEnumerator is NULL and an infinite loop, which is actually a clever design. I didn't catch it initially, so I should give it to that guy at MS who wrote it :) > 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. > Yeah, I forgot to mention. I caught it too. (I never run someone's code without rewriting it. :)
From: David Schwartz on 1 Jun 2010 05:21 On May 31, 5:06 pm, "nki00" <lukkycha...(a)gmail.com> wrote: > 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); It's legal under any compiler. However, if returned is greater than zero, it will spin forever. The formatting is confusing you. It's equivalent to: while (enumClassObj) { /*statements*/ } while(returned > 0) /*no statement here*/ ; So the last 'while' repeats nothing at all. DS
From: Jackie on 1 Jun 2010 07:29 On 6/1/2010 04:26, nki00 wrote: > :) 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. I meant more like a small part of memory that the OS is using for itself that can't be used for anything else no matter what. > (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. HDD space is measured in base 10, meaning kilo is 1000 instead of 1024. It can cause quite some confusion for people when it's calculated differently here and there. That's why I say KiB (kibibytes - kilo binary bytes) like others also are doing, but I am not sure if it is a standard (it was not at the time I learned about it, I think). So if the label says 1.5 TB, let's try this: 1.5 / (2^40 / 10^12) = 1.364 TiB And that's the same number you gave. :) My laptop HDD is 200 GB. Looking in Windows, it says 186.31 GB. Let's try this: 186.31 * (2^30 / 10^9) = 200.0488 GB 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. > Yeah. I just use OllyDbg now, and a plugin which allows debugging 64-bit applications. I also have another plugin which changes the disassembler engine in case I need it. It's only a user-land debugger though. Plugins are FullDisasm and Olly Advanced. FullDisasm: http://www.beaengine.org/ - I have useed of some of these libraries, by the way. I usually get other plugins from OpenRCE: http://www.openrce.org/downloads/details/241/Olly_Advanced
From: Jackie on 1 Jun 2010 07:50 On 6/1/2010 04:34, nki00 wrote: > No, what is the link to it? > It was in an earlier reply I made. Just a few changes like in the pow() function (because it was measured in KiB instead of bytes). The rest was mostly the same changes in variable names and the WQL query. http://pastebin.com/hjDYhaKD > Yeah, I looked into this Windows 7 64-bit version I just got and it is quite > difficult to tap into. I was actually more concerned with the Registry and > even there all the data seems to be scrambled (although in some easy manner) > but it is not what it used to be even in XP. Plus, the amounts of memory > available for Windows and the speed with which the code can be executed and > written makes it very difficult to use a debugger on. I'm not sure if most > of that Windows 7 stuff is well documented anyway? > Not sure what you mean with the registry. And if you mean the system would run slower when you have a kernel debugger running, that's understandable. You should only use it when needed. I am only taking a guess here by saying Windows 7's internals probably would not be documented much in detail, other than general things like how processes work, security, etc. > This 'while' serves as both an 'if' in case pEnumerator is NULL and an > infinite loop, which is actually a clever design. I didn't catch it > initially, so I should give it to that guy at MS who wrote it :) Seems logical. I just saw it and used it without looking more into it as it is not production code anyways. > Yeah, I forgot to mention. I caught it too. (I never run someone's code > without rewriting it. :) All that code for such a small thing looks like pure junk to me so I would copy/paste and change the important parts to give it a try at first, then rewrite it later. I saw MS' example after already writing most of my (non-production) code from scratch.
From: Leo Davidson on 1 Jun 2010 08:38
On Jun 1, 12:29 pm, Jackie <Jac...(a)an.on> wrote: > HDD space is measured in base 10, meaning kilo is 1000 instead of 1024. > It can cause quite some confusion for people when it's calculated > differently here and there. That's why I say KiB (kibibytes - kilo > binary bytes) like others also are doing, but I am not sure if it is a > standard (it was not at the time I learned about it, I think). So if the Using "KiB" only resolves half the ambiguity. People still have to use context and guesswork to understand what someone means when they say "KB" (unless they've seen the same person use "KiB" somewhere else). That's why I can't get behind the "KiB" movement. It's advocated by people who want to reclaim the SI suffixes at any cost; not by people who want to actually resolve the ambiguity. In fact, the "KiB" movement is *adding* ambiguity not taking it away. (Until recently, if you saw "KB" in a user interface, and it wasn't measuring raw disk size or network throughput, you could be pretty sure it was a multiple of 1024. Now you can be less sure what it means in any context. The contexts where "KiB" is actually used were almost all unambiguously multiples of 1024 when "KB" was used in the past, so that hasn't helped much either. Not that it wasn't an unfortunate problem originally, but it's been made worse, not better.) If the "KiB" movement had also advocated new suffixes for the multiples of 1000 in computing contexts, with the aim of never using the ambiguous SI-style suffixes at all when discussing byte sizes, then I might have joined them. |