Re: Why is Base3.exe using 700+ K in windows task manager ?

From: The Half A Wannabee ("The)
Date: 01/18/04 

Date: Sun, 18 Jan 2004 13:14:50 +0100

"Beth" <BethStone21@hotmail.NOSPICEDHAM.com> wrote in message
news:LUoOb.7$7r2.6@newsfep3-gui.server.ntli.net...
> The Half A Wannabee wrote:

> No, not at all, the figure reported by Windows Task Manager is the
> _total_ amount of RAM an application uses...this figure is usually
> _greatly_ larger than the file size because it includes many things...

Yeah. It was a rather "stupid" question come to think of it. I am glad you
proved stupid aint possible back there. Ignorance is maybe a better word for
it.....I can at least hope ;-) But Beth, you would have to look that up in a
Dictionary ? Lol, on second thought, maybe not ;-) Hope I one day can write
less ambigues code than the sentences above.

> For example, if you call any Kernel32 API (which, basically, you more
> or less have to do, as "ExitProcess" and things like that are in
> Kernel32.DLL :) then Kernel32.DLL is _also_ loaded into RAM...if you
> have a GUI interface then User32.DLL is responsible for the user
> interface elements and GDI.DLL is needed for painting windows...hence,
> at least these three DLLs tend to be loaded into RAM for even the
> simplest GUI program...

Yeah. Its killing. The minimum ! Delphi app = 50K uses 1,1 mega on my
PC.(XP) Spasm gets away with 700K and yes, that is nice (given the bad
situation all apps suffer under windows). But as you say things can get
really bad once you start calling a few DLLs. My plan is to avoid the OS
whenever
possible.

- as
> you can probably tell - so they don't quite understand that some
> people might actually _object_ to this kind of "laissez faire"
> who-gives-a-crap attitude of theirs)...

They understand it, but given no real competition they dont have give a
crap. They pretty much follow your receipe for giving user a treat, at their
own expense.

"
· The threads of the process that called the DLL can use handles opened by a
DLL function. Similarly, handles opened by any thread of the calling process
can be used in the DLL function.
· The DLL uses the stack of the calling thread and the virtual address space
of the calling process.
· The DLL allocates memory from the virtual address space of the calling
process.
"

What the above mean *exactly* I dont know. I think it sound rather vague.
Who can tell where memory is really located in a virtual adress space ? Are
the virtual adress space a table of pointers to memory, located in the two
diffrent processes ? If the memory is allocated in the client application
process, why do you need an interface function to share memory with it ? I
never know what a virtual adress space really was. I allways "imagined" it
to be a table that contains offsets to actuall memory. In the virtual
address space, the "start" of memory can be e.g 0037000, but the real
adresse may be mapped to a totally diffrent area of ram. This has some
advantage in that you can actually store memory adresses to disk.....like
location of procedures...and stuff, as long as the app is not changed, this
will work in most cases.

Later I found this :

Variable Scope.
The default scope of DLL variables is the same as that of variables declared
in the application. Global variables in a DLL source code file are global to
each process using the DLL. Static variables have scope limited to the block
in which they are declared. As a result, each process has its own instance
of the DLL global and static variables by default.

So what does this mean ? that in order to share dynamic memory, you need an
interface procedure, but statics is directly accessible ?

>
> Note that, in fact, 700KB is pretty good in Windows terms for a more
> or less "do nothing" application...it kind of tells me that you're
> probably not running XP here because

I am running XP, see above that a DELPHI minimum app uses 1,1 meg

I've tried a few tricks with this
> using _real_ "do nothing" applications and you basically have lost at
> least 1MB to "overhead" and "OS fluff" and variables to keep track of
> windows and that kind of thing before you add any actual code to do
> anything...

The tools you use have a worse memory footprint than even delphi ? Must be
C++ then ?

>
> Mind you, _once_ all your DLLs are loaded in and your windows are
> created and so forth, then you only (usually) pay for this "overhead"
> once...that is to say, something like XP might automatically "eat" 1MB
> for an application before anything else actually happens in that
> program...BUT, once paid, the rest of the RAM usage does tend to be
> _application_ RAM "proper", so to speak...stuff you know about
> directly like your allocations, stack use and, yes, raw file size...

Yes, but imagine my other applications, that uses a WHOLE bunch of diffrent
apis and DirectX etc...
This is the reason why I created my own memmanager in delphi, but theres a
lot of loose ends. One must track
every GDI handle too, and calculate their memory footprints, and you "never"
really can say for 100% sure that you're own programs are not wasting some
memory somewhere = have a small, still not notisable bug. This suck. I heard
sometimes back that NT was certified for use in the army !!!! So help us
God.

>
> If you've not already downloaded OllyDbg, then it's a thoroughly
> recommended program...and,

Thank you...I actually have it on my disk...still unused...may this was the
reason I downed it .

>
> But, after such "bad news", you probably now want to hear the "good
> news" (yes, there is "some", though not a great deal ;)...open up your
> "Task Manager" once more and then go to the "Processes" panel, as you
> have already been doing...then, under "view", you'll find "select
> columns"...choose that and you should see a whole bunch of extra
> "statistics" you can ask about an application...choose "virtual memory
> size" as well as "memory usage"...you'll note that they _differ_
> (often substantially so, sometimes just by a small amount :)...

Yeah, I still feel the Task Manager "lies" a LOT. I have centralized GDI
objects creation in my delphi apps, and know exactly how many objects is
created for each type, fonts, icon, bmps, HDC, +++ I created debug wrappers
around _all_ the GDI creation routines, to count them myself, but it NEVER
even comes close to the reported number of GDI objects. (of course...this
might still be a bug in my part.....hulk...) And this is an application that
does not even use the VCL. I have killed off all package and VCL support.

>
> And the reason for this is that Windows employs "virtual memory"
> throughout that "reserved memory" doesn't necessarily equate to
> _actual physical RAM being used_...as an example, so you get the basic
> idea, it was strictly not completely accurate to say "loading DLLs"
> above...in fact, they are "mapped"...and there is a subtle but useful
> difference there...what this means is that the area is "reserved" for
> that DLL - Kernel32.DLL, for instance - but Windows actually uses
> "demand loading" (like most virtual-memory-based modern OSes do
> :)...that is (this is simplified a little for clear example :), the
> area for the DLL is simply "reserved" to begin with and effectively
> nothing has been loaded...and then your application makes a call to
> "ExitProcess" or whatever in Kernel32.DLL, which triggers a "page

Okey...but I think ExitProcess is a ~bad~ example.... ;-)
IMO call 'Kernel32.GetModuleHandleA' is a better one

I ain't saying it's perfect by any means but it's not as
> wasteful as would actually be more typical Microsoft, throwing away
> 1MB rather than the reasonably small 4KB...well, Intel set 4KB "pages"
> in the hardware itself...you know that if Microsoft made these chips,
> the page size would be 4MB or something and you'd need 1024GB just to
> load in the "loading screen" while it boots ;)...

Heheh. Dont you allready ?

>
> This is why, as Randy notes in his "taking complete control of HLA" -
> when questioning how _USEFUL_ it actually is to create "smallest
> programs" with HLA - if you create a 256 byte or 3KB ".com" or ".exe"
> file, if you click on "Properties" about that file, then (at least on
> all the newer Windows versions :), you'll see _two_ figures...on is
> "size" and the other is "size on disk"...the "size on disk" figure is
> _always a multiple of 4KB_ because of the "page size" and how the file
> system works with it and so forth...therefore, with the 3KB file, 1KB
> is "wasted" by Windows itself in just how it works and stores
> things...

Oki....dont know...but..seems like a weak argument on his account. From *my*
perspective.

>
> Not that this, to my mind, means that one shouldn't make programs
> smaller...this is _always_ a Good Thing...

Absolutely agree.

smaller programs: download
> faster, take up less disk space, take up less RAM, may _run faster_
> due to less "cache thrashing" (hey, I just made that term up and it's
> quite poetic and it rhymes too...a "cache thrash"...has a nice sound
> to it ;),

Yes it has a nice ring to it. Allmost se*ual overtones here.. ;-) You "cache
trash tramp". Want me to give you a nice cachetrash Beth ? no hands, I
promise.

...blah-blah-blah...a

Love ya Beth.

> small program that does the same job as a big program in far less
> space is always a better thing...just because it might be possible to
> always make things "byte perfect" or that people have "lots of RAM and
> hard drive" space is NOT really a valid excuse...indeed, if they have
> so much RAM and so much hard drive space then we can have _millions_,
> not just hundreds and thousands of things in the exact same space
> without having to "upgrade" anything in the slightest...

...

> The only real reason not to at least attempt to "tidy up" a program to
> make better use of available resources is when we have a "no choice"
> situation...

Fire your Boss. Fire him !

> 5 years on some "feature" and then finding out that only he and 7
> other people in the entire world were actually the only ones
> particularly interested in that "feature"

> Microsoft, for example, don't need to consistently win the "Hugi size
> contest" with every single thing that they write...but it would go an
> awful long way, in my opinion, if they simply, you know, just
> _TRIED_...just gave a crap and gave it a go...just to _TRY_ once...

>
> "_ALL_ we have is the attempt"
> [ Socrates or Plato or Aristotle, I can never remember
> which...Socrates, probably ;) ]
>
> Beth :)
>
>
>